アカウント名:
パスワード:
タイムリーなことに、ちょっと前にSquirrelMail を PHP5.4 に対応させた [srad.jp]のですが、原因を一言出言うと「htmlspecialchars の仕様変更のせいで、Shift_JISやEUC-JPで表示するサイトでは、エンコーディングを明示的に指定しないhtmlspecialcharsの結果が空になる」というものです。
機械的な置換で容易に修正対応はできましたが、そんな泥臭いパッチをSquirrelMailの方に投げる気にもなれず、もうまさにPHPの仕様の変更を「仕様バグ」だと主張したい気分です…
EUC-JP/Shift_JISのサイトは、PH
似たような感じで、 "09223372036854775808" == "9223372036854775808"の結果がマイナーバージョンアップで変更されました。 [php.net]実害はないしバグレポートもされてるのに、なんだかな、と思います、
「===」では試した?というか元々PHPでは数値比較以外では「==」は使っちゃ駄目って常識だよね。(多言語から移ってきた人はまずここの比較演算子の糞仕様で苦労する。)
"09223372036854775808" === "9223372036854775808" // 文字列比較これでFALSEが返ってくるのはそうだけど、
"09223372036854775808" == "9223372036854775808" // 数値比較 (と思わせて、LONG型に変換できないから文字列比較)これで、以前はTRUEだったので、FALSEにしちゃいました…。
もしかしたら、今後、余白が入った文字列比較で、" TEST" === "TEST" // 文字列比較の結果がTRUEになる日が来たりするのだろうか…。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
仕様の変更を一方的にバグとして元に戻せと主張する (スコア:5, 興味深い)
タイムリーなことに、ちょっと前にSquirrelMail を PHP5.4 に対応させた [srad.jp]のですが、原因を一言出言うと「htmlspecialchars の仕様変更のせいで、Shift_JISやEUC-JPで表示するサイトでは、エンコーディングを明示的に指定しないhtmlspecialcharsの結果が空になる」というものです。
機械的な置換で容易に修正対応はできましたが、そんな泥臭いパッチをSquirrelMailの方に投げる気にもなれず、もうまさにPHPの仕様の変更を「仕様バグ」だと主張したい気分です…
EUC-JP/Shift_JISのサイトは、PH
Re:仕様の変更を一方的にバグとして元に戻せと主張する (スコア:3)
似たような感じで、
"09223372036854775808" == "9223372036854775808"
の結果がマイナーバージョンアップで変更されました。 [php.net]
実害はないしバグレポートもされてるのに、なんだかな、と思います、
Re:仕様の変更を一方的にバグとして元に戻せと主張する (スコア:1)
「===」では試した?
というか元々PHPでは数値比較以外では「==」は使っちゃ駄目って常識だよね。
(多言語から移ってきた人はまずここの比較演算子の糞仕様で苦労する。)
Re: (スコア:0)
"09223372036854775808" === "9223372036854775808" // 文字列比較
これでFALSEが返ってくるのはそうだけど、
"09223372036854775808" == "9223372036854775808" // 数値比較 (と思わせて、LONG型に変換できないから文字列比較)
これで、以前はTRUEだったので、FALSEにしちゃいました…。
もしかしたら、今後、余白が入った文字列比較で、
" TEST" === "TEST" // 文字列比較
の結果がTRUEになる日が来たりするのだろうか…。