それぞれ文字コードを指定できると思いますが、
お奨めの文字コードとその理由をお教えください。
また、お奨めでない文字コードについても、理由とともにお教えください。
私はなんとなくshift-jisを使うことが多いのですが、
EUCとかUTF-8なんかを使っているところを良く見かけるので、
気になっています。
perl上で正規表現や関数を使って日本語を含む文字列を検索したり変換したりする場合は、SJISには気を付ける必要があると思います。
EUCの場合は第1バイト目も第2バイト目も0xA1~0xFEに固定されていますが、SJISは第2バイト目の文字に0x40~0x7E が使われていて、文字で表すと、0x40は"@"、0x74は"t"みたいな感じに通常の半角文字としても扱えるコードが含まれています。
以下のプログラムをSJISで作って実行すると結果は"ァァイル"と表示されてしまいます。ぱっとみると分かりにくいですが、2行目の正規表現は「$s=~s/\x74/\x40/;」と同じと考える事ができ、SJISの第2バイト目の文字コードである0x40~0x7Eが含まれている事が分かります。
これを実際に実行してみると、"フ"のSJISコードは 0x83,0x74 なので、0x74が0x40に変換され、0x83,0x40の文字である"ァ"が表示される事となります。
$s="ファイル"; $s=~s/t/\@/; print $s;
文字コードにおススメっていうのはないのですが、文字化けを防ぐのに変更が必要な場合があります。プログラムが入るとEUCやUTF-8を使います。サーバの仕様によるところもあるので、やはりおススメは…?
perl上で正規表現や関数を使って日本語を含む文字列を検索したり変換したりする場合は、SJISには気を付ける必要があると思います。
EUCの場合は第1バイト目も第2バイト目も0xA1~0xFEに固定されていますが、SJISは第2バイト目の文字に0x40~0x7E が使われていて、文字で表すと、0x40は"@"、0x74は"t"みたいな感じに通常の半角文字としても扱えるコードが含まれています。
以下のプログラムをSJISで作って実行すると結果は"ァァイル"と表示されてしまいます。ぱっとみると分かりにくいですが、2行目の正規表現は「$s=~s/\x74/\x40/;」と同じと考える事ができ、SJISの第2バイト目の文字コードである0x40~0x7Eが含まれている事が分かります。
これを実際に実行してみると、"フ"のSJISコードは 0x83,0x74 なので、0x74が0x40に変換され、0x83,0x40の文字である"ァ"が表示される事となります。
$s="ファイル"; $s=~s/t/\@/; print $s;
今は UTF-8 が無難な気がします。
たとえば、近頃の Redhat の httpd.conf(Apache の設定ファイル)では、HTTP プロトコル上で文字コードを告げる「AddDefaultCharset」という項目が UTF-8 に設定されています。この場合、UTF-8 で書かれた HTML であれば、プロトコル上と実際のコンテンツの文字コードが一致していることになり、誤った文字コードで判断される確率が少なくなります。
よく、HTML で meta タグで文字コードを指定する話がありますが、あれは、あくまでも HTTP プロトコル中で文字コードが宣言されなかったケースを補うもので、本来は HTTP プロトコル中で宣言された文字コードが優先されます(といっても、IE は違いますが...)。
と考えると、とりあえず UTF-8 で書いておけば、上記のようなデフォルト状態の Web サーバでも、文字化けを防ぐ事ができます。
あと、XHTML のデフォルトの文字コードも UTF-8だし、近頃の Linux のデフォルトの文字コードも UTF-8 になってきているし、全体として UTF-8 という文字コードを使う下地が出来上がってきた感じがします。
ちなみに、本来の Shift-JIS と Windows で言っている Shift-JIS とは厳密には違います。この辺も、Shift-JIS でのトラブル要因になったりします。
perl5.8で日本語周りはかなり整備されたので,Shift_JISの問題はさほど気にしなくても良いのではないかと。例えばhachi2eeさんが例として挙げられているコードであれば,以下の様にencodingプラグマで文字コードを指定してやればうまく動きます。
#! /usr/bin/perl use encoding 'sjis'; my $s = "ファイル"; $s =~ s/t/\@/; print $s; 1;
最近はJavaScriptを使うケースが増えているので,そちらとの相性を考えるとUTF-8が無難ではないかと思います。
コメント(0件)