MacOSX で Unicode が全面的にサポートされている。その中で一番分からないのは、ファイル名が UTF8 NFD (Normalization Form Decomposition) で正規化されていることである。詳しく言えば NFD をベースにした微妙に異なるルールらしい(1, 2)。その結果なのか知れないが UTF-8-MAC と呼ばれることが多い。
Linux 界隈でサポートされる UTF8 は NFC で正規化されると言われている。ただし、正規化処理が為された結果ではなく、専ら合成済みの文字のみを扱っている結果として、UTF-8 NFC なんだと思う。 Windows とおんなじ理由と思う。
根拠は全くない。
Linux というより上位のフレームワーク／アプリケーション(Gnome,KDE 等)の扱いの問題なんだと思う。
UTF8 の正規化の問題は、Samba や netatalk では対応が進んでおり、運用上問題が出ないレベルまで押さえ込むことができるそうなぁ。
NFS に関しては、どっかで議論されている?だろうが、一般的な運用まで下りてきていない。
現状は、
- MacOSX はファイル名を UTF-8-MAC にして、NFSサーバに送っている。
- 一般的な NFS サーバは、ファイル名の変換を行わずに、ローカルなファイルシステムに送る。
- ローカルなファイルシステムも、ファイル名の変換を行わず、ディスクに記録される。
- MacOSX が作成したファイル名は UTF-8-MAC (NFD) で正規化されており、UTF8 NFC と異なるバイト列だった場合、Linux のNFSクライアントで不整合が発生する。
ローカルな記録をUTF-8-MAC に変えたり、NFS は諦めたり、MacOSX の対応が進まないか祈ってみたり、四苦八苦である。
NFSの実験
どうしたもんかなぁと思いつつ、ちょっとだけ実験することにした。
NFSサーバに以下の機能があればいいのかなぁ
- クライアントからのファイル名をUTF8 NFC に正規化する。
- クライアントに応じて、正規化方法を選択して、ファイル名をその正規化をして返す。
NFS のファイル名は変換しても大丈夫なんだろうか？とか疑問だが、一番最低限の実装を作ってみた。
- 検証するNFSサーバの実装は unfs3 を使う。従って、NFSv3 が対象。
- NFS プロトコールのみで、NFS の MOUNT プロトコールは手をつけない。
- NFD <=> NFC の変換は、かなの濁音・半濁音に限定する。
- クライアントの区別をせずに常に変換する。
- NFD => NFC の変換が行われるのは、LOOKUP / CREATE / MKDIR / SYMLINK / MKNOD / REMOVE / RMDIR / RENAME / LINKの引数内のファイル名とSYMLINKの引数内のシンボリックデータ。
- NFC => NFD の変換が行われるのは、READDIRの返答内のファイル名。
unfs3-0.9.20.utf8mac-20080305.patch.txt
検証方法
Linuxでは カーネルベースのNFSを使いつつ検証が出来するのが通なんだろうなぁ。
サーバ側(fserver)でパッチを当てた unfs3 のバイナリを作っておく。
# UNFSD=/usr/src/unfs3-0.9.20.utf8mac/unfsd <-- パッチ済みバイナリ
# EXPORTS=/etc/exports_test <-- テスト用の exportsファイル
# ${UNFSD} -d -u -p -n 44000 -m 44100 -e ${EXPORTS}
/etc/exports_test
/export/share 192.168.0.23(rw,no_root_squash)
MacOSX 側(192.168.0.23)でマウント
# mkdir /Volumes/unfs
# sudo mount -omountport=44100,port=44000 fserver:/export/share /Volumes/unfs
結び
濁点・半濁音だけだが変換が行われて、MacOSX から普通に扱える。。。
まぁ、いろいろ試したいことが思い浮かぶので、ちまちま実験していくかなぁ。
