htmlspecialchars/htmlentitiesはBMP外の文字を正しく扱えない

補足

この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。
備忘のため転載いたしますが、この記事は2009年10月14日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。
補足終わり

PHPの安定版(PHP5.3.0、PHP5.2.11)のhtmlspecialcharsおよびhtmlentitiesには、Unicodeの基本多言語面 (BMP)範囲外の文字、すなわち、U+10000以降の文字を正しく扱えない問題があります。
もっともシンプルな再現コードを以下に示します。

<?php
  $c = "\xF0\x90\x80\xBC"; // U+1003C
  $a = htmlspecialchars($c, ENT_QUOTES, 'UTF-8');
  echo bin2hex($a) . ':' . $a;

【処理結果】
266c743b:&lt;

U+1003Cは、Wikipediaの説明によると、大昔のギリシャの「線文字B」を表すそうで、小なり記号とは関係ないので、本来そのまま出力しなければならないものです。htmlspecialcharsおよびhtmlentitiesの内部処理で、コードポイントの下位16ビットしかみていないようで、このような結果となります。
線文字Bを扱う人口は少ないと思われますので、もう少し身近な例を探してみました。

<?php
  $c = "\xF0\xA2\x89\xBF";  // U+2227F（𢉿 …マダレに馬という字）
  $a = htmlentities($c, ENT_QUOTES, 'UTF-8');
  echo bin2hex($a) . ':' . $a;

【処理結果】
26736373696d3b:&scsim;

𢉿は、京都府長岡京市の地名で𢉿子ケ岳（からねがたけ）に使われている文字です（参考:稀少地名漢字リスト、Google Map）。一方、≿はSGMLの文字実体参照のマッピングに出てくる記号で、≿（カーブした大なり記号の下に～）を表します。この実体参照形式はFireFoxなどのブラウザでは表示できませんが、そのような文字実体参照に変換される経緯は、id:moriyoshiさんの「PHPのhtmlentities()で (HTML4.0的に) 余計に実体参照に変換されてしまう文字の一覧」に説明されています。
BMP外の文字を扱う機会は少ないとは思いますが、正常系のデータが正しく扱えないという意味では、先の文字エンコーディングのチェック不備よりも重い問題だと考えます。幸い、id:moriyoshiさんが先に気づかれて、文字エンコーディングの問題と合わせて修正されていますので、おそらくPHP5.3.2からは修正されるものと思われます。PHPの最新のスナップショットにて修正ずみであることを確認しています。

影響を受けるケース

この問題を受けるのは、文字エンコーディングとしてUTF-8を使用している場合に、BMP範囲外の文字が与えられた場合です。

対策

PHP側の対応が完了するまでの間は以下のようにすればよいと思います。htmlentitiesよりはhtmlspecialcharsの方が影響が少ないこと、通常htmlentitiesを使う理由はない（参考:htmlspecialcharsと不正な文字の話 ）ことから、htmlspecialcharsを使った上で、影響のある文字を扱わなければならない場合は個別に手当するしかないでしょう。Unicode5.1の範囲で、htmlspecialcharsにより不正に変換される文字は、以下の13種です。htmlentitiesを使用すると616種に増えます。𢉿もその一つです。

U+10022 線文字B音節文字
U+10026 線文字B音節文字
U+1003C 線文字B音節文字
U+20022 𠀢
U+20026 𠀦
U+20027 𠀧
U+2003C 𠀼
U+2003E 𠀾
U+E0022 言語タグ
U+E0026 言語タグ
U+E0027 言語タグ
U+E003C 言語タグ
U+E003E 言語タグ

個別に対応する方法を考えてみましたが、簡単な方法は思いつきません。いったん他の文字列に置き換えておいて、htmlspecialcharsの処理結果から、元の文字に戻す方法があると思いますが、面倒な処理になります。あるいは、影響を受ける文字を数値文字参照（𠀢など）に変換しておいて、htmlspecialcharsの第四パラメータ$double_encodeを0にして実行する方法もありますが、$double_encodeを0にする副作用もあります。元々実体参照や数値文字参照の形になってる文字列を変換しなくなるからです。このため現状では上記問題を許容した上で、PHP側で対応されるのを待った方がよい場合が多いような気がします。

まとめ

PHPのhtmlspecialcharsおよびhtmlentitiesには、Unicodeの基本多言語面 (BMP)範囲外の文字を正しく扱えません。次バージョン（PHP5.2.12、PHP5.3.2）では修正されると思われます。それまでの間は以下の方法で対処可能です。

• htmlentitiesではなくhtmlspecialcharsを使用する
• htmlspecialcharsでも影響を受ける13文字は個別に対応する、あるいは許容する