アカウント名:
パスワード:
タイムリーなことに、ちょっと前にSquirrelMail を PHP5.4 に対応させた [srad.jp]のですが、原因を一言出言うと「htmlspecialchars の仕様変更のせいで、Shift_JISやEUC-JPで表示するサイトでは、エンコーディングを明示的に指定しないhtmlspecialcharsの結果が空になる」というものです。
機械的な置換で容易に修正対応はできましたが、そんな泥臭いパッチをSquirrelMailの方に投げる気にもなれず、もうまさにPHPの仕様の変更を「仕様バグ」だと主張したい気分です…
EUC-JP/Shift_JISのサイトは、PH
元仕様も未定義なうえ振る舞いを変更したことも明記されていない物を仕様変更と言うのは
いや、htmlspecialchars のリファレンス [php.net]には
encoding 変換に使用されるエンコーディングを指定します。 省略した場合のデフォルト値は、PHP 5.4.0 より前のバージョンでは ISO-8859-1、そして PHP 5.4.0 以降では UTF-8 となります。
と仕様変更が明記されていますよ。その後に
この関数を使ううえでは ISO-8859-1 と ISO-8859-15、 UTF-8、cp866、 cp1251、cp1252 そして KOI8-R は事実上同等です。 string 自体がそのエンコーディングにおける有効な文字列である限り、 これらのエンコーディングでは htmlspecialchars() の影響が及ぶ文字がみな同じ位置にあるからです。
というもっととんでもない大嘘が書かれてたりしますが…日本以外でも、欧州の、ISO-8859-1で、英語以外のラテン文字(0xA0～0xFEの文字)を使ってるサイトを作っている人も同じようにはまるはず。でも、PHPの開発コミュニティはこれを「既存のコードに影響を及ぼさない変更」だと信じてるんでしょうねぇ…
じゃあ、やっぱりPHPがバグなんだよ。
# 元ネタに習い、糞野郎とでも付けておきましょうか？
まぁ、specialchars なんていう、仕様・定義を参照したら選びそうにない名前な時点でお察し。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
仕様の変更を一方的にバグとして元に戻せと主張する (スコア:5, 興味深い)
タイムリーなことに、ちょっと前にSquirrelMail を PHP5.4 に対応させた [srad.jp]のですが、原因を一言出言うと「htmlspecialchars の仕様変更のせいで、Shift_JISやEUC-JPで表示するサイトでは、エンコーディングを明示的に指定しないhtmlspecialcharsの結果が空になる」というものです。
機械的な置換で容易に修正対応はできましたが、そんな泥臭いパッチをSquirrelMailの方に投げる気にもなれず、もうまさにPHPの仕様の変更を「仕様バグ」だと主張したい気分です…
EUC-JP/Shift_JISのサイトは、PH
Re:仕様の変更を一方的にバグとして元に戻せと主張する (スコア:0)
元仕様も未定義なうえ振る舞いを変更したことも明記されていない物を仕様変更と言うのは
Re:仕様の変更を一方的にバグとして元に戻せと主張する (スコア:4, 興味深い)
いや、htmlspecialchars のリファレンス [php.net]には
と仕様変更が明記されていますよ。その後に
というもっととんでもない大嘘が書かれてたりしますが…
日本以外でも、欧州の、ISO-8859-1で、英語以外のラテン文字(0xA0～0xFEの文字)を使ってるサイトを作っている人も同じようにはまるはず。
でも、PHPの開発コミュニティはこれを「既存のコードに影響を及ぼさない変更」だと信じてるんでしょうねぇ…
Re:仕様の変更を一方的にバグとして元に戻せと主張する (スコア:1)
元仕様も未定義なうえ振る舞いを変更したことも明記されていない物を仕様変更と言うのは
じゃあ、やっぱりPHPがバグなんだよ。
# 元ネタに習い、糞野郎とでも付けておきましょうか？
Re:仕様の変更を一方的にバグとして元に戻せと主張する (スコア:1)
まぁ、specialchars なんていう、仕様・定義を参照したら選びそうにない名前な時点でお察し。