問題タブ [combining-marks]

文書化された変更で、「文字を結合する Unicode のより良い処理」というタイトルのリンクの説明をここに入力すると、VS Code は「文字を結合する Unicode の処理を​​改善し、そのようなシーケンスを (カーソル移動、編集操作、またはブロックで) アトミック文字として扱う」と述べています。カーソル レンダリング)". 私の問題は、それがまさに私がやりたくないことです。カーソル操作と編集操作で、基本文字と結合文字を別の文字として扱い、個別に編集できるようにしたい。

以前の動作 (切り替えなし) に戻す方法がないというのは正しいですか? (もちろん、以前のバージョンの VS Code をインストールすることもできますが、後で必要になる多くの変更が必要になる可能性が高いため、それは不利な提案です。) リクエストを送信する必要がありますか、それとも st を見落としていますか?

ところで、私は Unicode の正規化形式について知っています。NFC に正規化されると、カーソルは現在とほぼ同じように動作する必要があります。しかし、基本テキストが NFD である限り、結合文字を個別に編集できるようにしたいと考えています (特に、積み重ねられた分音記号を編集する必要がある場合に便利です)。

文字が占めるバイト数を決定するために、UTF-16 バイト ストリームを読み取るためのルールは何ですか? 私は標準を読みましたが、実際の UTF-16 でエンコードされたストリームの経験的な観察に基づいて、標準が当てはまらない場所があるようです (または、私が見逃している標準の側面があります)。 .

UTF-16 標準の読み取りからhttps://www.rfc-editor.org/rfc/rfc2781 :

実際には、少なくとも一部のケースでは、これが当てはまるようです。アドホック SQL スクリプト (SQL Server 2019; UTF-16 照合順序) を使用しますが、オンライン デコーダーでも検証されます。

ただし、次の ISO 10646 文字を UTF-16 にエンコードすると、4 バイトのように見えますが、先頭の 2 バイトを読み取っても、これほど長いかどうかはわかりません。

私は質問をソフトウェアにとらわれないようにしたいと思います。次の SQL は、既定の照合順序と既定の言語を使用して、Microsoft SQL Server 2019 でこの動作を再現します。(SQL Server はリトル エンディアンであることに注意してください)。

簡単に言えば、「このキャラクターの次の単語を読む必要がある」とどのように/なぜ0x2695考えますか? これが公開された UTF-16 標準と一致していないように見えるのはなぜですか?