私が開発しているアプリケーションは、西ヨーロッパと東ヨーロッパの人々だけでなく、米国でも使用されます。入力をエンコードし、出力を UTF-8 文字セットでデコードしています。
私の混乱は、このメソッド String(byte[] bytes, String charsetName) を使用する場合です。実際には文字エンコーディングである場合、文字セット名として UTF-8 を提供します。そして、私のデフォルトのecndingはEclipseでCp1252として設定されています。
これは、米国で Java アプリケーションで Cp1252 を文字セット エンコーディングとして使用し、UTF-8 を文字セット名として使用して出力テキスト ファイルを作成した場合、ヨーロッパの人々はこのファイルを Java アプリケーションで読み取ることができ、逆に？
それらはエンコーディングです。Java が「エンコード」を意味するときに「文字セット」をあちこちで使用するのは残念ですが、今は修正するのが難しいです :( 厄介なことに、IANA は同じ間違いを犯しました .
実際、Unicode 用語では、おそらく最も正確な文字エンコーディング スキームです。
文字エンコーディング形式とバイトシリアル化。Unicode には、UTF-8、UTF-16、UTF-16BE、UTF-16LE、UTF-32、UTF-32BE、および UTF-32LE の 7 つの文字エンコード方式があります。
文字エンコーディング形式は次のとおりです。
文字セット定義から、データを表すために使用される実際のコード単位へのマッピング。
はい、Unicode では 7 つの文字エンコーディング形式しか定義されていないという事実が、これをさらに混乱させています。基本的に、ほとんどの開発者が知っておく必要があるのは、Java 用語の「文字セット」は、テキスト データ ( String、char[]) とバイナリ データ ( byte[]) の間のマッピングであるということだけです。
この二つは直接関係ないと思います。
Eclipse 設定は、作成/編集したテキスト ファイル (通常はソース コード) を Eclipse エディターが保存する方法を決定します。他のエディターを使用できるため、ファイルは他のエンコード方式で保存される場合があります。Java コンパイラがソース コードのコンパイルに問題がない限り、安全です。
これ
java String(byte[] bytes, String charsetName)
は、ファイルまたはネットワークから読み取ったデータをどのように解釈するかを処理する独自のアプリケーション ロジックです。異なる charsetName (本質的に異なる文字エンコード スキーム) は、バイト配列の解釈が異なる場合があります。
「文字セット」は、テキストが使用する文字のセットを意味します。UTF-8/16 の場合、文字セットは「すべて」の文字になります。他の人にとっては、必ずしもそうではありません。昔は、誰もが独自の文字セットとエンコード スキームを発明していました。この 2 つはほぼ 1 対 1 のマッピングでした。したがって、1 つの名前を使用して、文字セットとエンコード スキームの両方を参照できます。