アカウント名:
パスワード:
タイムリーなことに、ちょっと前にSquirrelMail を PHP5.4 に対応させた [srad.jp]のですが、原因を一言出言うと「htmlspecialchars の仕様変更のせいで、Shift_JISやEUC-JPで表示するサイトでは、エンコーディングを明示的に指定しないhtmlspecialcharsの結果が空になる」というものです。
機械的な置換で容易に修正対応はできましたが、そんな泥臭いパッチをSquirrelMailの方に投げる気にもなれず、もうまさにPHPの仕様の変更を「仕様バグ」だと主張したい気分です…
EUC-JP/Shift_JISのサイトは、PHP5.3を使い続けるか、UTF-8になんとか移行するか、どちらかがまあ建設的な対応でしょうね。
ていうか、mbstring を入れてる場合、内部に internal_encoding という設定があるんだから、文字エンコーディングに関係する処理で internal_encodingを無視するのは仕様バグ以外の何者でもないだろうに…
似たような感じで、 "09223372036854775808" == "9223372036854775808"の結果がマイナーバージョンアップで変更されました。 [php.net]実害はないしバグレポートもされてるのに、なんだかな、と思います、
「===」では試した?というか元々PHPでは数値比較以外では「==」は使っちゃ駄目って常識だよね。(多言語から移ってきた人はまずここの比較演算子の糞仕様で苦労する。)
"09223372036854775808" === "9223372036854775808" // 文字列比較これでFALSEが返ってくるのはそうだけど、
"09223372036854775808" == "9223372036854775808" // 数値比較 (と思わせて、LONG型に変換できないから文字列比較)これで、以前はTRUEだったので、FALSEにしちゃいました…。
もしかしたら、今後、余白が入った文字列比較で、" TEST" === "TEST" // 文字列比較の結果がTRUEになる日が来たりするのだろうか…。
元仕様も未定義なうえ振る舞いを変更したことも明記されていない物を仕様変更と言うのは
いや、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 なんていう、仕様・定義を参照したら選びそうにない名前な時点でお察し。
問題を抱える個々人に言うつもりはありませんが、これだけ多くの問題点が指摘されている言語で、これだけ需要があるんですから、PHPの分派を作ろうという人々が現れないんですかね。
PHPのそういうところを気にする人は、PythonなりRubyなりに行ってしまうんかなと思います
Rubyも行き当たりばったりな言語だけど
Rubyは将来の方向性は行き当たりばったり感があるけど、==の仕様とか細かいところはだいぶましな感じ。
じゃあもうPHPの分派はあり得ないということですね
わかりました
エンコーディングを明示的に指定すればいいじゃん
エンコーディングを明示してないアプリが悪い。徳丸本に書いてあるだろ。それすらしてない糞アプリなんて使わない方が良い。
IEみたいに閉じタグを補完してくれないのはバグだと言うような話ですな。
公式サイトからして閉じタグ書くとバグる [php.net]とか言ってる連中ですよ。
いや解るんですがどこまで Laziness なんだと
# phpではなるべくシングルクォートとダブルクォートを使い分けてますがPerlでは連結演算子使いまくります(何
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
仕様の変更を一方的にバグとして元に戻せと主張する (スコア:5, 興味深い)
タイムリーなことに、ちょっと前にSquirrelMail を PHP5.4 に対応させた [srad.jp]のですが、原因を一言出言うと「htmlspecialchars の仕様変更のせいで、Shift_JISやEUC-JPで表示するサイトでは、エンコーディングを明示的に指定しないhtmlspecialcharsの結果が空になる」というものです。
機械的な置換で容易に修正対応はできましたが、そんな泥臭いパッチをSquirrelMailの方に投げる気にもなれず、もうまさにPHPの仕様の変更を「仕様バグ」だと主張したい気分です…
EUC-JP/Shift_JISのサイトは、PHP5.3を使い続けるか、UTF-8になんとか移行するか、どちらかがまあ建設的な対応でしょうね。
ていうか、mbstring を入れてる場合、内部に internal_encoding という設定があるんだから、文字エンコーディングに関係する処理で internal_encodingを無視するのは仕様バグ以外の何者でもないだろうに…
Re:仕様の変更を一方的にバグとして元に戻せと主張する (スコア:3)
似たような感じで、
"09223372036854775808" == "9223372036854775808"
の結果がマイナーバージョンアップで変更されました。 [php.net]
実害はないしバグレポートもされてるのに、なんだかな、と思います、
Re:仕様の変更を一方的にバグとして元に戻せと主張する (スコア:1)
「===」では試した?
というか元々PHPでは数値比較以外では「==」は使っちゃ駄目って常識だよね。
(多言語から移ってきた人はまずここの比較演算子の糞仕様で苦労する。)
Re: (スコア:0)
"09223372036854775808" === "9223372036854775808" // 文字列比較
これでFALSEが返ってくるのはそうだけど、
"09223372036854775808" == "9223372036854775808" // 数値比較 (と思わせて、LONG型に変換できないから文字列比較)
これで、以前はTRUEだったので、FALSEにしちゃいました…。
もしかしたら、今後、余白が入った文字列比較で、
" TEST" === "TEST" // 文字列比較
の結果がTRUEになる日が来たりするのだろうか…。
Re: (スコア:0)
元仕様も未定義なうえ振る舞いを変更したことも明記されていない物を仕様変更と言うのは
Re:仕様の変更を一方的にバグとして元に戻せと主張する (スコア:4, 興味深い)
いや、htmlspecialchars のリファレンス [php.net]には
と仕様変更が明記されていますよ。その後に
というもっととんでもない大嘘が書かれてたりしますが…
日本以外でも、欧州の、ISO-8859-1で、英語以外のラテン文字(0xA0~0xFEの文字)を使ってるサイトを作っている人も同じようにはまるはず。
でも、PHPの開発コミュニティはこれを「既存のコードに影響を及ぼさない変更」だと信じてるんでしょうねぇ…
Re:仕様の変更を一方的にバグとして元に戻せと主張する (スコア:1)
元仕様も未定義なうえ振る舞いを変更したことも明記されていない物を仕様変更と言うのは
じゃあ、やっぱりPHPがバグなんだよ。
# 元ネタに習い、糞野郎とでも付けておきましょうか?
Re:仕様の変更を一方的にバグとして元に戻せと主張する (スコア:1)
まぁ、specialchars なんていう、仕様・定義を参照したら選びそうにない名前な時点でお察し。
Re: (スコア:0)
問題を抱える個々人に言うつもりはありませんが、
これだけ多くの問題点が指摘されている言語で、
これだけ需要があるんですから、
PHPの分派を作ろうという人々が現れないんですかね。
Re: (スコア:0)
PHPのそういうところを気にする人は、PythonなりRubyなりに行ってしまうんかなと思います
Re: (スコア:0)
Rubyも行き当たりばったりな言語だけど
Re: (スコア:0)
Rubyは将来の方向性は行き当たりばったり感があるけど、==の仕様とか細かいところはだいぶましな感じ。
Re: (スコア:0)
じゃあもうPHPの分派はあり得ないということですね
わかりました
Re: (スコア:0)
エンコーディングを明示的に指定すればいいじゃん
Re: (スコア:0)
エンコーディングを明示してないアプリが悪い。
徳丸本に書いてあるだろ。それすらしてない糞アプリなんて使わない方が良い。
Re: (スコア:0)
IEみたいに閉じタグを補完してくれないのはバグだと言うような話ですな。
Re: (スコア:0)
公式サイトからして閉じタグ書くとバグる [php.net]とか言ってる連中ですよ。
いや解るんですがどこまで Laziness なんだと
# phpではなるべくシングルクォートとダブルクォートを使い分けてますがPerlでは連結演算子使いまくります(何