文字が占めるバイト数を決定するために、UTF-16 バイト ストリームを読み取るためのルールは何ですか? 私は標準を読みましたが、実際の UTF-16 でエンコードされたストリームの経験的な観察に基づいて、標準が当てはまらない場所があるようです (または、私が見逃している標準の側面があります)。 .
UTF-16 標準の読み取りからhttps://www.rfc-editor.org/rfc/rfc2781 :
| 先頭 2 バイトの値 | 結果の文字長 (バイト) |
|---|---|
0x0000-0xC7FF |
2 |
0xD800-0xDBFF |
4 |
0xDC00-0xDFFF |
無効なシーケンス (RFC2781 2.2.2) |
0xDFFF-0xFFFF |
4 |
実際には、少なくとも一部のケースでは、これが当てはまるようです。アドホック SQL スクリプト (SQL Server 2019; UTF-16 照合順序) を使用しますが、オンライン デコーダーでも検証されます。
| キャラクター | ユニコード名 | ISO10646 | UTF-16 エンコード (16 進数、ビッグ エンディアン) | サイズ (バイト) |
|---|---|---|---|---|
| あ | ラテン大文字 A | U+0041 | 00 41 |
2 |
| Б | キリル大文字BE | U+0411 | 04 11 |
2 |
| ァ</td> | カタカナ小文字A | U+30A1 | 30 A1 |
2 |
| うさぎの顔 | U+1F430 | D8 3D DC 30 |
4 |
ただし、次の ISO 10646 文字を UTF-16 にエンコードすると、4 バイトのように見えますが、先頭の 2 バイトを読み取っても、これほど長いかどうかはわかりません。
| キャラクター | ユニコード名 | UTF-16 エンコード (16 進数、ビッグ エンディアン) | サイズ (バイト) |
|---|---|---|---|
| ⚕️ | アスクレピオスの杖 | 26 95 FE 0F |
4 |
私は質問をソフトウェアにとらわれないようにしたいと思います。次の SQL は、既定の照合順序と既定の言語を使用して、Microsoft SQL Server 2019 でこの動作を再現します。(SQL Server はリトル エンディアンであることに注意してください)。
select cast(N'⚕️' as varbinary);
----------
0x95260FFE
簡単に言えば、「このキャラクターの次の単語を読む必要がある」とどのように/なぜ0x2695考えますか? これが公開された UTF-16 標準と一致していないように見えるのはなぜですか?