JavaScript: サロゲートペアと不正なバイト列を考慮して文字列の長さを求める
JavaScript: サロゲートペアと不正なバイト列を考慮して文字列の長さを求めるJavaScript: 孤立したサロゲートを代替文字の U+FFFD に置き換えるJavaScript: 制御文字を代替文字の U+FFFD に置き換えるJavaScript: String.prototype.codePointAt を定義するJavaScript: String.fromCodePoint を定義するJavaScript: 孤立したサロゲートを考慮してコードポイントから文字列を生成する JavaScript: for…of 構文を使ってコードポイント単位で文字にアクセスするJavaScript: 文字列を配列に変換するJavaScript: 文字列を逆順に並べ替えるJavaScript: サロゲートペアを考慮して部分文字列を求める2015年1月18日追記。最新の内容は Qiita をご参
javascriptで文字コード変換 - Qiita
javascriptで文字コード変換 概要 javascriptの文字列はUTF-16で String#charCodeAt(i) で取得出来る数値は2byte(0x0000から0xffff)になる。 escape("あ") は UTF-16がそのままエスケープされ "%u3042" になるが encodeURI("あ"),encodeURIComponent("あ") などではUTF-8に変換されて "%E3%81%82" になる。 とすることで UTF-16<=>UTF-8 の変換は出来るが、その他の文字コードは変換テーブルを用意する必要がある。 Shift_JIS(MS932), EUC-JP, UTF-8, JIS(iso-2022-jp)に対応したライブラリを2つ見つけたので検証する。 Encoding.js - Converts character encoding. http
Masato Kinugawa Security Blog: U+2028/2029とDOM based XSS
ECMAScriptの仕様では、0x0A/0x0D以外にU+2028/2029の文字も改行とすることが明記されています。 これはあまり知られていないように思います。 以下はアラートを出します。 <script> //[U+2028]alert(1) </script> 知られていないだけでなく、知っていたとしても、スクリプトで文字列を処理するときに、U+2028/2029まで考慮する開発者がどれだけいるのかという話です。 実際、U+2028/2029を放り込むと文字列リテラル内にその文字が生のまま配置され、エラーが出るページは本当にたくさんあります。まあ、エラーがでるだけなら、大抵の場合大きな問題にはなりません。 ところが、U+2028/2029によってXSSが引き起こされてしまう場合というのを最近実際に見ました。 Googleのサービスで見つけた2つのケースを取り上げたいと思います。 ケ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
