アプリケーションがどうやってUTF-8を理解して表示しているのか？そして、なぜ「間違ったUTF-8エンコード」を解釈してしまうのかを考えてみた - tohokuaikiのチラシの裏
前回のエントリで、「 なんで世にあるアプリケーションは1バイトで済むUTF-8を3バイト表現でもOKなんて勘違いをするの？」って書いたけど、なんでかを考えてみた。 きっかけは、コメント きっかけは、id:kick123からもらったコメント 「C2〜DFはC0〜DF？」ってところですが、1バイトで表現できるのは7ビットまでで、80を表現するには8ビットが必要です。 2バイト表現にあてはめるなら、「1100 0010」と「1000 0000」になり、1バイト目はC2になる。 ってことではないですか？ これ、最初「？？？」って感じだったんです。 理解するために、とりあえず「UTF-8で1byteで表せる文字一覧」を作ってみる。 utf-8_mapping_1byte posted by (C)ITOH Takashi これ出すのに使ったプログラムは、PHPで <?php for ($i=0; $
UTF-8の冗長なエンコードとは何で、なんでそれがセキュリティ的に危ないのか？を文字コード知識レヴェル3くらいの凡プログラマが考えてみる - tohokuaikiのチラシの裏
何故かあたり前にならない文字エンコーディングバリデーション | yohgaki's blog ってあるように、いまいち文字コードの不正な判定による危険性ってのが分かってない。 SJISの問題は、（2/3）SQLインジェクションを根絶！セキュア開発の極意 - 第5回■注目される文字コードのセキュリティ問題：ITproの記事がわかりやすかった。 というか、やっぱりPHP使ってると誰でも一度は「なんじゃこの『￥』は？」って思うもんなんで。 なるほど、確かに↓の図のように「あるバイト」が2つの意味を持つっていう文字コード形態はやばいんだなと。 EUC-JPはそんなことはしないで、1つのバイトには1つの意味しか取らせない。 だけど、これでも文字化けが起こることがある。経験的には、「マルチバイトをXX文字で切り落としたい」とかやった場合。ちゃんと文字コードを判定してくれるPHPでいえばmb_subst
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
