Natürliche Sortierung mit UTF-8 oder ISO-8859-15

[heisenberg]

Hi,

mal eine kleine Frage. Ich habe eine Datei:

datei.txt

Code: Alles auswählen

Bachmann Peter
Bach Silke

welche mir mit UTF8 locales so sortiert wird...

Code: Alles auswählen

$ LC_COLLATE=de_DE.UTF-8 sort datei.txt
Bachmann Peter
Bach Silke

mit C-locales in der alphabetischen Sortierung, so wie ich das haben möchte(Leerzeichen kleiner als alle Buchstaben):

Code: Alles auswählen

$ LC_COLLATE=C sort datei.txt
Bach Silke
Bachmann Peter

Das scheint so zu sein dass Leerzeichen bei der Sortierung mittels UTF-8 als Zeichen komplett ausgeblendet sind. Kann man irgendwie mit UTF-8 eine natürliche Sortierung erreichen?

Grüße & Dank im Voraus,
h.

NACHTRAG

Wenn ich mir z. B. für den Zeichensatz de_DE@euro(aka ISO-8859-15) - der ebensowenig wie gewünscht natürlich sortiert - anschaue, dann sehe ich in dem Zeichensatz von dem es abgeleitet ist in der Datei iso14651_t1 neben einem include eines weiteren templates nur das hier:

Code: Alles auswählen

...
<U4E00> <U4E00>;IGNORE;IGNORE;IGNORE
.. ..;IGNORE;IGNORE;IGNORE
<U9FA5> <U9FA5>;IGNORE;IGNORE;IGNORE
...

Ohne zu verstehen was es bedeutet, vermute ich doch dass da explizit steht: Bitte whitespace bei der Sortierung ignorieren. Wenn ich die 3 Zeilen auskommentiere dann scheint dass mit der Sortierung erst mal zu klappen.

Ich bin weiterhin verwirrt und gehe mal davon aus, dass alles seine Richtigkeit hat und aus einem bestimmten Grund so ist wie es ist und frage mich weiterhin, was der einfache Weg für die natürliche Sortierung ist. LC_COLLATE=C ist es ja eindeutigerweise nicht.

[Meillo]

In deinem Beispiel fehlt noch ein ``Bach Anton'', dann wird es noch klarer.

Hier mehr Infos zum gleichen Problem: http://stackoverflow.com/questions/2366 ... nd-lc-coll

Im konkreten Fall kannst du es so loesen:

Code: Alles auswählen

LC_COLLATE=de_DE.UTF-8 sort -t ' ' -k 1,1 -k 2,2

[heisenberg]

Danke Meillo für den Link. (Den Bach Anton hatte schon hinzugezogen. )

Hintergrund der Frage ist vor allem, dass das neue Verhalten, Leerzeichen zu ignorieren, statt Sie als Zeichen mit Minimalwert zu betrachten(Ich habe die Links noch nicht alle gelesen), dazu führt, das von einer größeren Scriptsammlung jetzt überall die Sortierungen brechen(Update von Ubuntu 8.04 auf Ubuntu 16.04). Die Scripte sollen auch möglichst kompatibel(mit anderen Unices) bleiben - aber da würde ich die von Dir vorgeschlagene Variante so einschätzen, das sort auch dort mit Sortierfelddefinitionen seit vielen Jahren umgehen kann.

[Meillo]

Hintergrund der Frage ist vor allem, dass das neue Verhalten, Leerzeichen zu ignorieren, statt Sie als Zeichen mit Minimalwert zu betrachten(Ich habe die Links noch nicht alle gelesen), dazu führt, das von einer größeren Scriptsammlung jetzt überall die Sortierungen brechen(Update von Ubuntu 8.04 auf Ubuntu 16.04).

Wenn man der Meinung ist, dass es davor falsch war und jetzt richtig ist, dann ist so Wechsel unausweichlich, sofern man nicht ewig mit dem Falschen leben will. Mir scheint jedoch, dass nicht alle das neue Verhalten richtig finden, damit kann man das schon kritisch sehen ... aber was will man machen?

Die Scripte sollen auch möglichst kompatibel(mit anderen Unices) bleiben - aber da würde ich die von Dir vorgeschlagene Variante so einschätzen, das sort auch dort mit Sortierfelddefinitionen seit vielen Jahren umgehen kann.

`-k' gibt es noch nicht immer. Es wurde von POSIX eingefuehrt, um das alte `+' mit Zahl (null-basierend) zu ersetzen. Alle neueren Implementierungen kennen aber `-k'.

Fuer mehr Details siehe: http://pubs.opengroup.org/onlinepubs/96 ... /sort.html (Hab nicht alles durchgelesen, scheint aber durchaus interessant und fuer das Thema hier relevant zu lesen sein.)

[heisenberg]

`-k' gibt es noch nicht immer.

Ich weiss. Ich bin auch schon ein paar Jährchen dabei.

... aber was will man machen?

So ist es. Linux - No Country for old men.

[Meillo]

`-k' gibt es noch nicht immer.

Ich weiss. Ich bin auch schon ein paar Jährchen dabei.

Ich war mir nicht sicher, ob aus deiner Aussage Unsicherheit oder Ueberzeugung spricht, darum die -- wie sich nun herausstellt -- unnoetige Anmerkung.

[heisenberg]

Dabei viele Jahre - aber hauptsächlich mit Linux. Wie die Situation bei den anderen Unices ist, da bin ich mir tatsächlich etwas unsicher. Ich würde die Situation bei den Basiswerkzeugen dort etwa 10 Jahre hinter den Linuxwerkzeugen einschätzen - also mit dem was per Default dabei ist - könnte aber auch mehr sein. Zusätzlich kann man ja auch dort auch halbwegs aktuelle GNU-Werkzeuge nachinstallieren oder die aktuellen Versionen kompilieren.

[Meillo]

Wie die Situation bei den anderen Unices ist, da bin ich mir tatsächlich etwas unsicher. Ich würde die Situation bei den Basiswerkzeugen dort etwa 10 Jahre hinter den Linuxwerkzeugen einschätzen - also mit dem was per Default dabei ist - könnte aber auch mehr sein.

Nicht zwangslaeufig. FreeBSD hat z.B. seit 2004 POSIX-kompatible Multibyte-Unterstuetzung bei cut(1), waehrend GNU cut noch immer nur so tut als koennte es das auch.

Es gibt Bereiche, da trifft deine Einschaetzung sicher zu, aber du musst auch schauen, was du als Default ansetzt. Wenn es von GNU voran getriebene Features sind, dass ist klar, dass die bei BSD z.B. nicht unbedingt auf den gleichen Featuritis-Zug aufspringen. Objektiv sollte man sich bei Fragen zum Default nur an POSIX orientieren, und POSIX hat ja zum Ziel den groessten gemeinsamen Nenner der vorhandenen Implementationen zu spezifizieren. Kritisch sind dann eben die Teile von POSIX, wo man aktiv nach vorne gearbeitet hat, wie AFAIK im Fall von `-k' bei sort(1).