Nautilus(GNOMEファイル)が完全にアルファベット順にソートされていないことがわかりました。
$ touch 1
$ touch 2
$ touch 3
$ touch '!2'
これにより、ファイルが次の順序で表示されます!2 1 2 3
。!
ASCIIコードが数字より小さいので、完全にアルファベット順です。ファイルを追加しましょう。
$ touch a
$ touch b
$ touch c
$ touch '!b'
これでファイルが次の順序で表示されます!2 1 2 3 a !b b c
。この表示は前後に!b
表示されます。これは、ファイルがアルファベット順に完全に整列されなくなることを意味します。b
a
$ touch 01
$ touch 02
$ touch 001
$ touch 002
!2 1 01 001 2 02 002 3 a !b b c
。最初は数字がアルファベット順になっているように見えましたが、ゼロで始まるファイルを追加した後にこれらの理論が壊れたため、これははるかに混乱しています。
興味深いことにls
、彼はノーチラスの意見に同意しませんでした。
$ which ls
/usr/bin/ls
$ ls
001 002 01 02 1 '!2' 2 3 a ab ac '!b' b ba c
Nautilusはここでどのアルゴリズムを使用していますかls
? Debian stable Gnomeドキュメントバージョン43.2。
答え1
デフォルトでは、 'ls' は 'sort' で使用するのと同じ libc ロケール固有のソート順を使用します。すべての*.UTF-8
ロケール(とは別に C.UTF-8
)、Glibcは実装します。Unicode ソートアルゴリズム(またはその他それに近い)は現在のロケールに合わせています。
(たとえば、「LC_COLLATE」セクションを参照してください。ロケールデータ/ロケール/es_ES.)
ls
出力をLC_COLLATE=C.UTF-8 ls
(または)とLC_COLLATE=C ls
比較します。
Nautilusが使用するアルゴリズムは、次の周りに回転します。g_utf8_collate_key_for_filename()GLib2から提供されます。これもロケールベースですが、ソースコードには「自然な」数値シーケンスもあります。説明する仕組み。
(ノーチラスにもあります。追加コードドットファイルとバックアップファイル(.*
sums#*
など)は、常にドットではなくファイルの後にソートされ、照合キーよりも優先順位が高くなります。 )
GNU 'ls'には、-v
Nautilusと同様に数値を処理する「自然(バージョン)」ソートオプションがあります(ただし、常にロケール順序ではなくASCII順序を使用します)。同様に「sort」にもあります-V
。
これは完全にアルファベット順です! ASCIIコードで表される数値より小さい
これは従わない。 ASCIIコードでソートいいえ「アルファベット順に並べ替え」。せいぜい自然タイプ。 (IBMが自分のPCでEBCDICを使用していないことを幸いだと思います...)
まず、ASCIIシーケンスがZ
前に続きますa
。これは英語でも明らかにアルファベットではありません。 (どちらの場合もロケール認識順序が使用されますAaBbCc..
が、ASCII順序はCまたはC.UTF-8をロケールとして指定することによって強制されますABC..Zabc..
。)
また、私の名前にはASCII以外のアルファベット文字が含まれています。 「ASCII順にアルファベット順に並べ替え」は未定義の操作で、Unicodeコードポイント順に並べ替えても結果は次のようになります。言語を話します。 (正しい順序はU + 0065 < U + 0117 < U + 0066です。)「ASCII」の「A」は「文字」ではなく「America」を意味することを覚えておいてください。
一方、ASCII シーケンスには実際にはアルファベットに属さない文字が含まれているため、アルファベット順に重みはありません。
この表示は前後に
!b
表示されます。これは、ファイルがアルファベット順に完全に整列されなくなることを意味します。b
a
完全にアルファベット順にソートされているため、両方とも!
アルファベット以外の文字と同じ重みを持ちます。b
!b