Unicode の根拠は何ですか? また、UTF-8 または UTF-16 が必要なのはなぜですか? Google で調べ、ここでも検索しましたが、よくわかりません。
でVSSSファイルの比較を行うと、2 つのファイルの UTF が異なるというメッセージが表示されることがあります。なぜこのようなことが起こるのでしょうか?
簡単に説明してください。
ベストアンサー1
なぜ Unicode が必要なのでしょうか?
（それほど古くはないが）初期には、存在していたのはアスキーこれは問題ありませんでした。必要なのは、この文にあるような制御文字、句読点、数字、文字だけだったからです。残念ながら、今日のグローバルな相互通信とソーシャル メディアの奇妙な世界は予測されておらず、同じ文書に English、العربية、汉语、עִבְרִית、ελληνικά、ភាសាខ្មែរ が混在しているのを見るのはそれほど珍しいことではありません (古いブラウザーを壊さなかったことを願います)。
しかし、議論のために、平均的なジョーがソフトウェア開発者だとしましょう。彼は、英語だけが必要だと主張し、ASCII のみを使用したいと考えています。これは、ユーザーであるジョーにとっては問題ないかもしれませんが、ソフトウェア開発者であるジョーにとっては問題です。世界の約半数は非ラテン文字を使用しており、ASCII を使用することは、これらの人々に対しておそらく配慮に欠けています。さらに、彼は自分のソフトウェアを、成長を続ける大規模な経済から閉ざしています。
そのため、すべての言語を網羅する文字セットが必要となり、ユニコード. すべての文字にコードポイントと呼ばれる一意の番号が割り当てられます。他の文字セットと比較したUnicodeの利点の1つは、最初の256のコードポイントがISO-8859-1、そしてASCIIでもあります。さらに、一般的に使用される文字の大部分は、2バイトの領域でのみ表現できます。基本多言語面 (BMP). この文字セットにアクセスするには文字エンコードが必要ですが、質問にあるように、UTF-8 と UTF-16 に焦点を当てます。
メモリに関する考慮事項
では、これらのエンコーディングでは、何バイトでどの文字にアクセスできるようになるのでしょうか?
- UTF-8:
- 1バイト: 標準ASCII
- 2バイト: アラビア語、ヘブライ語、ほとんどのヨーロッパの文字（特にジョージア語）
- 3バイト: BMP
- 4バイト: すべてのUnicode文字
- UTF-16:
- 2バイト: BMP
- 4バイト: すべてのUnicode文字
ここで言及しておく価値があるのは、BMPに含まれない文字には、古代の文字、数学記号、音楽記号、そしてより珍しい文字が含まれているということだ。中国語、日本語、韓国語（CJK）文字。
主に ASCII 文字を扱う場合、UTF-8 の方がメモリ効率が高くなります。ただし、主にヨーロッパ以外の文字を扱う場合、UTF-8 を使用すると、UTF-16 よりもメモリ効率が最大 1.5 倍低くなる可能性があります。大きな Web ページや長い Word 文書など、大量のテキストを扱う場合、パフォーマンスに影響する可能性があります。
エンコーディングの基礎
注: UTF-8 と UTF-16 がどのようにエンコードされるかがわかっている場合は、実際のアプリケーションについては次のセクションに進んでください。
- UTF-8:標準 ASCII (0-127) 文字の場合、UTF-8 コードは同一です。このため、既存の ASCII テキストとの下位互換性が必要な場合、UTF-8 は最適です。その他の文字には 2 バイトから 4 バイトが必要です。これは、これらの各バイトの一部のビットを予約して、マルチバイト文字の一部であることを示すことによって行われます。特に、各バイトの最初のビットは、
1ASCII 文字との衝突を避けるためのものです。 - UTF-16:有効な BMP 文字の場合、UTF-16 表現は単にそのコード ポイントです。ただし、非 BMP 文字の場合、UTF-16 はサロゲート ペアを導入します。この場合、2 つの 2 バイト部分の組み合わせが非 BMP 文字にマップされます。これらの 2 バイト部分は BMP 数値範囲から取得されますが、Unicode 標準によって BMP 文字としては無効であることが保証されています。さらに、UTF-16 は 2 バイトを基本単位とするため、次の影響を受けます。エンディアンこれを補うために、データ ストリームの先頭に、エンディアンを示す予約バイト オーダー マークを配置することができます。したがって、UTF-16 入力を読み込んでいて、エンディアンが指定されていない場合は、これをチェックする必要があります。
ご覧のとおり、UTF-8とUTF-16は互いに互換性がありません。したがって、I/Oを行う場合は、どのエンコーディングを使用しているかを確認してください。これらのエンコーディングの詳細については、UTFに関するよくある質問。
実用的なプログラミングの考慮事項
文字と文字列のデータ型:これらはプログラミング言語でどのようにエンコードされるのでしょうか? 生のバイトの場合、非 ASCII 文字を出力しようとすると、いくつかの問題が発生する可能性があります。また、文字型が UTF に基づいている場合でも、文字列が適切な UTF であるとは限りません。不正なバイトシーケンスが許可される場合があります。一般的に、UTF をサポートするライブラリを使用する必要があります。集中治療室C、C++、Java の場合。いずれにしても、デフォルトのエンコーディング以外のものを入力/出力する場合は、最初に変換する必要があります。
推奨、デフォルト、および主要なエンコーディング:どのUTFを使用するか選択できる場合、通常は作業環境の推奨標準に従うのが最善です。たとえば、UTF-8はWeb上で主流であり、HTML5以降は推奨されるエンコード逆に言えば、。ネットそしてジャワ環境は UTF-16 文字タイプに基づいています。紛らわしいことに (そして誤っていることですが)、多くの場合、「Unicode エンコーディング」が参照されますが、これは通常、特定の環境で支配的な UTF エンコーディングを指します。
ライブラリのサポート:使用しているライブラリは、何らかのエンコードをサポートしています。どのエンコードですか? 特殊なケースはサポートしていますか? 必要は発明の母なので、UTF-8 ライブラリは、1 バイト、2 バイト、さらには 3 バイトの文字が頻繁に発生する可能性があるため、通常は 4 バイト文字を適切にサポートします。ただし、サロゲート ペアは非常にまれにしか発生しないため、UTF-16 ライブラリと称されるライブラリのすべてがサロゲート ペアを適切にサポートしているわけではありません。
文字のカウント: Unicode には結合文字が存在します。たとえば、コード ポイント U+006E (n) と U+0303 (結合チルダ) は ñ を形成しますが、コード ポイント U+00F1 は ñ を形成します。これらは同じに見えますが、単純なカウント アルゴリズムでは、最初の例では 2 が返され、後者では 1 が返されます。これは必ずしも間違っているわけではありませんが、望ましい結果ではない可能性もあります。
等価性の比較: A、А、Α は同じに見えますが、それぞれラテン文字、キリル文字、ギリシャ文字です。C や Ⅽ のようなケースもあります。1 つは文字で、もう 1 つはローマ数字です。さらに、結合文字も考慮する必要があります。詳細については、Unicode の重複文字。
サロゲートペア: Stack Overflow では頻繁に話題に上がるので、いくつか例のリンクを紹介します。