ホームページ  >  記事  >  Java  >  Javaの中国語文字化けを解決する方法

Javaの中国語文字化けを解決する方法

伊谢尔伦
伊谢尔伦オリジナル
2016-11-26 09:55:391447ブラウズ

コンピューターの発展と普及に伴い、世界中の国が自国の言語や文字に適応するために独自のエンコード スタイルを設計するようになります。この混乱により、多くのエンコード方法が存在し、同じものになります。 2 進数は別の記号に解釈される場合があります。この非互換性の問題を解決するために、Unicode エンコーディングという素晴らしいアイデアが生まれました。 !

Unicode

Unicode は、Unicode、Unicode、および Unicode とも呼ばれ、各言語の各文字に統一された固有のコードを設定して、各言語の要件を満たします。クロス言語およびクロスプラットフォームのテキスト変換と処理。 Unicode は、世界中のすべての記号を含む「大きな文字コンテナ」と考えることができ、各記号には独自のエンコーディングがあり、文字化けの問題を根本的に解決します。したがって、Unicode はすべての記号のエンコードです [2]。

Unicode は、ユニバーサル文字セットの標準として開発され、書籍の形でも出版されました。これは、世界中のほとんどの書記体系を体系化してコード化する業界標準であり、コンピュータによる使用を容易にします。テキストを提示して処理します。 Unicode は現在も改訂され続けており、現在 100,000 文字以上が含まれており、業界で広く認識されており、コンピューター ソフトウェアの国際化およびローカリゼーションのプロセスで広く使用されています。

従来の文字エンコード方式の制限を解決するために Unicode が作成されたことはわかっています。従来のエンコード方式には、多言語環境をサポートできないという共通の問題があります。これは、インターネットのオープンな環境には適していません。許可された。現在、ほとんどすべてのコンピュータ システムは基本的なラテン文字をサポートしており、それぞれが他のさまざまなエンコード方式をサポートしています。これらと互換性を持たせるために、Unicode は ISO 8859-1 で定義された文字用に最初の 256 文字を予約しています。そのため、既存の西ヨーロッパ言語の変換には特別な考慮が必要なく、同じ文字が多数必要になります。文字は、異なる文字コード Go に繰り返しエンコードされるため、情報を失うことなく、古くて複雑なエンコード方式を Unicode エンコードに直接変換したり、Unicode エンコードから直接変換したりすることができます [1]。

実装方法

文字のUnicodeエンコードは決まっていますが、実際の送信プロセスでは、異なるシステムプラットフォームの設計が必ずしも一致していないことや、スペースの節約を目的として、Unicodeエンコードの実装が行われます。違う。 Unicode の実装は、Unicode Transformation Format (略して UTF) と呼ばれます [1]。

Unicode は文字セットであり、主に UTF-8、UTF-16、UTF-32 の 3 つの実装方法があります。現在は UTF-8 が主流の実装方式であるため、UTF-16 や UTF-32 が使用されることは比較的少ないため、以下では主に UTF-8 を紹介します。

UCS

Unicode に関して言えば、UCS について知る必要があるかもしれません。 UCS (Universal Character Set) は、ISO が策定した ISO 10646 (または ISO/IEC 10646) 規格で定義された標準文字セットです。他のすべての文字セットが含まれており、他の文字セットとの双方向の互換性が保証されています。つまり、テキスト文字列を UCS 形式に変換してから元のエンコーディングに戻しても、情報が失われることはありません。

UCS は各キャラクターにコードを割り当てるだけでなく、正式な名前も付けます。 UCS または Unicode 値を表す 16 進数は通常、先頭に「U+」が付けられます。たとえば、「U+0041」は文字「A」を表します。

リトルエンディアンとビッグエンディアン

各システム プラットフォームの設計が異なるため、一部のプラットフォームでは文字の理解が異なる場合があります (バイト オーダーの理解など)。これにより、バイト ストリームが別のコンテンツとして解釈されます。たとえば、特定の文字の 16 進値は 4E59 で、これは 4E と 59 に分割されます。MAC で読み取られると、下位ビットから始まり、MAC がバイト ストリームに遭遇すると、次のように解析されます。 594E. 検索 文字は「Kui」ですが、Windows プラットフォームでは上位バイト (4E59) から読み取りが開始され、見つかった文字は「B」です。つまり、Windows プラットフォームで保存された「B」は、MAC プラットフォームでは「Kui」になります。これは必然的に混乱を引き起こすため、Unicode エンコードではビッグ エンディアンとリトル エンディアンを区別するために 2 つの方法が使用されます。つまり、最初のバイトが最初に来る (ビッグ エンディアン モード)、2 番目のバイトが最初に来る (リトル エンディアン モード)。そこで、この時点で疑問が生じます。コンピュータは、特定のファイルがどのエンコード方式を使用しているかをどのようにして知るのでしょうか?

