< :前の番号
^ :番号順リスト
> :次の番号
P :前の記事
N :次の記事（スレッド移動）
|<:スレッドの先頭
>|:次のスレッド
^ :返事先
_:自分への返事
>:同じ返事先を持つ記事（前）
<:同じ返事先を持つ記事（後）
---:分割してスレッド表示、再表示
| :分割して（縦）スレッド表示、再表示
~ :スレッドのフレーム消去
.:インデックス
..:インデックスのインデックス
> What I would expect to happen is for Ruby file system methods to convert =
back to composed form on reading in file names again, so that matches on a =
strings or regexp defined as UTF-8 would work correctly. As it is these fai=
l, and the string displays normally but does not behave as you would expect=
.
An issue is people may write decomposed filename.
A imaginary use case is a program which make a filename from the name of
a music output from iTunes.
iTunes manages texts with UTF8-MAC.
So the people will confuse.
> Apologies if this has already been considered and I am rehashing an old a=
rgument, I just found this behaviour somewhat puzzling until I worked out w=
hat it was doing,
This issue is disscussed for long time.
First Ruby 1.9.0 set strings derived from filenames UTF8-MAC.
But some reported that if filenames is UTF8-MAC, it is hard to compare
with normal UTF-8 strings.
So from 1.9.2 filenames become UTF-8.
I find there is no correct simple answer.
> and even then it is painful to have to consider which flavour of UTF-8 i=
s in use and convert to NFC all the time.
More painful thing is normal UTF-8 is not NFCed UTF-8.
There is both NFCed one and NFDed one.
People are living with such ambiguousity all the time even if they don't no=
tice.
> It would be great if Ruby could just consistently return NFC (as is used =
when you use UTF-8) and convert as necessary for the file system, but never=
expose that to the user.
Again Ruby can't always return NFC strings because filenames are not
normalized and
may contain both NFCed one and NFDed one on other than HFS+.
(you may know Mac OS X's default filesystem is HFS+)
> If the translation from UTF8-MAC -> UTF-8 is entirely non-lossy and would=
do no harm to other UTF-8 strings
Yes until all part of the converting string is truly UTF8-MAC.
> perhaps the right thing to do here would be to auto-translate UTF-8-MAC t=
o UTF-8 on reading all file names assumed to be UTF-8 on Mac OS, as the OS =
default is decomposed, but the default in Ruby is composed.
I slightly doubt that this feature truely make people happy and there
are no side effect
even if without technical difficulty.
> Hopefully this would not affect any other users/file systems, but I'm afr=
aid I don't know enough to make that judgement call and may well have overl=
ooked something.
On Mac OS X, there are other than HFS+.
Mac OS X can use UFS, CDFS, NFS and so on.
They don't normalize filenames.
If you NFCed such filenames, you lost the file.
Moreover if you mount filesystems, a path may contain names from
different filesystems like
/ - HFS+
/foo - UFS
/foo/bar - ext4 over NFS
/foo/bar/baz - NTFS
/foo/bar/baz/cd - CDFS
Here, only "foo" is normalized.
If bar is "e`" (decomposed) and a directory named "=E8" (composed) in
the parent directory,
the path lost the file.