[1]
Unicode では結合文字に対応する前進文字
(例えば ACUTE ACCENT)
は間隔 + 結合文字
(例えば SPACE +
COMBINING ACUTE ACCENT)
と互換等価になっています。
ですから NFC や NFD はよいのですが、 NFKC
や NFKD を適用してしまうと、 CSS
の white-space や各種プログラム言語の構文をはじめ、
元のものと違う結果が得られることになります。
(名無しさん [sage])
[2]
ちなみに結合文字に対応する前進文字があればその文字に互換等価性が定義されているかというと必ずしもそうではなく、
例えば GRAVE ACCENT は
SPACE + COMBINING GRAVE ACCENT
と互換等価ではありません。
(ASCII 文字から非ASCII文字への等価性を設定するのは憚られたのでしょうが、体系として美しいとはいえません。)
(名無しさん [sage])
[3]
さらにちなみに、 U+02B0 からのブロックには
MODIFIER LETTER ACUTE ACCENT
など見るからに重複符号化なものが IPA 関連などと称して配置されていたりしますが、
この MODIFIER LETTER の類には正準等価も互換等価も定義されていません。
こういう例は腐るほどあります。釣り詐欺には格好というか釣堀ですわな。
(名無しさん [sage])
[4] 正規化で文字の数が変わってしまうのは大きな問題です。色々なものが色々なところで文字数に依存していますから。 (文字に関してバイト数やオクテット数に依存しているものは問題外ということで。)
たとえば、正規表現の文字クラス [がぎぐげご] はNFCなら機能しますが、NFDだと意味が変わってしまいます。
(名無しさん [sage])
[5] >>4 たとえば Mac OS X でファイル名 (NFDの亜種) に適用する正規表現を NFC 推奨のプログラミング言語中に書く時はどうするの? ファイル名はいちいち NFC に変換しないといけないの? (名無しさん [sage])
[6] i18n folk は正規化転符号化器なるものを推し進めているらしいけど、 そんなものをつかったら一体何が起きるのだか? (名無しさん [sage])