Bug #2154: filesystem encoding of UNIX

• Status: Rejected
• Assignee: naruse (Yui NARUSE)
• Target version: 2.6
• ruby -v: ruby 2.0.0dev (2012-10-25 trunk 37328)
• Backport: 2.3: UNKNOWN, 2.4: UNKNOWN

[usa (Usaku NAKAMURA)]

=begin
「Ruby M17N の設計と実装」によると(*1)、UNIXにおけるfilesystem
encodingはlocaleであると書かれているのですが、実際には現在の
実装はdefault externalになっています。
実装の方が間違ってる気がするのですが、どうでしょうか?

*1 http://jp.rubyist.net/magazine/?0025-Ruby19_m17n#l23
=end

[naruse (Yui NARUSE)]

• Status changed from Open to Closed
• % Done changed from 0 to 100

=begin
Applied in changeset r25140.
=end

[usa (Usaku NAKAMURA)]

• Description updated (diff)
• Status changed from Closed to Assigned
• Assignee changed from naruse (Yui NARUSE) to akr (Akira Tanaka)
• ruby -v changed from ruby 1.9.2dev (2009-09-28 trunk 25132) [i386-mswin32] to ruby 2.0.0dev (2012-10-25 trunk 37328)

と、いうことだったのですが、r25782において意図的にdefault externalに戻されています。
理由を発見できなかったのですが、なぜでしょう？

[akr (Akira Tanaka)]

2012年10月29日 10:31 usa (Usaku NAKAMURA) [e-mail]:

と、いうことだったのですが、r25782において意図的にdefault externalに戻されています。
理由を発見できなかったのですが、なぜでしょう？

その時点の記憶はすでにないのですが、おそらく、
locale と異なる encoding でパス名を扱いたい場合に、
設定できるようにするためではないかと思います。

とくに指定しなければ、default external は locale から設定されるので、
「UNIXにおけるfilesystem encodingはlocaleである」というのはそれほど
変ではないのではないでしょうか。

[田中 哲][たなか あきら][Tanaka Akira]

[usa (Usaku NAKAMURA)]

こんにちは、なかむら(う)です。

In message "[ruby-dev:46310] Re: [ruby-trunk - Bug #2154][Assigned] filesystem encoding of UNIX"
on Oct.29,2012 10:57:06, [e-mail] wrote:

その時点の記憶はすでにないのですが、おそらく、
locale と異なる encoding でパス名を扱いたい場合に、
設定できるようにするためではないかと思います。

とくに指定しなければ、default external は locale から設定されるので、
「UNIXにおけるfilesystem encodingはlocaleである」というのはそれほど
変ではないのではないでしょうか。

ふむ。
とすると、本当は、filesystem encodingを明示して設定するAPIが
合ったほうがいいんでしょうかね。
2.0.0にも間に合わなわなさそうなので今は深入りを避けますが。

さて、ここで問題なのですが、localeがUTF-8だとして、

p File.expand_path("a").encoding # A
Encoding.default_external = Encoding::EUC_JP
p File.expand_path("a").encoding # B
p File.expand_path("a".encode(Encoding::SHIFT_JIS)).encoding # C

としたとき、A, B, Cはそれぞれどうなるべきでしょう?

filesystem encoding(=default_external)を尊重するなら、

A: UTF-8
B: EUC-JP
C: EUC-JP

になるはずで、1.9.3-p286は実際そうなります。
一方で、実は現在のtrunkは引数のencodingを尊重しており、

A: US-ASCII (script encodingがそうなので)
B: US-ASCII
C: Shift_JIS

になります。

この辺色々悶々としていてるのですが、現時点での私の考えとして
は、

• ファイルシステムのencodingが原則として固定であるプラット
  フォーム(つまり例えばWindows)では、内部変換を行い、引数の
  encodingで結果を返す。

