大体のことは佐藤文優氏のblogに書かれてますが、氏の言うとおりUTF-8-MACはNFDではありませんし、WindowsはNFCではありません。
■macOS X/HFS+はNFDではない
NFDの詳しい話はウィキペディアやユニコードコンソーシアムのサイトを参照して下さい。。。
簡単に言うと、UNICODEには「正規化」という「NFD/NFC/NFKD/NFKC」の４種類の変換仕様があります。
この正規化は何かというと「文字を規則に沿って整える」もので、例えば文字検索をするときに文字の基準を揃えたいときなどに使用します。
その中のNFDとはNormalization Form Canonical Decompositionの略で「正準等価性で分解」というもので、雑に言うと「見た目変わらず合成出来る文字は分解して結合文字で表す」というものです。
例えば「が(U+304C)」は「が(U+304B,U+3099)」のように濁点や半濁点を合成用に分解、「Ä(U+00C4)」は「Ä(U+0041,U+0308)」のようにダイアクリティカルマークを合成用に分解します。
日本語の仮名や片仮名のみを変換する仕様なのではありません。
また、正規化は旧字体を新字体に変換する機能も持っているため、例えば「福(U+FA1B)」は「福(U+798F)」に変換されます。
この変換は4種に関係なく実行されます。
＊正規化の違いを同人技術誌から抜粋＊
macOS X/HFS+は旧字体は新字体に変換しない独自の仕様です。
つまりNFDではなく「特定の文字だけを分解(合成・結合型へ変換)するmacOS X/HFS+独自の仕様」です。
ですからUTF-8-MACをNFDと言ってはいけません。
私の勝手な推測ですが、apple社の人はこの仕様がNFDでは無いため「UTF-8-NFD」ではなく「UTF-8-MAC」と命名したのではないかと思います。
※私はmacOS Xを使用したことがありません。HFS+の仕様ではなくmacOS Xのかな漢字変換が独自分解形式(UTF-8-MAC)でOSはそれをそのままファイル名にしているだけの可能性もあります。
■WindowsはNFCではない
UTF-8-MACとの対比でWindowsはNFCであると言っているページがいくつも見つかりますが間違いです。
Windowsはユーザが入力した文字列は正規化せずそのままファイル名に使います。
試しに結合文字を持つ文字列を与えてファイルを作成してみると確認出来ると思います。
そもそも正規化は先に述べたように文字の検索などで内部的に使用するものであって、ユーザが入力した文字は基本的にそのまま記憶するのが普通です。
勝手に変換されては困ります。
また、ファイル共有などで困るとありますが、少なくともWindows側では該当ファイルをファイル選択ダイアログなどで選択出来るため困ることはほとんどありません。
困るとすれば見た目のファイル名が重複しているときに「どっち？」で悩む程度です。
どっち？🤔
■UTF-8-MACはUTF-8の亜種ではない
名前から誤解が生まれるのだと思いますが、UTF-8はUNICODEのエンコード(UTF-8,16,32)の一つであってその中の文字がNFD形式でもその他の形式でも関係ありませんし関知もしません。
粛々とコードポイントを変換するだけです。
- WTF-8やCESU-8
UTF-8の亜種で、コードポイントの変換方法が異なります。
U+10000以上の変換や不正サロゲートペアの扱いがUTF-8と異なります。
基本的に内部処理専用なので情報交換用として外に出してはいけないエンコードです。 - UTF-8-MAC
UTF-8の亜種ではなく、格納されている文字のうち特定の文字が結合文字で表現されている可能性があります。
UTF-8で問題なくデコード出来ます。
macOS X版iconvのソースはココにあるようです。
https://opensource.apple.com/tarballs/libiconv/
libiconv/lib/utf8mac.h がそれっぽいです。
あるサイトにはUTF-8-MACではBMP以外の文字は�(U+FFFD REPLACEMENT CHARACTER)に変換されると書かれていましたが、このソース(1177行辺りから)を見るとサロゲートぺアの処理(4Byte出力)が書かれているからそんなことはなさそうなんですよね。
間違っていたらご一報下さると幸いです。
特にmacOS Xが手元に無いのでファイルシステムの仕様なのかFEPの仕様なのか不明です。