TSfree 発言

Bruce.です。

ずるずると一ヶ月近く経ってしまいました。
#「五島勉｣って「ごとうべん」だよねえ

T.Watanabe writes:

> > んーここでいう「内部エンコーディング」とは具体的には何を意味している
> > のでしょうか?
> > スクリプト中に記述するときのエンコーディング?
> 
>   すいません、これは PHP 用語ですね。
> 
>   内部エンコーディング
>       スクリプトが文字列のエンコーディングとして想定しているもの
>   スクリプトエンコーディング
>       スクリプトの記述に利用するエンコーディング
> 
>   のはずです。（違ったらごめんなさい。）Ruby で言うと -K オプションに当
> たるのかな？

ちょうど? この辺に絡んだ話題が盛り上がってますね。

odz buffer - 文字化け
http://d.hatena.ne.jp/odz/20070215/1171555360

よくきたはてダ - 惜しいが間違っている
http://d.hatena.ne.jp/elf/20070214/1171381343

ＰＨＰの文字化けを本気で解決する - ぎじゅっやさん
http://hain.jp/index.php/tech-j/2007/02/13/p125


まあ同じようなもののようですね。


>   で、上のように生で書いちゃってるので、スクリプトエンコーディングと内部
> エンコーディングは当然一致してないと困るのです。これをしかし Python のように
> 
>   u"日本語"
> 
>   と書けるのであれば、ファイル自体は euc-jp でもそこに書かれている日本語
> の文字列を utf-8 として処理するっていうのが可能なんじゃないかなと思った
> わけです。そうするとリポジトリ内のファイルのエンコーディングをど
> ばーーーーっとまとめて変更しなくても、ちまちま変更していくことは可能だ
> なーと思ったわけです。

これをやるためには基準となるエンコーディング(≒Unicode)が必要となるわけで、
それはそれで茨の道ではないかと。単に符号拡張すればいいASCII圏の方々には
わかってもらいにくい数々の障壁がそこにはあるのですよ。
欧州の言語(フランス語とかドイツ語とか)でもひっかかることあるんだけどねい。


>   まぁ、皆さん仰るように触らぬ神に祟りなしですし、急ぎの要求はないのです
> が、個人的に心配になるケースもなくはないので utf-8 に移行できるならした
> 方がいいのかなーという気持ちもあるんですね。というのも、レガシーなサイト
> でよくある作りは
> 
>   内部               euc-jp
>   HTTP出力           sjis
>   期待されるHTTP入力  sjis
> 
>   だと思うんですけど、euc-jp と sjis ってあんがい誤判定が起きますよね？

euc-jpかsjisかの二択ならまあがんばれば(統計情報とかを活用)ある程度は
誤判定を避けられると思いますが、元文字列が十分な長さを持っていないとか
だと厳しいでしょうね。とくにそこに半角かながあったりすると。

ただPHPの場合はほかのスクリプティング言語と違って、生のテキストファイル
を扱うことはあまりないように思われるので、テキストストリームのビット
パターンから判定することはしないほうがかえって良いかも。

先のblogでも触れられていたと思いますが、webに関していえば今日では
自動変換を使うことの意味はほぼないんじゃないですかねえ。腐れたブラウザも
もう無視できるほどしかないでしょう。

いじょ。