インターネットの未来形。サイトが繋がり、共有し、協力して創り上げる、ひとつの巨大な情報システムです。そこでは、あらゆる情報がネットワーク上に蓄積され、我々はいつでも、どこからでも、多彩なデバイスを使ってそれらにアクセスできます。さまざまな情報提供やツール開発を通して、そんな世界の実現に少しでも貢献するべく活動していきます。検証機能を追加しましたが、本日はこれについて少し補足説明しようと思います。コードと同じ値になってしまうマルチバイトコードが存在するため、注意が必要です。文字エンコーディングについて詳しい方には当たり前のことかもしれませんが、案外広く知られてはいないような気がするので、記事にすることにしました。※誤解を招きやすい部分があるので、補足記事を書きました。よろしければ、ご参照ください。バイト)になる可変長の文字コードです。構成されるシーケンスとなります。上位互換であり、マルチバイトコードとシングルバイトコードの区別も明確で、とても扱いやすいエンコーディングです。実はこのエンコーディング方法には大きな落とし穴があります。文字を異なるシーケンスで表現できてしまう上記の表を見て感の良い方は気付いたかもしれませんが、バイト長の長いシーケンスで表現できる領域が、より短いシーケンスの領域を完全に含んでいます。ある文字を表現できるシーケンスが複数存在するのです。0x3C)は以下のコードでも表現できます。0xBCもちろん、これらのコードは規格で使用禁止となっているのですが、それだけで話が済むほど平和な世の中でもありません。アプリケーション側できちんと対処してやる必要があります。説明するまでもないかもしれませんが、このような不正なシーケンスが脆弱性に繋がる最も単純なケースとしては、例えば以下のプロセスが考えられます(わかりやすさ優先で、かなり無理やりに脆弱な処理にしています)。文字列に対してエスケープ処理を行っても、マルチバイトで表現されたコードはすり抜けてしまいます。まともな国際化ライブラリを使っていれば、上記のような不正な文字コードはきちんと処理してくれるはずです。ともに適切にエスケープしてくれました。変換した後にエスケープ処理を行うことでも対処できるかもしれません。複数のモジュールで構成されるような規模の大きいアプリケーションでは、そのすべてが適切な処理を行っていると保証するのも、なかなか難しいかと思います。ここはやはり、すべての外部入力に含まれる不正なシーケンスを、水際で正規化するという処理を徹底するのが一番かと思います。同様なことができるとご教示いただきました。以外でも使える汎用的なテクニックとして有用だと思います)。ともにサロゲートペアの領域が検出できないようです。サロゲートペアの領域も検出する必要がある場合は、やはり自分で検証を行わなければなりません。不正なシーケンスが含まれていれば、例外が発生します。この方法だと不正なシーケンスを含んだ文字列は全体を捨てるしか方法がありません。単純に処理を中断することが許されない場合は、やはり自分で正規化を行うしかありません。使っている正規化処理を単体で使えるようにしたものを再掲載しておきます。指定された文字に置き換え、その結果の文字列を返します。不正なシーケンスを置き換える文字です。整数を与えてください。