M.C.P.C.

―むり・くり―プラスコミュニケーション(更新終了)


| トップページ |

2004年11月 1日 02:47

netatalk 2ボリュームでのファイル名の長さの最大って結構短い。

このエントリーをはてなブックマークに追加 mixiチェック

netatalk_icon_2.pngこのエントリは全面改定されているので、コメント欄および、改訂記録を確認してください。

おさらい。

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でもこの現象は確認できました)。

しかし、もっともっと、短くなります。

「有限会社」、と「株式会社」の組文字でファイル名をつけてみましょう。

kabu-yuu-1.gif
▲有限会社のほうが弱い?

kabu-yuu-2.gif
▲ファイル名につけられた分をコピペ。有限会社の方は圧倒的に短い!

……

種明かし。

http://www.bekkoame.ne.jp/~iimori/sw/UnicodeUtilsOSAX.html

Combining characterの例としては以下の様な物が上げられます。 U2.png は DTPで必要な Adobe CID 8321を表すための Apple privateな物ですが、直接対応する Unicode code pointが無いこともあり 5 code pointの組み合わせです。これを UTF-8に encodeすると1文字で 15 byte必要になります。
    U1.png U+0031 + U+20DE
    U2.png 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 の制限があるとして、エントリを全面改定しました。

投稿 大野 義貴 [netatalk] | |

トラックバック(2)

トラックバックURL: http://blog.dtpwiki.jp/MTOS/mt-tb.cgi/497

afp3.xのファイル名長さ制限は、結構わかりにくいので一応説明します。 ただし、実際にはかなり長い名前が使えるので、運用上問題になるケースは稀だと思います。 http://dtpwiki.jp/?AFP http://blog.dtpwiki.jp/dtp/2004/11/netatalk_2.html これらのページでも微妙に間違った表現があります。 結論から書くと実質的な制限は、ファイル名をUTF-8-MAC (decomposed UTF-8)に変換して255byteです。 H... 続きを読む

afp3.xのファイル名長さ制限は、結構わかりにくいので一応説明します。 ただし、実際にはかなり長い名前が使えるので、運用上問題になるケースは稀だと思います。 http://dtpwiki.jp/?AFP http://blog.dtpwiki.jp/dtp/2004/11/netatalk_2.html 結論から書くと実質的な制限は、MacOSX 10.4迄は、 ファイル名をdecomposed UTF-8(UTF-8-MAC)に変換して255byteです。 MacOSX 10.5 Le... 続きを読む

コメント(10)

昨日気付いたのですが、この話はおかしいです。
「プ」がnetatalk経由で保存されると6バイトではなく3バイトになります。
netatalkがprecomposed utf-8に変換しているからです。
にも関わらず、42文字までしか使えない。
ということは、netatalkのバグです。
どうやらprecomposed utf-8に変換する前にバイト数を勘定しているような印象を受けます。

昨日気付いたのですが、この話はおかしいです。
「プ」がnetatalk経由で保存されると6バイトではなく3バイトになります。
netatalkがprecomposed utf-8に変換しているからです。

起こっている現象から原因を推測しました。確かに、Linux のファイルシステム上でのコードは確認していませんでした。今確認したら、Linux のファイルシステム上では、「プ」はほかのカタカナと同様に 3byte 取られます。

誤解を招かないように訂正しておきます。

RedHat7.2とSolaris9上で、2.0-rc2と2.0.0にcjkパッチを外したり、いろいろ設定を変えてみたりして実験したのですが、どうやらオリジナルnetatalkのバグという感じです。
具体的にソースのどこ?と聞かれると、それはまだ調べてないんですけど。

あと、別の人から問い合わせがあったのですが、玄箱(debian化してない )だと濁点付き文字が30字までしか使えないという話なんですよね。これがまた、よくわからない。他の環境ではみんな42文字なんですけど。

まず、訂正。
30文字というのは数え間違いで、実際には42文字だったそうです。

更に調べたら、色々わかってきました。
どうやら、netatalkの問題ではありません。
MacOSX側の問題です。
詳しいことは、また明日。

MacOSX-MacOSX間でafpで極めて長いファイル名をみると、
decomposed utf-8で255バイト名のところで、ブチッと切られる。
「がががが...」というような「が」が連続しているファイル名だと、最後の「が」の途中で切られて、「か」に化ける。
テキストエディットで適当な文書をつくり、ローカルディスクに保存するときにファイル名を「がががが...」とひたすら打っていくと、decomposed utf-8で255バイトを超えると保存ボタンがグレーアウトするので、保存出来ない。
OSXはdecomposed utf-8で255を超えないような策略が随所にある。
もしかしてafp3の仕様自体にそういう制限があるのかと思って、仕様書をさっきからずーーーっと読んでるが、見つからない。
だいたい、この仕様書、246ページもあるのだわさ。

http://www.intelligentworks.co.jp/tec/helios_afp.html
このページを読む限り、afp3.1にはそういう制限があるように書かれている。
しかし、その根拠がわからない。
OSXの実装がそうだというのか。
仕様書をちゃんと読むと、そう書かれているのか。

結局、afp3.1の仕様書には、Unicode nameの長さ制限は何も書かれていないようです。
OSXの実装がそうだから、それにあわせてnetatalkもdecomposeで255バイトということです。
OSX-OSX間でafpを使ったとき255超のファイル名をブチッと切るのに対し、netatalkはちゃんとmanglingするぶんだけ、偉いです。

UNIX側の文字数制限が255以上あれば十分で、それがネックになることはありません。

ローカルファイルシステムとネットワークファイルシステムで制限が異なるということなのですね。AFP が Macintosh の標準ネットワークファイルシステムとして存在しているのだからローカルファイルシステムと同じくらいのキャパシティを持っているのだろうと思っていたわけですが Apple 本家の実装もそうであれば、AFP 上のデータの取扱いもそれなりの対応を取らなければいけないようですね。

あり得るシチュエーションとしては、ローカルの HFS+ から AFP ボリュームへバカコピーすると失敗するとか、そういうところでしょうか。

おひさしぶりです。
昨日気付いたのですが、MacOSX 10.4.8のFinderで、有限会社、財団法人の合成文字が正常表示できません。分解されてバラバラに表示されます。
また、丸付き合成文字のマル大、マル小、マル控が正常表示できません。マルの位置がずれます。
一体、どうしちゃったんでしょう。

昨日気付いたのですが、MacOSX 10.4.8のFinderで、有限会社、財団法人の合成文字が正常表示できません。分解されてバラバラに表示されます。

うわ、エンバグしていましたか。ファイルシステムと文字コード周りのテストって大変そうですもんね。日本人じゃないと違和感に気づかなさそうだし(どの言語圏の人がテストしても間違わないように、よっぽどテスト項目として洗練しないと)。

まだ細かいところまではチェックしてませんが、
Leopardでは255Byte制限がなくなったようです。

コメントする