UTF-8 と GBK の違いは何ですか UTF8 GB2312

この記事の内容は、UTF-8 と GBK UTF8 GB2312 の違いに関するものです。必要な方は参考にしていただければ幸いです。

UTF-8: Unicode TransformationFormat-8bit、BOM が許可されますが、通常は BOM は含まれません。これは、国際文字を解決するために使用されるマルチバイト エンコーディングであり、英語の場合は 8 ビット (つまり 1 バイト)、中国語の場合は 24 ビット (3 バイト) を使用します。 UTF-8 には、世界中のすべての国で使用されている文字が含まれており、高い汎用性を持っています。 UTF-8 でエンコードされたテキストは、UTF8 文字セットをサポートするさまざまな国のブラウザで表示できます。たとえば、UTF8 エンコーディングであれば、外国人の英語版 IE でも中国語を表示でき、IE の中国語サポート パッケージをダウンロードする必要がありません。

GBK は、国家規格 GB2312 をベースに拡張した GB2312 と互換性のある規格です。 GBK のテキスト エンコーディングは 2 バイトで表されます。つまり、中国語と英語の文字は両方とも 2 バイトで表され、中国語の文字を区別するために最上位ビットが 1 に設定されます。 GBK にはすべての中国語の文字が含まれており、UTF8 よりも汎用性が低いですが、GBK よりも大きなデータベースを占有します。

GBK、GB2312 などは、Unicode エンコードを通じて UTF8 に変換する必要があります:
GBK、GB2312--Unicode--UTF8
UTF8--Unicode--GBK、GB2312

pCSS5 は単純に機能します:

1、GBK は通常、簡体字中国語文字のみをサポートする GB2312 エンコーディングを指します

2、utf は通常 UTF-8 を指し、簡体字中国語文字、繁体字中国語文字、英語、日本語、韓国語、その他の言語をサポートします (より広範囲の言語をサポート)文字)

3. 中国では通常、UTF-8 と gb2312 が使用されます。

具体的な詳細は次のとおりです。 Web サイトやフォーラムの場合、英語の文字が多い場合は、スペースを節約するために UTF-8 を使用することをお勧めします。ただし、多くのフォーラム プラグインは現在、一般に GBK のみをサポートしています。

エンコードの違いを詳しく解説

簡単に言うと、unicode、gbk、ビッグファイブコードがエンコードされた値で、utf-8、uft-16などはその値を表現したものです。前の 3 つのコードは互換性がありますが、同じ漢字でも 3 つのコード値はまったく異なります。たとえば、「中国語」の uncode 値は gbk の uncode 値と異なり、uncode が a040、gbk が b030 であり、その値を表現する形式が uft-8 コードであるとします。 utf-8 のコードは完全に uncode 専用にまとめられています。GBK を UTF-8 に変換したい場合は、まず uncode に変換してから utf-8 に変換すれば大丈夫です。

詳しくは以下の記事をご覧ください。

Unicode エンコーディングについて説明し、UCS、UTF、BMP、BOM、その他の用語について簡単に説明します

これは、プログラマーによってプログラマーのために書かれた興味深い読み物です。いわゆる「楽しい」とは、これまでよくわからなかった概念を簡単に理解し、知識を向上させることができることを意味します。これは、RPG ゲームのアップグレードに似ています。この記事を構成する動機は 2 つの質問です:

質問 1:

Windows メモ帳の「名前を付けて保存」を使用して、GBK、Unicode、Unicode ビッグ エンディアン、および UTF -8 変換で保存します。これらのエンコード方式の間で。これも txt ファイルです。Windows はエンコード方式をどのように識別するのでしょうか?
私はずっと前に、Unicode、Unicode bigendian、および UTF-8 でエンコードされた txt ファイルの先頭に、FF、FE (Unicode)、FE、FF (Unicode bigendian) というバイトがさらにいくつかあることを発見しました。 、EF、BB、BF (UTF-8)。しかし、これらのマーカーはどのような基準に基づいているのでしょうか?

質問 2:

