memo.xight.org - PHPの文字化け - 5つの誤解と5つの対策
Summary 設定すべき項目は以下． ;; Disable Output Buffering output_buffering = Off ;; Set HTTP header charset ; default_charset = EUC-JP ;; Set default language to Japanese mbstring.language = Japanese ;; HTTP input encoding translation is enabled. mbstring.encoding_translation = off ;; Set HTTP input encoding conversion to auto mbstring.http_input = pass ;; Convert HTTP output to EUC-JP mbstring.http_output
iPhone間の新しい文字化け「兄化け」 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
iPhone間の新しい文字化けパターンが発見されたのでメモ*1。この少なくとも3つのダメな仕様が重なって発生する文字化けは、発見者によって「兄化け」と命名された*2。 「兄化け」は、兄がSoftBankまたはauのiPhoneでメッセージアプリを、妹がiPhoneのメールアプリでdocomo.ne.jpアドレスを使っている場合に発生する。兄が絵文字入りのメールを送信すると、妹の環境では絵文字が豆腐に化け、それを引用して返信すると、今度は兄の側でメッセージ全文が化ける。 以下、この文字化けの理屈について。兄のメッセージアプリは、絵文字入りのメッセージをUTF-8で送信。キャリアの送信側のサーバが、これをドコモのShift_JISに変換する。しかし、妹のiPhoneのメールアプリはドコモのShift_JISに対応していないので、ドコモの絵文字を単に「Shift_JISの未定義領域の文字」として
各ブラウザが解釈可能なcharsetのリスト
各ブラウザがcharsetとして解釈可能な文字列の調査 A.テストの方法 以下にあるcharsetとして扱われそうな文字列をブラウザが認識できるか確認した。 IANAのcharacter-sets.xml ICUのリスト すいかサーバーさんで掲載されているcharsetのリスト Mozillaのcharsetalias.properties.html レジストリ (HKEY_CLASSES_ROOT\MIME\Database\Charset) mlang.dll Operaのインストールフォルダにあるopera.dll apple.comにあるmac-encodings.txt テストの具体的な方法はブログに書いた。 Masato Kinugawa Security Blog: 各ブラウザがサポートするcharsetのリスト ブログに書いた方法とはやり方が少し異なるが、ここでテストできる
講習会「文字集合と文字エンコーディング」について - はてなるせだいあり
なかなか豪快な記事(講習会「文字集合と文字エンコーディング」を開催しました — ディノオープンラボラトリ)を見つけたので、ツッコミを書いてみることにしました。ツッコミどころはかなり多いんですが、まぁ世の中の文字コードがらみの記事なんて大半がこんなものです。 「文字コード」という語は「正しい」か スライドの5ページ目は、「文字コード」という言い方は間違いという趣旨に見えますが、そうでもありません。 というのも、文字コードの世界は難しい世界です。複数のレイヤー、複数の国、複数のベンダーにまたがっているものが簡単になるはずがありません。しかし必須要素であるために、十分な知識を持たないまま、または必要性に駆られて十分な知見が集まる前に実装を行ってしまうこともしばしばあります。このことがさらに「歴史的経緯」としてさらに文字コードを難しくしています。例えばHTTPのcharsetパラメータは、char
UCS-2とは何か - なるせにっき
割り切った時点で、この記事ではUCS-2について書くつもりはなかったのですが、UTF-16を説明するにあたって必要と思われたので「今となっては古い方式です」という注釈をつけた上で記述を追加したものです。 さて、このエントリはこのおたよりへの返信なんですが、 各種エンコードの説明をしているのだが、中に何故か UCS-2 が。UCS-2は、エンコーディングじゃなくて文字セットですよね。JISX0208が現れたレベルの違和感。 2009-03-24 - それはそれ。これはこれ。 まず、あの記事では最初に「文字コードについて（中略）エンコーディングを中心に解説していきます」と言っていまして、所々曖昧にしています。曖昧にしたいところでは「文字コード」という語を使うようにしたつもりなんですが、今見ると徹底し切れてない気もする……な。ここは以後もっと気をつけます。 で、UCS-2ですが、ISO/IEC
講習会「文字集合と文字エンコーディング」を開催しました — ディノオープンラボラトリ
「文字集合と文字エンコーディング」というタイトルで、経験2〜3年目の人をターゲットに社内勉強会を開催しました。文字集合という単語を知っている必要はないですけど、少なくともUTF-8とShift_JISとでは扱える文字の種類数が違うことだけは伝えたかったので、その意味では目標が達成できたと思っています。 まとめ 文字集合とは、扱える文字の集合 JIS X 0208なら6000文字くらいの日本語の文字 UCS-2なら60000文字くらいの世界中の主要な文字 文字エンコーディングとは、文字の集合をバイト列に直す方式 Shift_JISはJIS X 0208（など）を1〜2バイトにする UTF-8はUCS-2を1〜3バイトにする 文字エンコーディング関連のツールを使いこなそう nkfやlvを使いこなそう 日本語を探すならlgrep 最終兵器：hexjaで16進ダンプ ムービー
第3回 US-ASCIIによるクロスサイトスクリプティング | gihyo.jp
今回は、US-ASCIIによるクロスサイトスクリプティング(XSS)という話題について紹介します。 前回までで説明したUTF-7によるXSSと同様に、攻撃者はUS-ASCIIという文字コードを巧みに利用することで、IEを対象にXSSを発生させることができます。US-ASCIIによるXSSは、UTF-7によるXSSと類似点も多いため、前回までの説明も併せて読んでおくとよいでしょう。 US-ASCIIによるXSSについても先に対策を書いてしまうと、UTF-7のときと同様にHTTPレスポンスヘッダにて Content-Type: text/html; charset=UTF-8 Content-Type: text/html; charset=Shift_JIS Content-Type: text/html; charset=EUC-JP のいずれかを出力するという原則を守ることで、完全に攻撃
第2回 UTF-7によるクロスサイトスクリプティング攻撃［後編］ | gihyo.jp
前回に引き続き、UTF-7によるクロスサイトスクリプティング（XSS）について説明していきます。 UTF-7によるXSSは、攻撃対象のコンテンツの文字エンコーディングが不明瞭な場合に、そのコンテンツを被害者のブラウザ（Internet Explorer）で開いたときに、そのコンテンツの文字エンコーディングがUTF-7であるとIEに誤認させ、「+ADw-script+AD4-」のようなUTF-7の文字列が有効なHTML要素として認識されるために発生します。 そして、「文字エンコーディングが不明瞭」な具体的な状況として、以下のような条件のいずれかに該当するということを前回説明しました。 レスポンスヘッダ、meta要素のどちらでもcharsetが指定されていない charsetにIEが解釈できないエンコーディング名が指定されている meta要素でcharsetを指定しているときに、meta要
第9回■上流工程で文字集合仕様と文字エンコーディングを決定する
これらの対策のうち，ここでは「文字集合の変換を伴う変換をしない」など，アプリケーション全体の文字コードの取り扱いについて上流工程で留意すべき内容について説明しよう。「入力値のチェック」については次回以降，「入力値の検証」の項で詳しく説明する。「アプリケーションでの正しいマルチバイト文字の処理」については，個別の処理内容の項で説明する。 文字コードの取り扱いについて，上流工程で留意すべき点としては，次の三つが挙げられる。 要求仕様として文字集合を定義する端末がサポートする文字集合を確認する実装に用いる文字エンコーディングを決定する まずアプリケーション仕様として，処理対象となる文字集合を規定する必要がある。日英語以外の韓国語や中国語，アラビア語などの対応が必要な場合はUnicodeを選択するしかない。さらに日本語だけの場合でも，例えばJIS X 0201＋JIS X 0208はJIS第2水準
シフトJIS / EUC-JPとUnicodeとの妥当な変換表: Netsphere Laboratories
2004.10.17 新規作成。2004.12.19 加筆。2005.04.02加筆。 最近、コンピュータで扱う文字列の文字コードがUnicodeでなければならない場面が増えてきた。UnicodeとシフトJIS、EUC-JPを変換する機会が多い。この変換は変換表で行うが、変換表が実際的なものでなければ、文字化けが発生することになる。 おかしな変換表は、これまでは、特にLinuxなどの上で動作するオープンソースソフトウェアで多く見られた。おそらく規格原理主義者が多かったためだろう。そもそも、規格どおりに変換表を作ると、実用的な変換表にはならない。しかし、最近ではまともな変換表を実装しているものも増えてきて、うまく選ぶだけでいいようになってきている。 変換表の違いをまとめたページはよく見かけるが、実際にどのような条件を満たして変換するものを選べばいいか不明なので、まとめてみた。 変換表に求めら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ＰＨＰの文字化けを本気で解決する - ぎじゅっやさん