タグ

mbstringに関するKumatchのブックマーク (2)

  • 文字コードに起因する脆弱性を防ぐ「やや安全な」php.ini設定

    補足 この記事は旧徳丸浩の日記からの転載です(元URL、アーカイブはてなブックマーク1、はてなブックマーク2)。 備忘のため転載いたしますが、この記事は2010年9月27日に公開されたもので、当時の徳丸の考えを示すものを、基的に内容を変更せずにそのまま転載するものです。 補足終わり PHPカンファレンス2010にて「文字コードに起因する脆弱性とその対策」というタイトルで喋らせていただきました。プレゼンテーション資料をPDF形式とslideshare.netで公開しています。 文字コードのセキュリティというと、ややこしいイメージが強くて、スピーカーの前夜祭でも「聴衆の半分は置いてきぼりになるかもね」みたいな話をしていたのですが、意外にも「分かりやすかった」等の好意的な反応をtwitter等でいただき、驚くと共に喜んでいます。土曜にPHPカンファレンスに来られるような方は意識が高いというの

  • 「mb_internal_encoding()は必須か?」に対しての疑問と検証 - よくきたblog

    はてなダイアリーのよくきたはてなから移動. mbstringで日語を扱う上では「必須」になります. 理由はデフォルトは「ISO-8859-1」なので. しかしこの記事にある理由は何かを間違えた別の要因による結果ではないか? と邪推するんですが. PHPのmb_encode_mimeheader関数で文字列をエンコードするときは、直前にmb_internal_encoding関数で変換したい文字列のエンコーディングをセットしてから呼ばないとうまく動作しないもよう。 あくまで「別の要因では?」というのは邪推なのでこの記事にある現象が再現するテストコードがほしいところです. で,試してみました. まず素の状態. こちらの環境 OS: Fedora Core(ほとんどrawhide) LANG=en_US.UTF-8 PHP: 5.1.2(自分でビルド) php.ini: ほぼ素のまま(mbst

  • 1