=begin
成瀬です。

Nobuyoshi Nakada wrote:

Mac OS Xのシステムコールとしては、NFCだろうとNFDだろうと区別せず
に通すようです。

正確にはVFSドライバのレイヤーですね。
そこで、上位レイヤーからのパスはファイルシステムに適した形に、
ファイルシステムからのパスはdecomposed UTF-8に、基本的には変換します。

「ファイルシステムに適した形」というのは、必ずしもdecomposed Unicodeには
ならないという意味です。
例えば、HFS+ではdecomposed UTF-16になります。
しかし、smb経由でWindowsのファイルサーバーにアクセスする場合、
Mac OS Xはファイル名を合成済み形式にしてアクセスを行います。
そして、分解済みのファイル名を持つファイルにはアクセスすることができません。

例外がUFSとNFSで、この2つでは上記の処理が行われません。

現状では、シェルのglobではNFDがそのまま渡されたり、それ以外の部
分ではNFCになっていたり、ARGVやENVはUTF-8のままであったり、
UTF8-MACを分けていることによるメリットはありません。UTF-8に統一
して、normalizeするメソッドを追加するほうがよいのではないでしょ
うか。

「normalizeするメソッド」はr23296にて、transcodeにUTF8-MACを追加という形で
対処を行いました。

「UTF-8に統一」というのには設定するエンコーディングを「UTF-8」にする
という意味だけですか？
ファイル名のリストを取得する際に変換という話もなさっていたように思いますが。

で、その場合ARGVやENVはどうするのかなぁという疑問がある¶

--
NARUSE, Yui [email protected]

=end

=begin
なかだです。

At Wed, 29 Apr 2009 18:43:26 +0900,
NARUSE, Yui wrote in [ruby-dev:38356]:

「ファイルシステムに適した形」というのは、必ずしもdecomposed Unicodeには
ならないという意味です。
例えば、HFS+ではdecomposed UTF-16になります。
しかし、smb経由でWindowsのファイルサーバーにアクセスする場合、
Mac OS Xはファイル名を合成済み形式にしてアクセスを行います。
そして、分解済みのファイル名を持つファイルにはアクセスすることができません。

例外がUFSとNFSで、この2つでは上記の処理が行われません。

ファイルシステムを意識したコードを書かなければならないというのは
かなりイヤですねぇ。

現状では、シェルのglobではNFDがそのまま渡されたり、それ以外の部
分ではNFCになっていたり、ARGVやENVはUTF-8のままであったり、
UTF8-MACを分けていることによるメリットはありません。UTF-8に統一
して、normalizeするメソッドを追加するほうがよいのではないでしょ
うか。

「normalizeするメソッド」はr23296にて、transcodeにUTF8-MACを追加という形で
対処を行いました。

encode("UTF-8", "UTF8-MAC") と
encode("UTF8-MAC").force_encoding("UTF-8") ですか?

前者はまぁともかく、後者は到底使いやすいとは思えません。せめて
encode("UTF-8", normalize: :decompose) とか。

「UTF-8に統一」というのには設定するエンコーディングを「UTF-8」にする
という意味だけですか？
ファイル名のリストを取得する際に変換という話もなさっていたように思いますが。

で、その場合ARGVやENVはどうするのかなぁという疑問がある¶

自動的な変換は一切なし、という方向に傾いています。

--
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
中田 伸悦

=end

=begin
成瀬です。

Nobuyoshi Nakada wrote:

なかだです。

At Wed, 29 Apr 2009 18:43:26 +0900,
NARUSE, Yui wrote in [ruby-dev:38356]:

「ファイルシステムに適した形」というのは、必ずしもdecomposed Unicodeには
ならないという意味です。
例えば、HFS+ではdecomposed UTF-16になります。
しかし、smb経由でWindowsのファイルサーバーにアクセスする場合、
Mac OS Xはファイル名を合成済み形式にしてアクセスを行います。
そして、分解済みのファイル名を持つファイルにはアクセスすることができません。

例外がUFSとNFSで、この2つでは上記の処理が行われません。

ファイルシステムを意識したコードを書かなければならないというのは
かなりイヤですねぇ。

新しいFSが出てきた時にそこではどういう扱いをするのか、
とかも考えないといけませんからねぇ。

現状では、シェルのglobではNFDがそのまま渡されたり、それ以外の部
分ではNFCになっていたり、ARGVやENVはUTF-8のままであったり、
UTF8-MACを分けていることによるメリットはありません。UTF-8に統一
して、normalizeするメソッドを追加するほうがよいのではないでしょ
うか。
「normalizeするメソッド」はr23296にて、transcodeにUTF8-MACを追加という形で
対処を行いました。

encode("UTF-8", "UTF8-MAC") と
encode("UTF8-MAC").force_encoding("UTF-8") ですか?

前者はまぁともかく、後者は到底使いやすいとは思えません。せめて
encode("UTF-8", normalize: :decompose) とか。

後者に対する問題意識は理解しますが、指定の際には行う変換が、
「Appleによって修正されたNFDから戻すための変換」だと明示する必要があります。
ので、encode("UTF-8", normalize: :decompose_mac)とかになりますか。

しかし、いっそのことUTF8-MACをUTF-8のaliasにしちゃってもいいかなとも思っています。

「UTF-8に統一」というのには設定するエンコーディングを「UTF-8」にする
という意味だけですか？
ファイル名のリストを取得する際に変換という話もなさっていたように思いますが。

で、その場合ARGVやENVはどうするのかなぁという疑問がある¶

自動的な変換は一切なし、という方向に傾いています。

自動変換を入れると上述のファイルシステムごとに分岐するか否かとかもあるんですよね。
一部を取り出せばあった方が良さそうだが、
全体として矛盾のない処理がきわめて困難なので変換なし、になるかなぁと。

--
NARUSE, Yui [email protected]

=end

=begin
成瀬です。

NARUSE, Yui wrote:

新しいFSが出てきた時にそこではどういう扱いをするのか、
とかも考えないといけませんからねぇ。

そういえば、SnowLeopardでZFSの読み書きがサポートされる
(Leopardでもサーバー版は読み込みサポートがある)と聞いたのですが、
実際にこの辺がどういう動きになるのかご存じな方は教えてください。

encode("UTF-8", "UTF8-MAC") と
encode("UTF8-MAC").force_encoding("UTF-8") ですか?

前者はまぁともかく、後者は到底使いやすいとは思えません。せめて
encode("UTF-8", normalize: :decompose) とか。

後者に対する問題意識は理解しますが、指定の際には行う変換が、
「Appleによって修正されたNFDから戻すための変換」だと明示する必要があります。
ので、encode("UTF-8", normalize: :decompose_mac)とかになりますか。

NormalizeのAPIをどうするのかは以前ももめた気がするので、とりあえず先送りで。

とりあえず、r23308からMac OS Xにおいて、
filesystem_encodingをUTF-8へと変更しています。
なお、自動変換については今まで通り行っています。

--
NARUSE, Yui [email protected]

=end