啞とｱが符号化できなかった問題についてもうちょっと深掘りしてみた（UTF-8）

前回の記事で、啞が消え、ｱがアにされてしまうという問題が発生した。 それに対し、前回の記事では「nkfの問題かな？」と予想していた。

そこで今回は、nkfによる変更を行わずに中身を見てみることにする。 test.txtはUTF-8で書かれているので、UTF-8の符号化を実際に見て見ることもできて一石二鳥だ。

コードと結果

コード

echo 'default:UTF-8'
cat $fname | hexdump  #普通に

出力結果

default:UTF-8
0000000 61 41 ef bd b1 e3 81 82 e9 98 bf e5 95 9e 0a 61
0000010 ef bd b1 61 e3 81 82 61 e9 98 bf 61 e5 95 9e 61
0000020 0a                                             
0000021

デコードしてみる

参考：Unicode文字ツール

61（a） 41（A） ef bd b1（ｱ） e3 81 82（あ） e9 98 bf（阿） e5 95 9e（啞） 0a（LF）

今回は、啞もｱも符号化されている。やったー。

61（a） ef bd b1（ｱ） 61（a） e3 81 82（あ） 61（a） e9 98 bf（阿） 61（a） e5 95 9e（啞） 61（a） 0a（LF）

ASCIIと制御コード以外は全て３バイトで、見やすくて良い。

感想

• JIS, Shift-JIS, EUCには半角カナ領域があるはずなのに、誤って全角カナとして符号化していた
• EUCには啞が含まれているはずなのに、符号化できなかった。
• nkfによる文字コード変換を行わないと、啞もｱも符号化されている様子が確認できた。

啞とｱはnkfで（UTF-8からJIS, Shift-JIS, EUCには）正しく変換できないことが分かった。