正規表現処理の濁点でハマった話

別にハマったと言うほどでは無いんですが、結構内容が衝撃的だったので、備忘録として記事を書いておきます。

この二つは全く別の文字列です

とりあえずこの二つの文字列を見てください。

あなたには何が見えましたか？

ブラウザ越しのほとんどの人の環境では、1番も2番も全く同じように見えるのではないでしょうか？

少なくとも、僕の環境からは何の違いも見当たりません。

別物であるという証明

違いがわかりやすくしてみる

Wordにコピペした場合こうなります。（HTML形式でコピペすると違いがわかりません）

さらに文字コードを調べてみる

なんと、Windows関係のソフトが標準的によく利用する「Shift-JIS」という文字コード形式ではこの濁点・半濁点は存在すらしないようです。

「で？何が問題なの？」

と思ったあなたは確実にプログラマではありません（笑）

大抵のプログラマは「こいつはヤバすぎる」と感じるはずです。

恥ずかしながら僕もこの事象は知りませんでしたので、割と衝撃を受けました。（濁点が分離する現象があるのは知ってましたが、見たら分かると思ってました）

実際にこの分離された濁点が引き起こす問題

とりあえず、PCからこのページを見ている方は、ブラウザのページ検索のポップアップ（Ctrl + F）を開いてください。

そして、まず1番の「プログラミング」 と言う文字列をコピーし、検索窓に入れます。

僕の環境（Google Chrome）では上記の画像の様に提示した文字列1番2番ともに検索に引っかかり、ハイライトされます。

ただ2番の「プログラミング」 を検索窓に入れた場合、 下の画像のように2番しか検索に引っかからず、一番はハイライトされません。

この問題が引き起こす最大の問題は検索に引っ掛からないということです。

ここでいう検索とはプログラム上から指定した文字列にマッチさせるような動作全てを指します。

モノによっては対策されてる

上記の例に挙げた「Google Chrome」の場合なんかだと１番の文字列を検索窓に入れても２番を引っ掛けることができてるようですので、一部対策されてます。

逆は無理なようですが。

逆側の対策をしてない理由は推測するに、この分離する濁点を意図せず入力してしまう環境がごく一部な点からコスト/リターンが合わないからじゃないかなと思います。

濁点分離が問題となる具体的なケース

濁点や半濁点が分離している文字列が問題を引き起こす具体的な例を挙げてみましょう。

1. データベース検索や一致判定でのトラブル

データベースに保存された文字列が、分離型濁点を含むものと通常型の文字列が混在している場合、検索クエリが意図通りに動作しなくなる可能性があります。

例えば：

SELECT * FROM users WHERE name = 'プログラミング';

上記クエリが、分離型濁点を含む プログラミング を保存したレコードを返さない、という問題が発生します。これにより、データの一貫性が崩れ、ユーザー体験を損なう結果になりかねません。

2. ファイル名やパスの扱い

ファイルシステム上で濁点分離文字列が存在すると、ファイルの検索や読み込み時に問題を引き起こすことがあります。

例：

1. ファイル名として プログラミング.txt を保存。

2. 別のプログラムが プログラミング.txt を探す。

結果：同じ名前に見えても別ファイルとして扱われ、エラーやファイルが見つからない事態に繋がる。

3. 正規表現の挙動

正規表現を用いたパターンマッチングでも注意が必要です。以下の例で確認できます：

import re

# 通常のカタカナ
pattern = re.compile(r'プログラミング')

# 分離型濁点の文字列
text = 'プログラミング'

match = pattern.match(text)
print(match)  # None が返る

正規表現エンジンは文字列を「バイトレベル」で比較するため、分離型濁点を意識しないとマッチしません。

解決策や対策方法

このような問題を防ぐために、いくつかの解決策を検討します。

1. 文字列正規化（Normalization）を使用する

Pythonの場合、unicodedata モジュールで正規化が可能です。

import unicodedata

text = 'プログラミング'  # 分離型濁点の文字列
normalized_text = unicodedata.normalize('NFC', text)

print(normalized_text)  # 'プログラミング' に変換される

正規化には以下の2種類があり、用途に応じて選択します：

• NFC（Normalization Form C）： 濁点を結合。

• NFD（Normalization Form D）： 濁点を分離。

2. 入力データの検証

ユーザー入力や外部から取り込むデータに対して、正規化処理をルール化することが重要です。

3. システム全体での統一

• データベース保存前に正規化を行う。

• ファイル名生成時も統一ルールを適用。

まとめ

分離型濁点問題は、見た目には気付きにくいものの、検索や一致判定のようなシステムの基盤部分に大きな影響を及ぼします。特に多言語対応や国際化されたシステムでは、日本語特有の濁点問題を見落としがちです。

この問題を回避するために：

1. 常に文字列を正規化 する。

2. システム全体で統一ルール を持つ。

3. 検証とテストを徹底 する。

シンプルに思える文字列操作でも、Unicodeの世界では奥深い課題が潜んでいることを忘れないようにしたいですね。