匿名質問者

仕事でUnix→Linux環境にアプリケーションを移植します。


影響範囲を調べていたのですが、
「表」などある特定の文字列を含むShift-JISのリテラルを
扱った時に文字化けが発生するという記事を見つけました。
ttp://security.cs.shinshu-u.ac.jp/~t_takeda/cat/index.php?Shift-JISと0x5C

原因はShift-JISでの該当文字の2バイト目が0x5cとなり、0x5cがバックスラッシュに
あたるため、エスケープとして扱われ、文字化けするということまでわかりました。

しかし、試しに移植予定の環境(RHEL6.3 Shift-JIS bash)でecho 表表と入力したところ、
特に文字化けもなく無事に表表と表示されておりました。

文字化けをしなかった原因ですが、
参考にした記事が古く、現在のbashが日本語対応したからなのかな??と
考えているのですが、正しいでしょうか?
# リリースノートを見てもbashがバージョンアップで日本語対応した、という
# メモは見つけられなかったのですが、他に理由が思いつかず・・・

回答の条件
  • 1人5回まで
  • 登録:
  • 終了:2013/04/24 23:25:04

回答1件)

匿名回答1号 No.1

本当はちゃんとソースを追った方が、と思いつつも、それには労力も時間も必要なので、ちょっと想像混じりで。

まず、bash がコマンドラインの入力を処理する時ですが、これは readline というライブラリを経由して処理しています。
The GNU Readline Library

で、readline の Ver 4.3 と合わせて、bash がマルチバイトに対応したのが 2002 年のようです。
bashがマルチバイト文字に正式対応 | スラッシュドット・ジャパン
上記ページには Shift_JIS や 0x5c の件には具体的に触れていませんが、とりあえず 10 年ぐらい前には、この辺の処理に対応できるようになっていたと思われます。

で、bash が正しく処理出来れば、echo に「表表」という引数が渡されるのですが、echo 自体は単に引数に渡された文字列をそのまま標準出力に出力するのがデフォルトの挙動なので、そもそも「0x5c」を見つけた時に何か特別な事をする必要がありません。「-e」オブションがついていれば、echo 自信が何らかの解釈をしますが、そうでなければ、そのまま標準出力に出すだけになります。

bash の場合に戻ってみると、bash コマンドラインで「\」記号に対して特別な解釈をする(エスケープ処理をする)ので、bash は正しく Shift_JIS を解釈できる必要があります。

あとは、標準出力先が正しく表示できるか、という問題になります。例えば、Windows から Teraterm や putty などでつないでいるケースであれば、それらのソフトが正しく Shift_JIS を扱えれば、正しく表示されます。ソフトの設定で文字コードの指定を間違えて文字化けした経験はあると思いますが、そこは合わせてしまえば正しく表示できます。ただ、Linux でテキストコンソールを使っている場合は、そもそも日本語の文字を表示出来ないケースが殆んどなので、テキストコンソールでの実行の場合は、文字コードによらず日本語の文字が表示出来ないことが多いです。

匿名質問者

まとまっていない質問に対し、
丁寧に回答していただきありがとうござました。
紹介していただいたリンク先も拝見させていただきました。

・bashは日本語化対応されている。
・エスケープと処理するか、2バイト文字として適切に
 判断されるかは入出力を行うコマンド次第
・受け取ったリテラルを適切に表示できるかどうかは出力先次第

ということですね。

試しにCで作成したアプリは文字化けを起こしたので、
回答者様のおっしゃるとおりだとわかりました。
と言うことは入出力を行うコマンドを洗い出して調べないといけないようですね・・・
なかなか大変そうです。

助かりました。
ありがとうございました。

2013/04/19 00:26:15

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

回答リクエストを送信したユーザーはいません