複数のUnicodeエンコーディングがあるのはなぜですか？

Unicodeは、以前の試み（ASCIIなど）のほとんどでアドレス空間（8ビット）が小さいため、多くの異なるエンコーディングを使用するという問題全体を回避するように設計されていると思いました。

では、なぜ多くのUnicodeエンコーディングがあるのですか？UTF-8、UTF-16などの（本質的に）同じバージョンの複数のバージョンでも

人々は各キャラクターに21ビットを費やすことを望まないからです。現代のすべてのシステムでは、これは基本的に文字ごとに3バイトを使用することを意味します。これは、人々が慣れているものの3倍であるため、Unicodeを採用することを嫌がりました。妥協点を見つけなければなりませんでした。たとえば、UTF-8は、レガシーASCIIファイルをまったく変換する必要がないため、英語のテキストには適していますが、ヨーロッパ言語にはあまり役に立たず、アジア言語にはほとんど役立ちません。

基本的に、はい、単一のユニバーサルエンコーディングと単一のユニバーサルキャラクターチャートを定義できましたが、市場はそれを受け入れませんでした。

Unicodeは、各コードポイントがグリフ（グラフィック表現）で表される「CodePoints」を一意に記述する21ビット文字エンコードです。

• プレーン内のコードポイントを識別するために使用される16ビット（ほとんどのコードポイントはプレーン0上にあります）。
• プレーンを識別する5ビット。

サポートされているエンコーディングは次のとおりです。

• UTF-8（8ビット値を使用して各ポイントをエンコード）
• UTF-16（16ビット値を使用して各ポイントをエンコードするため）
• UTF-32（32ビット値を使用して各ポイントをエンコードするため）

しかし、デコード時のエンコーディングが何であれ、それらはすべて同じ意味を持つ特定のコードポイントにマップされます（これがクールな理由です）。

• 'A'（U + 65）
  UTF-32 => 0x00000041 UTF-16 => 0x0041 UTF-8 => 0x41
• ローマ字小文字OE '（U + 0153）
  UTF-32 => 0x00000153 UTF-16 => 0x0153 UTF-8 => 0xC5 0x93
• 未割り当て（U + 11153）
  UTF-32 => 0x00011153 UTF-16 => 0xD804 0xDD53 UTF-8 => 0xF0 0x91 0x85 0x93

UTF-8

これは可変サイズの形式です。各コードポイントは1〜4バイトで表されます。

UTF-16

これは可変サイズの形式です。「Basic Multilingual plane」（BMPまたはPlane 0）上のコードポイントは、1つの16ビット値で表すことができます。他のプレーン上のコードポイントは、サロゲートペア（2 16ビット値）で表されます。

UTF-32

これは固定サイズの形式です。すべてのコードポイントは、単一の32ビット値で表されます。

私は2つのアイデアを分けるのが便利だと思います：

1. Unicode-世界中の文字をコードポイントにマッピングします。
2. エンコーディング-ビットパターン（UTF-8、UTF-16など）へのコードポイントのマッピング。

UTF-8、UTF-16、およびその他のエンコーディングには、それぞれ長所と短所があります。それについてウィキペディアをよく調べてください。

UTF-7、UTF-8、UTF-16、およびUTF-32は、文字の同じコーディング（コードポイント）の単純なアルゴリズム変換形式です。これらは、文字の体系化の1つのシステムのエンコードです。

また、256文字を超える文字セットを処理するための以前のほとんどのスキームよりも、アルゴリズム的に前後にナビゲートするのが簡単です。

これは、一般的に国別、場合によってはベンダー固有のグリフのコード化とは大きく異なります。日本語だけでも、JISのバリエーションがたくさんありました。EUC-JPや、DOS / Windowsマシンで使用されていたコードページ指向のJIS変換は、Shift-JISと呼ばれていました。（ある程度、これらのアルゴリズム変換がありましたが、それらは特に単純ではなく、利用可能な文字にベンダー固有の違いがありました。これに数百カ国を掛け、より洗練されたフォントシステムの漸進的な進化（ポストグリーンスクリーン時代）、そしてあなたは本当の悪夢を持っていました。