• ファイルシステムのencodingが個々の利用者にゆだねられてい
  て、システム的にはバイト列として扱われているプラットフォ
  ーム(つまり普通のUnix)では、内部では単にバイト列として扱
  い、default_externalにforce_encodingして結果を返す。

とするのがよいのかなあ、と思っています。
プラットフォームによって挙動が違うのがやや残念ですが、結局こ
れが既存のスクリプトに最も影響を与えない方法なのかなあ、と...

皆さんどう思われますか。

それでは。

U.Nakamura [e-mail]

[kosaki (Motohiro KOSAKI)]

とくに指定しなければ、default external は locale から設定されるので、
「UNIXにおけるfilesystem encodingはlocaleである」というのはそれほど
変ではないのではないでしょうか。

ふむ。
とすると、本当は、filesystem encodingを明示して設定するAPIが
合ったほうがいいんでしょうかね。
2.0.0にも間に合わなわなさそうなので今は深入りを避けますが。

めんどくさいケースは以下の２つですかね。

ロケールは UTF-8
ファイルシステムはFAT（よってファイルシステムのファイル名はShiftJIS or another country specific codepage)
ファイルの中身は EUC

※これはSDカードなどで実際に発生しうる

2. ロケールはUTF-8だけどファイルシステムエンコーディングはUTF8MACな某OS

というパターンだと思うので、これをケアする必要があるならAPIが必要そうに思えます。要望を上がってこない所をみるとあんまり困ってないのかな

まとまってないので思いついたことを箇条書きで書くと

・Linuxではlocale(UTF-8)、MacではUTF8MAC、WindowsではUTF-16（だっけ？）がデフォルトのファイルシステムエンコーディングであって欲しい
・SDカード対策のために違うエンコーディングを指定できて欲しい。これはdefault_externalをかえるよりかは引数で与えれたほうが便利そうな気がする。
default_externalを変えちゃうと別のスレッドがぎゃっといいそうだから
・default_filesystem_encondingみたいなのがあれば、昔のLinuxのイメージに残っているEUC-JPなデータをサルベージするときに便利そうである
・2.0ではデフォルトはlocaleにしておいたほうが、あとから自然に拡張できるような気がする

以上です。もうちょっと考えてからまたなんか書くかも

[shyouhei (Shyouhei Urabe)]

On 11/02/2012 01:56 PM, KOSAKI Motohiro wrote:

とくに指定しなければ、default external は locale から設定されるので、
「UNIXにおけるfilesystem encodingはlocaleである」というのはそれほど
変ではないのではないでしょうか。

ふむ。
とすると、本当は、filesystem encodingを明示して設定するAPIが
合ったほうがいいんでしょうかね。
2.0.0にも間に合わなわなさそうなので今は深入りを避けますが。

めんどくさいケースは以下の２つですかね。

ロケールは UTF-8
ファイルシステムはFAT（よってファイルシステムのファイル名はShiftJIS or another country specific codepage)
ファイルの中身は EUC

※これはSDカードなどで実際に発生しうる

2. ロケールはUTF-8だけどファイルシステムエンコーディングはUTF8MACな某OS

というパターンだと思うので、これをケアする必要があるならAPIが必要そうに思えます。要望を上がってこない所をみるとあんまり困ってないのかな