最近、UTF-32、UTF-16、UTF-8 の相互変換を実現する ConvertUTF.c をインターネット上で見かけました。 Unicode エンコード (UCS2)、GBK、および UTF-8 エンコード方式についてはすでに知っています。しかし、このプログラムは私を少し混乱させ、UTF-16 と UCS2 の関係が何であるかを思い出せません。 関連情報を確認した結果、これらの問題が最終的に明確になり、Unicode についての詳細も学びました。記事を書いて、同じような質問を持つ友人に送ってください。この記事はできる限りわかりやすく書かれていますが、読者はバイトとは何か、16 進数とは何かを知っている必要があります。

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

ビッグ エンディアンとリトル エンディアンは、CPU がマルチバイト数値を処理するための異なる方法です。たとえば、文字「汉」の Unicode エンコードは 6C49 です。では、ファイルに書き込むときは、6C を前に書くべきでしょうか、それとも 49 を前に書くべきなのでしょうか?先頭に6Cが書かれている場合はビッグエンディアンです。先頭に49が書かれている場合はリトルエンディアンです。

「エンディアン」という言葉は、「ガリバー旅行記」に由来しています。リリパットの内戦は、ビッグエンディアンとリトルエンディアンのどちらの卵を割るかによって引き起こされ、その結果、6人の皇帝が命を落とし、もう1人が王位を失いました。

一般的にエンディアンを「バイトオーダー」と訳し、ビッグエンディアンとリトルエンディアンを「ビッグエンド」「リトルエンド」と呼びます。

1. 文字エンコーディング、内部コード、そしてちなみに中国語の文字エンコーディング
文字はコンピュータで処理される前にエンコードされなければなりません。コンピュータで使用されるデフォルトのエンコード方式は、コンピュータの内部コードです。初期のコンピューターでは、中国語の文字を処理するために 7 ビット ASCII エンコーディングを使用し、簡体字中国語用には GB2312 を、繁体字中国語用には big5 を設計しました。

GB2312 (1980) には、6763 個の漢字と 682 個のその他の記号を含む、合計 7445 文字が含まれています。漢字領域の内部コード範囲は上位バイトが B0 ～ F7、下位バイトが A1 ～ FE で、占有コードビットは 72*94=6768 です。このうち空席はD7FA～D7FEの5名です。

GB2312 がサポートする中国語の文字が少なすぎます。 1995 年の漢字拡張仕様 GBK1.0 には 21,886 個の記号が含まれており、漢字領域と図形記号領域に分かれています。漢字エリアには 21003 文字が含まれます。

ASCII、GB2312 から GBK まで、これらのエンコード方式には下位互換性があります。つまり、これらのスキームでは同じ文字は常に同じエンコードを持ち、後の標準ではさらに多くの文字がサポートされます。これらのエンコードでは、英語と中国語を均一に処理できます。中国語のエンコードを見分ける方法は、上位バイトの最上位ビットが 0 ではないことです。プログラマがこれらを何と呼ぶか​​によると、GB2312 と GBK は両方とも 2 バイト文字セット (DBCS) に属します。

2000 年の GB18030 は、GBK1.0 に代わる公式の国家規格です。この標準には、27,484 の漢字のほか、チベット語、モンゴル語、ウイグル語、その他の主要な少数民族言語が含まれています。漢字語彙に関しては、GB18030 では GB13000.1 の 20902 文字に CJK 拡張 A (Unicode コード 0x3400-0x4db5) の 6582 文字が追加され、合計 27484 文字の漢字が収録されています。

CJK は中国、日本、韓国を意味します。コードビットを節約するために、Unicode は中国、日本、韓国の 3 つの言語の文字を統一してエンコードします。 GB13000.1 は ISO/IEC 10646-1 の中国語版であり、Unicode 1.1 に相当します。

