MacOS X とのファイル共有

おひさしぶりです。moriyama です。

今回は、Linux でファイルサーバーを構築する際に、Windows 以外にも MacOS X も接続してファイル共有する場合の日本語ファイル名の扱いについて書こうと思います。

MacOS X のパス名

MacOS X ではパス名の文字コードは UTF-8 です。そして Unicode Normalization Form D (NFD) と呼ばれる Unicode の正規化処理を施してあります。そのため MacOS X では「が」を「か」と結合文字の濁点「゛」に分解されてエンコードされる事になります。

合成済みの文字と分解された文字のコード値は次のようになっています。

	コード値(スカラ値)	UTF-8 バイト列
合成済みの文字 (が)	U+304C	E3 81 8C
分解された文字 (か+゛)	U+304B U+3099	E3 81 8B E3 82 99

• 濁点「゛」のコード値は U+309B ではなく、結合文字は別コードポイントが用意されていて U+3099 です。

ファイル名やディレクトリ名に合成済みの文字を与えてファイルやディレクトリを作成した場合、分解された文字を使ってファイルが作られます。MacOS X では合成済みの文字を使ったファイルやディレクトリは作成される事はありません。

MacOS X のパス名での Unicode 正規化処理は、MacOS X 10.2.x までは Unicode 2.1 をベース、MacOS X 10.3 からは Unicode 3.2 をベースとしています。ただし、次の範囲の文字は分解および正規化の対象外となっています。よって、Unicode 規格をそのまま実装したライブラリ等で正規化処理を行うと MacOS X ファイルのファイル名と異なるエンコードとなってしまうので注意が必要です。

• U+2000～U+2FFF http://www.unicode.org/charts/PDF/U2000.pdf
• U+F900～U+FAFF http://www.unicode.org/charts/PDF/UF900.pdf
• U+2F800～U+2FAFF http://www.unicode.org/charts/PDF/U2F800.pdf (2007/09/06 追記)

以後、MacOS X のパス名で使用される UTF-8 を 正規化 Decomposed UTF-8 と呼ぶことにします。

Linux のパス名

Linux カーネルおよび ext3 などのファイルシステムではパス名の Unicode の正規化処理は行われていませんので、合成済みの文字と分解された文字を別の文字として区別します。

LANG=ja_JP.UTF-8、ext3 ファイルシステム上で次の 2 つのファイルを作成可能 (MacOS X では分解された文字でしかファイルは作られない)

$ touch "が.txt"
$ touch `perl -Mutf8 -Mencoding=utf8 -MUnicode::Normalize -e 'print Unicode::Normalize::NFD("が.txt");'`
$ ls
が.txt  が.txt

Linux では通常、パス名には合成済みの文字が使われます。

以後、Linux のパス名で使用される UTF-8 を 非正規化 Preomposed UTF-8 と呼ぶことにします。

NFS でのファイル共有

一般的に NFS ではファイル名文字コードに関して特別な処理を行っていないため、クライアントとサーバの両方で同じ文字コードを使ってやりとりする必要があります。

Linux と MacOS X 間で NFS でファイル共有を行った場合、非正規化 Precomposed UTF-8 と 正規化 Decomposed UTF-8 の違いが問題になります。

Linux で NFS サーバを立ててファイル共有した場合、MacOS X から見ると同名のファイルが複数作られてしまい、MacOS X からは、そのうちの一つにしかアクセスできないという問題が発生します。

問題が起きないようにする為には、Linux のパス名を 正規化 Precomposed UTF-8 となるようにするか、MacOS X 側で正規化 Precomposed UTF-8 でファイル名のやりとりをするようにしてもらう必要があるでしょう。

現状では、NFS はマルチプラットフォームに未対応のファイル共有プロトコルだと考えておいた方が良いでしょう。

SMB/CIFS (Samba) でのファイル共有

SMB/CIFS でのファイル名のやりとりは、Linux や Windows では、非正規化 Precomposed UTF-16LE でやりとりされ、MacOS X では 正規化 Precomposed UTF-16LE でやりとりされています。

正規化処理を行っているか否かという違いはありますが、Linux、Windows、MacOS X のいづれも Precomposed UTF-16LE でファイル名のやりとりを行っていますので日本語ファイル名もほぼ問題なくファイル共有が出来ます。

UTF-8-MAC

MacOS X の libiconv には UTF-8-MAC という codeset が追加されています。

これは MacOS X の Samba の unix charset に指定します。Linux でも UTF-8-MAC を追加した libiconv を使えるようにして次のようなファイルサーバを構築する場合があるようです。

• Linux で NFS サーバと Samba サーバを立てる
• MacOS X とは NFS でファイル共有
• Windows とは SMB/CIFS(Samba) でファイル共有 (unix charset = UTF-8-MAC)