後者に関してはリクエストが来てますね([ruby-core:48745] [Bug #7267])、否定的な返答しちゃったけど。

[kosaki (Motohiro KOSAKI)]

2. ロケールはUTF-8だけどファイルシステムエンコーディングはUTF8MACな某OS

というパターンだと思うので、これをケアする必要があるならAPIが必要そうに思えます。要望を上がってこない所をみるとあんまり困ってないのかな

後者に関してはリクエストが来てますね([ruby-core:48745] [Bug #7267])、否定的な返答しちゃったけど。

まったく技術的じゃない感覚論でいうと、Macユーザロケールやdefault_external を
UTF-8MACにすることはありえないと思うので、気持ち的にはなんらかのケアをしてあげたいなあとか思うんですよね。
自分はMacで日本語ファイル名を一切つかってないのでなかなか手が動かないけど

[usa (Usaku NAKAMURA)]

こんにちは、なかむら(う)です。

In message "[ruby-dev:46375] Re: [ruby-trunk - Bug #2154][Assigned] filesystem encoding of UNIX"
on Nov.03,2012 04:56:59, [e-mail] wrote:

ロケールは UTF-8
ファイルシステムはFAT（よってファイルシステムのファイル名はShiftJIS or another country specific codepage)
ファイルの中身は EUC

※これはSDカードなどで実際に発生しうる

これ、私も気になってるんですが、苦情を見かけないのが不思議で
す。
みなさんどうしてるんでしょう?

ただ、よくわかんないんですが、最近はSDカードとかFATつっても
FAT32じゃないんすかね。
であればUnicodeなファイルエントリもあるはずなのでファイルシス
テムドライバが真面目に作ってあればUTF-8でファイル名アクセスが
できて問題ないようにも思います。
この辺はそういうシステムを使ってる人に聞きたいところ。

2. ロケールはUTF-8だけどファイルシステムエンコーディングはUTF8MACな某OS

というパターンだと思うので、これをケアする必要があるならAPIが必要そうに思えます。要望を上がってこない所をみるとあんまり困ってないのかな

困ってる話は卜部さんも紹介されたようにけっこうな頻度で見かけ
るように思います。
ここは成瀬さんが深く考えていたはずなので説明お願いします。

まとまってないので思いついたことを箇条書きで書くと

・Linuxではlocale(UTF-8)、MacではUTF8MAC、WindowsではUTF-16（だっけ？）がデフォルトのファイルシステムエンコーディングであって欲しい

Windowsではいわゆる「W」は内部的にUTF-8に変換して扱うことにし
たので、next majorあたりでファイルシステムエンコーディングは
UTF-8にします。

スクリプトはUTF-16を返されてもASCII compatibleじゃないので

制限がきつくて使えないし、ruby内部でもASCII compatibleじゃ

ない文字列をパス名として扱えるようにはほとんどなってない。

・SDカード対策のために違うエンコーディングを指定できて欲しい。これはdefault_externalをかえるよりかは引数で与えれたほうが便利そうな気がする。
default_externalを変えちゃうと別のスレッドがぎゃっといいそうだから
・default_filesystem_encondingみたいなのがあれば、昔のLinuxのイメージに残っているEUC-JPなデータをサルベージするときに便利そうである

これは先に書いたとおり私も同意します。

・2.0ではデフォルトはlocaleにしておいたほうが、あとから自然に拡張できるような気がする

default_externalじゃなくて、ということでしょうか?

実はbackportの都合で今時点の1.9.3 HEADも現状のtrunkの実装を引
き継いでいるので、個人的には、まずさっさと2.0.0でどうするか、
を決めてしまいたい気分です。1.9.3はそれに合わせるので。

ところで、しろさきさんってこっち見てます?
見てたらいろいろ教えて欲しいところ。

それでは。

U.Nakamura [e-mail]

[h.shirosaki (Hiroshi Shirosaki)]

2012/11/5 U.Nakamura [e-mail]:

実はbackportの都合で今時点の1.9.3 HEADも現状のtrunkの実装を引
き継いでいるので、個人的には、まずさっさと2.0.0でどうするか、
を決めてしまいたい気分です。1.9.3はそれに合わせるので。

expand_pathのencodingが引数のencodingと同じになるのは、コードを書くときには、それはそれで分かりやすいとは思います。encodingが自動的に変わらないということなので。

パス名にマルチバイトを使うと、トラブルの元になりますから、私は使わないようにしています。

--
Hiroshi Shirosaki

[h.shirosaki (Hiroshi Shirosaki)]

2012/11/5 U.Nakamura [e-mail]:

ただUNIX系については特に意図せず変更されていると思うので、現
時点では挙動を戻すのが妥当なラインかと思っているのですが...
なおこの変更は例のWindows用のFile.expand_path高速化の副作用で
あるというのが私の観測なので、それが事実かどうか(そして事実だ
としたらどこを直せばいいのか)をちょっと考えてみてほしいです。

File.expand_pathのencodingが変わったのは、中田さんの修正による変更のように思います。
私は意図的に仕様を変更したのだと思っていました。
Windows用のFile.expand_pathは、その変更にあわせてあります。

--
Hiroshi Shirosaki

[usa (Usaku NAKAMURA)]

こんにちは、なかむら(う)です。

In message "[ruby-dev:46403] Re: [ruby-trunk - Bug #2154][Assigned] filesystem encoding of UNIX"
on Nov.05,2012 21:33:52, [e-mail] wrote:

File.expand_pathのencodingが変わったのは、中田さんの修正による変更のように思います。

なんですとー。
どうなんですか＞なかださん

私は意図的に仕様を変更したのだと思っていました。
Windows用のFile.expand_pathは、その変更にあわせてあります。

Windowsについては以前から私にはそういう意志があるのでいいんで
すが。
どっかでごっちゃになってるのかな。

それでは。

U.Nakamura [e-mail]

[kosaki (Motohiro KOSAKI)]

・2.0ではデフォルトはlocaleにしておいたほうが、あとから自然に拡張できるような気がする

default_externalじゃなくて、ということでしょうか?

default_external
という仕様にしてしまうと、default_file_systemを作った時に互換性のため最終仕様が以下のようになってしまうので、わかりにくいかなあとか思ってました

以下の順に影響

1. expand_path()の引数エンコーディング
2. default_file_system
3. defaut_external
4. locale

深い理由ではないので無視してもらっても

[naruse (Yui NARUSE)]

usa (Usaku NAKAMURA) wrote:

In message "[ruby-dev:46375] Re: [ruby-trunk - Bug #2154][Assigned] filesystem encoding of UNIX"
on Nov.03,2012 04:56:59, [e-mail] wrote:

ロケールは UTF-8
ファイルシステムはFAT（よってファイルシステムのファイル名はShiftJIS or another country specific codepage)
ファイルの中身は EUC

※これはSDカードなどで実際に発生しうる

これ、私も気になってるんですが、苦情を見かけないのが不思議で
す。
みなさんどうしてるんでしょう?

ただ、よくわかんないんですが、最近はSDカードとかFATつっても
FAT32じゃないんすかね。
であればUnicodeなファイルエントリもあるはずなのでファイルシス
テムドライバが真面目に作ってあればUTF-8でファイル名アクセスが
できて問題ないようにも思います。
この辺はそういうシステムを使ってる人に聞きたいところ。

現状では default_external を SJIS にしてファイル開くときに external encoding を EUC-JP に設定とかですかねぇ。

2. ロケールはUTF-8だけどファイルシステムエンコーディングはUTF8MACな某OS

というパターンだと思うので、これをケアする必要があるならAPIが必要そうに思えます。要望を上がってこない所をみるとあんまり困ってないのかな

困ってる話は卜部さんも紹介されたようにけっこうな頻度で見かけ
るように思います。
ここは成瀬さんが深く考えていたはずなので説明お願いします。

filesystem encoding を UTF8-MAC にすると、non ASCII が入った瞬間 UTF-8 の文字列と比較できなくなって困り、
UTF-8 にすると UTF-8 なのに decomposed なので困るという八方ふさがりな状態であるという、
当たり前の知見が得られました。

[mame (Yusuke Endoh)]

• Target version changed from 2.0.0 to 2.6

[mame (Yusuke Endoh)]

• Assignee changed from akr (Akira Tanaka) to naruse (Yui NARUSE)

なんとなく成瀬さんに振り直してみます。このチケット、いかが思われますか。

[naruse (Yui NARUSE)]

• Status changed from Assigned to Rejected

特に要望は来ていないように思うのでrejectで。