Unicode正規化（NFC/NFD/NFKC/NFKD変換）

テキストをNFC/NFD/NFKC/NFKDの4形式に変換し、コードポイント数・UTF-8バイト数・変化の有無を一覧表示。Macで濁点が分離する問題の検出・修正にも対応します。

Macで作ったファイルを別の環境に持っていったら「が」で検索してもヒットしない、という経験はありませんか。濁点が別の文字として分離しているのが原因のことが多いです。このツールはテキストをNFC/NFD/NFKC/NFKDの4形式に変換し、文字数・バイト数の違いを一覧表示します。

使い方

上の欄に確認したいテキストを貼り付ける。
NFC・NFD・NFKC・NFKDそれぞれのコードポイント数・UTF-8バイト数・元との違いが一覧で表示される。数値だけでなく、変換後の文字列自体も下のコピー欄で確認できる。
濁点の分離（Mac特有の問題）を検出した場合は、NFCで修正した文字列が別枠に表示される。

仕組み・計算式

Unicode正規化はUnicode標準附属書UAX #15で定義される仕様で、String.prototype.normalize()はECMAScript仕様（ECMA-262）でこれをそのまま呼び出せるメソッドです。NFC/NFKCは合成済み（濁点などを1文字にまとめる）、NFD/NFKDは分解済み（濁点などを別の結合文字に分ける）の形式です。試してみると、「か」+結合文字の濁点（U+3099）は見た目は「が」と同じでもコードポイント数が2、UTF-8バイト数が5になり、NFCで正規化すると1文字・3バイトの「が」に一致しました。NFKC/NFKDはさらに、①のような丸数字や㈱、全角英数字、半角カナも標準的な形に変換するため、見た目や桁数が変わることがあります。

現場の落とし穴: 絵文字家族（👨‍👩‍👧‍👦のようなZWJ結合絵文字）を含む文字列でも、normalize()はコードポイントの並びを崩さないので分割される心配はありません。試したところ、見た目の文字数（グラフェム数）は正規化前後で変わりませんでした。

よくある質問

Q. NFKCで文字数が減ることがあるのはなぜですか？

A. ㈱のような合字が「(株)」のように複数文字へ展開される一方、全角英数字が半角1文字に統一されるなど、文字ごとに増減の方向が違うためです。

Q. どの形式を使えばいいですか？

A. Web上の一般的なテキスト比較にはNFCが標準的です。検索や重複判定を緩くしたい場合はNFKCが使われることがあります。

Q. ファイル名の「が」が別扱いされるのを防ぐには？

A. 保存前にNFCで正規化しておくと、Macで分離された濁点が1文字の「が」にまとまり、他OSと同じバイト列になります。