だいぶ間があいてしまいましたが、本年1月31日に開催された、第04回まっちゃ445勉強会目覚まし勉強会におけるライトニングトークの資料を公開します。 UnicodeによるXSSとSQLインジェクションの可能性View more presentations from ockeghem.
Ajax で文字化けする条件を調査してみた 【Blog Hackers Conference 2005 補足エントリー その2】 発表時間が全然足りなくて一言もしゃべれなかった「Ajax で日本語文字化け」ネタの調査結果をエントリーしておきます。 Safari ユーザのみなさんは Ajax なページを見るときに「文字化けすぎで見れん!」という経験を一回はされていると思います。例えば「WEBプログラミング NOW!: Googleサジェスト--Safariで文字化け」で述べられているように Google サジェストが化け化けになったりして、枕を涙で濡らす日々を過ごしていることと思われます(v1.3 では動作すらしません(泣))。この文字化けは、どうもデータを XML ではなくテキスト形式で受け取っているときに起こるようです。詳しい原因は「WEBプログラミング NOW!: Googleサジェス
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト(言語、フレームワークなど)か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
何故かあたり前にならない文字エンコーディングバリデーション | yohgaki's blog ってあるように、いまいち文字コードの不正な判定による危険性ってのが分かってない。 SJISの問題は、(2/3)SQLインジェクションを根絶!セキュア開発の極意 - 第5回■注目される文字コードのセキュリティ問題:ITproの記事がわかりやすかった。 というか、やっぱりPHP使ってると誰でも一度は「なんじゃこの『¥』は?」って思うもんなんで。 なるほど、確かに↓の図のように「あるバイト」が2つの意味を持つっていう文字コード形態はやばいんだなと。 EUC-JPはそんなことはしないで、1つのバイトには1つの意味しか取らせない。 だけど、これでも文字化けが起こることがある。経験的には、「マルチバイトをXX文字で切り落としたい」とかやった場合。ちゃんと文字コードを判定してくれるPHPでいえばmb_subst
PHP学習日記 DelphiでC/Sプログラムを書いていたSunvisorがPHPに挑戦する課程を綴るブログ。はたしてWebアプリを作れるようになるのでしょうか。 過去のエントリ CakePHPと文字化け において なんだか,いろいろなことをやり過ぎて,本当はしなくても良いことまでやったのかもしれません。またdbに記録する文字コード体系と,表示の文字コード体系が違うものではいけないのかなど,不明な点が多くあります。文字コードについては今後も研究課題にしたいと思います。 と研究課題にすることにしたのですが,今回文字化け解消の方法を再度実験してみました。MySQLの4.1以降では文字コードの自動変換機能が実装され,逆にそのために文字化けに悩まされることが多くなったとの情報を得ました。また,PHPの文字コードの扱いについても色々と調べてみました。 参考サイト MySQLリファレンス - 24.4
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く