WordPressのプラグインを作るのに、日本語の正規表現が必要なのだけれど、
ぐぐると、何やら情報が混乱ぎみだったので、調べた結果だけをまとめておく。

まぁ、 WordPressのコーディングルールを見て、正式に公開する気は無くなったので、
自分(と自身で何とか出来る人)だけ使えれば良いのだけど。

orgのテーブルだけ変換するプラグインを作った時には何も考えなかったけれど、
Unicodeに対応するのは結構面倒だ、という話。

出来れば関わりたくない。
調べた結果、org-modeのタグを見付けるだけなら、意識しなくて良さそうだ。

# 正規表現の種類
まず、正規表現自体が3種類もある。(汗)

|———+———–+——————————-|
| 名称 | 種類 | 備考 |
|———+———–+——————————-|
| pcre | Perl 互換 | preg_～関数 |
| | | UTF-8 のみ扱える |
| | | パターン修飾子に u を指定する |
| | | 注意点がそれありに有る |
|———+———–+——————————-|
| mbregex | mbstring | mb_ereg～関数 |
| | | 別途インストールが必要 |
|———+———–+——————————-|
| regex | POSIX | 非推奨 |
|———+———–+——————————-|

余計なインストールを避けるなら、 pcre 一択。

とりあえず見付けた、pcre(Perl互換正規表現)の問題一覧。

– 対応する日本語コードは UTF-8 のみ
– UTF-8 を使う場合は、パターン修飾子に u を指定する(PCREのドキュメントに見付からないけど)
– 処理の制限値があり、越えると 0(マッチしない)を返す
– 文字クラス(alnum,alpha,ascii…)の動作が曖昧？ドキュメント上は日本語にマッチしないはずだけど。。。
– 「.」はデフォルトでは改行にマッチしない

# 使用する関数やライブラリ；mb_～は必要か？
mbstring を使う場合のデメリットはこんな感じ。

– WordPressのプラグインのために追加インストールが必要
– 内部エンコーディングとは別に、検索対象の日本語コードを指定する必要がある

追加しなきゃならないのは、今回は致命的だなぁ。

問題あるにせよ、気をつければ pcre(preg_match/preg_replace)で十分事足りそう。
日本語自体で正規表現を書かなければ良いのだし。

# Unicodeの制御信号、異体字セレクタなどの影響
日本人としては信じ難いことに、Unicodeには似た漢字を同じコードで表わす仕様がある。
Standardized VariantsとかVariation selectorとか、見たところ場当たり的に追加された様だ。

実際には、見付けたいのはアスキー文字の部分なので、
例えば「．*」に漢字を含めてくれるのなら、今回は気にしなくて良い。

問題の頻度を想像するに、起きてから対策すれば良い程度のものだろう。
そして今回は、起こりそうにない。(起さない… きっと)