Unicode

コーディング

サロゲートのエンコーディングは、符号位置を ${\displaystyle CP}$、ハイサロゲートを ${\displaystyle HSG}$、ローサロゲートを ${\displaystyle LSG}$ とすると次の通りに計算する。

${\displaystyle HSG=\mathrm {floor} \left({\frac {CP-10000_{16}}{400_{16}}}\right)+{\rm {D800}}_{16}}$

${\displaystyle LSG=\left(CP-10000_{16}\right){\bmod {4}}00_{16}+{\rm {DC00}}_{16}}$

デコーディングは、

${\displaystyle CP=10000_{16}+\left(HSG-{\rm {D800}}_{16}\right)\times 400_{16}+\left(LSG-{\rm {DC00}}_{16}\right)}$

である。

コード変換例

「𠮷^{[注釈 4]}」U+20BB7 のエンコードを考えてみる。

${\displaystyle {\color {green}0010\ 0000\ 10}{\color {blue}11\ 1011\ 0111}_{2}\ ({\rm {20BB7}}_{16})}$ から

${\displaystyle 0001\ 0000\ 0000\ 0000\ 0000_{2}\ (10000_{16})}$ を引くと、結果は

${\displaystyle {\color {green}0001\ 0000\ 10}{\color {blue}11\ 1011\ 0111}_{2}\ ({\rm {10BB7}}_{16})}$ となる。

これを上位10ビット値と下位10ビット値に分割する。

${\displaystyle {\color {green}0001\ 0000\ 10}_{2}\ ({\color {green}0042}_{16}),\ \ {\color {blue}11\ 1011\ 0111}_{2}\ ({\rm {\color {blue}03B7}}_{16})}$

ハイ（上位）サロゲートを形成するために上位ビットに ${\displaystyle {\rm {D800}}_{16}}$を加える。

${\displaystyle {\color {green}00\ 0100\ 0010}_{2}\ ({\color {green}0042}_{16})+1101\ 1000\ 0000\ 0000_{2}\ ({\rm {D800}}_{16})=1101\ 10{\color {green}00\ 0100\ 0010}_{2}({\rm {D842}}_{16})}$

ロー（下位）サロゲートを形成するために下位ビットに ${\displaystyle {\rm {DC00}}_{16}}$ を加える。

${\displaystyle {\color {blue}11\ 1011\ 0111}_{2}\ ({\rm {\color {blue}03B7}}_{16})+1101\ 1100\ 0000\ 0000_{2}\ ({\rm {DC00}}_{16})=1101\ 11{\color {blue}11\ 1011\ 0111}_{2}({\rm {DFB7}}_{16})}$

結果

${\displaystyle {\rm {\color {green}D842}}_{16},\ {\rm {\color {blue}DFB7}}_{16}}$ (UTF-16 符号単位列)

${\displaystyle {\rm {\color {green}D8}}_{16},\ {\rm {\color {green}42}}_{16},\ {\rm {\color {blue}DF}}_{16},\ {\rm {\color {blue}B7}}_{16}}$(UTF-16BEでの符号化バイト列)

${\displaystyle {\rm {\color {green}42}}_{16},\ {\rm {\color {green}D8}}_{16},\ {\rm {\color {blue}B7}}_{16},\ {\rm {\color {blue}DF}}_{16}}$(UTF-16LEでの符号化バイト列)

次の表は、この文字変換と他をまとめたものである。 色は、コードポイントからのビットがUTF-16バイトにどのように分配されるかを示した。 なお、UTF-16エンコーディングプロセスによって追加された追加ビットは黒で示されている。

YEN SIGN 問題

Shift JIS では JIS X 0201 における（日本や中国の通貨の）円記号 "¥" が 0x5C に置かれている。これを Unicode のマッピングに合わせると YEN SIGN (U+00A5) にマップされる。しかし、0x5C は ASCII ではバックスラッシュ "\" に相当し、C言語などでエスケープ文字として使われる事から、この文字のコードを変更すると問題が起きる。極端な例として、0x5C が円記号とエスケープ文字の両方の目的で使われているケース（たとえばC言語のprintf関数で printf("¥¥%d¥n", price); など）も考えられる。

そのため、Unicode を利用するアプリケーションでは、U+007F 以下のコードに関しては移動させないという暗黙のルールができている。

そうなると、Unicode 環境では円記号がバックスラッシュの表示に変わってしまうように思われるが、これは日本語用のフォントデータの 0x5C の位置には円記号の字形を当ててしまうことで対処している。これによって、日本語環境での表示上は 0x5C の位置で円記号を用いることができる。

この問題は日本語環境に限ったことではない。もともと ISO 646 上では、0x5C を含む数種の文字は自由領域（バリアント）として各国での定義を認めていた。そのため、日本語以外でも ASCII でバックスラッシュに相当するコードに異なる記号を当てているケースが多い。例えば、韓国では通貨のウォン記号 (WON SIGN, U+20A9, "₩")、デンマークやノルウェーではストローク付きO (LATIN CAPITAL LETTER O WITH STROKE, U+00D8, "Ø") などである。（後者は後の時代には、0x5C はバックスラッシュのままとし、ISO 8859 シリーズを用いることが一般化した。）

波ダッシュ・全角チルダ問題

JIS X 0221 規定の JIS X 0208 と JIS X 0221 の対応表では、波ダッシュは WAVE DASH (U+301C, "〜") に対応させている。

しかし、マイクロソフトは Windows の Shift_JIS と Unicode の変換テーブルを作成する際に、JIS X 0208 において 1 区 33 点に割り当てられている波ダッシュ "〜" を、Unicode における全角チルダ (FULLWIDTH TILDE, U+FF5E, "～") に割り当てたため不整合が生じた。

この結果、macOS 等の JIS X 0221 準拠の Shift_JIS ⇔ Unicode 変換テーブルをもつ処理系と Windows との間で Unicode データをやり取りする場合、文字化けを起こすことになる。そこで Windows 以外の OS 上で動くアプリケーションの中には、CP932 という名前でマイクロソフト仕様の Shift_JIS コード体系を別途用意して対応しているケースが多い。この原因とされている Unicode 仕様書の例示字形の問題に関しては、波ダッシュ#Unicodeに関連する問題を参照。