Unicode を NFKC にノーマライズ

具体的な変換例

NFKC は互換分解の後に再合成し、字体や文字幅の違いが失われる場合があります。処理はブラウザー内で行われ、例の「こんにちは ＡＢＣ ①」は「こんにちは ABC 1」になります。全角文字や囲み数字が通常の文字へ変わることがあり、変更は必ずしも元に戻せません。受け取り側がこれらの文字を同等とみなすと明示している場合だけ適用してください。識別子や記録の元の表記を保持する必要があるなら、変換前の文字列も保存します。

表現形式の仕組み

Unicode 正規化には四つの形式があります。NFC と NFD は正準形式で、定義に応じて合成または分解しながら正準等価性を保ちます。NFKC と NFKD は互換性に基づく対応付けも適用し、全角ラテン文字や丸付き数字を通常の形に変えることがあります。この変換で、用途によって重要な違いが失われ得ます。C は再合成、D は分解を意味します。正規化後の結果は見た目が同じでも、コードポイント列は変わる場合があります。正規化は一部の厳密一致の比較や検索索引に有用ですが、システム全体で同じ形式を使う必要があります。万能なセキュリティーフィルターでも、言語間の翻字器でもありません。NFKC は互換分解の後に再合成するため、印刷上の区別が消えることがあります。データベースのキーへ NFKC を導入する前に、全角文字、丸付き数字、普通の文字を含め、その欄の実例を複数比較してください。

元は異なる二つの文字列が同じキーに正規化される場合、衝突をどう扱うか決めてください。この変換ツールではその方針を決められません。NFKC を二回適用した結果は安定しているはずですが、安定性と元に戻せることは別です。明確な規則なしに、表示名や署名付きの元データを正規化後の値で上書きしないでください。セキュリティに関わる識別子は、アプリケーション全体の検証規則と、見分けにくい文字を検出する規則でもテストしてください。互換正規化だけでは十分ではありません。

限界と信頼性

正規化は言語を翻訳せず、見た目が紛らわしいすべての文字を取り除くものでもありません。互換性正規化では、文字の表記上の違いが意図的に変わることがあります。製品が互換性のある文字形を同一視すると決めた場合、NFKC は検索キーに適します。たとえば全角のラテン文字や丸囲み数字は、互換性分解と再合成を経て普通の文字に変わる場合があります。これは方針の選択であり、あらゆる識別子に対する自動的な改善ではありません。変換後の文字列には利用者が入力した形が残らないことがあるため、表示や監査で忠実性が重要なら原文も保存してください。NFKC だけで視覚的に紛らわしい文字をすべて解決したり、入力をパーサーにとって安全にしたりはできません。