補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2009年9月30日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、PHPのhtmlspecialchars関数の第三パラメータ(文字エンコーディング指定)により、どこまで文字エンコーディングの妥当性チェックをしているかを報告します。 2007年4月に、寺田氏(id:teracc)の素晴らしいエントリ「htmlspecialcharsと不正な文字の話」により、htmlspecialcharsは、第三パラメータの文字コードを実質的に無視しており、不正な文字エンコーディングが指定された場合、その文字はチェックされずにすり抜けてしまうという結果が報告されています。
これまでに挙げた文字コードについて、正規表現を使用して mb_check_encoding() の代替用の関数を書いてみました。ある程度、妥当なものになっているとは思いますが、間違い等に気付いた方がおられましたら、ご指摘ください。 UTF-8 については、RFC3629 を参考にしました。各文字は4バイト以下、冗長な表現、サロゲートペアの領域を FALSE と判定します。 <?php function is_valid_encoding( $str, $encoding ) { switch ( $encoding ) { case 'ASCII' : $regex = '/(?:' . '[\x00-\x7f]' // ASCII (mb_check_encoding) // . '[\x00\x09\x0a\x0d\x20-\x7f]' // ASCII (mb_detect_enco
Posted on 7月 19, 2006 Filed Under PHP | CSVのインポート機能を持ったシステムをPHP4環境からPHP5環境へ移行したら、 なぜかCSVデータを正しく読み込んでくれない。っていうか一文字目が文字化け。 超悩んだあげくぐーぐるさんで検索しても以下のような記事しかみつからず。 [PHP-dev 1205] PHP5のfgetcsv()関数について 人力検索はてな - PHP4からPHP5へソースの移(長いので略) csvファイルを読み込むと1バイト目の日本語が文字化け 3つ目の掲示板のyossyはあたくし自身なんですが・・・。 setlocaleとかいろいろ試してもしても結局読み込まれるCSVの文字コードは ほとんどSJISなせいなためかなんだかうまくいきません。 ちなみに検証環境はほぼFedoraCore4のデフォルトです。 PHPは5
惜しいけど間違っている点がいくつか. ●default_charsetはデフォルトの文字コードのことではない。 非常に誤解しやすい内容。 default_charsetというパラメータはご存じの人も多いと思う。 それに大抵の初心者本にはこれを設定するように書いてあるが、 むしろ逆である。 default_charsetとは 出力時にHTTPヘッダとして送信する文字コード名 のこと。 これを指定しておくと以下のコードが自動で出力される。 default_mimetype = 'text/html'で default_charset = 'utf-8'の場合 header('Content-Type: text/html; charset:utf-8'); default_charsetは関係ない.もし未指定なら単に Content-Type: text/htmlが出力されます. これだとコン
これまで2回にわたってWebアプリケーションにおける入力値検証とセキュリティ対策の関係を説明してきた。入力値検証はセキュリティ上の根本的対策ではないが,保険的な対策として効果が期待でき,特に制御コードや不正な文字エンコーディングによる攻撃対策には有効であることを説明した。 今回は,Webアプリケーション開発によく使われる4種類の言語(Perl,PHP,Java,ASP.NET)に関して,入力時処理の具体例を示す。ここで取り上げる「入力時処理」とは以下の内容を含んでいる。 文字エンコーディングの検証文字エンコーディングの変換入力値検証 Perlによる実装の方針 Perl言語はバージョン5.8から内部文字エンコーディングとしてUTF-8をサポートし,文字単位での日本語処理が可能だ。文字エンコーディング処理にはEncodeモジュールを使用する。入力値検証には正規表現を用いるのが便利だ。 ■文字エ
(序論)文字化けの発生メカニズム概論と解析方法 ネスケ4.Xで特定の文字(試・時・事・私など)が文字化けする場合 → document.writeで文字化けする漢字の規則性 → ネットスケープ4.Xのキャッシュ機構 → 2種類の解決方法 CGIで特定の文字(表・予・申・能・ソ・十など)が文字化けする → Shift_JISでCGIを作成する場合の注意点 → PHPで「表\示」「十\和田湖」「申\し込み」などと表示される場合 「(はしご高)」が使えない理由 → Windowsでは表示されるが、Macでは文字化けする文字 → Macでは表示されるが、Windowsでは文字化けする文字 → 機種依存文字チェック・プログラム(Flashフォームなど) 文字化けしないための工夫 → メタタグの指定は有効か? → 「美乳」で文字化けが直るって本当? フォントを指定したら文字化けした。 → フォントの指
【1】 文字列コード問題との戦い Pythonに限った話ではないのですが、 日本語を取り扱うコードを書いていると やっかいなエンコーディングトラブルに遭う事は少なくないでしょう。 エンコーディングトラブルとは コンパイラ・インタプリタがソースコードを解釈できない。 画面表示が化ける。 意図した入力ができない。 エンコード・デコード時にエラーがでる。 正しいファイル名のつもりなのにファイルが見つからない。 出力させたファイルの中身が読めない。 などといった現象を基本としていろんな問題を引き起こします。 問題のすべては「コード変換」に発生します。 実際の文字列が何のエンコーディングで、 渡す先が何のエンコーディングを期待しているか? それらを確認して合致させるように変換をするということが基本です。 【2】 「Python日本語版が必要」というのは誤解 P
ざくっとこのネタのもとについて. うーん、だとするとMacだからですかねぇ?SJISの「表」をaddslashesを通しても、Magic_QuoteをONにしても「表」のままです。 mbstring.internal_encoding = utf-8が原因だったorz 察するところはありますが細かいことはあまり書かないで起きます.結論で言うと残念ながら多分それは原因ではないです(苦笑 by Tadashi "ELF" Jokagi おろ。mbstring.internal_encodingとmbstring.encoding_translationの合わせ技的な原因なんだろうと察したんですが違うんですかね。 結論ではNo,mbstring.encoding_translationが諸悪の根源. #諸悪とかいわれるなら何であるんだ? とかは別レイヤーの話なのでポイッ!! 前提条件 まず前提条
yamaokaです。 PHPで日本語を扱う場合、mbstringモジュールを利用する場合が多いと思います。 日本語に特有の機能(カタカナの全角/半角変換など)も備わっていて、とても便利です。 しかし、日本以外ではmbstringモジュールはあまり利用されていないようです。 代わりに利用されているのがiconvモジュールで、 最近話題のフレームワーク、symfonyでも 国際化の機能を実現するために内部で利用されています。 iconvモジュールはPHP 5でPHPの本体に組み込まれました。 別途用意して組み込む必要があるmbstringモジュールと違って、最初から使用できるので便利ですね。 PHPのマニュアルのiconv関数のページを見ると、 いくつかの関数が定義されているのがわかります。 それぞれ、mbstring関数との 対応表を作ってみました。 iconv関数mbstring関数
・CGIで特定の文字(表・予・申・能など)が文字化けする 自動バックアップ・テスサーバー付きの新機能スマートリリース CGIやPHPなどの技術系でSuper FAQ(よくある質問)がこれです。下記のような文字化けが発生します。 文字化けしている漢字は「表」「予」「申」「能」「十」「ソ」などです。第1章の「Netscape4.Xのdocument.write時の文字化け」は音が「シ」のものに集中的に文字化けが見られるなど、顕著な規則性がありました。今回の文字化けは、「音」が似通っているという特色はありません。 しかし、それぞれの漢字のShift_JISコードを調べてみると、ある規則性が浮かび上がってきます。Shift_JISコードを調べるには、序論で紹介したようなIMEやことえりの文字一覧表でもいいのですが、ここではURLエンコードを利用してみます。 URLエンコードは、プログラマーでない方
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く