PHP の mbstring に関するメモ

a. 静的ライブラリとして組み込む方法

PHP のソースコードからコンパイルする場合、configure のオプションに、--enable-mbstring を追加します。また、スクリプトファイルを Shift_JIS で記述した場合は --enable-zend-multibyte も追加します。

PHP 4.3.4 以降では、コンパイル時に --enable-mbstring を指定すると、マルチバイト正規表現関数も使用できるようになります。--disable-mbregex とするとマルチバイト正規表現関数が使用できなります。

PHP 4.3.3 以前では、--enable-mbregex を追加することでマルチバイト正規表現関数が使用できるようになります。

まとめると以下の表のようになります。

PHP 5.2.10 での mbstring に関するコンパイルオプションは以下の通りです。マルチバイト正規表現のバックトラックを無効にするオプションが追加されました。

  --enable-mbstring       Enable multibyte string support
  --disable-mbregex         MBSTRING: Disable multibyte regex support
  --disable-mbregex-backtrack
                            MBSTRING: Disable multibyte regex backtrack check
  --with-libmbfl[=DIR]      MBSTRING: Use external libmbfl.  DIR is the libmbfl base
                            install directory [BUNDLED]

PHP 5.3.0 からは、外部の onigruma(マルチバイト正規表現ライブラリ)を使用することができるようになりました。

  --enable-mbstring       Enable multibyte string support
  --disable-mbregex         MBSTRING: Disable multibyte regex support
  --disable-mbregex-backtrack
                            MBSTRING: Disable multibyte regex backtrack check
  --with-libmbfl[=DIR]      MBSTRING: Use external libmbfl.  DIR is the libmbfl base
                            install directory [BUNDLED]
  --with-onig[=DIR]         MBSTRING: Use external oniguruma. DIR is the oniguruma install prefix.
                            If DIR is not set, the bundled oniguruma will be used

b. 共有ライブラリとして使用する方法

まず、共有ライブラリを作成する必要があります。開発環境を準備し、PHP のソースコードを展開後、phpize コマンドを使用してからコンパイルします。

例えば、PHP 5.2.5 で mbstring 拡張モジュールを作成する場合は、以下のようにします。

$ tar jxvf php-5.2.5.tar.bz2
$ cd php-5.2.5/ext/mbstring
$ phpize
$ ./configure --enable-mbstring
$ make
$ make test
$ sudo make install

インストールが終了したら、php.ini に以下の行を記述します。extension_dir は PHP のバージョンや PHP のコンパイルオプションによって変わります。インストールされた場所を指定してください。

extension_dir = "/usr/local/lib/php/extensions/no-debug-non-zts-20060613/"
extension=mbstring.so

c. Windows 環境の場合

ダウンロードした PHP のパッケージの中に、php_mbstring.dll が含まれています。

php.ini で extension_dir と extension を設定します。

extension_dir = "C:/php/ext"
extension=php_mbstring.dll

a. php.ini の mbstring 設定オプション

php.ini には、以下のような mbstring の設定があります。詳しくは php.ini の mbstring 設定オプション (PHP マニュアル) を参照してください。

日本語を使用するのであれば、mbstring.language を "Japanese" に、mbstring.internal_encoding を PHP スクリプトを書いている文字コード(UTF-8、または、EUC-JP など)と合わせておくと良いと思います。

• ※1 mbstring.encoding_translation を有効にした場合、mbstring.encoding_translation は mbstring.http_input の設定に従って、入力 HTTP クエリ文字列を内部文字コード(mbstring.internal_encoding)に変換します。ただし、文字コードの検出に失敗すると、文字化けの原因になります。

  また、PHP 4.3.2 以前で HTML フォームの enctype に multipart/form-data を指定する場合、以下の点に注意が必要です。

  注意: PHP 4.3.2 およびそれ以前のバージョンの場合、HTML フォームの enctype が multipart/form-data に
  設定された場合、mbstring は、POST データの文字エンコーディングを変換しません。この場合、文字列を
  内部文字エンコーディングに変換してやる必要があります。
  PHP 4.3.3 以降、HTML フォームの enctype が multipart/form-data に設定され、かつ、php.ini において
  mbstring.encoding_translation に On が指定されている場合、POST データの変数とアップロードされた
  ファイルの名前の文字エンコーディングは、内部文字エンコーディングに変換されます。ただし、クエリキー
  に関しては、変換されません。
  

  PHP マニュアル - HTTP 入出力

• ※2 mbstring.http_output_conv_mimetypes は出力時に指定した文字コードに変換する機能(ob_start() と mb_output_handler() を使用)が、Content-Type に XHTML(application/xhtml+xml)を指定した場合、文字コードが変換されないという問題を解消するために追加されました(参考: [PHP-dev 1398] mb_output_handlerによる文字エンコーディング変換について)。

b. mbstring.internal_encoding を 指定しなかった場合のデフォルト設定

php.ini で mbstring.internal_encoding を指定しなかった場合、mbstring.language の設定に対応した mbstring の内部文字コードが設定されます。

実際には以下のようになります。

• mbstring.language に何も設定しない場合、neutral 設定されます。

• mb_language() で言語設定を変更した場合は internal_encoding は変更されません。

c. zend_multibyte について

PHP のコンパイル時の configure オプションに --enable-zend-multibyte を追加すると、PHP のスクリプトファイルの文字コードが指定できるようになります。php.ini または、.htaccess の mbstring.script_encoding で文字コードを指定します。

mbstring.script_encoding に文字コードを設定すると、スクリプトファイルを読み込む際に、指定した文字コードを内部文字コード(internal_encoding)に変換します。このため、スクリプトファイルの文字コードに SJIS(Shift_JIS) や UTF-16 などを使用することができます。通常では、内部文字コードには、SJIS, UTF-16, ISO-2022-JP などを設定しても想定通りに動作しません。

php.ini では、mbstring セクションに以下のような設定を追加します(複数指定や "auto" も設定可能)。

mbstring.script_encodeing = "SJIS, EUC-JP, UTF-8"

.htaccess で指定する場合は以下のようにします。

php_value mbstring.script_encodeing "auto"

a. mbstring の内部変数一覧

mbstring では、以下の内部変数が定義されています。mb_get_info() を使用することで、確認できます。

• ※1 mb_http_input() では設定変更できそうに思えますが、この関数では設定できません。mb_parse_str() を実行すると、結果が設定されます。

• ※2 8進数で設定します。詳しくは 関数のオーバーロード機能(PHP マニュアル)を参照してください。

• ※3 func_overload の値によって自動的に設定されます。

• ※4 language を変更すると自動的に設定されます。

• ※5 文字コード変換時に不正文字があった場合にカウントされます。

• ※6 mb_detect_encoding() で使用されます。詳しくは、mb_detect_encoding() 関数の strict(第3引数) と php.ini の mbstring.strict_detection で説明しています。

• ※7 zend_multibyte が有効になっている場合に表示されます。ini_set() で指定を変更できますが、実際にはスクリプト中での動的な変更はできないようです(PHP 5.2.6 時点)。

• ※8 PHP 5.3.0 以降で表示されます。デフォルト値は"^(text/|application/xhtml\\+xml)" です。

a. mbstring 関数について

mbstring の関数を使用する場合、内部文字コード(internal_encoding)と変数の文字コードが合っていないと正しく動作しない関数があります。また、PHP スクリプトが書かれたファイルの文字コードについても、意識しておく必要があります。zend_multibyte を有効にしていない場合、PHP ファイルの文字コードが変数の文字コードになります。

多くの mbstring の関数では、引数に文字コードを指定できますが、省略した場合は internal_encoding が使用されます。また、文字コードは指定できませんが、internal_encoding 使用される関数もあります。

例えば mb_encode_mimeheader() や mb_send_mail() では、文字コードを設定する引数はありませんが、internal_encoding を使用します。もし、引数として渡す文字列の文字コードが internal_encoding と違う場合、文字化けの原因になります。

b. mbstring 関数一覧

mbstring 関数は以下の通りです(マルチバイト正規表現関数を除く)。各関数は PHP マニュアルの関数説明にリンクしています。

c. mb_language() 関数

i. mb_language() 関数の第1引数(language)

mb_language() は、第1引数(language)に "Japanese", "ja", "English", "en", "uni" などが設定可能です(PHP マニュアル : mb_language)。引数の大文字、小文字は区別されません("JA" と "ja" は同じです)。また、php.ini の mbstring.language で設定した場合も機能的にはほぼ同等です。

mb_language() は、主に以下の2つの機能があります。

• mb_convert_encoding() や mb_convert_variables() などの引数の入力文字コードに "auto" を使用した場合に影響を与えます("auto" の展開と文字コードリストを参照)。

• mbstring の内部設定である、language(言語設定)および、メール設定(mail_charset, mail_header_encoding, mail_body_encoding)を変更します。これらの内部設定は mb_get_info() (PHP 5.1.3 以降で使用可能)で確認できます。

  各内部設定値は以下の表のように設定されます。

  mb_language() に対応する言語設定とメール関係の内部設定値

  内部設定値	説明	English(En)	Uni	Japanese(Ja)
  language	言語設定	English	Uni	Japanese
  mail_charset	メールの送信文字コード	ISO-8859-1	UTF-8	ISO-2022-JP
  mail_header_encoding	メールヘッダの文字コード	Quoted-Printable	BASE64	BASE64
  mail_body_encoding	メール本文の文字コード	8bit	BASE64	7bit

ii. "auto" の展開と文字コードリスト

いくつかのマルチバイト文字列関数では、文字コードを指定する引数に "auto" を設定できます。"auto" を設定した場合、内部変数 language(mbstring.language または、mb_language() で設定した言語)によって、展開される文字コードリストが変化します。

