本当は怖い文字コードの話：第8回 Unicodeからの多対一の変換［後編］ ｜gihyo.jp … 技術評論社（情報元のブックマーク数）
はせがわさんの、怖い怖い文字コード（違ｗｗｗｗ
UNICODEによるディレクトリトラバーサルとか色々ありましたねぇ・・・
いくつかのメールクライアントは，添付ファイル名をUnicodeからShift_JISに変換して開こうとしますので，添付ファイルにU+00A9のコピーライトマーク「c」を使った「cON」やU+00A5の円記号「\」を使った「\..\..\windows\win.ini」のようなファイル名を与えると，Shift_JISへの変換の結果ファイル名が「CON」というWindowsでの予約デバイス名や，「h..h..hwindowshwin.ini」（hは0x5Cのバックスラッシュすなわちディレクトリ区切り記号）となり，メールクライアントが固まる，あるいは既存のファイルを上書きして添付ファイルを展開してしまうという問題がありました。
第8回 Unicodeからの多対一の変換［後編］ ：本当は怖い文字コードの話｜gihyo.jp … 技術評論社
UNICODEから他のエンコーディングへの変換が発生していることを開発者が理解していて、それが脆弱性になりえることを想像できるか・・・
このように，Unicodeから他の文字エンコーディングへの変換によって引き起こされる脆弱性というのは，さまざまなソフトウェアのさまざまな個所で発生しています。
第8回 Unicodeからの多対一の変換［後編］ ：本当は怖い文字コードの話｜gihyo.jp … 技術評論社
気をつけなければいけないのは，「Unicodeから他のエンコーディングへの変換」が開発者も意識していない暗黙のうちに発生することがあるという点です。
うっはー、色々な場面で変換されるんですね、、、これは結構大変だ。
それ以外にも外部DLLの呼び出し時の引数の変換（たとえばVBにおけるDLLとの文字列の受け渡しやC#におけるDllImportでのCharSet=CharSet.AutoあるいはCharSet=CharSet.Ansiの指定など），クリップボードからCF_TEXTを指定してのANSI文字列としてのテキストの取得など，プログラマが明示的に意識していない場合でもUnicodeからShift_JISへ変換される機会は多数あります。
第8回 Unicodeからの多対一の変換［後編］ ：本当は怖い文字コードの話｜gihyo.jp … 技術評論社
これらの変換においては，WC_NO_BEST_FIT_CHARS を指定していない「似ている文字への変換」と同様の変換方法が使用されるため，脆弱性につながることになります。