ユニコードのこれらの変換形式が必要なのはなぜですか？多くのレガシーシステムはASCII範囲の7ビット文字のシーケンスを想定していたため、これらのシステムを破損せずに安全にデータを渡す7ビットのクリーンなソリューションが必要であり、UTF-7が必要でした。次に、8ビット文字セットを処理できる最新のシステムがありましたが、一般にヌルには特別な意味があったため、UTF-16は機能しませんでした。2バイトは最初のインカネーションでUnicodeの基本的な多言語プレーン全体をエンコードできるため、UCS-2は「Windows NTやJava VMのような」「一からUnicodeを認識する」システムの合理的なアプローチのように思えました。それを超える拡張には追加の文字が必要でしたが、その結果、Unicode標準で予約されていた21ビットのエンコーディングのアルゴリズム変換が行われ、サロゲートペアが生まれました。それにはUTF-16が必要でした。ストレージの効率よりも文字幅の一貫性が重要なアプリケーションがある場合、UTF-32（かつてUCS-4と呼ばれていました）がオプションでした。

UTF-16は、リモートで処理するのが複雑な唯一のものであり、この変換の影響を受ける小さな範囲の文字と、先頭の16ビットシーケンスが末尾から完全に明確な範囲にあるという事実によって容易に軽減されます16ビットシーケンス。また、エスケープシーケンスを処理するためにステートマシン（JISおよびEUC）が必要な東アジアの多くのエンコーディングで前後に移動したり、保証されたものが見つかるまで複数の文字を移動したりするよりも簡単ですリードバイトにのみ（Shift-JIS）。UTF-16は、16ビットシーケンスを効率的に処理できるシステムでもいくつかの利点がありました。

数十（実際には数百）の異なるエンコーディングを経験する必要がない場合、または同じドキュメント（古いMacOsバージョンのWorldScriptなど）でも異なるエンコーディングで複数の言語をサポートするシステムを構築する必要がある場合を除き、ユニコード変換フォーマットの不必要な複雑さ。しかし、それは以前の選択肢に比べて複雑さが劇的に減少し、各形式は実際の技術的制約を解決します。また、互いに効率的に変換可能で、複雑なルックアップテーブルを必要としません。

Unicodeは、多くの異なるエンコーディングを持つという問題全体を回避するようには設計されていません。

Unicodeは、使用中のコードページに応じて多くの異なるものを表す1つの数字の問題全体を回避するように設計されました。0〜127の数字は、Ansiコードページの同じ文字を表します。これは、ASCIIチャートまたは文字セットとも呼ばれるものです。256文字を許可するAnsiコードページでは、128〜255の数字が異なるコードページの異なる文字を表します。

例えば

• 数字$ 57は、すべてのコードページで大文字のWを表しますが、
• 番号$ ECは、コードページ437（米国）の初期シンボルを表しますが、コードページ775（バルト語）の「ローマ字小文字Nセディラ」
• セントサインは、コードページ437では9ドルですが、コードページ775では96です。

Unicodeがしたことは、これをすべて逆さまにすることでした。Unicodeには「再利用」はありません。各数字は、単一の一意の文字を表します。Unicodeの数字$ 00A2はセント記号であり、セント記号はUnicode定義のどこにも表示されません。

では、なぜ多くのUnicodeエンコーディングがあるのですか？UTF-8、UTF-16などの（本質的に）同じバージョンの複数のバージョンでも

同じエンコーディングの複数のバージョンはありません。同じUnicode文字定義マップには複数のエンコーディングがあり、これらはUnicodeに存在するさまざまな言語プレーンのさまざまな使用法のストレージ要件を管理するために「発明」されました。

Unicodeは4.294.967.295の一意の文字を定義します（または定義するスペースがあります）。アルゴリズム変換を行わずにこれらをディスク/メモリストレージにマップする場合は、文字ごとに4バイトが必要です。すべての言語プレーンの文字を含むテキストを保存する必要がある場合は、UTF-32（基本的にはまっすぐな1文字-Unicode定義の4バイトストレージエンコード）がおそらく必要です。

