文字コードが引き起こすセキュリティ上の問題として，もっとも興味深いもののひとつである，Unicodeから他の文字コードへの「多対一の変換」で引き起こされる問題点について，今回と次回で説明します。

ご存じのとおり，Unicodeには非常に多数の文字が収録されていますが（現在最新版のUnicode 5.1.0では100,713文字が収録されているそうです⁠）⁠，Unicodeから他の文字コードへの変換においては，互換性や可読性の維持のためか，複数のUnicodeの文字が他の文字コードでは単一の文字に変換されることがあります。

この「多対一」の変換が，開発者も想定していなかったような問題を引き起こす原因となることが多々あります。

具体的な例として，Windows上でのUnicodeからの変換について説明します。

Windows上でのUnicodeからShift_JISへの変換

Windows上での文字列のUnicode（UTF-16LE）からShift_JISへの変換においては，多くの場合APIのWideCharToMultiByteが使用されます。

このWideChatToMultiByte関数は，2番目の引数にWC_NO_BEST_FIT_CHARSというフラグを指定することができます。

WC_NO_BEST_FIT_CHARSを指定した場合，Unicode文字に対応するShift_JISの文字が存在しない場合には，特定の文字(デフォルトでは '?')に変換されます。

WC_NO_BEST_FIT_CHARSが指定されていない場合，Unicode文字に対応するShift_JISの文字が存在しない場合には，「よく似た文字」に変換されてしまいます。

WC_NO_BEST_FIT_CHARSを指定せずにWideCharToMultiByte関数を実際に呼び出した場合の文字の変換例を，表1に示しておきます。

この表を見るとわかるように，例えば発音記号のついた文字「À」（⁠U+00C0）やU+00C1（Á）はShift_JISに変換すると「A」（⁠0x41）に置き換わりますし，コピーライトマーク「©」（⁠U+00A9）は 「⁠c」（⁠0x63）に置き換わります。

このように，WC_NO_BEST_FIT_CHARS を設定しない変換においては，Unicode と Shift_JIS の間では多対一の変換が行われてしまいます。