ich habe eine Tabelle, die u.a. viele Namen enthält und möchte diese
alphabetisch sortieren.
Wie kann ich es machen, die z.B. "Ä" als "Ae" einsortiert wird und nicht
nach Z steht. Gibt's da eine Möglichkeit?
Vielen Dank für Eure Hilfe,
Gruß,
Jürgen
man Unicode.
"Lutz Donnerhacke" <lu...@iks-jena.de> wrote in message
news:slrn92n3p...@taranis.iks-jena.de...
Es war wirklich nicht schwer zu erraten. Unicode 3.0 liegt als Wälzer neben
mir.
> * Juergen Lehle wrote:
> >Wie kann ich es machen, die z.B. "Ä" als "Ae" einsortiert wird und nicht
> >nach Z steht. Gibt's da eine Möglichkeit?
>
> man Unicode.
hmpf. inwiefern vereinfacht oder ermoeglicht Unicode die sortierung
deutscher umlaute?
--
frobnicate foo
>ich habe eine Tabelle, die u.a. viele Namen enthält und möchte diese
>alphabetisch sortieren.
>Wie kann ich es machen, die z.B. "Ä" als "Ae" einsortiert wird und nicht
>nach Z steht. Gibt's da eine Möglichkeit?
Ein zusätzliche Feld/einen zusätzlichen Index einrichten (oder eine
temporäre Tabelle?). Bei diesem diesem die Umlaute konvertieren. Dabei kann
man gleich die Gross/Kleinschreibung ignorieren.
Variante 1: Ö --> OE (Telefonbuch)
Variante 2: Ö --> O (Duden)
Andere Umlaute äquivalent.
Christian
Sortiere UTF8 als Octets. Die Sortierreihenfolge ist identisch zu UTF-16.
Und diese ist - bei kanonischer Kodierung, d.h. ohne Sonderglyphen wie äöü -
gleich der umgangssprachlichen Sortierung. 'ä' wird kanonisch als 'a'
'accenct diareses' (sp?) kodiert.
> * frank paulsen wrote:
> >lu...@iks-jena.de (Lutz Donnerhacke) writes:
> >> * Juergen Lehle wrote:
> >> >Wie kann ich es machen, die z.B. "Ä" als "Ae" einsortiert wird und nicht
> >> >nach Z steht. Gibt's da eine Möglichkeit?
> >>
> >> man Unicode.
> >
> >hmpf. inwiefern vereinfacht oder ermoeglicht Unicode die sortierung
> >deutscher umlaute?
>
> Sortiere UTF8 als Octets. Die Sortierreihenfolge ist identisch zu UTF-16.
> Und diese ist - bei kanonischer Kodierung, d.h. ohne Sonderglyphen wie äöü -
> gleich der umgangssprachlichen Sortierung. 'ä' wird kanonisch als 'a'
> 'accenct diareses' (sp?) kodiert.
fraglos. nur leider loest das weder Juergens problem, noch ist die
dabei erhaltene sortierfolge im deutschen EDV-umfeld ueblich.
viel fataler ist aber, dass in unicode mehrere vom bitmuster nicht
gleichwertige darstellungen fuer nationale sonderzeichen existieren
koennen, 'Capital letter A with ring' sieht zwar genauso aus wie
'Angstrom sign', ist aber nur schwer auf gleichheit zu pruefen. wenn
mich nicht alles taeuscht gilt das sogar fuer 'ä', das muesste neben
0061 0308 'latin small letter a'+'combining diaresis' auch als 00E4
'latin small letter a with diaresis' durchgehen. wenn man da nicht
saemtliche eingaben normalisiert wird automatische sortierung in
erster naeherung nur muell erreichen.
ich zitierea mal aus der unicode-FAQ:
=======================================================================
Q: So all I need is Unicode, right?
A: Unicode is not a magic wand; it is a standard for the storage and
interchange of textual data. Somewhere there has to be code that
recognizes and provides for the conventions of different languages
and countries. These conventions can be quite complex, and require
considerable expertise to develop code for and to produce the data
formats. Changing conditions and new markets also require
considerable maintenance and development. Usually this support is
provided in the operating system, or with a set of code
libraries.
=======================================================================
und das heisst nichts anderes, als dass DBMS auch weiterhin eigene
sortiertabellen mitbringen muessen, wenn landes- oder anwendungs-
spezifische sortierfolgen erzeugt werden sollen.
XML und Unicode sind IMHO nicht grundlos so eng verzahnt: es ist
ganz erfrischend, globalgalaktisch umfassende datenformate zu
definieren, bei tatsaechlicher realisierung haperts dann aber
typisch an den altbekannten stellen.
man Buzzword
--
frobnicate foo
Er hat MySQL, ... stimmt.
>noch ist die dabei erhaltene sortierfolge im deutschen EDV-umfeld ueblich.
Nein?
>viel fataler ist aber, dass in unicode mehrere vom bitmuster nicht
>gleichwertige darstellungen fuer nationale sonderzeichen existieren
>koennen, 'Capital letter A with ring' sieht zwar genauso aus wie
>'Angstrom sign', ist aber nur schwer auf gleichheit zu pruefen.
man Kanonisch.
>ich zitierea mal aus der unicode-FAQ:
Danke.
>und das heisst nichts anderes, als dass DBMS auch weiterhin eigene
>sortiertabellen mitbringen muessen, wenn landes- oder anwendungs-
>spezifische sortierfolgen erzeugt werden sollen.
Natürlich.
>man Buzzword
Danke. Univerum rebooted. Reality checked.
kannst Du mir bitte genauer erklären wie das gehen soll. Ich hab leider von
dem Zeug noch nicht soviel Ahnung.
Danke,
Jürgen
CREATE FUNCTION sortstring (a : VARCHAR) RETURNS VARCHAR AS
'$_ = shift;
my %s = {"ä" => "ae", "ö" => "oe", "ü" => "ue", ...};
s/([${\join('',keys %s)}])/$s{$1}/eig;
return lc($_);
' LANGUAGE 'perl';
SELECT ... FROM ... WHERE ... ORDER BY sortstring(field);
> * frank paulsen wrote:
> >lu...@iks-jena.de (Lutz Donnerhacke) writes:
> >> Sortiere UTF8 als Octets. Die Sortierreihenfolge ist identisch zu
> >> UTF-16. Und diese ist - bei kanonischer Kodierung, d.h. ohne
> >> Sonderglyphen wie äöü - gleich der umgangssprachlichen Sortierung. 'ä'
> >> wird kanonisch als 'a' 'accenct diareses' (sp?) kodiert.
> >
> >fraglos. nur leider loest das weder Juergens problem,
>
> Er hat MySQL, ... stimmt.
:-)
ernsthaft: wie loest PostGreSql das?
MS-SQL-Server hat unterschiedliche nationalisierungen, auch wenn man
Unicode verwendet, Oracle dito, ADS auch, selbst DB/2 mit seinen DBCS
hat da keinen wenigstens europaweit einheitlichen standard. wenn man
da laenderuebergreifenden datenaustausch betreibt kommt es immer
wieder zu witzigen effekten.
> >noch ist die dabei erhaltene sortierfolge im deutschen EDV-umfeld ueblich.
>
> Nein?
'ä' ist unicode 00e4, das muesste UTF-8 dann wohl als C3 A4 codiert
werden, also zwei oktetts. wenn ich das sortiere passiert irgendwas
schreckliches.
bei UTF-16 wuerden alle umlaute am ende einsortiert, das ist zwar
genau das, was MySQL macht (UTF-16 <00FF ist mehr oder weniger ISO
8859-1[1]), aber garantiert nicht humanvertraeglich.
> >viel fataler ist aber, dass in unicode mehrere vom bitmuster nicht
> >gleichwertige darstellungen fuer nationale sonderzeichen existieren
> >koennen, 'Capital letter A with ring' sieht zwar genauso aus wie
> >'Angstrom sign', ist aber nur schwer auf gleichheit zu pruefen.
>
> man Kanonisch.
'Å' ist _das_ kanonische beispiel fuer die versteckten macken von
Unicode. aus kompatibilitaetserwaegungen gibt es das zeichen
mindestens dreimal: 'Angstrom sign', 'Capital letter A with ring' und
'Capital letter A'+'Combining ring above'. durch normalisierung
bekommt man maximal die letzten beiden moeglichkeiten in eine
abgebildet, bleiben noch zwei optisch, aber nicht semantisch
gleichwertige zeichen an unterschiedlichen positionen.
man _kann_ zwar gemaess http://www.unicode.org/unicode/standard/where/
vorrangregeln verwenden, aber ich habe mir sagen lassen, dass das
spaetestens beim mixen tuerkischer, deutscher und finnischer zeichen
nichttrivial wird und unbefriedigende sortierergebnisse bringt.
[1] und dann war da noch die episode mit dem Euro-Zeichen.
--
frobnicate foo
Vermutlich gar nicht. Gehört ja eigentlich auch nicht da hin. Sollte aber im
Zweifel mit einer Funktion wie ich sie im Thread angegeben habe zu lösen sein.
>> >noch ist die dabei erhaltene sortierfolge im deutschen EDV-umfeld ueblich.
>>
>> Nein?
>
>'ä' ist unicode 00e4, das muesste UTF-8 dann wohl als C3 A4 codiert
>werden, also zwei oktetts. wenn ich das sortiere passiert irgendwas
>schreckliches.
Im Buch 'Unicode 3.0' ist es Kapitel 5.7. Dort werden Sortierrichtungen,
mehrstufige und mehrdimensonale Sortieralgorithmen behandelt, wie sie in den
verschiedenen Sprachen üblich sind. Auch das Äquivalenzproblem ist dort
behandelt.
Man liest dort im einleitenden Abschnitt 'Culturally Expeced Sorting':
: For example, Swedish treats U+00C4 (Latin Capital Letter A with
: Diaeresis) as an individual letter, sorting it after 'z' in the alphabet;
: German, however, sorts it either like 'ae' or like other accented forms
: of 'ä' following a. Spanish traditionally sorts it digraph 'll' as if it
: were a letter between 'l' and 'm'. ...
Dann folgen einige einführende Seiten zu den o.g. Algorithmen.
>bei UTF-16 wuerden alle umlaute am ende einsortiert, das ist zwar
>genau das, was MySQL macht (UTF-16 <00FF ist mehr oder weniger ISO
>8859-1[1]), aber garantiert nicht humanvertraeglich.
Diese Aussage ist falsch. Kanonisch ist das 'ä' = U+0061 U+0308.
>> >viel fataler ist aber, dass in unicode mehrere vom bitmuster nicht
>> >gleichwertige darstellungen fuer nationale sonderzeichen existieren
>> >koennen, 'Capital letter A with ring' sieht zwar genauso aus wie
>> >'Angstrom sign', ist aber nur schwer auf gleichheit zu pruefen.
>>
>> man Kanonisch.
>
>'Å' ist _das_ kanonische beispiel fuer die versteckten macken von
>Unicode. aus kompatibilitaetserwaegungen gibt es das zeichen
>mindestens dreimal: 'Angstrom sign', 'Capital letter A with ring' und
>'Capital letter A'+'Combining ring above'. durch normalisierung
>bekommt man maximal die letzten beiden moeglichkeiten in eine
>abgebildet, bleiben noch zwei optisch, aber nicht semantisch
>gleichwertige zeichen an unterschiedlichen positionen.
U+00C5 oder U+212B ist kanonisch U+0041 U+030A.
Für die meisten anderen Zeichen wie U+00E4 ist die kanonische Schreibweise
sogar per Äquivalenz gefordert.
>man _kann_ zwar gemaess http://www.unicode.org/unicode/standard/where/
>vorrangregeln verwenden, aber ich habe mir sagen lassen, dass das
>spaetestens beim mixen tuerkischer, deutscher und finnischer zeichen
>nichttrivial wird und unbefriedigende sortierergebnisse bringt.
Niemand sagt, daß sortieren trivial ist. Knuth widmet dem Problem ein ganzes
Kapitel.
> * frank paulsen wrote:
> >bei UTF-16 wuerden alle umlaute am ende einsortiert, das ist zwar
> >genau das, was MySQL macht (UTF-16 <00FF ist mehr oder weniger ISO
> >8859-1[1]), aber garantiert nicht humanvertraeglich.
>
> Diese Aussage ist falsch. Kanonisch ist das 'ä' = U+0061 U+0308.
right. ich sollte keine pflichtenhefte als referenz zu diskussionen
ueber standards benutzen.
--
frobnicate foo