"auto" は、以下の関数の引数に設定すると有効に機能します。

• mb_convert_encoding() の第3引数

• mb_convert_variables() の第2引数

• mb_detect_encoding() の第2引数

• mb_detect_order() の第1引数

"auto" は以下の表のように展開されます。

• language を設定せずに、"auto" を使用すると、文字コードリストは "ASCII, UTF-8" になります。この場合、mb_detect_encoding() の引数で "auto" を使用しても、JIS、EUC-JP、SJIS として検出されることはありません。

• mb_detect_encoding() や mb_convert_variables() などの入力文字コードを省略した場合、内部変数 detect_order の値が使用されます。"auto" が使用されるわけではありませんので、注意してください。

• "auto" は mb_detect_encoding() で文字コードを検出する場合には便利ですが、文字コードの検出に失敗し、文字化けの原因となることがあります。

日本語の文字コード検出をしたいのであれば、多くの場合、"auto" を使用を使用せず、想定される文字コードを列挙した方が確実です。内部変数 detect_order を設定するか、明示的に検出文字コードリストを設定してください。

上記の "auto" の設定(ASCII, JIS, UTF-8, EUC-JP, SJIS)では、検出する文字列の文字コードが UTF-8 であると分かっている場合(例えば、HTML への出力を UTF-8 で行っており、ブラウザからも UTF-8 で文字列が送られてくることが期待できる場合)はうまく動作します。しかし、HTML の出力を SJIS (Shift_JIS) で行っている場合、UTF-8 や EUC-JP としても正しい文字列が入力される可能性があります。その場合、誤って文字コードを検出し、文字化けの原因になります。特に、入力文字列が短い場合、誤検出が多くなります。

入力文字列がほとんどの場合、SJIS であることが分かっているのであれば、ASCII, JIS, SJIS, UTF-8, EUC-JP と SJIS を前に持ってくると良いと思います。入力文字列 SJIS でない場合に UTF-8 や EUC-JP として文字コードを検出させるようにすることで、誤検出する可能性が低くなります。

iii. mb_language() 関数の引数に設定可能な言語一覧

mbstring は他にも様々な言語で使用されることが想定されています。以下は、PHP 5.3.0 で mb_language() の引数に設定可能な言語一覧です。

• 設定可能な値と省略形の指定では、大文字・小文字は区別されません。

• PHP 5.2.5 以前でアルメニア語を指定するには、"Armenian " と後ろにスペース1文字が必要です。

• ウクライナ語は PHP 5.3.0 で追加されました。

d. mb_check_encoding() 関数

mb_check_encoding() は、PHP 4.4.3、PHP 5.1.3 で追加された関数です。文字列が指定した文字コードとして有効なものかどうかを調べることができます。

ただし、PHP 4.4.3 〜 PHP 4.4.4、PHP 5.1.3 〜 PHP 5.2.0 では、UTF-8 の判定で常に TRUE を返すという問題があります([PHP-dev 1338] mb_check_encoding() のテスト)。

また、mb_check_encoding() は引数なしの場合のみ、特殊な挙動になります。

• 引数を省略せずに使用した場合

  $string = "入力文字列";
  $encoding = mb_internal_encoding();    // 内部文字コード(internal_encoding)を取得
  // 内部文字コードと変数の文字コードが同じかどうかをチェック
  $result = mb_check_encoding( $string, $encoding );
  if ( ! $result ) {
      // エラー処理
  }
  

  PHP 4.4.5 と PHP 5.2.1 以降では、以下の2つの結果は同じになります。

  1. $result = mb_check_encoding( $string, $encoding )

  2. $result = ( $string === mb_convert_encoding( $string, $encoding, $encoding ) )

  PHP 5.2.6 以前では判定文字列に NULL バイトが含まれていた場合、mb_check_encoding() の判定が正しくない場合がありましたが、これは PHP 5.2.7 で修正されました。

• 第2引数を省略した場合

  $string = "入力文字列";
  // 内部文字コード(internal_encoding)と変数の文字コードが同じかどうかをチェック
  $result = mb_check_encoding( $string )
  if ( ! $result ) {
      // エラー処理
  }
  

  第2引数を省略すると、内部文字コード(internal_encoding)を使用します。

• 引数なしの場合

  $internal_encoding = mb_internal_encoding();    // 内部文字コードを取得
  // mb_convert_variables() で内部文字コードに変換
  mb_convert_variables( $internal_encoding, "ASCII,eucJP-win,SJIS-win,UTF-8", $post1, $post2 );
  // mb_convert_variables() が正しく変換できたかどうかをチェック
  $result = mb_check_encoding();
  if ( ! $result ) {
      // エラー処理
  }
  

  PHP 4.4.5 以降、PHP 5.2.1 以降では、HTTP クエリの文字コード自動変換機能(mbstring.encoding_translation)が有効になっていた場合、自動変換に成功したかを判定することができます。成功したかどうかを判定する場合は、スクリプトの最初の方で mb_check_encoding() を引数なしで使用してください。自動変換が成功した場合は TRUE を、失敗した場合は FALSE を返します。

  ただし、mb_check_encoding() で UTF-8 から別の文字コードへ変換した場合の結果判定には意味がありません。mb_check_encoding() は内部変数 illegal_chars が 0 かどうかによって判定を行っています。mbstring のライブラリである、mbfilter は UTF-8 の不正文字の検出を厳密を行っていないため、多くの場合、内部変数 illegal_chars がカウントされず、結果が TRUE になります。

e. mb_detect_encoding() 関数の第3引数(strict) と php.ini の mbstring.strict_detection

mb_detect_encoding() の第3引数に TRUE を指定すると厳密に文字コードを検出するようになります。第3引数を省略すると、php.ini の mbstring.strict_detection の設定に従います。

実際の処理としては、ある文字コードの検査中に、マルチバイトの有効な上位バイトが存在しているのに、有効な下位バイトが存在しない文字があった場合、検査中の文字コードは正しいと判定されません。これは、正しくない文字コードで検出しようとした場合に起きやすいものです。文字コードの検出率が高くなりますが、その分、処理は重くなります。

PHP のソースコードを見ると、ext/mbstring/libmbfl/mbfl/mbfilter.c で、mbfl_identify_filter の flag フィールドと status フィールドを使用して処理しているようです。

f. mb_encode_mimeheader() 関数の第5引数(indent)

mb_encode_mimeheader() の第5引数の indent は、MIME エンコードの際のインデントを指定できます。

