なぜmacはNFCでなくNFDを採用したのか

Mac（macOS）のファイルシステム（HFS+やAPFS）が、ファイル名の扱いにNFD（Normalization Form Decomposition：分解正規化）に近い形式を採用している理由は、主に「ファイルシステムレベルでの一意性の確保」、「検索・ソートの効率化」、そして「開発当時の歴史的背景」にある。

WindowsやLinux、ウェブ標準（HTML5など）がNFC（合成正規化）を主流とする中で、なぜMacだけが異なるのか。その技術的・思想的な理由を以下に解説する。

-----

1. そもそもNFCとNFDの違いとは

理由を理解するために、日本語の「が」を例に、コンピュータによる文字の認識方法を整理する。

NFC「が」(U+304C) は1文字扱い

NFD「か」(U+304B) と「゛」(U+3099)  で2文字扱い

-----

2. AppleがNFDを採用した主な理由

HFS+（Mac OS 8.1で導入されたファイルシステム）が設計された1998年頃の思想が大きく影響している。

 ファイル名の「一意性」を保証するため（正規化の強制）

ユーザーが画面上で「café」というファイルを作成した際、それが「caf + é (合成)」で入力されたか、「caf + e + ´ (分解)」で入力されたかによって、見た目が同じなのに別のファイルとして保存される事態は避けねばならない。

これを防ぐため、ファイルシステム側で「保存時は必ず特定の形式（NFD）に変換する」というルールを設けた。これにより、入力方法に関わらずファイル名は常に同じバイト列となる。

なぜNFCでなくNFDを選んだのか

NFD（分解形）の方が、文字の構造として「原子的」であり、将来新しい合成文字（合成形）がUnicode規格に追加されたとしても、システムカーネルを変更せずに対応しやすいという判断があったとされる。

検索とソート（並べ替え）の高速化・単純化

ファイルシステムにとって「ソート（並び替え）」は頻繁に行われる高負荷な処理である。

NFD（分解形）で保存しておけば、アクセント記号や濁点が分離されているため、「基底文字（ベースの文字）」だけでの比較が容易になる。

 例:「Apple」と「Ápple」を並べる場合

      NFDであれば「A」と「A + ´」の比較になる。最初の「A」を見た時点で「同じグループ」と判定しやすく、アクセント記号を無視した検索（Collation）の実装が高速かつ単純になる。

互換性と「Apple独自のNFD」

Macが採用しているのは厳密なUnicodeのNFDではなく、「NFD-Mac（または Modified NFD）」と呼ばれる独自仕様である。

本来のNFDはあらゆる文字を分解するが、Appleは一部の漢字や記号については分解しない（NFCのままにする）例外ルールを設けた。これは、当時の古いMac OS（Classic Mac OS）の文字コードとの可逆性（Round-trip conversion）を維持するために必要な措置であった。この「実用性重視の独自拡張」を行うベースとして、NFDの方が都合が良かったという側面もある。

-----

3. この仕様による弊害（「濁点分離問題」）

Macユーザー以外が遭遇する有名なトラブルに、ファイル名の文字化け（通称：濁点分離）がある。

  * Macで「バックアップ.txt」を作成（NFD: ハ + ” + ッ + ク + ア + ッ + フ + ゜）

  * Windowsに渡す（WindowsはNFCが標準）

  * Windows側で適切に処理できないツールを使用すると、ファイルが開けなくなったりする。

これは、Macがファイルシステムレベルで強制的にNFDに変換して保存し、取り出す際もNFDのまま渡すために発生する現象である。

-----

まとめ

MacがNFDを採用しているのは単なる気まぐれではなく、以下のようなエンジニアリング上の判断によるものだ。

1.  ファイルの一意性: 見た目が同じなら同じファイルとして扱うための正規化。

2.  カーネルの単純化: 基底文字と修飾文字を分けることで、ソートや検索ロジックをシンプルにする。

3.  歴史的背景: HFS+設計当時（1990年代後半）、将来の拡張性と旧来のコード体系との互換性を保つために、分解形（Modified NFD）が最適解とされた。

現在ではCPU性能も向上し、NFCでも十分高速に処理できるため、「今ゼロから作るならNFCを採用したかもしれない」という議論もある。しかし、膨大な過去の資産との互換性を保つため、最新のAPFSでもこの仕様は継承されている。