MySQL unterscheidet nicht zwischen ä und a

A

AS-N

New Member
Hallo,

ich habe hier eine MySQL 5.0.45, welche mit utf-8 läuft.
Apache, PHP sind auch umgestellt und die ganze Sache läuft schon.
Derzeit hab ich nur das Problem, dass die Datenbank nicht zwischen normalen Selbstlauten und Umlauten unterscheidet, wenn man danach sucht.

Auch im PHPMyAdmin liefert die Suche nach %a% und %ä% die gleichen Ergebnisse.
Suche ich nach %äß% werden mir Ergebnisse angezeigt, die ss und a im Namen haben.

Das gleiche Phänomen habe ich natürlich dann auch auf unserer Website bei der dortigen Suche.
Kann man dieses Verhalten der mySQL irgend wie beinflussen?

--
Ciao
AS-N
 
Bin jetzt selber auf die Lösung gekommen, wenn man als Kollation utf8_general_ci einstellt, dann ist für mysql ä=a, ö=o und ü=u.

Das soll so laut DIN für diese Buchstaben auch gelten.
Mein etwas verwirrter Blick in den neusten Duden bestätigte dies, da wird tatsächlich ä,ö und ü einfach unter die jeweiligen Mutterbuchstaben einsortiert.
ich denke mich zu erinnern, dass das zu meiner Schulzeit noch anders war.

Das Problem ist, dass damit für mysql z.Bsp. das Wort "Mühle" gleich dem Wort "Muhle" ist, das halte ich für extrem gefährlich, z.Bsp. wenn es sich um ein Passwort handelt.

Als einzige Möglichkeit wäre das Umstellen der Kollation auf utf8_bin, was dann aber wieder gleich "case sensitive" ist.
Hier wird zwar jetzt zwischen ö - o, ü - u und ä - a unterschieden, aber dafür bekommt man kein Ergebnis geliefert, wenn mann nach "mühle" sucht, es aber "Mühle" in der mysql steht.
Gerade bei der Produktsuche in einem Shop kann man das ja einem Kunden nicht wirklich zumuten.

Eine andere Lösung scheint es nicht zu geben, Schade.

--
Ciao
AS-N
 
Last edited by a moderator:
AS-N said:
halte ich für extrem gefährlich, z.Bsp. wenn es sich um ein Passwort handelt.
Click to expand...
Ähm, Passwörter dürfen nicht im Klartext, sondern nur als Hash (zeitgemäß: SHA1 oder besser SHA256) in der Datenbank gespeichert werden. Da Hashes i.d.R. noch mit einem Digest (z.B. Base64) behandelt werden, ist es faktisch unmöglich, dass sie Umlaute enthalten. Zudem sucht man Passwörter selten unscharf.

Für eine case insesitive Suche benutzt man i.d.R. einen Index, welchen man funktional anlegen kann.
D.h. man indiziert nicht den Inhalt der Spalte sondern das Ergebnis von LOWER(SpaltenWert) und sucht dann nach "LOWER(SpaltenWert) LIKE '<vorher schon lowercaster begriff>%'" um v.A. auch in den Genuss der vollen Performace zu kommen.
(Ich hoffe, das stimmt - ich habe ein bisschen von PgSQL übertragen...)
 
You must log in or register to reply here.
Back
Top