UCS データベースで UTF-16 の範囲が予約されているのはなぜですか?
UTF-16 は、 one または two を使用して文字スカラー値を表す方法にすぎunsigned 16-bitsません。これらの値のレイアウトは、文字スカラー値に関連付けてはなりません。そのような表現から実際の文字スカラー値を取得するには、何らかのアルゴリズムを適用する必要があるためです。
D800-DBFF予約された範囲とが UCS データベースで予約されておらず、範囲内のすべての文字を単一DC00-DFFFで表すことができる UTF-16 の別の表現があり、上位ビットが設定されている場合、別の 16 ビットの後に残りの文字が続くと仮定します。ビット、およびバイト オーダー マークについては、2 つの可能な値を予約します。それだけです。0-7FFFunsigned 16-bits
もし私が間違っていたら、あなたは私にそれを説明してくれませんか。
ありがとう
提案されたスキームは、現在のサロゲート ペア スキームよりも効率が低く、これが 1 つの問題です。
Currently, only 0xD800-0xDFFF (2048 code units) are "out of bounds" as normal characters, leaving 63488 code units mapping to single characters. Under your proposal, 0x8000-0xFFFF (32768) code units are reserved for multi-code-unit code points, leaving only the other 32768 code units for single-code-unit code points.
I don't know how many code points are currently specified in the basic multilingual plane, but I wouldn't be surprised if it were more than 32768, and of course it can grow. As soon as it's more than 32768, there would be more characters which require two code units to be represented under your proposal than in UTF-16 as it stands.
これで、UCS に予約済みの範囲を含める必要がないことに同意します (そして、いくつかの点で意味の醜い組み合わせです)。かなり効率的なソリューション。
これにはマイナス面がほとんどありません。UCS には十分なスペースがあるため、この小さなブロックを確保することは、将来の拡張の余地が大幅に少なくなることを意味するわけではありません。
仮定
このビットは情報に基づいた推測です。どのバージョンの Unicode でどの文字が使用されているかを調べるために調査を行うこともできますが、少なくとももっともらしい説明だと思います。
この特定のブロックが使用されている本当の理由は、おそらく歴史的なものです。長い間、Unicode は実際にはすべて 16 ビットでした...そして、文字はすでに上限の範囲 (スキームが立ち入り禁止と見なす部分) に割り当てられていました。以前に割り当てられていなかった 2048 個の値のブロックを取得することにより、以前の有効な UCS-2 シーケンスはすべて同じ意味を持つ有効な UTF-16 シーケンスとして保持され、UCS 範囲は BMP を超えて拡張されました。範囲が 0xF800 ～ 0xFFFF だった場合、いくつかの側面がより簡単になる可能性がありますが、それでは遅すぎました。
コードポイントD800-DFFFは、現在の UTF-16 エンコード スキームでは自分自身として表すことができないため、予約されています。それらは範囲内にあるため、0000-FFFF1 つの UTF-16 コードユニットを使用してそのままエンコードされます。それが許可されている場合、プロセッサが UTF-16 シーケンスをデコード/順方向にシークしているときに、D800-0xDBFF範囲内のコードユニットに遭遇すると、そのコードユニットがスタンドアロンのコードポイントを表すか、サロゲート ペアの開始を表すかを決定する必要があります。それを行う唯一の方法は、次のコードユニットを見て、それがDC00-DFFF範囲内にあるかどうかを確認することです。シーケンスを逆方向にデコード/シークする場合と同様に、DC00-DFFF範囲内のコードユニットに遭遇した場合、次のコードユニットを見て、それが範囲内にあるかどうかを確認します。D800-DBFF範囲。これにより、デコード/シークが少し難しくなり、エラーが発生しやすくなります。
実際の文字使用のためにコードポイントの予約を解除DB00-DFFFするには、あいまいさを引き起こさない別の方法で特定のコードポイントをエスケープするために、UTF-16 エンコーディング スキームのロジックを変更する必要があります。ただし、現在のエンコード方式では、そのような変更は不可能です。したがって、それらは永久に予約されたままになります。