Webアプリ開発に関する記事を書いています。他の話題（映画、音楽等）は別ブログで。
2009-10-06
htmlspecialcharsに関する残念なお知らせ
「htmlspecialcharsのパッチ私案」に書いた件、バグレポートを出してみましたが、「すでに同じバグレポートがあるだろ」という理由により、あえなく却下されました。
せめて先方が「同じ」とみなしているレポート番号ぐらいは示してほしくて、そのようにコメントしましたが、お相手のjaniという人は気難し屋のようで*1、教えてもらえる気がしません。
私なりに探した結果、下記のレポートがくさいように感じました。
「不正なUTF-8シーケンスの場合に空文字列を返すのはおかしい」というレポートで、私のそれとは正反対どころか、Shift_JISにもEUC-JPにも触れられていない別個のものです。もちろん、私はレポート送信前に読み、別個と判断しました。
とはいえ、これぐらいしか似たようなレポートが見つかりません。他にあるようでしたら、ぜひお教えください。
#43896 についたコメントを見ると、どうも「PHPの利用者が自分で対処するのが正解」という流れになっているようです。もし、その基準にもとづいて私のレポートが却下されたのであれば、今後も htmlspecialchars の文字エンコーディング妥当性チェックが改善される見込みは薄いでしょう。残念ながら、自衛するしかないと思われます。
追記（2009-10-07）
PHPの開発陣には期待できないことが分かったので、Suhosinにfeature wishesとしてメールしてみました。
Suhosinについては下記の記事が参考になります。
もしリプライがなければ、私はもうお手上げです。私の書いたパッチは自由に使っていただいてかまいませんが、保守するつもりはありませんので、ご了承ください。ここから先は、PHPを愛している方たちにおまかせします。
追記その2（2009-10-08）
日本語のブログのURL書いて「危ないです」というのも、"I don't know whether it is useful though :)"なんて日本的謙遜も、伝わらなくても仕方ないかと
はてなブックマーク - AKIMOTOのブックマーク
ありがとうございます。このようなご意見を待っていました。
id:AKIMOTOさんに限らず、私のレポートの仕方が悪かったせいだと思われる方、ぜひ本件を引き継いでいただけないでしょうか。私の望みは htmlspecialchars の文字エンコーディング妥当性チェックが改善されることであって、どなたかが達成されるのであれば、それで万々歳です。採用されるレポートの書き方もそれで分かるでしょうし。
「いや、お前のレポートのせいで改善される見込みがなくなったんだ、余計なことをするな」といわれるのであれば、「それは残念です」とお答えするほかありません。
追記その3（2009-10-08）
ご指摘ありがとうございます。生かせるものは生かしたいと思います。
私は今回の件については、意図が伝わらなかったせいで却下されたのではなく、伝わったうえで却下されたのだと思っています。PHP開発陣の総意は「htmlspecialchars にはバリデーションの責務はない」というもので、その立場に立てば、記述が丹念であろうとなかろうと、過去に似たようなバグレポートがあろうとなかろうと、私のレポートを却下して当然です。
レポートを通じて気づかされたPHP開発陣の総意、つまりPHPの仕様は、私には「残念」なものでした。記事タイトルの「残念」には、そういう意味が込められています。テンプレートエンジンなんだから、validateしたっていいと思うんだけどねえ。PHPの残念さを見くびってました。
追記その4（2009-10-08）
なんども追記すみません。私なりに良案が浮かんだので、別のバグレポートを提出してみました。
ポイントは：
- セキュリティの話にはアレルギーがありそうなので、純粋なバグレポートにした
- 相手の言質（ChangeLog）を利用した
- 冗長なUTF-8については諦めた（仕方ない）
の3点です。
これならすぐには却下されない（ひょっとしたら採用される）と思うんですが、どうなるでしょうか。
*1：OS欄に「All」と書いてあるレポートに対して、毎度「AllというOSはない」と返しているところから、そう感じました。もし「*」と入力するのが正解なのであれば、レポートフォームにそう注意書きしときゃいいのにね。