[PHP-users 12229] Re: bomつきutf-8 ファイルでのheader によるリダイレクト

[Osamu Shigematsu]

重松です。こんにちは。

> BOMをUTF-8に含みたいというわけではなく、何気なく使用したエディタでUTF-8というと
> デフォルトではBOMを含むのが普通だったので含んだ状態で作業を行っておりました。
> 今おもうと、そのエディタがおかしいんですね。

おかしくはないと思いますが、現実的な問題として、

問題:
	BOM を含む UTF-8 を使う場合 header() 関数が機能しない

解決案:
	(1) UTF-8N にする
	(2) 他の符号化形式にする
	(3) bugs.php.net を調べて、
		a. 直っている版があれば、アップデートする
		b. 直ってないなら、自分で直す
		c. 直るまで待ち、その間は他の解決案でしのぐ
	(4) あきらめる or mod_ruby とかにする

というような選択肢があり、実を取るなら (1) かなと。:-)

とりあえず、BOM のご利益としては、もしかしたら、Unicode だと
判定するときの材料となるかもしれない、ということくらいですね。

で、便乗質問になるのですが、PHP におけるエンコードの判断は、
どのようなアルゴリズムでなされているのでしょうか?

というのは、Ken Lunde 氏の「日本語情報処理」(CJVK の旧版) では、
エンコーディングの判断に固有のパターンの検出で行っていたのですが、
他のメーリングリスト (cppll) で、babel という template を見たときに、
( http://www.tietew.jp/cppll/archive/5944 )
最近の I18N 環境では、手法そのものが変わっていることに気づきました。

もし、BOM を判断材料としているならば、UTF-8 でも、BOM をつければ、
Unicode として判定するようになっており、そして、
そういう判断をするライブラリが多いようならば、
あながち UTF-8 の BOM も無駄とはいえない気もしないでもないです。

# libiconv だとか読めいいでしょうが、そこまで時間が取れていないので。

ただ、BOM がないことを前提としているコードも少なくないと思いますから、
影響はいろいろなところに及びそうですね。

すくなくとも、strlen() だとかそのあたりは当然だめでしょうし、
mb 系も対応が取れているのか、あと、正規表現だとか。

# ところで、PHP も鬼車に変わるんでしょうか? ライセンス的にも
# すっきりすると思うんですが。

> 結論としてはWEB系でUTF-8というと、UTF-8のことでなくUTF-8Nのことと
> 解釈すべきなのでしょうか。

yo-ji さんがお使いの PHP では?

-- 
Osamu Shigematsu <m5issige@mr.hitachi-medical.co.jp>