マルチバイト文字のtrim
yahoo!の検索エンジンがGooleの検索エンジンになるというニュースはありましたが
とうとう切り替わったのを確認してしまいました。（徐々に切り替わっていくらしい）
Googleはページの表示スピードも見てるらしいので少しでもPHPのスピードを上げたくて最近ではベンチを使って速度を比較している。
他者の計ったベンチがGoogleで調べればすぐに出てくるのになぜ自分で調べるかというと、例えば文字の置換はstr_replaceを使い。
$str = str_replase(“AAA”, “BBB”, $str);
とするが普通で速度も早いが、検索文字（例の場合”AAA”）の出現がレアな場合
if (strpos($str,”AAA”) !== false) $str = str_replase(“AAA”, “BBB”, $str);
と置換する前に先に検索した方が早かったりするので、実際のデータが無いと分からないのでベンチを計る必要が出てきたりする。
そんな中、比較的遅いというmb_ereg_replaceを使ってるマルチバイトのtrimを調査してみることにした。
$str = mb_ereg_replace(“^[ ]+”, “”, $str);
$str = mb_ereg_replace(“[ ]+$”, “”, $str);
昔、Shift-JISで単純にtrimの第2引数に全角スペースを入れてトリムすると文字化けしたのでmb_ereg_replaceを使ってるが、安全だけど遅い。
そこで昔文字化けした理由を調べに文字コードをwikipediaで見てみた。
Shift_JIS
第1バイトが81-9FとE0-FC、
第2バイトが40-7Eと80-FC
EUC-JP
第1バイトがA1-A8とADとB0-F4とF9-FC、（亜種は8FとF5-FEも）
第2バイトがA1-FE（亜種は第3バイトにもA1-FE）
UTF-8
第1バイトがC2-FD、
第2バイト以降が80-BF
trimのデフォルトの第2引数は
” ” (0x20), 半角スペース
“\t” (0x09), タブ
“\n” (0x0A), 改行
“\r” (0x0D), 復帰
“\0” (0x00), NUL バイト
“\x0B” (0x0B), 垂直タブ
とどの文字コードにも危険なコードが含まれていないので普通に使える。
ただtrimはマルチバイトには対応していないのでシングルバイトに変換され削除されるので全角スペースを除去しようとすると下記のように問題が発生する。
Shift_JISの全角スペースは0x8140でtrimの第2引数に全角スペースを入れると81と40が削られアウト
（http://charset.7jp.net/sjis.htmlの81と40が絡む行や列が文字化けする。）
EUC-JPの全角スペースは0xA1A1でtrimの第2引数に全角スペースを入れるとA1が削られアウト
（http://charset.7jp.net/euc.htmlのA1が絡む行や列が文字化けする。）
UTF-8の全角スペースは0xE38080でtrimの第2引数に全角スペースを入れるとE3と80が削られアウト
正しく全角スペースをトリムするならmb_ereg_replaceしか無く、すべての全角スペースが半角スペースになってもよければ
$str = trim(str_replase(“ ”, ” “, $str));
と先に全角スペースを半角スペースに変換するなど、シチュエーションによって使い分けるしか無いようだ。
Tags: PHP