UTF-8は、何百万もの新しい文字を含む広大なエイリアン言語の包含をサポートできるでしょうか？
エイリアンの侵略 が発生し、既存のすべてのコンピューターシステムでそれらの言語をサポートすることを余儀なくされた場合、UTF-8はそれらの可能性のある大量の文字を可能にする方法で設計されていますか？
（もちろん、私たちはエイリアンが実際に言語を持っているかどうか、彼らがコミュニケーションするかどうか、またはどのようにコミュニケーションするかはわかりませんが、議論のために、彼らがそうすることを想像してください。）
たとえば、言語が何百万もの新しく発見されたグリフ、記号、および 結合文字 で構成されている場合、UTF-8は理論的にはこれらの新しいグリフを含め、すべてをサポートするように非破壊的な方法で拡張できます。既存のソフトウェア？
グリフが現在のサイズ制限をはるかに上回り、単一のグリフを表すためにより多くのバイトを必要とする場合、私はもっと興味があります。 UTF-8が展開できない場合、UTF-32に対する単一の利点は、単に下位文字のサイズであることを証明しますか？
Unicode標準には、十分なスペースがあります。 Unicodeコードポイントは、「プレーン」と「ブロック」で構成されています。合計17のプレーンのうち、 11は現在未割り当て です。各プレーンは65,536文字を保持するため、現実には外国語用に50万のコードポイントがあります（最初の接触の前にすべての絵文字で埋めない限り）。 Unicode 8.0では、合計120,737のコードポイントのみが割り当てられ（合計容量の約10％）、ほぼ同じ量が割り当てられていませんが、アプリケーション固有のプライベートな使用のために予約されています。合計で974,530個のコードポイントが割り当てられていません。
UTF-8はUnicodeの特定のエンコーディングであり、現在コードポイントごとに4オクテット（バイト）に制限されており、これはUTF-16の制限と一致しています。特に、UTF-16は17プレーンのみをサポートします。以前は、UTF-8はコードポイントごとに6オクテットをサポートし、32768プレーンをサポートするように設計されていました。原則として、この4バイトの制限を引き上げることはできますが、これはUnicodeの現在の組織構造を壊し、UTF-16を段階的に廃止する必要があります。特定のオペレーティングシステムやプログラミングでどれだけ固定されているかを考えると、近い将来には起こりそうにありません。言語。
UTF-16がまだ一般的に使用されている唯一の理由は、単一のUnicode平面のみをサポートしていた欠陥のあるUCS-2エンコーディングの拡張であることです。それ以外の場合は、UTF-8（固定幅ではない）とUTF-32（ASCII互換、一般的なデータのためのスペースの無駄）ではない）の両方から望ましくないプロパティを継承し、エンディアンを宣言するためにバイトオーダーマークが必要です。 。これらの問題にもかかわらず、UTF-16が依然として人気があることを考えると、UTF-16がすぐに変更されることを楽観視しているわけではありません。うまくいけば、私たちの新しいエイリアンオーバーロードは、彼らのルールと彼らの知恵にこの障害を感じるでしょう- 地球の表面からUTF-16を追放する 。
UTF-8が実際に拡張される場合、それが表すことができる絶対最大値を調べる必要があります。 UTF-8は次のように構成されています。
Char. number range | UTF-8 octet sequence
(hexadecimal) | (binary)
--------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
（恥知らずにコピーされた RFCから 。）最初のバイトは常に、現在の文字を構成するフォローアップバイトの数を制御することがわかります。
最大8バイトを許可するように拡張すると、追加の非Unicode表現が得られます。
111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
11111110 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
11111111 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
この手法で実現できる最大の表現を計算する
10000000₂
+ 00100000₂ * 01000000₂
+ 00010000₂ * 01000000₂^2
+ 00001000₂ * 01000000₂^3
+ 00000100₂ * 01000000₂^4
+ 00000010₂ * 01000000₂^5
+ 00000001₂ * 01000000₂^6
+ 00000001₂ * 01000000₂^7
またはベース10：
128
+ 32 * 64
+ 16 * 64^2
+ 8 * 64^3
+ 4 * 64^4
+ 2 * 64^5
+ 1 * 64^6
+ 1 * 64^7
これにより、表現の最大量は4,468,982,745,216になります。
したがって、これらの40億文字（ または1兆円 ）が外国語を表すのに十分である場合、最小限の労力で現在のUTF-8を拡張して、新しいエイリアンオーバーロード;-)
RFC3629 は、UTF-8を文字あたり最大4バイトに制限します。最大値は0x10FFFFで、最大1,112,064のコードポイントを許可します。明らかに、この制限を削除して標準を拡張することができますが、これにより、その制限まで機能する既存のコードの重大な変更が証明されます。
データファイルの観点から見ると、標準が各バイトの最上位ビット（MSB）が設定されている場合、次のバイトがエンコードの一部であるという基準に基づいて機能するため、これは重大な変更ではありません。 RFC3629の前でも、標準は31ビットに制限されていて、4バイト目のMSBは設定されていません。
ただし、標準を0x10FFFFを超えて拡張すると、UTF-8のUTF-16との部分的なデータ互換性が失われます。
実際には、文字を結合している場合、2つのUnicodeコードポイントコードのみが無限に多くのグリフを表します。
たとえば、Unicodeが韓国語のハングルアルファベットをエンコードする2つの方法を比較します。 Hangul Syllables と Hangul Jamo です。 Hangul Syllabelsの文字は単一のコードポイントC6C3ですが、Hangul Jamoの文字は3つのコードポイント110B（ㅇ）116E（ㅜ） 11B9（ㅅ）。明らかに、結合文字を使用するとコードポイントが大幅に少なくなりますが、各文字を書き込むためにより多くのバイトが必要になるため、書き込み効率が低下します。
このトリックを使用すると、現在UTF-8またはUTF-16でエンコードできるコードポイントの数を超える必要はありません。
私の言語が地球上の言語よりも多くのメッセージあたりのバイト数を必要とするならば、それはエイリアンがどれほど気分を害するかによると思います。彼らが何百万ものキャラクターのそれぞれを、たとえば100kの結合文字のごちゃごちゃとして表現することを気にしなければ、問題はありません。一方、地球人よりも多くのバイトを使用するように強制されて2階級の市民のように感じられる場合は、競合が発生する可能性があります（ TF-8ですでに観察されているものとは異なりません ）。