EUC-JP と Shift_JIS を相互に変換する際、0x5c と 0x7e の扱いが問題になります。EUC-JP と Shift_JIS は長い歴史があり、日本の人々にはこれらを扱ってきた長い経験があります。 それを紹介します。
訳注: なぜ問題になるかというと、EUC-JP の 0x21 から 0x7e までの範囲は ASCII であり、 Shift_JIS の 0x21 から 0x7e までの範囲は JIS X 0201 ローマ字だからです。ASCII と JIS X 0201 ローマ字はほとんど同じですが、0x5c と 0x7e だけが異なります。 ASCII では 0x5c と 0x7e はそれぞれ逆スラッシュとチルダですが、 JIS X 0201 ローマ字ではそれぞれ円記号とオーバーラインです。 ですので、厳密には、0x5c と 0x7e は変換できないのです。 ただし、JIS X 0201 ローマ字の 0x7e はチルダでもかまわないことになっているそうですので、 0x5c だけが問題となります。
解決法は非常に単純です。円記号と逆スラッシュとを、 同じ文字の異なるグリフだとみなすのです。そうすると、 ASCII と JIS X 0201 ローマ字との相違は無視できます。
訳注: 文字とグリフ。文字は抽象的な概念です。 それを具体的に目に見える形にしたものがグリフです。 たとえば、「あ」という文字があったとき、 それを半角にしても全角にしても、あるいは点字でも同じ「あ」 という文字です。ただし「あ」と「ア」は違う文字です。 ちなみに、悪評高い統合漢字ですが、たとえば日本漢字の 「骨」と中国漢字の「骨」とを統合していますが、 Unicode Consortium の見解としては、 それらが同じ文字の違うグリフだから統合するのは正しい、 というものです。
つまり、ある日本人 (たいていの日本人はエンコーディングに関する 知識を持っていません。ある一定の人々 [Windows と Macintosh のユーザ] が「Shift_JIS」を唯一のエンコーディングの名前として 知っています) が「Shift_JIS」と言うとき、実際にはそれは 「CP932」を意味しています。
Shift_JIS と CP932 の違いを知らない、 そのような日本の人々のことを責めないでください。 Shift_JIS と CP932 の違いは、実際には、CP932 は (マイクロソフトの) 独自拡張文字がある、というだけなのです。 混乱のもととなる、Shift_JIS と CP932 の記号の非互換性を もたらしたのは Unicode なのです。
日本の人々が「Shift_JIS」と言えばたいていそれは「CP932」 を意味する、と私は言いましたが、その理由を説明します。 たとえば、DOS/Windows のプログラマは、Shift_JIS で (厳密には CP932 で) 円記号 + 「n」と表記することによって 「改行」を表現しようとします。このことが、Microsoft が CP932 の 0x5c を U+005C 以外に変換することができない理由なのです。
Windows ユーザだけでなく UNIX ユーザも、Shift_JIS の 0x5c が円記号なのか逆スラッシュなのかについて、 多義性があるものとみなしてとらえています。たとえば、 広く普及している日本語のエンコーディング変換プログラムである nkf や qkc は、ASCII (EUC-JP の 0x21-0x7e) と JIS X 0201 ローマ字 (Shift_JIS の 0x21-0x7e) とを区別しません。 私はよく、Windows 上で動く telnet/ssh クライアントの TeraTerm を使いますが、円記号が出てくると私はそれを文脈に従って 逆スラッシュに読み換えます。(文脈とはつまり、 日本人が書いたものならたいてい円記号とみなし、 日本人以外が書いたものならそれはいつも逆スラッシュとみなせる、 ということです)。
このように、私は Shift_JIS の 0x5c が U+005C に変換されても 文句を言いません。むしろ、EUC-JP と Shift_JIS における ASCII と JIS X 0201 ローマ字の違い (言いかえれば、公式の規格を厳密に解釈すること) のほうが、多くの日本人を混乱させます。