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 よりも汎用性が劣りますが、UTF8 は GBD よりも大きなデータベースを占有します。
GBK、GB2312 などは、Unicode エンコードを通じて UTF8 に変換する必要があります。
GBK、GB2312--Unicode--UTF8
UTF8--Unicode--GBK、GB2312
Web サイトやフォーラムで英語の文字が多く含まれる場合は、スペースを節約するために UTF-8 を使用することをお勧めします。ただし、多くのフォーラム プラグインは現在、一般に GBK のみをサポートしています。
エンコードの違いを詳しく解説 簡単に言うと、unicode、gbk、ビッグファイブコードがエンコードされた値で、utf-8、uft-16などはその値を表現したものです。前の 3 つのコードは互換性がありますが、同じ漢字でも 3 つのコード値はまったく異なります。たとえば、「Han」の uncode 値は gbk とは異なり、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 エンコード方式の間で変換できます。または、 http://www.knowsky.com/tools/utf8.aspに直接アクセスしてオンライン変換することもできます。
これも 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 を設計しました。
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-2 は、UCS-4 の BMP の最初の 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 110xxxxxx 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/unicode-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 )
私は、Windows API を使用するバージョンと Windows API を使用しないバージョンを含む、UTF-8、UCS-2、および GBK を相互に変換するためのソフトウェア パッケージを作成しました。今後時間があれば整理して個人ホームページ（ http://fmddlmyy.home4u.china.com ）に載せたいと思います。
いろいろ考えた後、すぐに書き終えることができると思い、この記事を書き始めました。思いの外、文言の検討や細部の確認に時間がかかり、午後1時半から9時までかけて書きました。一部の読者がそれから恩恵を受けることを願っています。
付録 1 ロケーション コード、GB2312、内部コード、およびコード ページについて話しましょう。この記事の文についてまだ質問している人がいます。
「GB2312 の原文は市外局番のままです。市外局番から内局番まで、上位バイトと下位バイトにそれぞれ A0 を追加する必要があります。」
詳しく説明しましょう:
「GB2312の原文」とは、1980年の国家標準「中華人民共和国国家標準情報交換用中国語コード化文字セット基本セット GB2312-80」を指します。この規格では、2 つの数値を使用して中国語の文字と中国語の記号をエンコードします。最初の数値は「エリア」と呼ばれ、2 番目の数値は「ビット」と呼ばれます。そのため、ロケーションコードとも呼ばれます。エリア 1 ～ 9 は中国語記号、エリア 16 ～ 55 は第 1 レベルの漢字、エリア 56 ～ 87 は第 2 レベルの漢字です。現在、Windows には位置入力メソッドもあります。たとえば、1601 と入力すると「ああ」が得られます。 (この位置入力方法では、16 進数の GB2312 と 10 進数の位置コードを自動的に認識できます。つまり、B0A1 を入力すると「ah」も取得されます。)
内部コードとは、オペレーティング システム内の文字エンコーディングを指します。初期のオペレーティング システムの内部コードは言語に依存していました。現在の 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 に従って文字を解釈すると、文字化けが発生します。このとき、たとえば次のように、charset を指定するステートメントを HTML ファイルに追加するだけです。
<meta http-equiv="Content-Type" content="text/html; charset=ISO8859-1">
オリジナル作成者が使用したコードページが ISO8859-1 に準拠していれば文字化けは発生しません。
Ah のロケーション コードについて話しましょう。Ah のロケーション コードは 1601、16 進数で 0x10、0x01 です。これは、コンピュータで広く使用されている ASCII エンコーディングと競合します。 00-7f の ASCII エンコーディングと互換性を持たせるために、市外局番の上位バイトと下位バイトにそれぞれ A0 を追加します。このようにして、「あ」のコードはB0A1となります。 2 つの A0 を追加したエンコーディングを GB2312 エンコーディングとも呼びますが、GB2312 の原文にはこれについてはまったく言及されていません。