GB18030 のエンコーディングは、シングルバイト、ダブルバイト、および 4 バイト方式を採用しています。このうち、シングルバイト、ダブルバイト、GBKは完全互換です。 4 バイトエンコーディングのコードビットには、CJK 拡張子 A の 6582 文字の漢字が含まれています。たとえば、GB18030 の UCS 0x3400 のエンコーディングは 8139EF30 にする必要があり、GB18030 の UCS 0x3401 のエンコーディングは 8139EF31 にする必要があります。

Microsoft は GB18030 用のアップグレード パッケージを提供していますが、このアップグレード パッケージは、CJK 拡張子 A: 新曲王朝-18030 の 6582 中国語文字をサポートする新しいフォント セットのみを提供しており、内部コードは変更されません。 Windows の内部コードは GBK のままです。

ここにいくつかの詳細があります:

GB2312 の元のテキストは依然として位置コードであり、位置コードから内部コードまで、上位バイトと下位バイトに A0 を追加する必要があります。それぞれ。

どの文字エンコーディングでも、コーディング単位の順序はエンディアン スキームによって指定され、エンディアンとは関係ありません。たとえば、GBK のコーディング単位はバイトであり、漢字を表すには 2 バイトが使用されます。これら 2 バイトの順序は固定されており、CPU のバイト順序には影響されません。 UTF-16 のエンコード単位はワード (全角) であり、ワード間の順序はエンディアンによって決まります。 UTF-16は後で導入されます。

GB2312 の 2 バイトの最上位ビットは両方とも 1 です。ただし、この条件を満たすコード ポイントは 128*128=16384 個だけです。したがって、GBKおよびGB18030の下位バイトの最上位ビットは1ではない可能性があります。ただし、これは DBCS 文字ストリームの解析には影響しません。DBCS 文字ストリームを読み取るとき、上位ビットが 1 であるバイトが見つかった限り、次の 2 バイトは、下位バイトとは何ですか。

2. Unicode、UCS および UTF
前述したように、ASCII、GB2312、GBK から GB18030 までのエンコード方式には下位互換性があります。 Unicode は ASCII とのみ互換性があり (より正確には、ISO-8859-1 と互換性があります)、GB コードとは互換性がありません。たとえば、文字「汉」の Unicode エンコードは 6C49 ですが、GB コードは BABA です。

Unicodeも文字コード化方式ですが、国際機関によって設計された世界中のすべての言語に対応できるコード化方式です。 Unicode の学名は「UniversalMultiple-Octet Coded Character Set」であり、UCS と呼ばれます。 UCS は、「Unicode CharacterSet」の略称として見ることができます。

