0x5c の話について補足

ASCII コードなんて覚えてないよ、的な反応がいくつかあったので補足。まぁ、説明してないんだから、そういう反応は当然なんだけど、あのエントリは文字エンコーディングに詳しい人はコードを覚えているという話ではない。
たとえば端末が CP932 な環境だと以下の様なことが起こる。

% perl -e 'print "表示\n"'
侮ｦ

% perl -e 'print "ソ"'
Can't find string terminator '"' anywhere before EOF at -e line 1.

まぁ、これは「表」と「ソ」の 2byte 目が 0x5c == 「\」 で、Perl が 「\」 を特別扱いすることが原因なんだけど、「\」 は escape character だったり directory separator だったりで、何かと特別扱いされることが多くて、2bytes 目に 0x5c が来る Shift_JIS/CP932 は何かと問題を引き起こすことが多い。
で、そういうところに何回かはまっていると、自然と(覚える気がなくても) 0x5c == 「\」 というのを覚えてしまうんじゃないか、というのがあのエントリの意味。というより自分が気が付いたら覚えていたなぁと。でも「A」の ASCII コードが何番かなんてことは覚えていない。
まぁ、本当のところをいうと、「文字エンコーディングの問題に詳しい人」というより、「Shift_JIS の 0x5c 問題によくはまる人」というぐらいの意味なんだけど。
あと、Shift_JIS や EUC-JP の 0x5c (YEN-Sign) を Unicode にマップするときも歴史的に事情があってアレだという話がある。たとえば、Linux の iconv はこんな挙動を示す。

% echo -n \\ | iconv -f CP932 -t UCS-2LE | hexdump
0000000 005c
0000002

% echo -n \\ | iconv -f Shift_JIS -t UCS-2LE | hexdump
0000000 00a5
0000002

% echo -n \\ | iconv -f EUC-JP -t UCS-2LE | hexdump
0000000 005c
0000002

不思議だね。