このエントリは全面改定されているので、コメント欄および、改訂記録を確認してください。
おさらい。
Mac OS X のファイル共有プロトコルの AFP 3 では、ファイル名が decomposed UTF-8 で送信されます。日本語でよく使われる文字(ひらがなカタカナ漢字など)においては、3 byte 消費します。また、Mac OS X の AFP 3 クライアントは、255byte の制限を持っているということです。なので、Mac OS X から、netatalk 2 のボリュームにつけられるファイル名の長さとしては、おおむね、255 ÷ 3 = 85 文字となります。
ところが、Mac OS X のローカルファイルシステム(HFS+)では decomposed UTF-16(UTF-16,Normalization form D)で正規化されているので、濁点、半濁点が付く文字は、たとえば、「プ」なら、イメージとして、「フ」+「゜」の2文字を使うので(ふつうの「゜」と合成用の「゜」はそれぞれ、u+309C,u+309A と別のコードが振られています)、Mac OS X 上では UTF-16 2文字分=4 byte、AFP 3においては、decomposed UTF-8としてファイル名が取り扱われるので、6 byte 消費し、現在の netatalk 2 のボリュームでつけられるファイル名の長さは、Mac OS X の AFP 3 クライアントの 255 byte 制限を受け、85 文字より短くなってしまいます(この記事のコメント欄参照、netatalk 2.0.1でもこの現象は確認できました)。
しかし、もっともっと、短くなります。
「有限会社」、と「株式会社」の組文字でファイル名をつけてみましょう。
▲有限会社のほうが弱い?
▲ファイル名につけられた分をコピペ。有限会社の方は圧倒的に短い!
……
種明かし。
http://www.bekkoame.ne.jp/~iimori/sw/UnicodeUtilsOSAX.html
Combining characterの例としては以下の様な物が上げられます。
は DTPで必要な Adobe CID 8321を表すための Apple privateな物ですが、直接対応する Unicode code pointが無いこともあり 5 code pointの組み合わせです。これを UTF-8に encodeすると1文字で 15 byte必要になります。
U+0031 + U+20DE
U+F862 + U+6709 + U+9650 + U+4F1A + U+793E
有限会社の組文字1文字で、Mac OS X のファイルシステム上で 10byte、AFP 3においては 15 byte も使っていたらたまったもんじゃあありませんね。Mac OS X の AFP 3 クライアントの 255 byte 制限にすぐ引っかかってしまいます。
でも、よく考えると、これのおかげで、CID にあって、Unicode に無いグリフも Unicode で指定できるのですね。
<img alt="netatalk_icon_2.png" src="http://blog.dtpwiki.jp/dtp/img/netatalk_icon_2.png" width="48" height="48" border="0" align="left" hspace="8" />もう netatalk 2 の問題というよりも、Mac OS X の Unicode の仕様なんですが。<br clear="left" />おさらい。Linux 側では、Ext 3 で 255バイト長までのファイル名がつけられますが、ファイル名に UTF-8 のエンコーディングをつかうと、日本語でよく使われる文字(ひらがなカタカナ漢字など)においては、3 byte 消費します。なので、Mac OS X から、netatalk 2 のボリュームにつけられるファイル名の長さとしては、おおむね、255 ÷ 3 = 85 文字となります。ところが、Mac OS X のファイルシステム(HFS+)では UTF-16,Normalization form D で正規化されているので、濁点、半濁点が付く文字は、たとえば、「プ」なら、イメージとして、「フ」+「゜」の2文字を使うので(ふつうの「゜」と合成用の「゜」はそれぞれ、u+309C,u+309A と別のコードが振られています)、Mac OS X 上では UTF-16 2文字分=4 byte、Linux 上の UTF-8 では、6 byte 消費し、<del>netatalk 2 のボリュームでつけられるファイル名の長さはもっと短くなります。</del><ins>現在の netatalk 2 のボリュームでつけられるファイル名の長さは、Mac OS X 上でのbyte 数計算と、Linux 上でのファイルシステムで収納できる byte 数の両方の制限を受け、85 文字より短くなってしまいます(この記事の<a href="http://blog.dtpwiki.jp/dtp/2004/11/netatalk_2.html#c1502886">コメント欄参照</a>、netatalk 2.0.1でもこの現象は確認できました)。</ins>もっと、短くなります。「有限会社」、と「株式会社」の組文字でファイル名をつけてみましょう。<img alt="kabu-yuu-1.gif" src="http://blog.dtpwiki.jp/dtp/img/kabu-yuu-1.gif" width="450" height="340" border="0" /><strong>▲有限会社のほうが弱い?</strong><img alt="kabu-yuu-2.gif" src="http://blog.dtpwiki.jp/dtp/img/kabu-yuu-2.gif" width="450" height="263" border="0" /><strong>▲ファイル名につけられた分をコピペ。有限会社の方は圧倒的に短い!</strong>……種明かし。<a href="http://www.bekkoame.ne.jp/~iimori/sw/UnicodeUtilsOSAX.html"><cite>http://www.bekkoame.ne.jp/~iimori/sw/UnicodeUtilsOSAX.html</cite></a><blockquote cite="http://www.bekkoame.ne.jp/~iimori/sw/UnicodeUtilsOSAX.html">Combining characterの例としては以下の様な物が上げられます。 <img alt="U2.png" src="http://blog.dtpwiki.jp/dtp/img/U2.png" width="24" height="24" border="0" />は DTPで必要な Adobe CID 8321を表すための Apple privateな物ですが、直接対応する Unicode code pointが無いこともあり 5 code pointの組み合わせです。これを UTF-8に encodeすると1文字で 15 byte必要になります。<br /> <img alt="U1.png" src="http://blog.dtpwiki.jp/dtp/img/U1.png" width="24" height="24" border="0" /> U+0031 + U+20DE<br /> <img alt="U2.png" src="http://blog.dtpwiki.jp/dtp/img/U2.png" width="24" height="24" border="0" /> U+F862 + U+6709 + U+9650 + U+4F1A + U+793E</blockquote>有限会社の組文字1文字で、Mac OS X 上で 10byte、Linux の UTF-8 のボリュームで 15 byte も使っていたらたまったもんじゃあありませんね。でも、よく考えると、これのおかげで、CID にあって、Unicode に無いグリフも Unicode で指定できるのですね。
(2005.1.30 16.09訂正)
<del>netatalk 2 のボリュームでつけられるファイル名の長さはもっと短くなります。</del><ins>現在の netatalk 2 のボリュームでつけられるファイル名の長さは、Mac OS X 上でのbyte 数計算と、Linux 上でのファイルシステムで収納できる byte 数の両方の制限を受け、85 文字より短くなってしまいます(この記事の<a href="http://blog.dtpwiki.jp/dtp/2004/11/netatalk_2.html#c1502886">コメント欄参照</a>、netatalk 2.0.1でもこの現象は確認できました)。</ins>
(2007-02-11 15.40追記)
このエントリは当方の環境で測定された結果から書いたものですが、実際には異なっているという指摘がありました。詳しくは、下記エントリをご覧下さい(このエントリを書き直しても正確になる自信はないので)。
So-net blog:HAT:afp3.xでのファイル名長さ制限 [blog.so-net.ne.jp]
(2007-02-13 11.09訂正)
当方でやっと Mac OS X Server 環境が用意できましたので、指摘された部分を確認したところ、確かに、Mac OS X Server でも、通常の日本語文字は 85文字程度、濁点を持つかな「が」は、42文字目まで「が」が入り、43文字目は「か」しか入らないことがわかり、どこかの部分で decomposed UTF-8 で 255 byte の制限がかかっていることが確認できました。指摘をいただいた HAT さんによると、AFP 3の通信のパケット解析をされたと言うことで、ここに decomposed UTF-8 の制限があるとして、エントリを全面改定しました。