しかし、ほとんどすべてのテキストがすべての言語面の文字を使用しているわけではありません。そして、文字ごとに4バイトを使用することは大きな無駄のようです。特に、地球上のほとんどの言語は、Basic Multi-lingual Plane（BMP）：Unicode定義の最初の65536番号として知られているものの中で定義されていることを考慮すると。

そして、UTF-16が登場しました。BMPの文字のみを使用する場合、UTF-16は文字ごとに2バイトのみを使用して非常に効率的に保存します。BMP以外の文字には、より多くのバイトのみを使用します。UTF-16LE（リトルエンディアン）とUTF-16BE（ビッグエンディアン）の違いは、コンピューターメモリ内での数値の表現方法（バイトパターンA0は16進数$ A0または$ 0Aを意味する）にのみ関係します。

西ヨーロッパ言語のほとんどのテキストのように、テキストで使用する文字がさらに少ない場合は、テキストのストレージ要件をさらに制限する必要があります。したがって、ASCIIチャートに存在する文字（最初の128個の数字）とAnsi文字からの選択（さまざまなコードページの2番目の128個の数字）を格納するためにシングルバイトを使用するUTF-8。この「最も使用される文字」セット以外の文字には、より多くのバイトのみが使用されます。

要約すると：

• ユニコードは、地球上のすべての言語（および起動するクリンゴン語）のすべての文字と、固有の番号へのいくつか（数学、音楽など）のマッピングです。
• エンコードとは、テキスト内の文字の「平均使用量」を考慮して、この一意の文字マップの番号をできるだけ効率的にスペースとして使用してテキストを保存するように定義されたアルゴリズムです。

Unicodeは、数字と文字の間のマップを定義します。ただし、番号を受信者に送信する場合、その番号の表現方法を定義する必要があります。それがUTFの目的です。バイトストリームで数値を表現する方法を定義します。

UTF-32の背後にある理論的根拠は単純です。これは、Unicodeコードポイントの最も単純な表現です。では、なぜすべてがUTF-32ではないのでしょうか？2つの主な理由：

一つはサイズです。UTF-32では、すべての文字に4バイトが必要です。Basic Multilingual Placeの文字のみを使用するテキストの場合、これはUTF-16の2倍のスペースです。英語のテキストの場合、US-ASCIIの4倍のスペースです。

より大きな理由は後方互換性です。「エンコードされていない」UTF-32以外の各Unicodeエンコーディングは、以前の標準との後方互換性のために設計されました。

• UTF-8：US-ASCIIとの後方互換性。
• UTF-16：UCS-2との下位互換性（BMPを超えて拡張される前の16ビットUnicode）。
• UTF-7：非8ビットクリーンメールサーバーとの下位互換性。
• GB18030：中国語のGB2312およびGBKエンコーディングとの下位互換性。
• UTF-EBCDIC：EBCDICのBasic Latinサブセットとの下位互換性。

ユニコードは、多くの異なるエンコーディングを持つという問題全体を回避するように設計されていると思いました

ありました。UTF-8、-16、および-32間の変換は、さまざまな言語およびさまざまなOS の数百のさまざまな文字エンコーディングの古いシステムを扱うよりもはるかに簡単です。

zipファイルは、ファイルを非常に小さく（特にテキスト）圧縮してから、元のファイルの同一コピーに圧縮解除できることを知っています。

ジッピングアルゴリズムには、実際には、選択する特性が異なるいくつかの異なるアルゴリズムがあります：保存（圧縮なし）、縮小、縮小（方法1〜4）、内破、トークン化、デフレート、Deflate64、BZIP2、LZMA（EFS）、WavPack、PPMd、理論的にはそれらすべてを試して最良の結果を選択することができますが、通常はDeflatedを使用します。

UTFはほぼ同じように機能します。それぞれ異なる特性を持ついくつかのエンコーディングアルゴリズムがありますが、通常はUTF-8を選択します。これは、他のUTFバリアントとは対照的に広くサポートされているためです。通常、ASCIIの8ビット拡張を使用する最新のコンピュータープラットフォームで使用します。