【分散型バージョン管理】 Mercurial 【hg】

>>457
ちょっと誤解があるようだから補足しとく。

HFS+のファイル名の正規化形(Normalization Form)は正規のNFDとは少し違うので、HFS+の正規化
形は標準とは異なるという主張自体は正しい。
ただし、独自の正規化形であってもHFS+がファイル名を正規化しているのは確かなので、HFS+の
ファイル名は正規化されていないという主張（たまにそう書いてしまう人がいる）は厳密には間違い。

むしろ正規化されてないのはNTFSの方で、NTFSでは1つのファイル名でNFCとNFDの混在すら可能。
Windowsの日本語IMEはNFCしか吐かないので、NTFSはNFCで正規化されていると誤解されやすい
んだけど、ファイル名としてNFDな文字列やNFCとNFDが混在した文字列を指定した場合に、NTFS
で保存されるファイル名がNFCに正規化されるような事はない。（これは実際に試せば分かる）

ついでだけど、伝統的な*NIXのファイル名はNULL文字を含まないバイト列に過ぎないので、エンコー
ディングの概念は無いし、NTFSよりもファイル名の制限が緩い。
gitがファイル名を保存する時に単なるバイト列としか見なさない実装（だよね？）なのはこれが原因。

SCMがファイル名を正規化されたUnicode文字列であると仮定できれば話は色々と単純になるんだけ
ど、世の中には色々な環境があるのが悩みどころ。

NTFSのそれは (WCHAR)0 を含まない WCHAR列に過ぎないんじゃなかったっけ。
と思ったけど大文字小文字の話が合った。

WCHARも16ビット、32ビットあって単純じゃないのよね。
NTFSも本当にUTF-16なのか？という疑問もあるらしいし。
http://jp.rubyist.net/magazine/?0025-Ruby19_m17n#f07

fixutf8が独自のマップを作っているみたいだけど、これくらいやらないと解決しないんじゃないかな？

わかるけどRuby1.9じゃないがエンコーディングの情報も入れてくれないと、
仮にクライアント側で個別に環境毎にファイル名の対処するにしてもできなくないか？

UTF-8のファイル名をバイト列で格納する、そのバイト列のままWindowsに出力すれば
化けるか、クライアントでエラーが起きるかというのが今までで実際に起きている問題だろ
逆もしかり

もしクライアント側で環境に合わせて変換するにしても、
このバイト列はなんなんだ？何から変換すればいいんだ？ということになる。
そりゃ、もちろん推測はできるだろうが。

>>466
HFS+のファイル名がNFDとは違うのは、
別の正規化というよりもエンコーディング形式のUTF-8-MACとして扱われているくらいだね

MACの正規化って違うんじゃね？という人は、UTF-8-MACでぐぐったら早いと思う

>468
Windows SDKが定義する16bitのWCHARという型って意味でWCHARって書いたんだけど、紛らわしかったか。すまん。
UNIXのファイル名がバイト列に過ぎないのと同様に、生き別れのサロゲートペアなんかも入れられたはず。BOMやU+FFFFも入るかも。

>>471
エンコーディングと正規化の話は独立した別の話だし、UTF-8-MACはエンコーディングじゃないよ。
GNU iconvやSamba等でUTF-8-MACをエンコーディング名として指定した場合に、エンコーディング
としてはUTF-8を使いつつ、特定の正規化形（＝Appleが古いAPIとの互換性の都合でU+2000-2FFF,
U+F900-FAFF, U+2F800-2FAFFの範囲を分解しないように一部改変したNFD）で正規化する仕組み
になってるだけ。
ちなみに UTF-8-MAC という名前の初出は、日本Sambaユーザー会のsugj-tech MLの人達が、いわ
ゆる濁点問題を解決するために作成したパッチ。命名したのは日本人だったりする。

>>473
前半はわかってる。
>>471を見てUTF-8-MACはエンコーディングなんだ、と勘違いする人がでてくるなら、その話はわかる。