TSfree 発言

今日日比谷線でrmsらしき人を目撃したBruce.です。

T.Watanabe さんは書きました (2006/11/21 23:18):
>   まぁ何もしてないくせに偉そうなことは言えないんですけどね(^^;  PHP を書
> く人は他の言語を使ってる人よりもソースを読んだり仕様と挙動の違いを意識で
> きる人の割合が少ないんじゃないかという感じはしますね。フィードバックが足
> りてないってのはあるでしょうね。

裾野は思いっきり広いような気はするんですけどねえ (^^;
決して読みやすいソースではありませんでしたが、Perlに比べれば
まだまだですよ。とかゆってみる。

窓口みたいなものはあるんでしょうか?
ってわたしが報告するとは限らんのですが(笑)

今回これを見つけたきっかけは、UTF-8でスクリプトを書いていると、
マルチバイト文字を含んだファイル名の検索でファイルシステム上に
存在していても失敗してしまうという某MLでの投稿に始まるスレッド
です。

libcレベルでは、日本語Windowsであればファイル名はANSI(日本語
WindowsならShiftJIS(正確にはコードページ932))の文字列で渡さな
ければなりません。ですから、UTF-8文字列をlibcの関数に渡しても
変換する手間をかけなければ見つかりっこないわけです。

ところがフォローのメールの中に、UTF-16(およびUTF-32)に変換して
渡してやればfile_existによる検索で成功するというのがあったんで
すね。Win32APIレベルではANSIのものとは別にUnicode対応のものが
あるわけで、それを考えればUTF-16で渡して云々というのは納得で
きなくもありません。

しかし、そのためにはPHPの文字列オブジェクト(と云っちゃいますが)
が自分のエンコーディングが何者であるかを知らなければならないわけ
です。あるいは、UTF-16文字列に常にBOMが付いているのであれば、
それで見分けられるという可能性はあります。ただし、Win32APIに渡す
にはBOMをつけてはいけないので、やはりなんらかの手間がかかるわけ
です。

ということで疑問に思ってソースを眺めてみたのですが、Unicode対応
のAPIやlibcの関数をリンクしている気配がないと。そこでふと思いつ
いたのが、little-endianでならんでいて、BOMがないのであれば先頭
バイトがナルバイト(\0)になる可能性があるが果たして? ということで
試してみたらどんぴしゃり(笑)

ブラックボックスに適当な入力を放り込んだだけで仕様を云々しちゃ
いけませんね。MLには調査結果投げませんけど ;-P
ユーザーメーリングリストだから開発に近い人がいないってのは
あるかもしんないなあ。

ああ、思いっきり長くなってしまった。
すまんす。

-- 
木村浩一
  I thought what I'd do was, I'd pretend I was one of those deaf-mutes.
  mail kbk@...
        web  www.kt.rim.or.jp/~kbk/zakkicho/
             homepage3.nifty.com/farstar/