StringBuffer
特にreverse()メソッドのドキュメントを読んでいました。そのドキュメントでは、サロゲート ペアについて言及しています。このコンテキストでのサロゲート ペアとは何ですか? 低サロゲートと高サロゲート とは何ですか?
7 に答える
「サロゲート ペア」という用語は、UTF-16 エンコード方式で高いコード ポイントを持つ Unicode 文字をエンコードする手段を指します。
Unicode 文字エンコーディングでは、文字は 0x0 ~ 0x10FFFF の値にマップされます。
内部的に、Java は UTF-16 エンコード方式を使用して Unicode テキストの文字列を格納します。UTF-16 では、16 ビット (2 バイト) のコード単位が使用されます。16 ビットには 0x0 から 0xFFFF までの範囲の文字のみを含めることができるため、この範囲を超える値 (0x10000 から 0x10FFFF) を格納するには、追加の複雑さが使用されます。これは、サロゲートと呼ばれるコード単位のペアを使用して行われます。
サロゲート コード ユニットは、2 コード ユニット シーケンスの先頭または末尾で許可されるかどうかに応じて、「高サロゲート」と「低サロゲート」として知られる 2 つの範囲にあります。
そのドキュメントが言っていることは、無効な UTF-16 文字列はreverse
有効な文字列の逆である可能性があるため、メソッドを呼び出した後に有効になる可能性があるということです。サロゲート ペア (ここで説明) は、1 つの Unicode コード ポイントをエンコードする UTF-16 の 16 ビット値のペアです。下位サロゲートと上位サロゲートは、そのエンコーディングの 2 つの半分です。
小さな序文
Unicode はコード ポイントを表します。各コード ポイントは、Unicode 標準に従って 8、16、または 32 ビットのブロックにエンコードできます。
バージョン 3.1 より前は、主に UTF-8 として知られる 8 ビットのエンコーディングと、UCS-2 または「2 オクテットでコード化されたユニバーサル文字セット」として知られる 16 ビットのエンコーディングが使用されていました。UTF-8 は Unicode ポイントを 1 バイト ブロックのシーケンスとしてエンコードしますが、UCS-2 は常に 2 バイトを使用します。
A = 41 - UTF-8 の 8 ビットの1 ブロック
A = 0041 - UCS-2 の 16 ビットの 1 ブロック
Ω = CE A9 - UTF-8 の 8 ビットの 2 ブロック
Ω = 03A9 - の 1 ブロックUCS-2 で 16 ビット
問題
コンソーシアムは、人間が読める言語をカバーするには 16 ビットで十分であると考えており、2^16 = 65536の可能なコード値が得られます。これは、現在 65536 コード ポイントのうち 55,445 を含むプレーン 0 (BMP または Basic Multilingual Plane とも呼ばれます) にも当てはまります。BMP は、中国語-日本語-韓国語記号 (CJK) を含む、世界中のほぼすべての人間の言語をカバーしています。
時が経ち、新しいアジアの文字セットが追加され、中国語の記号だけで 70,000 ポイント以上かかりました。現在、標準の一部として絵文字ポイントさえあります。新しい 16 の「追加」プレーンが追加されました。UCS-2 の部屋は、Plane-0 より大きなものをカバーするには十分ではありませんでした。
ユニコード決定
- Unicode を 17 プレーン × 1 プレーンあたり 65,536 文字 = 1,114,112 最大ポイントに制限します。
- 各コード ポイントに 32 ビットを保持し、すべてのプレーンをカバーするために、以前は UCS-4 として知られていた UTF-32 を提示します。
- 動的エンコーディングとして UTF-8 を引き続き使用し、UTF-8 を各コード ポイントで最大 4 バイトに制限します。つまり、ポイントごとに 1 から 4 バイトまでです。
- UCS-2 の廃止
- UCS-2 に基づいて UTF-16 を作成します。UTF-16 を動的にすると、ポイントごとに 2 バイトまたは 4 バイトが必要になります。High Surrogates と呼ばれる U+D800–U+DBFF の 1024 ポイントを UTF-16 に割り当てます。低サロゲートと呼ばれる 1024 個のシンボル U+DC00–U+DFFF を UTF-16 に割り当てます。
これらの変更により、BMP は UTF-16 の 16 ビットの 1 ブロックでカバーされ、すべての「補助文字」はそれぞれ 16 ビットで 2 ブロックを表すサロゲート ペアでカバーされ、合計 1024x1024 = 1 048 576 ポイントになります。
上位サロゲートは下位サロゲートよりも前になります。この規則からの逸脱は、不適切なエンコーディングと見なされます。たとえば、ペアのないサロゲートは正しくなく、高いサロゲートの前に立つ低いサロゲートは正しくありません。
、「MUSICAL SYMBOL G CLEF」は、サロゲート 0xD834 0xDD1E (2 x 2 バイト) のペアとして UTF-16 でエンコードされ、
UTF-8 では 0xF0 0x9D 0x84 0x9E (4 x 1 バイト) として
、UTF-32 では 0x0001D11E としてエンコードされます。 (1 × 4 バイト)。
現在の状況
- 標準によれば、サロゲートは具体的には UTF-16 にのみ割り当てられますが、歴史的に一部の Windows および Java アプリケーションは、現在サロゲート範囲に予約されている UTF-8 および UCS-2 ポイントを使用していました。
不正な UTF-8/UTF-16 エンコーディングを使用するレガシー アプリケーションをサポートするために、新しい標準 WTF-8である Wobbly Transformation Format が作成されました。ペアになっていないサロゲートや不適切なシーケンスなど、任意のサロゲート ポイントをサポートします。現在、一部の製品は標準に準拠しておらず、UTF-8 を WTF-8 として扱います。 - サロゲート ソリューションは、「不正なサロゲート ペア」を使用しようとするだけでなく、いくつかのセキュリティ上の問題を引き起こしました。
多くの歴史的な詳細は、トピックに従うために抑制されました ⚖.
最新の Unicode 標準は、http://www.unicode.org/versions/latestにあります。
サロゲート ペアは、特定の文字をエンコードする UTF-16 の方法を参照します。