Wikipedia (http://zh.wikipedia.org/wiki/) によると: 歴史的には、Unicode を独立して設計しようとした組織が 2 つありました。それは、国際標準化機構 (ISO) とソフトウェア製造会社です。ビジネス協会 (unicode.org)。 ISO は ISO 10646 プロジェクトを開発し、Unicode コンソーシアムは Unicode プロジェクトを開発しました。

1991 年頃、双方は世界が 2 つの互換性のない文字セットを必要としていないことを認識しました。そこで彼らは、双方の作業を統合し、協力して単一のコーディング リストを作成し始めました。 Unicode2.0 以降、Unicode プロジェクトでは ISO 10646-1 と同じフォントが使用されます。

現在、両方のプロジェクトがまだ存在しており、それぞれの標準を独立して発行しています。 Unicode コンソーシアムの最新バージョンは、2005 年の Unicode 4.1.0 です。 ISO の最新規格は ISO 10646-3:2003 です。

UCS はエンコード方法のみを規定しており、このエンコードを送信または保存する方法は規定していません。たとえば、文字「中国語」の UCS エンコーディングは 6C49 です。このエンコーディングを送信および保存するには、4 つの ASCII 数値を使用できます。また、それを表すために、UTF-8 エンコーディングを使用することもできます。重要なのは、コミュニケーションの双方の当事者が同意する必要があるということです。 UTF-8、UTF-7、および UTF-16 はすべて広く受け入れられているソリューションです。 UTF-8 の特別な利点は、ISO-8859-1 と完全な互換性があることです。 UTFとは「UCS Transformation Format」の略称です。

IETF の RFC2781 および RFC3629 は、RFC の一貫したスタイルで UTF-16 および UTF-8 のエンコード方式を明確、簡潔かつ厳密に記述しています。いつも忘れてしまうのですが、IETF は Internet Engineering Task Force の略称です。ただし、IETF によって維持されている RFC は、インターネット上のすべての仕様の基礎です。

2.1. 内部コードとコード ページ
現在、Windows カーネルはすでに Unicode 文字セットをサポートしているため、カーネルは世界中のすべての言語をサポートできます。ただし、既存のプログラムやドキュメントの多くは GBK などの特定の言語エンコーディングを使用しているため、Windows が既存のエンコーディングをサポートせずにすべて Unicode を使用することは不可能です。

Windows はコード ページを使用して、さまざまな国や地域に適応します。コード ページは、前述の内部コードとして理解できます。 GBK に対応するコード ページは CP936 です。

Microsoft は GB18030: CP54936 のコード ページも定義しています。ただし、GB18030 には 4 バイト エンコーディングがいくつかあり、Windows コード ページは 1 バイトと 2 バイトのエンコーディングのみをサポートしているため、このコード ページは実際には使用できません。

3、UCS-2、UCS-4、BMP
UCS には、UCS-2 と UCS-4 の 2 つの形式があります。名前が示すように、UCS-2 は 2 バイトでエンコードされ、UCS-4 は 4 バイトでエンコードされます (実際には 31 ビットのみが使用され、最上位ビットは 0 である必要があります)。簡単な数学ゲームをやってみましょう。

UCS-2 には 2^16=65536 コード ポイントがあり、UCS-4 には 2^31=2147483648 コード ポイントがあります。

UCS-4 は、最上位ビットに応じて 2^7=128 のグループに分割され、最上位ビットは 0 になります。各グループは、次に高いバイトに基づいて 256 プレーンに分割されます。各プレーンは 3 番目のバイトに基づいて 256 行 (行) に分割され、各行には 256 個のセルが含まれます。もちろん、同じ行内のセルは最後のバイトが異なるだけで、残りは同じです。

グループ 0 のプレーン 0 は、Basic Multilingual Plane (BMP) と呼ばれます。また、UCS-4 では、上位 2 バイトが 0 のコード ビットを BMP と呼びます。

UCS-4 BMP の最初の 2 つのゼロ バイトを削除して、UCS-2 を取得します。 UCS-4 の BMP を取得するには、UCS-2 の 2 バイトの前に 2 つのゼロ バイトを追加します。現在の UCS-4 仕様では、BMP の外側に割り当てられた文字はありません。

4. UTF エンコーディング

UTF-8 は UCS を 8 ビット単位でエンコードします。 UCS-2 から UTF-8 へのエンコード方法は次のとおりです。

UCS-2 エンコード (16 進数) UTF-8 バイト ストリーム (バイナリ)
0000 - 007F 0xxxxxxx
0080 - 07FF 110xxxxx 10xxxxxx
0800 - FFFF 1110xxxx 10xxxxxx 10xxxxxx

たとえば、「中国語」文字の Unicode エンコードは 6C49 であるため、6C49 は 0800 ～ FFFF の間にあるため、3 バイトのテンプレートを使用する必要があります: 1110xxxx 10xxxxxx10xxxxxx。 。 6C49 をバイナリで書くと、0110 110001 001001 となります。このビット ストリームを使用してテンプレート内の x を順番に置き換えると、1110011010110001 10001001、つまり E6 B1 89 が得られます。

読者はメモ帳を使用して、コーディングが正しいかどうかをテストできます。 UTF-8 でエンコードされたテキスト ファイルを開くと、UltraEdit は自動的に UTF-16 に変換するため、混乱が生じる可能性があることに注意してください。このオプションは設定でオフにできます。より良いツールは Hex Workshop です。

UTF-16 は、UCS を 16 ビット単位でエンコードします。 0x10000 未満の UCS コードの場合、UTF-16 エンコードは、UCS コードに対応する 16 ビットの符号なし整数と等しくなります。 0x10000 以上の UCS コードについては、アルゴリズムが定義されています。ただし、実際に使用する UCS2 または UCS4 の BMP は 0x10000 未満である必要があるため、現時点では UTF-16 と UCS-2 は基本的に同じであると考えてください。ただし、UCS-2は単なる符号化方式であり、実際の送信にはUTF-16が使用されるため、バイトオーダーの問題を考慮する必要があります。

5. UTF バイト順序と BOM
UTF-8 はエンコード単位としてバイトを使用し、バイト順序の問題はありません。 UTF-16 は、エンコード単位として 2 バイトを使用します。UTF-16 テキストを解釈する前に、まず各エンコード単位のバイト順序を理解する必要があります。たとえば、「Kui」の Unicode エンコードは 594E、「B」の Unicode エンコードは 4E59 です。 UTF-16 バイトストリーム「594E」を受信した場合、これは「Ku」ですか、「B」ですか?

Unicode 仕様でバイト順序をマークする推奨方法は、BOM です。 BOMとは「部品表」のBOMリストではなく、バイトオーダーマークのことです。 BOM は少し賢いアイデアです。

UCS エンコーディングには「ZERO WIDTH NO-BREAKSPACE」という文字があり、そのエンコーディングは FEFF です。 FFFE は UCS には存在しない文字ですので、実際の送信では出現しないはずです。 UCS 仕様では、バイト ストリームを送信する前に文字「ZERO WIDTH NO-BREAK SPACE」を送信することを推奨しています。

このように、受信機が FEFF を受信した場合は、バイト ストリームがビッグ エンディアンであることを意味し、FFFE を受信した場合は、バイト ストリームがリトル エンディアンであることを意味します。したがって、「ZERO WIDTH NO-BREAK SPACE」という文字は BOM とも呼ばれます。

UTF-8 ではバイト順序を示すために BOM は必要ありませんが、BOM を使用してエンコード方式を示すことができます。 「ZERO WIDTH NO-BREAKSPACE」という文字の UTF-8 エンコードは EF BB BF です (読者は以前に紹介したエンコード方法を使用して確認できます)。したがって、受信側が EF BBBF で始まるバイト ストリームを受信すると、それが UTF-8 でエンコードされていることを認識します。

Windows は BOM を使用してテキスト ファイルのエンコード方法をマークします。

6. その他の参考資料
この記事の主な参考資料は、「ISO-IEC 10646 と Unicode の概要」(http://www.nada.kth.se/i18n/ucs/) です。ユニコード -iso10646-oview.html)。

また、良さそうな情報を 2 つ見つけましたが、最初の質問に対する答えはすでに見つけていたため、読みませんでした。

「Unicode について Unicode 標準の概要」 (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a)
「文字セット エンコーディングの基本について」文字セット エンコーディングとレガシー エンコーディング" (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter03)
UTF-8、UCS-2、GBK を相互に記述しましたWindows API を含むバージョンと含まないバージョンを含む、変換されたパッケージ。今後時間があれば整理して個人ホームページに載せたいと思います

この記事は、すべての論点を明確に考えてから、しばらくすれば書き終えることができると思って書き始めました。思いの外、文言の検討や細部の確認に時間がかかり、午後1時半から9時までかけて書きました。一部の読者がそれから恩恵を受けることを願っています。

付録 1 場所コード GB2312、内部コード、およびコード ページについて話しましょう
一部の友人は、記事内のこの文についてまだ質問しています:
「GB2312 の原文は依然として場所です」位置コードから内部コードまでは、上位バイトと下位バイトにそれぞれA0を追加する必要があります。「

詳しく説明します:

」GB2312の原文です。 「中華人民共和国の国家標準情報交換のための中国語コード化文字セットの基本セット GB2312-80」という 1980 年の国家標準を指します。この規格では、2 つの数値を使用して中国語の文字と中国語の記号をエンコードします。最初の数値は「エリア」と呼ばれ、2 番目の数値は「ビット」と呼ばれます。そのため、ロケーションコードとも呼ばれます。エリア 1 ～ 9 は中国語記号、エリア 16 ～ 55 は第 1 レベルの漢字、エリア 56 ～ 87 は第 2 レベルの漢字です。現在、Windows には位置入力メソッドもあります。たとえば、1601 と入力すると「ああ」が得られます。 (この位置入力方法では、16 進数の GB2312 と 10 進数の位置コードを自動的に認識できます。つまり、B0A1 を入力しても「ああ」が返されます。)

内部コードは、オペレーティング システム内の文字エンコーディングを指します。初期のオペレーティング システムの内部コードは言語に依存していました。現在の Windows はシステム内で Unicode をサポートしており、コード ページを使用してさまざまな言語に適応しています。「内部コード」の概念は比較的曖昧です。 Microsoft では通常、デフォルトのコード ページで指定されたエンコーディングを内部コードと呼びます。

内部コードという用語の正式な定義はなく、コード ページは単なる Microsoft 社の名前です。プログラマーとして、これらの用語が何であるかを知っていれば、これらの用語を詳しく調べる必要はありません。

いわゆるコード ページ (コード ページ) は、言語の文字エンコーディングです。たとえば、GBK のコード ページは CP936、BIG5 のコード ページは CP950、GB2312 のコード ページは CP20936 です。

Windows には、デフォルト コード ページ、つまり文字を解釈するためにデフォルトで使用されるエンコーディングの概念があります。たとえば、Windows メモ帳でテキスト ファイルを開くと、その内容はバイト ストリーム (BA、BA、D7、D6) です。 Windows ではそれをどのように解釈すればよいでしょうか?

Unicode エンコード、GBK、BIG5、または ISO8859-1 に従って解釈する必要がありますか? GBKに従って解釈すると、「漢字」という言葉が得られます。他のエンコード解釈によれば、対応する文字が見つからないか、間違った文字が見つかる可能性があります。いわゆる「誤り」とは、文章作成者の本来の意図と異なっており、文字化けが発生することをいいます。

答えは、Windows が現在のデフォルト コード ページに従ってテキスト ファイル内のバイト ストリームを解釈するということです。デフォルトのコード ページは、コントロール パネルの地域オプションから設定できます。メモ帳の [名前を付けて保存] には ANSI 項目があり、実際にはデフォルトのコード ページのエンコード方法に従って保存されます。

Windows の内部コードは Unicode であり、技術的には複数のコード ページを同時にサポートできます。ファイルが使用するエンコーディングを説明でき、ユーザーが対応するコード ページをインストールしている限り、Windows はファイルを正しく表示できます。たとえば、HTML ファイルで文字セットを指定できます。

一部の HTML ファイル作成者、特に英語の作成者は、世界中の誰もが英語を使用していると信じており、ファイル内で文字セットを指定していません。 0x80 ～ 0xff の文字を使用すると、中国語 Windows がデフォルトの GBK に従って文字を解釈すると、文字化けが発生します。このとき、たとえば
## のように、文字セットを指定するステートメントを HTML ファイルに追加するだけです。 # オリジナル作成者が使用したコードページが ISO8859-1 に準拠していれば文字化けは発生しません。

Ah のロケーション コードについて話しましょう。Ah のロケーション コードは 1601、16 進数で書くと 0x10、0x01 です。これは、コンピュータで広く使用されている ASCII エンコーディングと競合します。 00-7f の ASCII エンコーディングと互換性を持たせるために、市外局番の上位バイトと下位バイトにそれぞれ A0 を追加します。このようにして、「あ」のコードはB0A1となります。また、2 つの A0 を追加したコードを

GB2312 コード と呼びますが、GB2312 の原文にはこれについてはまったく言及されていません。

上記は、UTF-8 と GBK UTF8 GB2312 の違いについての完全な紹介です。HTML チュートリアルについて詳しく知りたい場合は、PHP 中国語 Web サイトに注目してください。

以上がUTF-8 と GBK の違いは何ですか UTF8 GB2312の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。