これは、以下の問題に対処するために導入されました。

    ・Subject が RFC 違反
      メールヘッダーはフィールド名とフィールド値(と改行文字)の合計が
      76 文字未満としていますが，mb_encode_mimeheader() は 74 文字で
      ハードコーディングされているため，フィールド値だけで 74 文字で
      改行されます．よって 1 行目が「Subject:」の分長くなります．
    ・Windows は改行文字は「\r\n」でなければ RFC 違反
      Windows は引数で渡された値がそのまま SMTP プロトコルに使用され
      ます．SMTP は CR+LF の改行文字でなければならないので，LF だけ
      では RFC 違反になります．
    ・いきなり第 2 引数あるいは(省略値)でエンコードしようとする
      「[php-users:####]」のように ASCII で始まる場合でもいきなり MIME
      エンコードしようとします．その為，一部の ML ドライバーやメーラー
      などで問題が出る場合があるようです．

[PHP-dev 1186] Re: PHP4.4.1でmb_send_mailの第5引数が利かなくなってる

どのような場合に使用すべきかについては、以下のように説明されています。

使い方は単純で
$head = mb_encode_mimeheader($s, 'ISO-2022-JP', 'B', "\r\n", strlen("Subject: "));
のように5番目の引数にオフセットを指定できるようにしただけです。

[PHP-dev 1197] Re: PHP4.4.1でmb_send_mailの第5引数が利かなくなってる

PHP マニュアル: mb_encode_mimeheader には、indent は PHP 5 で追加されたことになっていますが、正確には、PHP 4.4.2 と PHP 5.1.1 から使用可能です。

g. mb_send_mail() 関数

i. mb_send_mail() 関数によくある間違った使い方

mb_send_mail() でも、他の mbstring の関数と同様に、内部文字コード(internal_encoding) と各引数の文字コードが一致しているかが重要です。

mb_send_mail() を使用する際に、メール本文(第3引数)を ISO-2022-JP(JIS) に変換してから渡す必要はありません。そのコードは偶然うまく動作しているだけですので、注意してください。

うまく動作しているように見えるのは、ISO-2022-JP の文字列を Shift_JIS や EUC-JP、UTF-8 などの文字コードから ISO-2022-JP に変換しても、変化しないためです。ISO-2022-JP に変換後、mb_send_mail() を使用すると、メール本文を internal_encoding から ISO-2022-JP に変換します。再度文字コード変換を行う分、無駄な処理が増えています。

問題が出るケースとしては、UTF-8 でメールを送信する場合です。language を Uni にして、先に ISO-2022-JP に変換するような処理を入れた場合、文字化けしたメールが送信されます。

Subject(第2引数:メールの題名)も同様です。変数の文字コードと internal_encoding が一致していれば、mb_send_mail() がメールを送信する際に必要な文字コードに変換します。

ii. mb_send_mail() 関数の第5引数(additional_parameter)

PHP マニュアルでは、mb_send_mail() 関数の第5引数は、以下のように説明されています。

additional_parameter(mb_send_mail() の第5引数)は、MTA へ渡す コマンドライン引数です。sendmail を利用する際に正しい Return-Path を設定するためなどに利用すると便利です。

PHP マニュアル: mb_send_mail

実際には、sendmail コマンドで Return-Path を設定するには、-f mailaddress@example.com のように、実際の送信元のメールアドレスを指定します。

php.ini の mail.force_extra_parameters を設定している場合、こちらが優先されます。その場合、mb_send_mail() の第5引数は無視されます。

iii. mb_send_mail() 関数の使用例

以下に、mb_send_mail() で簡単にメールを送信する関数を作成してみました。

メールの送信元と送信先にも日本語の名前を付加したい場合の例です。2行目の mb_internal_encoding() で、UTF-8 を指定していますが、PHP スクリプトの文字コードに合わせて設定してください。

<?php
mb_language( 'Japanese' );
mb_internal_encoding( 'UTF-8' );

// ... メール送信用の設定

send_mail( $subject, $body, $from_name, $from_address, $to_name, $to_address );

function is_mail_addr( $mail_address, $check_domain = FALSE )
{
    if ( ! preg_match(
            '!\A[-\\!#$%&\'*+/\w=?^_`{|}~.]+@'
            . '([-\\!#$%&\'*+/\w=?^_`{|}~]+\.[-\\!#$%&\'*+/\w=?^_`{|}~.]+|localhost)'
            . '\z!i' , $mail_address )
    ) {
        return FALSE;
    }
    if ( $check_domain ) {
        list ( , $domain ) = explode( '@', $mail_address );
        if ( ! checkdnsrr( $domain, 'MX' )
          && ! checkdnsrr( $domain, 'A'  )
          && ! checkdnsrr( $domain, 'CNAME' )
        ) {
            return FALSE;
        }
    }
    return TRUE;
}

function send_mail( $subject, $body, $from_name, $from_addr, $to_name, $to_addr )
{
    // メールアドレスの妥当性チェック
    if ( ! is_mail_addr( $from_addr, TRUE ) ) { return FALSE; }
    if ( ! is_mail_addr( $to_addr,   TRUE ) ) { return FALSE; }

    $envelope_from = '-f ' . $from_addr; // 本当の送信元のメールアドレス
    $from_header   = mb_encode_mimeheader( $from_name, 'ISO-2022-JP', 'B', "\n", strlen( 'From: ' ) );
    $from_header  .= "\n <" . $from_addr . '>';
    $to_header     = mb_encode_mimeheader( $to_name,   'ISO-2022-JP', 'B', "\n", strlen( 'To: '   ) );
    $to_header    .= "\n <" . $to_addr .   '>';
    $extra         = 'From: ' . $from_header;

    return mb_send_mail( $to_header, $subject, $body, $extra, $envelope_from );
}

h. 文字コード変換関数 mb_convert_encoding(), mb_convert_variables()

i. mbstring が提供する文字コード変換関数

mbstring が提供している文字コード変換関数は以下の2つです。

• mb_convert_encoding(string $str, string $to_encoding [, mixed $from_encoding])

• mb_convert_variables(string $to_encoding, mixed $from_encoding, mixed &$vars [, mixed &$... ])

mb_convert_encoding() は、第1引数の文字列($str)の文字コードを第3引数の文字コードリスト($from_encoding)から第2引数の文字コード($to_encoding)に変換し、その結果を返します。

mb_convert_variables() は、第3引数以降の複数の配列、オブジェクト、文字列($vars)の文字コードを第2引数の文字コード($from_encoding)から第1引数の文字コード($to_encoding)に変換し、第3引数以降の値に上書きします。第3引数以降の値は全て同じ文字コードにする必要があります。

文字コードリスト(mb_convert_encoding() の第3引数と mb_convert_variables() の第2引数)の指定方法は以下の表の通りです。

※自動判別の場合、前から順に指定された文字コードが変換対象の文字列に一致するかどうかを判定します。判定の結果が一致した場合、その文字コードを変換元の文字コードとして使用します。

ii. 文字コード変換で不正文字列を変換した場合の代替文字

PHP にも、文字コード変換で入力文字列の文字コードが不正、または、出力文字列の文字コードに文字が存在しない場合の代替文字を設定する機能があります。

php.ini では、mbstring.substitute_character、PHP スクリプトでは、mb_substitute_character() で設定可能です。

設定方法は以下の通りです。

• php.ini で設定する場合

  mbstring.substitute_character = 63     ; 代替文字として 63(?) を設定
  mbstring.substitute_character = 65533  ; 代替文字として U+FFFD を設定
  mbstring.substitute_character = "long" ; 変換元の文字の値(例: BAD+C0, BAD+80)を出力する 
  mbstring.substitute_character = "none" ; 代替文字を出力しない
  

• PHP スクリプト中で設定する場合

  mb_substitute_character( 63 );      // 代替文字として 63(?) を設定
  mb_substitute_character( 0xFFFD );  // 代替文字として U+FFFD を設定
  mb_substitute_character( 'long' );  // 変換元の文字の値(例: BAD+C0, BAD+80)を出力する
  mb_substitute_character( 'none' );  // 代替文字を出力しない
  

PHP マニュアルの mbstring の実行時設定では、設定例として、以下のように記載されていますが、実際にはそのようにはなりません。実際には、代替文字として ? が出力されます。

mbstring.substitute_character = none ; 文字を出力しない

原因は、ini ファイルで none を設定すると、0(null) に変換されてしまうためです。substitute_character が未設定の場合、substitute_character には 63("?") が設定されます(mb_get_info() で確認可能)。

現状(PHP 5.4.11 以前)では、php.ini で substitute_character に none(代替文字を出力しない)を設定するには、以下の設定をする必要があります。

mbstring.substitute_character = "none"

または、PHP スクリプトの中で文字コード変換関数を実行する前に mb_substitute_character() を実行します。

mb_substitute_character( 'none' );

a. 使用可能な文字コード名と MIME 名、エイリアスの一覧

以下が、PHP の mbstring で使用可能な文字コード名と MIME 名、エイリアスの一覧です。文字コードを指定する場合、大文字、小文字は区別されません。

以下の表での MIME 名は、mbstring で MIME 名として扱われているものです。正式な MIME 名とは違うものが入っています(7bit、8bit、HTML-ENTITIES、Quoted-Printable など)。

MIME 名については、IANA の文書を参照してください(http://www.iana.org/assignments/character-sets)。

b. レガシーエンコーディングの追加

PHP 5.2.1 以降では、PHP マニュアル : マルチバイト文字列関数 (mbstring) : サポートされるエンコーディング に記載されている文字コードの他に、CP51932 と ISO-2022-JP-MS が文字コードとして使用できるようになりました。([PHP-dev 1345] PHP への CP932 系エンコーディングの追加パッチ)

CP51932 (Windows Codepage 51932)
--------------------------------
o Windows で使用されている日本語EUC。
o EUC-JP の JIS X 0212 およびユーザー定義文字には対応していない。
o 機種依存文字のコード割り当てが eucJP-win とは異なる。

ISO-2022-JP-MS
--------------
o ISO-2022-JP に次の文字集合を追加
    文字集合                                    エスケープシーケンス
    NEC特殊文字 (JIS X 0208 13区)               ESC $ B
    NEC選定IBM拡張文字 (JIS X 0208 89区〜92区)  ESC $ B
    JIS X 0201 片仮名                           ESC ( I
    ユーザー定義文字                            ESC $ ( ?
o Windows Codepage 50221 (Windows の 7ビットJISコード) とは、ユーザー
  定義文字を除いて互換性あり。

[PHP-dev 1345] PHP への CP932 系エンコーディングの追加パッチ

これらの文字コードの詳細については、以下の情報を参照してください。

• CP51932 (Legacy Encoding Project)

• ISO-2022-JP-MS (Legacy Encoding Project)

c. 絵文字変換用のエンコーディング追加

PHP 5.4.0 から、mbstring で携帯各社(DoCoMo, KDDI, Softbank)の絵文字が追加されました。

絵文字変換に関連して追加されたエンコーディングは以下の通りです。

• ISO-2022-JP-MOBILE#KDDI (エイリアス: ISO-2022-JP-KDDI)

• SJIS-Mobile#DOCOMO (エイリアス: SJIS-DOCOMO, shift_jis-imode, x-sjis-emoji-docomo)

• SJIS-Mobile#KDDI (エイリアス: SJIS-KDDI, shift_jis-kddi, x-sjis-emoji-kddi)

• SJIS-Mobile#SOFTBANK (エイリアス: SJIS-SOFTBANK, shift_jis-softbank, x-sjis-emoji-softbank)

• UTF-8-Mobile#DOCOMO (エイリアス: UTF-8-DOCOMO, UTF8-DOCOMO)

• UTF-8-Mobile#KDDI-A

• UTF-8-Mobile#KDDI-B (エイリアス: UTF-8-Mobile#KDDI, UTF-8-KDDI, UTF8-KDDI)

• UTF-8-Mobile#SOFTBANK (エイリアス: UTF-8-SOFTBANK, UTF8-SOFTBANK)

入力文字列を UTF-8 としてデータベースやファイルに格納することが想定されています。出力時は、必要に応じて機種を判別して各社に対応した Shift_JIS に変換します。

DoCoMo の絵文字を含む Shift_JIS の文字列を UTF-8 に変換する場合の例は以下の通りです。

$utf8 = mb_convert_encoding( $sjis, "UTF-8-Mobile#DoCoMo", "SJIS-Mobile#DoCoMo" );

また、UTF-8-Mobile#KDDI-B は KDDI の非公式マッピングですが、UTF-8-Mobile#KDDI がエイリアスになっており、実際にはこちらを使用した方が良さそうです(KDDI (AU)携帯電話のUTF-8絵文字の仕様)。

以下のページに実装を担当された廣川さんの解説があります。

• libmlfl(mbstring)への絵文字のサポート追加 (Opensource days)

• mbstring/libmbfl モバイル用UTF-8 (Opensource days)

• KDDI (AU)携帯電話のUTF-8絵文字の仕様 (Opensource days)

• mbstring(libmbfl)で携帯絵文字サポート：Unicode 6.0に含まれない文字 (Opensource days)

a. マルチバイト正規表現関数について

マルチバイト正規表現は PHP 4.2.0 から導入されました。PHP 4.x は全て Ruby と同じ正規表現エンジンを使用しています。

PHP 4.x で使用できる正規表現演算子については、PHP で使用できる正規表現演算子(mb_ereg)(正規表現メモ)が分かりやすいと思います。

PHP 5.0.0 から正規表現エンジンに onigruma を使用しています。PHP 5.0.0 以降で使用できる正規表現演算子については、鬼車 正規表現を参照してください。onigruma のバージョンは PHP 5.0.x は 3.7.0、PHP 5.1.x は 3.7.1、PHP 5.2.x は 4.4.4、PHP 5.3.x と PHP 5.4.x は 4.7.1 が使用されています。

マルチバイト正規表現で使用する文字コードは mb_regex_encoding() を使用して変更することができます。設定していない場合、内部文字コード(internal_encoding)が使用されます。mb_regex_encoding() で指定可能な文字コード一覧を、マルチバイト正規表現で指定可能な文字コードにまとめました。

b. マルチバイト正規表現関数一覧

マルチバイト正規表現関数は以下の通りです。各関数は PHP マニュアルの関数説明にリンクしています。

• mb_regex_set_options() は PHP 4.3.0 で追加されました。詳細は、マルチバイト正規表現のオプションを参照してください。

• mb_ereg_replace_callback() は PHP 5.4.1 で追加されました。詳細は、mb_ereg_replace_callback() 関数を参照してください。

c. マルチバイト正規表現で指定可能な文字コード

mb_regex_encoding() で指定可能な文字コードは以下の通りです(PHP 5.3.0 の時点)。問題となることはほぼないと思いますが、mbstring の内部文字コード(internal_encoding)で指定可能な文字コードと一部違いがあります。PHP 5.0.0 以降、以下の指定可能な文字コードに変更はありません。

d. マルチバイト正規表現のオプション

mb_regex_set_options() と mb_ereg_replace() の第4引数、mb_eregi_replace() の第4引数、mb_ereg_replace_callback() の第4引数で指定できる正規表現のオプションです。

mb_ereg(), mb_eregi(), mb_split() はオプションが設定できません。これらの関数は mb_regex_set_options() を使用することでオプションを設定できます。

mb_ereg_replace() の説明にオプションに関して少しだけ説明がありますが、説明されていないオプションもあります。以下に PHP で使用可能なマルチバイト正規表現関数で使用可能なオプションをまとめました。

i. PHP 4.x のオプション

以下の表のオプションが使用できます。何も設定していない場合は "p"(POSIX 互換モード) になります。

ii. PHP 5.0.0 以降のオプション

以下の表のオプションが使用できます。何も設定していない場合は "pr"(POSIX 互換モード(シングルラインモードおよび、マルチラインモード)、Ruby 形式の正規表現パターン文法)になります。

e. mb_ereg_replace_callback() 関数

mb_ereg_replace_callback() は PHP 5.4.1 で追加された関数です。正規表現にマッチした文字列に対してコールバック関数による置換ができます。

以前から、mb_ereg_replace() のオプションに "e" を渡すことで同様のことは可能でしたが、信頼できない入力に使用するとリモートからコード実行される可能性がありました。

信頼できない入力に対しては、絶対に e 修正子を使用してはいけません。 (preg_replace() と同様)自動的なエスケープは行いません。このことを忘れていると、自分の書いたアプリケーションにリモートコード実行の脆弱性を作りこんでしまうことになります。

PHP マニュアル: mb_ereg_replace

PHP 5.4.1 からは、mb_ereg_replace_callback() を使用することで、置換にコールバック関数を使用できるようになります。

置換文字列の文字コードが UTF-8 の場合は、preg_replace_callback() も使用できます。u 修飾子を使用すると、UTF-8 の文字列を扱えます。こちらは PHP 4.1.0(Win32 では、PHP 4.2.3)からサポートされています。

a. mb_detect_encoding() が失敗する(PHP 4.3.11, PHP 5.0.0 - PHP 5.0.4)

• 概要

  • PHP 4.3.11、PHP 5.0.0 で混入したバグにより、mb_detect_encoding() が正しく文字コード検出をできないことがありまます。

    これが原因で mb_convert_encoding() が失敗することがあり、文字化けを起こすことがあります。

• バグを含んでいるバージョン

  • PHP 4.3.11, PHP 5.0.0 - PHP 5.0.4

• 修正されたバージョン

  • PHP 4.4.0, PHP 5.0.5

• 参考リンク

  • [PHP-users 25298] mb_convert_encoding/mb_detect_encoding について

b. mb_encode_mimeheader() 関数が正常に動作しない(PHP 4.4.0 - PHP 4.4.1, PHP 5.0.4 - PHP 5.0.5)

• 概要

  • PHP 4.4.0 で混入したバグにより、mb_encode_mimeheader() でマルチバイト文字を含む文字列のエンコードが失敗する事があります。

    これが原因で、mb_encode_mimeheader() でエンコードした文字列や mb_send_mail() を使用して送信したメールの Subject が文字化けする事があります。

• バグを含んでいるバージョン

  • PHP 4.4.0 - PHP 4.4.1, PHP 5.0.4 - PHP 5.0.5

• 修正されたバージョン

  • PHP 4.4.2, PHP 5.1.0

• 参考リンク

  • [PHP-users 26184] PHP4.4.0でメールを送信すると、題名が文字化けします。

  • [PHP-users 26193] Re: PHP4.4.0でメールを送信すると、題名が文字化けします。

  • [PHP-users 27247] php5.0.5のmbstringで文字化け

c. mb_send_mail() 関数の第 5 引数が無視される(PHP 4.4.1)

• 概要

  • PHP 4.4.1 では、mb_send_mail() の第 5 引数に指定できる sendmail コマンドに対するオプションが無視されるという問題がありました。

    これが原因で、Envelope From の情報を設定できずに、メールを送信できなくなるなどの問題が発生しました。

• バグを含んでいるバージョン

  • PHP 4.4.1

• 修正されたバージョン

  • PHP 4.4.2

• 参考リンク

  • [PHP-users 27354] PHP4.4.1でmb_send_mailの第5引数が利かなくなってる？

d. mb_send_mail() 関数の作成する Subject: 行の文字数が RFC 違反(PHP 4.4.1 以前, PHP 5.0.5 以前)

• 概要

  • メールヘッダの Subject: の行で、文字数が RFC で規定されている 76 文字未満を満たさないことがありました。mb_encode_mimeheader() の第5引数でユーザが indent を指定してから、mb_send_mail() に渡すことで、この問題を回避できるようになりました。

    詳しくは、上記のmb_encode_mimeheader() 関数の第5引数(indent) を参照してください。

• バグを含んでいるバージョン

  • PHP 4.4.1 以前, PHP 5.0.5 以前

• 修正されたバージョン

  • PHP 4.4.2, PHP 5.1.1

• 参考リンク

  • [PHP-dev 1186] Re: PHP4.4.1でmb_send_mailの第5引数が利かなくなってる

  • [PHP-dev 1197] Re: PHP4.4.1でmb_send_mailの第5引数が利かなくなってる

e. mb_send_mail() 関数の To: (第1引数) にメールヘッダの埋め込みが可能(PHP 4.4.1 以前, PHP 5.0.5 以前)

• 概要

  • mail() では To: に改行コードが入っていた場合は改行コード除去する処理が行われるようになっていましたが、PHP 4.4.1 以前、PHP 5.0.5 以前では、mb_send_mail() では改行コードの除去が行われていませんでした。

    このため、To: に改行コードが含まれていた場合、任意のメールヘッダを追加される危険性がありました。

• バグを含んでいるバージョン

  • PHP 4.4.1 以前, PHP 5.0.5 以前

• 修正されたバージョン

  • PHP 4.4.2, PHP 5.1.0

• 参考リンク

  • [PHP-dev 1199] mb_send_mail の引数のサニタイズについて

  • PHP Bugs: #35307: [PATCH] header can be injected when using mb_send_mail()

  • PHP "mb_send_mail()" "To:" Header Injection Vulnerability (Secunia)

  • PHP MB_Send_Mail TO Argument Header Injection Vulnerability (SecurityFocus)

f. MOPB-26-2007:PHP mb_parse_str() register_globals Activation Vulnerability(PHP 4.4.6 以前、PHP 5.2.1 以前)

• 概要

  • mb_parse_str() が一つの引数のみで呼び出された場合、memory_limit 制限などで割り込まれると内部的に有効化された register_globals 設定が無効化されません。このため、この Apache のプロセスは PHP コードからは検出不可能な状態で register_globals 設定が有効にされてしまうという問題があります。

• バグを含んでいるバージョン

  • PHP 4.4.6 以前, PHP 5.2.1 以前

• 修正されたバージョン

  • PHP 4.4.7, PHP 5.2.2

• 参考リンク

  • MOPB-26-2007:PHP mb_parse_str() register_globals Activation Vulnerability (php-security.org)

  • MOPB-26-2007:PHP mb_parse_str() register_globals Activation Vulnerability 日本語訳 (yohgaki's blog)

  • PHP Mb_Parse_Str Function Register_Globals Activation Weakness (SecurityFocus)

g. "auto" の内部で扱われる文字コードがリクエストごとに初期化されない(PHP 5.2.5 以前)

• 概要

  • Apache モジュール版の PHP の問題です。

    PHP の内部の文字コードリストがリクエストごとに初期化されないという問題があります。mb_language() で文字コードリストが変更されると、次のリクエストでも引き継がれてしまい、php.ini で設定した文字コードリストに戻りません。

    スクリプト側で毎回 mb_language() を実行していれば問題は出ませんが、php.ini の設定に頼っていると、意図しない動作になる可能性があります。

    再現コードは次の通りです。試す場合は、php.ini の mbstring の設定を mbstring.language = Japanese にしてください。

    <?php
    mb_detect_order( 'auto' );
    echo implode( ', ', mb_get_info( 'detect_order' ) );    // (*1)
    mb_language( 'Russian' );
    mb_detect_order( 'auto' );
    echo implode( ', ', mb_get_info( 'detect_order' ) );    // (*2)
    

    初回のアクセス時(Apache 起動後)には、以下のようになります。

    (*1) : ASCII, JIS, UTF-8, EUC-JP, SJIS
    (*2) : ASCII, UTF-8, KOI8-R, Windows-1251, CP866

    何度かアクセスすると、結果が以下のように変わります。

    (*1) : ASCII, UTF-8, KOI8-R, Windows-1251, CP866
    (*2) : ASCII, UTF-8, KOI8-R, Windows-1251, CP866

• バグを含んでいるバージョン

  • PHP 5.2.5 以前

• 修正されたバージョン

  • PHP 5.2.6

• 参考リンク

  • [PHP-dev 1390] mbstring のいくつかの関数の挙動について

  • [PHP-dev 1391] Re: mbstring のいくつかの関数の挙動について

h. PHP 5.2.6 で修正された mbstring 関係のバグ一覧

PHP 5.2.6 では、以下のバグ修正が行われています。

1. "auto" の内部で扱われる文字コードリストがリクエストごとに初期化されない(PHP 5.2.5 以前)

2. mb_strtoupper(), mb_strtolower() で不正な文字コードを第2引数に指定すると不要なエラーメッセージまで出力される

   • PHP 5.2.5 以前では、mb_strtoupper() と mb_strtolower() において、第2引数(文字コード)に不正な文字コード名を指定すると、不要なエラーメッセージまで出力されます。

     PHP 5.2.6 からは、不要な場合は、エラーメッセージが出力されないように修正されました。

   • 参考: PHP Bugs: #43998: Two error messages returned for incorrect encoding for mb_strto[upper|lower] (bugs.php.net)

3. mb_ereg() の第1引数に不正な値を入力しても成功する

   • PHP 5.2.5 以前では、mb_ereg() の第1引数(検索パターン文字列)に不正な値(NULL, FALSE, 空文字列)を入力しても、int(1) が返ります。

     PHP 5.2.6 からは、第1引数に不正な値が入力されると、エラーになるように修正されました。

   • 参考: PHP Bugs: #43994: mb_ereg 'successfully' matching incorrectly (bugs.php.net)

4. mb_strrpos() の第3引数に負の値を指定するとバイト単位で扱われる

   • PHP 5.2.5 以前では、mb_strrpos() の第3引数(検索オフセット)に負の値を指定すると、文字数単位ではなく、バイト単位で扱われていました。

     このため、マルチバイト文字列が含まれている文字列の場合、正しい結果が得られない可能性がありました。

     PHP 5.2.6 からは、文字列単位で扱われるように修正されました。

   • 参考: PHP Bugs: #43841: mb_strrpos offset is byte count for negative values (bugs.php.net)

5. mb_strpos() の文字列境界チェックが文字数単位ではなくバイト単位で行われる

   • mb_strpos() では、第3引数(検索オフセット)の数値を設定すると、指定した文字数から検索を開始します。第3引数で第1引数(調べたい文字列)より大きな文字数を指定すると、エラーになるはずでしたが、PHP 5.2.5 以前では、この限界値の算出をバイト単位で行っていました。

     PHP 5.2.6 からは、第1引数(調べたい文字列)よりも第1引数(調べたい文字列)に大きな数値を指定すると、エラーになるように修正されました。

   • 参考: PHP Bugs: #43840: mb_strpos bounds check is byte count rather than a character count (bugs.php.net)

6. mb_ereg*_replace() の PHP 式評価時の第2引数に不正な値を入力すると PHP がクラッシュする可能性がある

   • mb_ereg_replace() と mb_eregi_replace() では、第4引数(オプション)に 'e' を指定した場合、第2引数(置換文字列) が PHP の式として評価されます。

     この 'e' オプションを使用した場合、ある文字列('<', '>', '?' など)を直接第2引数に指定すると PHP がクラッシュする可能性があります。

     再現コードは以下のようになります。

     php -r "mb_ereg_replace( 'str', '<', 'sample str', 'e' );"

   • 参考: PHP Bugs: #43301: mb_ereg*_replace() crashes when replacement string is invalid PHP expression (bugs.php.net)

i. mb_check_encoding() の第1引数に NULL バイトから始まる文字列を入力すると TRUE を返す(PHP 5.2.6 以前)

• 概要

  以下の条件の場合、mb_check_encoding() の第1引数に NULL バイトから始まる文字列を入力すると、不正な文字コードでも TRUE を返します。

  • substitute_character(内部変数) が none の場合

  • 第2引数(文字コード)にUTF-8を指定した場合

  再現コード:

  <?php
  // mb_substitute_character( 'none' );
  $str    = "\0\xFF\xFF\xFF"; //不正な文字列
  $result = mb_check_encoding( $str, "UTF-8" );
  var_dump( $result );
  

  結果は以下のようになります。

  • PHP 5.2.6

    bool(true)

  • PHP 5.2.7

    bool(false)

  回避方法として、mb_check_encoding() の代わりに以下のような代替関数を使用すれば正しい結果を得ることが可能です。

  function check_encoding( $val, $enc )
  {
      return $val === mb_convert_encoding( $val, $enc, $enc );
  }

• バグを含んでいるバージョン

  • PHP 5.2.6 以前

• 修正されたバージョン

  • PHP 5.2.7

• 参考リンク

  • マルチバイト関数の挙動を調べる　【その１】 (■右も左もわかりません■)

  • [PHP-dev 1397] mb_check_encoding() の第1引数の最初に \0 が入力された場合の問題について

j. mb_check_encoding() で一部の不正な SJIS(Shift_JIS) の文字列を TRUE と判定する(PHP 5.2.8 以前)

mb_check_encoding() で第2引数に SJIS または SJIS-win を指定し、第1引数に SJIS としては不正な文字列 "0x81 0x3a" などを指定すると TRUE を返します。

どの範囲を TRUE と誤判定するのかは mb_check_encodingは何をチェックするのか（その1 SJIS編） を参照してください。

• バグを含んでいるバージョン

  • PHP 5.2.8 以前

• 修正されたバージョン

  • PHP 5.2.9

• 参考リンク

  • mb_check_encodingは何をチェックするのか（その1 SJIS編） (hnwの日記)

  • PHP Bugs: #47399: mb_check_encoding returns true with illegal SJIS string

k. 内部変数 strict_detection が有効な状態で、不正な文字列の文字コード検出を行うと無限ループが発生する(PHP 5.1.2 - PHP 5.2.8)

PHP 5.1.2 〜 PHP 5.2.8 では、以下の条件において、無限ループが発生することがあります。

• php.ini が以下の設定で、クライアントからのリクエスト時に不正な文字列を受け取った場合

  • mbstring.http_input = auto

  • mbstring.encoding_translation = On

  • mbstring.strict_detection = On

• php.ini が上記と同様の設定で、mb_parse_str() を使用して文字列を変換した場合(この場合、mbstring.encoding_translation = Off でも再現します)

  再現コードは以下の通りです。

  mb_parse_str( "a=%fc", $dummy );

• 内部変数 strict_detection を有効にして mb_convert_variables() で不正な文字列を変換した場合

  再現コードは以下の通りです。

  ini_set( 'mbstring.strict_detection', 1 );
  mb_convert_variables( 'UTF-8', 'auto', $a = array( "\xfc" ) );

PHP 5.0.5 以前のバージョンでは、内部変数 strict_detection が存在しないため、この問題は発生しません。

• バグを含んでいるバージョン

  • PHP 5.1.2 - PHP 5.2.8

• 修正されたバージョン

  • PHP 5.2.9

• 参考リンク

  • Bug #45239 Hang (99.9%CPU) when encoding_translation is on (bugs.php.net)

l. PHP 5.2.9 で修正された mbstring 関係のバグ一覧

PHP 5.2.9 では、以下のバグ修正が行われています。

1. mb_check_encoding() で一部の不正な SJIS(Shift_JIS) の文字列を TRUE と判定する(PHP 5.2.8 以前)

2. 内部変数 strict_detection が有効な状態で、不正な文字列の文字コード検出を行うと無限ループになる(PHP 5.1.2 - PHP 5.2.8)

3. ユーロ記号(€: U+20AC)をユニコードから CP936(中国語簡体字) に変換すると不正な文字列になる

   • PHP 5.2.8 以前でユーロ記号をユニコード文字列(U+20AC)から CP936 に変換すると、不正な文字列(0x00 0x80)になります。

     php-5.2.8 -r 'var_dump( bin2hex( mb_convert_encoding( "\x20\xac", "CP936", "Unicode" ) ) );'
     string(4) "0080"

     PHP 5.2.9 で以下のように、正しく変換するように修正されました。

     php-5.2.9 -r 'var_dump( bin2hex( mb_convert_encoding( "\x20\xac", "CP936", "Unicode" ) ) );'
     string(2) "80"

   • 参考: Bug #46843 Broken Euro symbol conversion into CP936 (bugs.php.net)

4. mb_stripos(), mb_strripos() で offset(第3引数) の扱いが不正

   • PHP 5.2.8 以前のmb_stripos(), mb_strripos() では、offset(第3引数)を使用した場合、stripos() や strripos() の結果と違う場合がありました。

     PHP 5.2.9 では、stripos() と strripos() と同等になるように修正されました。

   • 参考: PHP Bugs: #45923: mb_st[r]ripos() offset not handled correctly (bugs.php.net)

5. mb_detect_encoding() で不正な文字コードを指定して検出を行うと、その後で Segmentation Fault を起こすことがある

   • PHP 5.2.8 以前では、存在しない文字コードを指定して文字コードを検出した後、mb_convert_encoding() などを使用すると、メモリの二重解放が発生します。このため、Segmentation Fault が発生することがあります。

     PHP 5.2.9 では、メモリの二重解放を回避するように修正されました。

   • 参考: Bug #47245 crash following mb_detect_encoding (bugs.php.net)

6. mb_strpos() の offset(第3引数) に負の値を渡すとバイト単位でカウントされる

   • mb_strpos() は offset(第3引数) に負の値を入力できますが、その場合、文字数ではなく、バイト単位で値を返します。

     この問題は PHP 5.2.9 で修正されました。

   • 参考: PHP Bugs: #43841: mb_strrpos offset is byte count for negative values (bugs.php.net)

m. 特定の環境で mbstring.internel_encoding の値が反映されない場合がある(PHP 5.2.9 以前)

.htaccess で mbstring.internal_encoding を 指定し、さらに、encoding_translation が On の場合に発生する問題です。

上記の環境で、リクエストで受け取った文字列が、.htaccess で設定した mbstring.internel_encoding に変換されないことがあります。

• バグを含んでいるバージョン

  • PHP 5.2.9 以前

• 修正されたバージョン

  • PHP 5.2.10, PHP 5.3.0

• 参考リンク

  • [PHP-dev 1445] mbstring.internel_encoding の値が反映されない場合がある件(1)

  • [PHP-dev 1446] mbstring.internel_encoding の値が反映されない場合がある件(2)

n. mb_check_encoding() が UTF-8 のユニコードのサロゲートペア領域を判定すると TRUE を返す(PHP 5.3.0 より前)

PHP 5.3.0 より前のバージョンの mb_check_encoding() では、サロゲートペア領域(U+D800 - U+DFFF)の UTF-8 による表現を判定すると TRUE を返します。

UTF-8 でサロゲートペア領域の文字は直接符号化してはならないことになっています(RFC3629)。

$ php-5.2.10 -r 'var_dump( mb_check_encoding( "\xed\xa0\x80","UTF-8" ) );'
bool(true)

"\xed\xa0\x80" は UTF-8 で U+D800 を表現したものです。

PHP 5.3.0 で、この判定が FALSE になるように修正されました。

• バグを含んでいるバージョン

  • PHP 5.3.0 より前のバージョン

• 修正されたバージョン

  • PHP 5.3.0

• 参考リンク

  • mb_check_encodingは何をチェックするのか（その3 UTF-8編） (hnw の日記)

  • RFC3629

  • UTF-8: サロゲートペアの扱い (Wikipedia)

o. parse_str() を使用すると、mbstring の内部エンコーディングがリセットされる(PHP 5.2.10, PHP 5.3.0)

PHP 5.2.10 および、PHP 5.3.0 では、parse_str() を使用すると、内部エンコーディングが php.ini または、.htaccess で設定した値に戻るという問題があります。

• バグを含んでいるバージョン

  • PHP 5.2.10, PHP 5.3.0

• 修正されたバージョン

  • PHP 5.2.11, PHP 5.3.1

• 参考リンク

  • PHP Bugs: #48697: mb_internal_encoding() value gets reset by parse_str() (bugs.php.net)

p. BOM 付き UTF-16 の文字列の変換で不正な結果になることがある(PHP 5.2.11 以前, PHP 5.3.1 以前)

BOM 付き UTF-16 の文字列(Little Endian)を mb_convert_encoding() で別の文字コードに変換すると文字列が壊れる問題が修正されました。

以下のようなテストコードで確認可能です。

<?php
// テスト(UTF-16: BOM 付き Little Endian の文字列)
$str = "\xFF\xFE\xC6\x30\xB9\x30\xC8\x30";
var_dump( bin2hex( mb_convert_encoding( $str, "UTF-16", "UTF-16" ) ) );
var_dump( mb_convert_encoding( $str, "UTF-8", "UTF-16" ) );

PHP 5.2.12 以降、PHP 5.3.2 以降では、以下のように正常に変換されます。

string(12) "30c630b930c8"
string(9) "テスト"

• バグを含んでいるバージョン

  • PHP 5.2.11 以前, PHP 5.3.1 以前

• 修正されたバージョン

  • PHP 5.2.12, PHP 5.3.2

• 参考リンク

  • PHP Bugs: #49528: UTF-16 strings prefixed by BOMs wrondly converted (bugs.php.net)

  • [PHP-dev 1488] mbstring の文字列変換、文字エンコーディング検出の関連の問題について

q. mbstring.strict_mode が On の場合、mb_detect_encoding() が不正な結果を返すことがある(PHP 5.2.11 以前, PHP 5.3.1 以前)

mb_detect_encoding() は、strict_mode が On の場合、先行バイトのみ正しく、後続バイトが不正な場合、false を返します。しかし、最後に先行バイトのみの文字列であった場合、true を返していた問題が修正されました。

以下のようなテストコードで確認可能です。

<?php
var_dump( "SJIS" === mb_detect_encoding( "\x81", "SJIS", TRUE ) );

PHP 5.2.12 以降、PHP 5.3.2 以降では、以下のように判定されます。

bool(false)

• バグを含んでいるバージョン

  • PHP 5.2.11 以前, PHP 5.3.1 以前

• 修正されたバージョン

  • PHP 5.2.12, PHP 5.3.2

• 参考リンク

  • PHP Bugs: #49536: mb_detect_encoding() returns incorrect results when strict_mode is turned on (bugs.php.net)

  • [PHP-dev 1488] mbstring の文字列変換、文字エンコーディング検出の関連の問題について

a. mb_ereg()、mb_ereg_replace() で UTF-8 の一部の文字がマッチしない

• 説明

  PHP 4.4.9 で使用されているマルチバイト正規表現エンジンは古く、UTF-8 の文字列の扱いが不十分であるという問題があります。このため、mb_ereg() 等の関数で一部の文字がマッチしないなどの問題があります。PHP 5.x ではマルチバイト正規表現エンジンが変更されています。PHP 5.x では UTF-8 を正しく扱えますので、この問題はありません。

  (2008.08.14): 記述の修正、追記、リンクの追加を行いました。

• 回避方法

  • PCRE ライブラリを利用する

    UTF-8 の文字列を正規表現で扱う場合、preg_match() や preg_replace() を使用します。これらの Perl 互換の正規表現関数では u 修飾子(パターン修飾子を参照)を使用することで、UTF-8 の文字列を扱えます。

  • EUC-JP 等、他の文字コードに変換してから処理する

    EUC-JP 等であれば、正しく処理できますので、先に他の文字コードに変換してから処理を行い、処理終了後に UTF-8 に戻すことでこの問題を回避することができます。

• 参考リンク

  • [PHP-users 29358] mb_ereg() で漢字を正常に判別できない？

  • [PHP-users 29510] UTF-8、正規表現で全角スペースがヒットしないことがある？

  • マルチバイト対応正規表現関数（mb_ereg系）でUTF-8の文字列が正しく処理できない件について (ます's Diary - どうでもいい事100選)

b. Apache モジュール版を使用している場合、.htaccess や ini_set() で設定した mbstring の内部変数が別のリクエストに影響する

• 説明

  php.ini で設定していない mbstring の内部変数がある場合、.htaccess や ini_set() で設定した mbstring の内部変数が別のリクエストに反映されてしまうという問題です。internal_encoding や script_encoding、substitute_character などが別のリクエストに反映されることが確認されています。この問題は PHP 5.2.7 で修正される予定ですが、PHP 4.4.9 では修正されていません。

• 回避方法

  以下のどちらかを行うことで回避できます

  • php.ini や .htaccess で初期値を設定する

  • 使用する mbstring の内部変数をスクリプトの最初で全て設定する

• 参考リンク

  • PHP Bugs: #45691: some per-dir or runtime settings may leak into other requests

  • [PHP-users 33830] .htaccessのmbstring系の設定がディレクトリをまたいで他のphpに反映されてしまう現象について

c. Apache モジュール版を使用している場合、"auto" の内部で扱われる文字コードリストが別のリクエストに影響する

• 説明

  上記で紹介した "auto" の内部で扱われる文字コードリストがリクエストごとに初期化されない(PHP 5.2.5 以前)と同じ問題です。mb_language() で文字コードリストを変更すると、次のリクエストでも引き継がれてしまい、php.ini で設定した文字コードリストに戻りません。PHP 4.4.9 では修正されませんでした。

• 回避方法

  PHP スクリプトの最初で mb_language() を実行し、使用言語を指定すれば問題を回避できます。

• 参考リンク

  • "auto" の内部で扱われる文字コードリストがリクエストごとに初期化されない(PHP 5.2.5 以前)

  • [PHP-dev 1390] mbstring のいくつかの関数の挙動について

  • [PHP-dev 1391] Re: mbstring のいくつかの関数の挙動について

d. mb_ereg() の第1引数に不正な値(NULL, FALSE, 空文字列)を入力しても成功する

• 説明

  上記の PHP 5.2.6 で修正された mbstring 関係のバグ一覧 で紹介したものと同じ問題です。mb_ereg() の第1引数(検索パターン文字列)に不正な値(NULL, FALSE, 空文字列)を入力しても、int(1) が返ってきます。この問題も PHP 4.4.9 では修正されませんでした。

• 回避方法

  第1引数の入力文字列を確認してから使用すれば問題を回避できます。

• 参考リンク

  • PHP 5.2.6 で修正された mbstring 関係のバグ一覧

  • PHP Bugs: #43994: mb_ereg 'successfully' matching incorrectly (bugs.php.net)

e. mb_check_encoding() の第1引数に NULL バイトから始まる文字列を入力すると TRUE を返す

• 説明

  上記の mb_check_encoding() の第1引数に NULL バイトから始まる文字列を入力すると TRUE を返す(PHP 5.2.6 以前)と同様の問題です。この問題は PHP 5.2.7 で修正されましたが、PHP 4.4.9 では残っています。

• 回避方法

  第1引数の文字列の NULL バイトを先に削除する、または上記で紹介した代替関数を使用すれば問題は回避できます。

• 参考リンク

  • mb_check_encoding() の第1引数に NULL バイトから始まる文字列を入力すると TRUE を返す(PHP 5.2.6 以前)

  • [PHP-dev 1397] mb_check_encoding() の第1引数の最初に \0 が入力された場合の問題について

f. mb_check_encoding() で一部の不正な SJIS(Shift_JIS) の文字列を TRUE と判定する

• 説明

  上記の mb_check_encoding() で一部の不正な SJIS(Shift_JIS) の文字列を TRUE と判定する(PHP 5.2.8 以前)と同様の問題です。この問題は PHP 5.2.9 で修正されましたが、PHP 4.4.9 では残っています。

• 回避方法

  簡単な回避方法はありません。入力文字列が SJIS や SJIS-win として妥当かどうかを判定したい場合、以下のように preg_match() と正規表現を使用する方法があります。

  // SJIS の場合
  (bool)preg_match( '/^(?:[\x00-\x7f\xa1-\xdf]|(?:[\x81-\x9f\xe0-\xef][\x40-\x7e\x80-\xfc]))*$/', $str );
  
  // SJIS-win の場合
  (bool)preg_match( '/^(?:[\x00-\x7f\xa1-\xdf]|(?:[\x81-\x9f\xe0-\xfc][\x40-\x7e\x80-\xfc]))*$/', $str );
  

• 参考リンク

  • mb_check_encoding() で一部の不正な SJIS(Shift_JIS) の文字列を TRUE と判定する(PHP 5.2.8 以前)

  • mb_check_encodingは何をチェックするのか（その1 SJIS編） (hnwの日記)

g. ユーロ記号(€: U+20AC)をユニコードから CP936(中国語簡体字) に変換すると不正な文字列になる

• 説明

  上記の PHP 5.2.9 で修正された mbstring 関係のバグ一覧 で紹介したものと同じ問題です。この問題は PHP 5.2.9 で修正されましたが、PHP 4.4.9 では残っています。

• 回避方法

  ありません。

• 参考リンク

  • PHP 5.2.9 で修正された mbstring 関係のバグ一覧

  • Bug #46843 Broken Euro symbol conversion into CP936 (bugs.php.net)

h. mb_detect_encoding() で不正な文字コードを指定して検出を行うと、その後で Segmentation Fault を起こすことがある

• 説明

  上記の PHP 5.2.9 で修正された mbstring 関係のバグ一覧 で紹介したものと同じ問題です。この問題は PHP 5.2.9 で修正されましたが、PHP 4.4.9 では残っています。

• 回避方法

  mb_detect_encoding() に不正な文字コードを指定されないようにすれば回避できます。

• 参考リンク

  • PHP 5.2.9 で修正された mbstring 関係のバグ一覧

  • Bug #47245 crash following mb_detect_encoding (bugs.php.net)

i. mb_check_encoding() が UTF-8 のユニコードのサロゲートペア領域を判定すると TRUE を返す

• 説明

  上記の mb_check_encoding() が UTF-8 のユニコードのサロゲートペア領域を判定すると TRUE を返す(PHP 5.3.0 より前) で紹介したものと同様の問題です。

• 回避方法

  直接の回避方法はありません。UTF-8 の文字コード判定に、mb_check_encoding() ではなく、正規表現を使用することで、厳密なチェックを行うことが可能です。

j. mbstring.strict_mode が On の場合、mb_detect_encoding() が不正な結果を返すことがある

• 説明

  上記の mbstring.strict_mode が On の場合、mb_detect_encoding() が不正な結果を返すことがある(PHP 5.2.12 以前, PHP 5.3.0) で紹介したものと同様の問題です。

• 回避方法

  直接の回避方法はありません。正規表現を使用して厳密な文字コード検出を行うことは可能です。

k. BOM 付き UTF-16 の文字列の変換で不正な結果になることがある

• 説明

  上記の BOM 付き UTF-16 の文字列の変換で不正な結果になることがある(PHP 5.2.12 以前, PHP 5.3.0) で紹介したものと同様の問題です。

• 回避方法

  直接の回避方法はありません。UTF-16 の文字列を扱う場合は、外部コマンド(iconv, nkf など)で変換することは可能です。

a. PHP による日本語の文字コード判定スクリプト

PHP による日本語の文字コード判定スクリプト (2004.11.21 の過去ログ)に書いたものです。

文字列の文字コードを判定する場合、PHP には mb_detect_encoding() が用意されていますが、文字列が短い場合、判定に失敗することが多くなりますので、もう少し判定率の良いスクリプトを作成してみました。

mbstring(マルチバイト文字列関数) と mbregex(マルチバイト正規表現関数) が必要です。文字コード範囲が重なるような場合は、SJIS-win を優先させています。

各文字コードの範囲については、Perl メモ:文字の正規表現を参考にしました。

(2008.02.03 修正)

以前のスクリプトでは、日本語を含まない長い文字列を入力すると、セグメンテーションフォールトが発生することを確認しました。そういった問題が起こらないようにスクリプトの正規表現を修正しました。

/**
 * 日本語文字列の文字コード判定(ASCII/JIS/eucJP-win/SJIS-win/UTF-8 のみ)
 */
function detect_encoding_ja( $str )
{
    $enc = @mb_detect_encoding( $str, 'ASCII,JIS,eucJP-win,SJIS-win,UTF-8' );

    switch ( $enc ) {
    case FALSE   :
    case 'ASCII' :
    case 'JIS'   :
    case 'UTF-8' : break;
    case 'eucJP-win' :
        // ここで eucJP-win を検出した場合、eucJP-win として判定
        if ( @mb_detect_encoding( $str, 'SJIS-win,UTF-8,eucJP-win' ) === 'eucJP-win' ) {
            break;
        }
        $_hint = "\xbf\xfd" . $str; // "\xbf\xfd" : EUC-JP "雀"

        // EUC-JP -> UTF-8 変換時にマッピングが変更される文字を削除( ≒ ≡ ∫ など)
        mb_regex_encoding( 'EUC-JP' );
        $_hint = mb_ereg_replace( "\xad(?:\xe2|\xf5|\xf6|\xf7|\xfa|\xfb|\xfc|\xf0|\xf1|\xf2)", '', $_hint );

        $_tmp  = mb_convert_encoding( $_hint, 'UTF-8', 'eucJP-win' );
        $_tmp2 = mb_convert_encoding( $_tmp,  'eucJP-win', 'UTF-8' );
        if ( $_tmp2 === $_hint ) {

            // 例外処理( EUC-JP 以外と認識する範囲 )
            if (
                // SJIS と重なる範囲(2バイト|3バイト|iモード絵文字|1バイト文字)
                ! preg_match( '/^(?:'
                    . '(?:[\x8E\xE0-\xE9][\x80-\xFC])+|'
                    . '(?:\xEA[\x80-\xA4])+|'
                    . '(?:\x8F[\xB0-\xEF][\xE0-\xEF][\x40-\x7F])+|'
                    . '(?:\xF8[\x9F-\xFC])+|'
                    . '(?:\xF9[\x40-\x49\x50-\x52\x55-\x57\x5B-\x5E\x72-\x7E\x80-\xB0\xB1-\xFC])+|'
                    . '[\x00-\x7E]+'
                    . ')+$/', $str ) &&

                // UTF-8 と重なる範囲(全角英数字|漢字|1バイト文字)
                ! preg_match( '/^(?:'
                    . '(?:\xEF\xBC[\xA1-\xBA])+|'
                    . '(?:[\xE4-\xE9][\x8E-\x8F\xA1-\xBF][\x8F\xA0-\xEF])+|'
                    . '[\x00-\x7E]+'
                    . ')+$/', $str )
            ) {
                // 条件式の範囲に入らなかった場合は、eucJP-win として検出
                break;
            }
            // 例外処理2(一部の頻度の多そうな熟語を eucJP-win として判定)
            // (珈琲|琥珀|瑪瑙|癇癪|碼碯|耄碌|膀胱|蒟蒻|薔薇|蜻蛉)
            if ( mb_ereg( '^(?:'
                . '\xE0\xDD\xE0\xEA|\xE0\xE8\xE0\xE1|\xE0\xF5\xE0\xEF|\xE1\xF2\xE1\xFB|'
                . '\xE2\xFB\xE2\xF5|\xE6\xCE\xE2\xF1|\xE7\xAF\xE6\xF9|\xE8\xE7\xE8\xEA|'
                . '\xE9\xAC\xE9\xAF|\xE9\xF1\xE9\xD9|[\x00-\x7E]+'
                . ')+$', $str )
            ) {
                break;
            }
        }

    default :
        // ここで SJIS-win と判断された場合は、文字コードは SJIS-win として判定
        $enc = @mb_detect_encoding( $str, 'UTF-8,SJIS-win' );
        if ( $enc === 'SJIS-win' ) {
            break;
        }
        // デフォルトとして SJIS-win を設定
        $enc   = 'SJIS-win';

        $_hint = "\xe9\x9b\x80" . $str; // "\xe9\x9b\x80" : UTF-8 "雀"

        // 変換時にマッピングが変更される文字を調整
        mb_regex_encoding( 'UTF-8' );
        $_hint = mb_ereg_replace( "\xe3\x80\x9c", "\xef\xbd\x9e", $_hint );
        $_hint = mb_ereg_replace( "\xe2\x88\x92", "\xe3\x83\xbc", $_hint );
        $_hint = mb_ereg_replace( "\xe2\x80\x96", "\xe2\x88\xa5", $_hint );

        $_tmp  = mb_convert_encoding( $_hint, 'SJIS-win', 'UTF-8' );
        $_tmp2 = mb_convert_encoding( $_tmp,  'UTF-8', 'SJIS-win' );

        if ( $_tmp2 === $_hint ) {
            $enc = 'UTF-8';
        }
        // UTF-8 と SJIS 2文字が重なる範囲への対処(SJIS を優先)
        if ( preg_match( '/^(?:[\xE4-\xE9][\x80-\xBF][\x80-\x9F][\x00-\x7F])+/', $str ) ) {
            $enc = 'SJIS-win';
        }
    }
    return $enc;
}

文字コード判定の考え方としては、以下のようになっています。

1. EUC-JP -> UTF-8 への変換してから、UTF-8 -> EUC-JP を行った場合、逆変換に成功することは少ない

2. まず、文字コードがあいまいな文字列を EUC-JP として検出させ、1. より、EUC-JP で無いことを確認した場合は SJIS か UTF-8 を判定

3. EUC-JP での逆変換に成功した場合、SJIS と文字コードが重なる部分は SJIS を優先

4. EUC-JP でない場合、UTF-8 と仮定して逆変換に成功した場合のみ UTF-8 として検出

5. 例外は個別対応

この文字コード判定スクリプトには以下の問題があります。

• 少し重くなる

• PHP の mbstring に依存している(汎用性がない)

• EUC-JP のいわゆる半角カタカナ(\x8e[\xa1-\xfc])や、EUC-JP の一部の文字([\xe0-\xea][\xa1-\xfc])のみで構成される文字列は SJIS-win として判定される

• UTF-8 の一部の記号(数学記号とギリシア文字の一部)が含まれる文字列が eucJP-win として判定される

使用方法としては、以下のように文字コードが分からない日本語文字列を UTF-8 に変換するような関数を作成する場合に便利です。

function convert_utf8( $str )
{
    $encoding = detect_encoding_ja( $str );
    return mb_convert_encoding( $str, 'UTF-8', $encoding );
}

b. 入力時フィルタ

最近は、不正な文字(マルチバイトの上位バイトのみ入力するなど)を攻撃に使用されるなど、Web アプリケーションでもいろいろと考慮することが多くなっています。

個人的に、文字コードに可憐する問題への対処を含め、できる限り環境を統一するようなフィルタを作って、最初にインクルードして使用しています。何かの参考になるかもしれませんので、公開しておきます。

このスクリプトを使用することで、以下の環境にあわせる目的としています。

• register_globals = Off

• magic_quotes_gpc = Off

• 改行コードを "\n" に統一

• 文字列に NULL バイトが含まれていない

• 入力された変数( $_GET, $_POST, $_SERVER など)の文字コードが内部文字コードと同じ

function __input_filter()
{
    // php.ini の register_globals が有効になっていた場合は、登録された変数を削除
    if ( ini_get( 'register_globals' ) ) {
        if ( isset( $_REQUEST['GLOBALS'] ) ) {
            trigger_error( 'GLOBALS overwrite attempt detected', E_USER_ERROR );
        }
        $no_unset = array(
            'GLOBALS'  => '', '_GET'    => '', '_POST' => '', '_COOKIE' => '',
            '_REQUEST' => '', '_SERVER' => '', '_ENV'  => '', '_FILES'  => ''
        );
        $input = array_merge(
            $_GET, $_POST, $_COOKIE, $_SERVER, $_ENV, $_FILES,
            isset( $_SESSION ) ? (array)$_SESSION : array()
        );
        foreach ( array_keys( $input ) as $k ) {
            if ( ! isset( $no_unset[$k] ) && isset( $GLOBALS[$k] ) ) {
                unset( $GLOBALS[$k] );
            }
        }
    }
    // $HTTP_*_VARS を削除
    foreach ( array_keys( $GLOBALS ) as $k ) {
        if ( strncmp( $k, 'HTTP_', 5 ) === 0 ) {
            unset( $GLOBALS[$k] );
        }
    }

    // php.ini で magic_quotes_gpc が有効になっていた場合、エスケープを削除
    if ( get_magic_quotes_gpc() ) {
        function __stripslashes_r( $a )
        {
            if ( is_array( $a ) ) {
                return array_map( __FUNCTION__, $a );
            }
            return stripslashes( $a );
        }
        if ( $_SERVER  ) { $_SERVER  = __stripslashes_r( $_SERVER  ); }
        if ( $_GET     ) { $_GET     = __stripslashes_r( $_GET     ); }
        if ( $_POST    ) { $_POST    = __stripslashes_r( $_POST    ); }
        if ( $_COOKIE  ) { $_COOKIE  = __stripslashes_r( $_COOKIE  ); }
        if ( $_REQUEST ) { $_REQUEST = __stripslashes_r( $_REQUEST ); }
    }

    // 改行コードを統一し、NULL バイトを削除
    function __unify_filter( $a )
    {
        if ( is_array( $a ) ) {
            return array_map( __FUNCTION__, $a );
        }
        return str_replace( "\0", "",
            strtr( str_replace( "\x0D\x0A", "\n", $a ), "\x0D\x0A", "\n\n" )
        );
    }
    if ( $_GET     ) { $_GET     = __unify_filter( $_GET     ); }
    if ( $_POST    ) { $_POST    = __unify_filter( $_POST    ); }
    if ( $_COOKIE  ) { $_COOKIE  = __unify_filter( $_COOKIE  ); }
    if ( $_REQUEST ) { $_REQUEST = __unify_filter( $_REQUEST ); }
    if ( $_SERVER  ) { $_SERVER  = __unify_filter( $_SERVER  ); }
    if ( $_ENV     ) { $_ENV     = __unify_filter( $_ENV     ); }
    if ( $_FILES   ) { $_FILES   = __unify_filter( $_FILES   ); }

    // 入力された文字コードが内部文字コードと違った場合、エラーとして検出
    if ( extension_loaded( 'mbstring' ) ) {

        function __check_encoding( $val, $key, $encoding )
        {
            if ( is_array( $val ) ) {
                array_walk( $val, __FUNCTION__, $encoding );
            }
            else if ( (string)$val !== mb_convert_encoding( $val, $encoding, $encoding ) ) {
                trigger_error( 'Invalid character encoding', E_USER_ERROR );
                exit;
            }
            if ( (string)$key !== mb_convert_encoding( $key, $encoding, $encoding ) ) {
                trigger_error( 'Invalid character encoding', E_USER_ERROR );
                exit;
            }
        }
        $enc = mb_internal_encoding();
        if ( $_GET     ) { array_walk( $_GET,     '__check_encoding', $enc ); }
        if ( $_POST    ) { array_walk( $_POST,    '__check_encoding', $enc ); }
        if ( $_COOKIE  ) { array_walk( $_COOKIE , '__check_encoding', $enc ); }
        if ( $_REQUEST ) { array_walk( $_REQUEST, '__check_encoding', $enc ); }
        if ( $_SERVER  ) { array_walk( $_SERVER,  '__check_encoding', $enc ); }
    }
}

// フィルタを実行
__input_filter();

このスクリプトの処理としては、以下の通りです。

• register_globals が有効になっていた場合、登録されたグローバル領域の変数を削除(スーパーグローバル変数を除く)

• $GLOBALS を上書きするような要求があった場合、エラーとしてスクリプトを終了

• magic_quotes_gpc が有効になっていた場合、エスケープを解除

• 入力文字列の 改行コードを \n に統一

• 入力文字列の NULL バイトを削除

• 入力文字列のキーと値が内部文字コード(internal_encoding)と違う場合は、エラーとしてスクリプトを終了

使い方は、上のスクリプトを適当なファイル(inputfilter.inc.php など)に保存して、最初に実行するスクリプト(index.php など)の最初の方で以下のように実行します。有効な内部文字コードを設定していないとエラーになりますので、注意してください。

<?php
mb_language( 'Japanese' );
mb_internal_encoding( 'UTF-8' ); // スクリプトの内部エンコード
include( 'inputfilter.inc.php' );

上記のスクリプトは、以下に掲載されていたコードなどを参考にさせていただきました。

• 私はどのように register_globals を扱うべきですか? (PHP マニュアル)

• これからのプログラムの作り方 - 文字エンコーディング検証は必須 (yohgaki's blog)