Easier ArrayBuffer to String conversion with the Encoding API | Blog | Chrome for Developers
Over two years ago, Renato Mangini described a method for converting between raw ArrayBuffers and the corresponding string representation of that data. At the end of the post, Renato mentioned that an official standardized API to handle the conversion was in the process of being drafted. The specification has now matured, and both Firefox and Google Chrome have added native support for the TextDec
Encoding Standard
Participate: GitHub whatwg/encoding (new issue, open issues) Chat on Matrix Commits: GitHub whatwg/encoding/commits Snapshot as of this commit @encodings Tests: web-platform-tests encoding/ (ongoing work) Translations (non-normative): 日本語 1. Preface The UTF-8 encoding is the most appropriate encoding for interchange of Unicode, the universal coded character set. Therefore for new protocols and for
PHP 5.4におけるhtmlspecialchars()の問題 - Opensource days
PHP 5.4 beta 2が出ているところですが、ソースコード(html.c)を見ていて、XSS対策で使用される htmlspecialchars()の文字コード指定がPHP 5.3とは異なる動作をすることに気が付きました。 内部文字コード(mbstring.internal_encoding)が使用される以下のようなシチュエーションです。 <?php // test.php echo htmlspecialchars("foo",ENT_QUOTES,""); mbstring.internal_encoding="SJIS-win"と指定することにします。(推奨はできませんが、)外字対応（絵文字対応）でCP932を使用したい場合を想定しています。 PHP 5.3で実行 php53/sapi/cli/php -d mbstring.internal_encoding="SJIS-win
PHP DOM XML extension encoding processing
I recently worked with PHP's DOM XML extension while working on Zend Framework's Zend_Search_Lucene HTML highlighting capabilities, and uncovered some undocumented features and issues with the extension in regards to character encoding. The information contained in this article should also apply to other libxml-based DOM implementations, as PHP's DOM extension simply wraps that library. 1. Interna
第10回 文字コードが引き起こす表示上の問題点［後編］ | gihyo.jp
前回は、文字コードの引き起こす問題がソフトウェアの処理上だけでなく、人間に対する視覚的な効果という点でも強く影響を与え、攻撃者にとっての強力な道具となることがある、という点について説明しました。今回も前回に引き続き、そのような文字コードが引き起こす視覚的な問題点について説明します。 拡張子の偽装 Unicodeを利用したWindowsにおける拡張子の偽装は、文字コードを利用した視覚的な攻撃の中でも特にインパクトの大きいものだと思います。 Unicodeには多数の文字に加え、さまざまな制御も収録されています。そのような制御コードのうち、U+202E「RIGHT-TO-LEFT OVERRIDE」（RLO）と呼ばれる文字をファイル名に含めることで、見かけ上の拡張子を簡単に偽装することができます。 たとえば、copy-txt.exeという名前の実行可能ファイルがあったとします。 図1 copy
Shift_JISにおける危険な文字まとめ
今時Shift_JISでプログラミングするバカな奴はいないだろうけど折角まとめたので公開 2バイト目がアスキーコードど丸被りしているものを列挙する@[\]^_`{|}~405B5C5D5E5F607B7C7D7E81 ー―‐／＼??＋??±×82・・・・・・Ａ・・・・83ァゼソゾタダチボポマミ84АЪЫЬЭЮЯклмн85・・・・・・・・・・・86・・・・・・・・・・・87????????・????・・・??88・・・・・・・・・・・89院閏噂云運雲荏閲榎厭円8A魁骸浬馨蛙垣柿顎掛笠樫8B機擬欺犠疑祇義宮弓急救8C掘啓圭珪型契形鶏芸迎鯨8D后梗構江洪浩港砿鋼閤降8E察纂蚕讃賛酸餐施旨枝止8F宗充十従戎柔汁旬楯殉淳90拭深申疹真神秦須酢図厨91繊措曾曽楚狙疏捜掃挿掻92叩端箪綻耽胆蛋畜竹筑蓄93邸甜貼転顛点伝怒倒党冬94如納能脳膿農覗倍培媒梅95鼻票表評豹廟描府怖扶敷96法房暴望某棒冒本翻凡
htmlspecialchars()/htmlentities()について - 2009-10-19 - T.Teradaの日記
id:t_komuraさんの、最新の PHP スナップショットでの htmlspecialchars()/htmlentities() の修正内容についてを読みました。 見ていて気になったことが１つあります。 2. EUC-JP …（省略）… (2) \x80 - \x8d, \x90 - \xa0, \xff については、そのまま出力される <?php var_dump( bin2hex( htmlspecialchars( "\x80", ENT_QUOTES, "EUC-JP" ) ) ); var_dump( bin2hex( htmlspecialchars( "\x8d", ENT_QUOTES, "EUC-JP" ) ) ); var_dump( bin2hex( htmlspecialchars( "\x90", ENT_QUOTES, "EUC-JP" ) ) ); va
perl - EncodeでXSSを防ぐ : 404 Blog Not Found
2009年03月03日19:00 カテゴリLightweight Languages perl - EncodeでXSSを防ぐ 良記事。 第7回■文字エンコーディングが生み出すぜい弱性を知る：ITpro だけど、問題点のみ具体例があって、対策にないのが片手落ちに感じられたので、その点を補足。 結論だけ言ってしまえば、Perlなら以下の原則を守るだけです。 404 Blog Not Found:perl - Encode 入門 すでにOSCONでもYAPCでも、あちこちそちこちでこの基本方針に関しては話したのですが、ここ 404 Blog Not Found でも改めて。 Perl で utf8 化けしたときにどうしたらいいか - TokuLog 改め だまってコードを書けよハゲ入り口で decode して、内部ではすべて flagged utf8 で扱い、出口で encode する。これが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - inexorabletash/text-encoding: Polyfill for the Encoding Living Standard's API
Twitter / Hiromitsu Takagi: とはいえやはり本来はそれ htmlspecialchars の責任じゃないよなあ。という考察を書きたいが、優先度は相対的に低