各ブラウザが解釈可能なcharsetの比較表
変更履歴 2013年 3月 6日：作成 2013年 4月11日：Firefox 20、19でブラウザメニューからのみ選択可能になっていたBig5-HKSCSを再びサポートしたようなので更新 https://bugzilla.mozilla.org/show_bug.cgi?id=845743 2013年 8月24日：Firefox 20、「UTF-16」と指定した場合、「UTF-16LE」のエイリアスとして固定で解釈するようになったようなので更新 2014年 3月22日：Firefox 28の結果に更新(使用できるものがかなり限られた/一部がreplacementになった) 2014年 9月 5日：Chrome 37の結果に更新(一部がreplacementになった) 2014年12月15日：Chrome 39の結果に更新(SCSU/BOCU-1/CESU-8/ibm864のサポート終了、
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
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
Accept-Charset Is No More
Now that Firefox 10 has been released, none of the major browsers send only Chrome sends the Accept-Charset HTTP header. During the Firefox 4 development cycle, I noticed that IE, Chrome and Safari were not sending the Accept-Charset HTTP header in their HTTP requests. This meant that the Web had to work even without browser sending that header. It was already obvious that Accept-Charset was obsol
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
本当は怖い文字コードの話 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
メールの符号化は悪だ - あどけない話
Subject: の日本語文字を符号化する方法(RFC 2047)とファイル名のそれ(RFC 2231)とが何故違うのか説明する機会がありましたので、ブログでも公開するとともに、僕の意見を述べさせてもらいます。 予備知識 Subject: の値に ASCII 文字以外を入れる場合は、RFC 2047 に従って符号化します。たとえば、 Subject: 日本語文字 は、以下のように変換されます。 Subject: =?iso-2022-jp?B?GyRCRnxLXDhsSjg7ehsoQg==?= 一方、「ファイル.pdf」というファイル名は、RFC 2231 に従って以下のように符号化します。 Content-Disposition: attachment; filename*=iso-2022-jp''%1B%24B%25U%25%21%25%24%25k%1B%28B%2Epdf RF
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JavaScript++かも日記 - 1997年からの