Unicodeの仕様では、各ファイルの先頭にエンコード順序を示す文字を付加することが規定されており、この文字の名前は「ZERO WIDTH NO-BREAK SPACE」と呼ばれ、FEFFで表されます。これはちょうど 2 バイトであり、FF は FE より 1 大きい値です。

テキスト ファイルの最初の 2 バイトが FE FF の場合は、ファイルがビッグ エンディアン モードを使用していることを意味し、最初の 2 バイトが FF FE の場合は、ファイルがスモール エンディアン モードを使用していることを意味します。

UTF-8

UTF-8 は Unicode の可変長文字エンコーディングであり、1 ~ 4 バイトを使用して記号を表すことができ、バイト長は記号によって異なります。 Unicode 標準の任意の文字を表すために使用でき、そのエンコードの最初のバイトは ASCII と互換性があるため、ASCII 文字を処理する元のシステムをそのまま、またはわずかな変更のみで引き続き使用できます。したがって、電子メール、Web ページ、およびテキストを保存または送信するその他のアプリケーションでは、このエンコーディングが徐々に推奨されるようになりました。

UTF-8 は、各文字をエンコードするために 1 ~ 4 バイトを使用します。エンコード規則は次のとおりです。

1) シングルバイト記号の場合、バイトの最初のビットは 0 に設定され、次の 7 ビットは 0 に設定されます。この記号はユニコードコードです。したがって、英語の文字の場合、UTF-8 エンコーディングと ASCII コードは同じです。

2) n バイトのシンボル (n>1) の場合、最初のバイトの最初の n ビットが 1 に設定され、n+1 番目のビットが 0 に設定され、後続のバイトの最初の 2 ビットが に設定されます。 10.言及されていない残りの 2 進ビットはすべて、このシンボルの Unicode コードです。

変換表は次のとおりです:

Javaの中国語文字化けを解決する方法

上記の変換表によれば、UTF-8の変換エンコード規則を理解するのが非常に簡単になります: 最初のバイトの最初のビットが0の場合、それは次のことを意味します。 byte 1 の場合は文字のみで、連続する 1 の数はその文字が占めるバイト数を示します。

UTF-8 エンコーディング [3] を実装する方法を示すために、漢字「ヤン」を例に挙げます。

「strict」の Unicode は 4E25 (100111000100101) であることが分かります。上記の表によれば、4E25 は 3 行目 (0000 0800-0000 FFFF) の範囲にあることがわかります。 「strict」の 8 エンコードには 3 バイトが必要です。つまり、形式は「1110xxxx 10xxxxxx 10xxxxxx」です。次に、「strict」の最後の 2 進数から始めて、形式の x を後ろから前に埋め、余分なビットを 0 で埋めます。このようにして、「Yan」の UTF-8 エンコーディングは「11100100 10111000 10100101」であることがわかり、16 進数に変換すると E4B8A5 になります。

Unicode と UTF-8 間の変換

上記の例から、「Yan」の Unicode コードは 4E25 で、UTF-8 エンコーディングは E4B8A5 であることがわかります。これらは異なるため、プログラムによって変換する必要があります。これを実現するには、Windows プラットフォームで最も簡単で直感的な方法はメモ帳です。

「エンコーディング(E)」の下部には、ANSI、Unicode、Unicodeビッグエンディアン、UTF-8の4つのオプションがあります。

ANSI: メモ帳のデフォルトのエンコード方式は、英語ファイルの場合は ASCII エンコード、簡体字中国語ファイルの場合は GB2312 エンコードです。注: 異なる ANSI コードは相互に互換性がありません。情報が国際的に交換される場合、2 つの言語に属するテキストを同じ ANSI エンコード テキストに保存することはできません。つまり、UCS-2 エンコード方式を直接使用することはできません。 2 バイトには文字の Unicode コードが格納されます。この方式は「リトルエンディアン」方式です。

Unicode ビッグ エンディアン: UCS-2 エンコード方式、「ビッグ エンディアン」方式。

UTF-8: 上記を読んでください (UTF-8)。

> Viewer" を実行すると、次の結果が得られます。

ANSI: 2 バイトの「D1 CF」は、まさに「strict」の GB2312 エンコードです。

Unicode: 4 バイト「FF FE 25 4E」。「FF FE」はスモールエンドストレージ方式を表し、実際のエンコードは「25 4E」です。

Unicode ビッグ エンディアン: 4 バイト「FE FF 4E 25」、「FE FF」はビッグエンドの格納方法を表し、実際のエンコードは「4E 25」です。

UTF-8: エンコードは 6 バイト「EF BB BF E4 B8 A5」です。最初の 3 バイト「EF BB BF」は、これが UTF-8 エンコードであることを示し、最後の 3 バイト「E4B8A5」は「厳密」です。特定のエンコードの場合、その格納順序はエンコード順序と一致します。


声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。