[Namazu-win32-users-ja 1258] Re: 解決しました（ Re: mknmzの処理が中断する ）

[Tadamasa Teranishi]

寺西です。

Toru Ishizuka wrote:
> 
> > 誤解があるようですが、1023 文字ぐらいまでなら、ファイル名の長さ
> > は関係ありません。
> 　英語では確認していないのですが、日本語をパスに含む場合
> 260バイトを超えると明らかに挙動がおかしくなります。

あぁ、日本語を含む場合だけ起こるわけではなくて、日本語を含む場合で
しか確認されていなかったわけですね。
# ちょっと誤解していました。

日本語を含むからといって、パスの長さは関係ないですよっていう話を
していたのですが、日本語かどうかは別に関係なく、パスが 260 文字を
超えるとおかしいということですか?

# 文字を書き換えると 260 文字超えてもいけるとか何とかという話が混じって
# いたような、いなかったような...。

260 文字というところが怪しいですが、これは _MAX_PATH の制限ぽい
ですね。

# うる覚えで _MAX_PATH が 1024 と誤解していたが...。

> > 日本語の問題は単純に文字コードの問題です。
> > Find::File, -f 等の問題は全てそうですから。
> 
> 　こちらの指摘は、長さが短くても日本語の取り扱いはあやし
> いということですよね。調べてみるといわゆるSJISのトレイル
> バイトに0x5cが入るような問題でしょうか。
> 　何年前の話だろうか。。

こちらは
何年前だろうが、ActivePerl が日本語に対応していないので起こる問題
です。
パス区切り記号を '\' に決めた奴と、日本語のコードをそのパス区切り記号
を含むような Shift_JIS 系に決めた奴の責任ですな。
そして、この特殊事情を外国の方がほとんど理解できないことが悲劇です。
# 「何でそんな変なコード使っているの?」って話になってしまう。

> 　逆に、このOSであれば長い日本語ファイルでも扱えると確認
> できている環境があれば教えてもらえますでしょうか。

日本語の問題を除外して、260文字を超えるパスの話ですと、Windows では
無理ぽいです。
# ちょっと誤魔化してすり抜けるようになっていたかと思いましたが、
# 実際問題が生じているのなら無理だったっぽいので。

公式には ANSI版 API は _MAX_PATH までしかサポートしていません。
また、ActivePerl は ANSI版 API を使うので、芋づる式に _MAX_PATH 
の制限がかかります。

Namazu for Windows は別に ActivePerl を使わなければならない訳では
ないので、
ActivePerl 以外に内部で Unicode 系 API を使う JPerl 系の実装が
あれば、それを使うと解決するような気がしますが、実際そんな実装は
たぶんないです。

なので、unix 系 OS を使いましょう。ということになるかと思います。

それはともかく、

> 　こちらはダメなパスです。
> c:\１２３４５６７８９０\１２３４５６７８９０\１２３４５６７８９０\１２３４５６７８９０\１２３４５６７８９０\１２３４５６７８９０\１２３４５６７８９０\１２３４５６７８９０\１２３４５６７８９０\１２３４５６７８９０\１２３４５６７８９０\270バイト_______________________.xls

って、ファイルはどうやって作ったのでしょう。

手元の Excel 2007 だと260文字を超えるパス名をセーブすると、
「入力されたパス'....'は長すぎます。パスを短くしてください。」
って、怒られました。
# 保護機能?
-- 
=====================================================================
寺西 忠勝(TADAMASA TERANISHI)  yw3t-trns ＠ asahi-net.or.jp
http://www.asahi-net.or.jp/~yw3t-trns/index.htm
Key fingerprint =  474E 4D93 8E97 11F6 662D  8A42 17F5 52F4 10E7 D14E