[前へ]   [目次へ]   [次へ]

0x5c問題


いよいよ、0x5c問題について書きます。

まず、0x5c問題とは何かということですが、
とりあえず私は、「2バイト目に0x5cを含む文字が起こす問題全般」だと考えています。
この「2バイト目に0x5cを含む文字」は後述します。(・・・もう見えてるかもしれませんが(笑))

その中で今回書くのは英語版環境や日本語処理に問題がある環境で発生する問題です。
(文字コード指定可能な環境ならば当然文字コードを正しく指定しなければ問題が発生します。
   言語が漢字(文字)コード指定を持っている(だったはず)のRuby言語では要設定確認です)
   
ちなみに何で英語版は問題になるのかといえば、たいていの場合、1文字を2バイトで表すなんてこと自体、
考えて作られてないからです。(アルファベットだけなら1バイトで十分)

前回のASCIIコード表を見ていただけると分かると思いますが、0x5cは「\」です。

そして、「\」は多くの言語で特別な扱いをされています。
さらに、この文字はShift_JISの日本語第2バイトとしても存在しています。

英語版や日本語処理に問題があると、この日本語第2バイトにある0x5cをエスケープシーケンスと勘違いしてしまいます。
その結果、予期せぬ結果をもたらすというわけです。

以下が、Shift_JIS文字コードにおいて2バイト目に0x5cを持つ文字の一覧です。

― ソ Ы \ 噂 浬 欺 圭 構 蚕 十 申 曾 箪 貼 能 表 暴 予 禄 兔 喀 媾 彌 拿 杤 歃
濬 畚 秉 綵 臀 藹 觸 軆 鐔 饅 鷭 x x \ \


以上の文字をエスケープシーケンスが解釈される部分で使用するとこの0x5c問題が発生します。
比較的よく使われると思われる「ソ」「十」「貼」「能」「表」「暴」「予」
ぐらいは覚えておいたほうがいいかもしれません。

で、発生すると何が起こるのかというと、
これらの第2バイトがエスケープシーケンスの開始として扱われ、次の1文字と結合します。
その結果、エスケープシーケンスが成立するとそのように扱われ、
成立しなかった場合はその2文字は消滅するか、その他の挙動を示します。
(これは実行しているほうが無効なエスケープシーケンスを見つけたときの挙動になります。大抵は消滅するようです)

どちらにせよ、本来の第2バイトを失った文字はその次にたまたま続いたバイトを第2バイトとして扱います。
もう何になるか分かりませんね(笑)。

これはperl(英語版なのでこの問題を抱える)で遭遇した問題ですが、
print "一覧表"
と書いて実行したところ、よく分からないエラーが発生して「?」となったことがあります。

この場合、「表」が0x5c問題を発現させ、さらに次の文字列の終了である"とくっついて
\"(文字"を表す)エスケープを成立させてしまいました。
結果として文字列の終了は消え去り、その後も文字列として処理され、最終的にエラーになりました。

しかも、エディタで見てると全く分かりません。
完璧に書いてあるように見えます。
だからこそこの0x5c問題は厄介なのです。
これはもう暗記しておくしかないかもしれません。

こんな時は問題の文字の直後に\を付け足すと、問題が発現しても
\\(文字\を表す)エスケープが成立し、\が一個減り、一個残ります。
これで第2バイトは変化せず、正しく表示されます。

今調べて分かったのですが、続く文字列のパターンによっては、
文字列終了直後に全角文字にでくわして
Unrecognized character \x8B at test.pl line 3. 
のようなエラーも発生することがあるようです。

[前へ]   [目次へ]   [次へ]

プログラミング講座 総合目次

最終更新 2008/10/17