運用上の注意点としては、Linux でファイル操作をする場合に、ファイル名に Precomposed UTF-8 が混じらないようにするという事と、libiconv に追加した UTF-8-MAC で U+10000 以上の文字を変換できない可能性があります。(http://www.opensource.apple.com/darwinsource/ の Mac OS X 10.4.9 Darwin 8.9 の libiconv で確認。JIS X 0213:2004 では 303文字が該当します。)

MacOS X とのファイル共有に SMB/CIFS を使っている場合は、MacOS X は SMB/CIFS のパケット中のファイル名を Precomposed UTF-16LE にしていますので、Linux の Samba サーバの unix charset は UTF-8 で大丈夫です。

ファイルサーバの文字コード

ファイルサーバを立ててファイル共有する場合に、どこでどのような文字コードを使えばよいのか、また問題点を以下に示します。

図1 は Windows, MacOS X, Linux すべて SMB/CIFS でファイル共有する場合を示しています。クライアントとサーバ間でやりとりされるファイル名は Precomposed UTF-16LE なので MacOS X を意識せずにファイル共有可能です。日本語ファイル名の観点からは、この構成が一番問題が少ないと言えます。

図1

図2は Windows, MacOS X は SMB/CIFS でファイル共有し、Linux は NFS でファイル共有する場合を示しています。ファイルサーバにはファイル名は Precomposed UTF-8 で記録されているため、Linux から NFS マウントして問題なく日本語ファイル名を扱えます。

図2

図3 は Windows と Linux は SMB/CIFS でファイル共有し、MacOS X は NFS でファイル共有する場合を示しています。ファイルサーバの iconv(3) で UTF-8-MAC を利用でるようにする必要があり、ファイルサーバでのファイル操作では、Precomposed UTF-8 が混在しないように注意を払って運用管理する必要があります。

MIRACLE LINUX および Asianux Server 3 の iconv(3) には UTF-8-MAC が追加されていませんので、この構成のファイルサーバは構築できませんので御注意ください。

図3

図4 は Windows は SMB/CIFS でファイル共有し、MacOS X と Linux は NFS でファイル共有する場合を示しています。ファイルサーバの iconv(3) で UTF-8-MAC を利用でるようにする必要があり、ファイルサーバでのファイル操作では、Precomposed UTF-8 が混在しないように注意を払って運用管理する必要があります。また、クライアントの Linux マシン ではファイル名に Precomposed UTF-8 が混じらないように注意する必要があります。

MIRACLE LINUX および Asianux Server 3 の iconv(3) には UTF-8-MAC が追加されていませんので、この構成のファイルサーバは構築できませんので御注意ください。

図4

図3の構成では、ファイルサーバでのファイル名(パス名)に、合成済みの文字 (Precomposed UTF-8) が混在してしまわないように運用・管理を行い、図4 ではファイルサーバの運用・管理に加えて、NFS でファイル共有している Linux や UNIX 系のクライアントOSでのファイル名(パス名)の扱いに注意を払う必要があります。

運用・管理上の制約を排除するためには、理想的には Linux で UTF-8 のパス名を扱う際に、U+2000〜U+2FFF, U+F900〜U+FAFF, U+2F800〜U+2FAFF を正規化の対象外とする Unicode Normalization Form C (NFC) で Unicode の正規化処理を行うようにする必要があると思われます。

Linux の UTF-8 パス名で Unicode 正規化処理が施されていない現状では、図1や図2の構成で Unicode 正規化処理を必要としないシステム構成で運用するか、運用管理に注意を払って図3や図4 の構成でシステム構築していく必要があります。それぞれの構成でのメリット・デメリットを把握してシステム構築をする必要があるでしょう。一番問題なのは、事前に問題点を把握できないままシステムを構築してしまって、実運用になってからユーザの指摘で問題点に気がつくというケースで、そうなってしまってから慌ててしまわないようにしておきたいものです。

参考

Unicode Standard Annex #15 Unicode Normalization Forms

http://unicode.org/reports/tr15/

Technical Note TN1150 HFS Plus Volume Format

http://developer.apple.com/jp/technotes/tn1150.html

Technical Q&A QA1173: Text Encodings in VFS (2007/09/06 追記)

http://developer.apple.com/jp/qa/qa2001/qa1173.html

小形克宏の「文字の海、ビットの舟」――文字コードが私たちに問いかけるもの
特別編25 JIS X 0213の改正は、文字コードにどんな未来をもたらすか（8）
番外編：改正JIS X 0213とUnicodeの等価属性／正規化について（下）

http://internet.watch.impress.co.jp/www/column/ogata/sp25.htm

File Systems, Unicode and Normalization

http://developers.sun.com/global/products_platforms/solaris/reference/presentations/IUC29-FileSystems.pdf