✔ Umlaute (CASE)

[crazy_chicken]

Hallo Zusammen,

ich habe eine MySQL-Tabelle mit der Spaltenname "Name" (varchar(100) / latin1_german1_ci).

Eine Suche mit Umlauten klappt aber Groß- und Kleinschreibung werden nicht ignoriert.
Tabelleneintrag "Öffentlich".
Suche nach LIKE "ö%" liefert kein Ergebnis, nur LIKE "Ö%" funktioniert.

Kann da jemand weiterhelfen - Suche schon den ganzen Tag nach einer Lösung!

DANKE!

 

[sheel]

Hi

welche Softwareversion ist das denn?
Kannst du vllt. eine SQL-Datei mit Tabledefinition und Beispielinserts reinstellen?
Mit welchem Programm etc. erfolgt der Zugriff auf die DB?

 

[crazy_chicken]

Hi,

MySQL Version: 5.6.37
PHP Version: 7.0
Erstellung der Tabelle: via PHP MyAdmin

die Daten wurden über PHP in die Datenbank reingeschrieben, nicht über MyAdmin bereich!

Spalteninfos: VarChar(100), latin1_german1_ci
Beispieleintrag in der Tabelle: 1 / Öffentlicher Dienst

reicht das so?

 

[Kalito]

Naja, du kannst es umgehen, wenn du bei deinem Statement alles als Kleingeschrieben deklarierst.

SELECT * FROM my_table where lower(my_field) like '%searchkey%'

 

[crazy_chicken]

Hi Kalio,

leider bringt die Funtkion LOWER() in dem Fall gar nichts!

 

[sheel]

reicht das so?

Eher nicht. Bitte wirkliches SQL, und als Datei angehängt statt reinkopiert.

Zu LOWER, sollte eigentlich (auch) funktionieren, nur kann Queries sehr viel langsamer machen (weil ein Spaltenindex, falls vorhanden, dadurch nicht verwendet werden kann).

Jedenfalls, dein Beispiel "Öffentlicher Dienst" oben ist schon ein deutlicher Hinweis, dass das Problem kein DB-Bug ist Schaut nach UTF8-Inhalt aus, der als Latin1 angezeigt wird (bzw. im Browser schon UTF8, aber vor der Anzeige eine Umwaldung Latin1->Utf8, wegen dem Spaltentyp).

Falls es nicht bekannt ist, nicht nur die HTML-Ausgabe von PHP, PHP-Codedateien, und Mysqlspalten haben einen Zeichensatz, sondern auch die "Verbindung" per Mysqli/PDO von PHP zur DB. PHP kann da einstellen, wie die Daten ankommen sollen, und falls die DB-Spalte nicht dazupasst wird vorher automatisch umgewandelt. Mit einem Browserinhalt in UTF8 sollten PHPmyAdmin usw. Spalteninhalte daher immer korrekt anzeigen, auch wenn die Spalte was anderes ist - so ein verunstaltetes Ö ist nicht in Ordnung.
Angenommen PHP und PHPmyAdmin haben keinen groben Bug, dann steht in der DB wirklich kein Ö, sondern eben dieses Zeug, und deswegen wird auch kein Ö gefunden.
Grund zB. dass die Verbindung beim reinschreiben auf Latin1 gestellt war, obwohl von UTF8 gesendet wurde... falls das so ist, korrigieren geht, aber dabei sollte man sich sicher sein dass wirklich alle Zeilen in der Spalte falsch sind (bzw. welche Zeilenbereiche). Die Umwandlung macht schon richtige Sachen nämlich kaputt.

 

[crazy_chicken]

sheel - vielen Dank!

Das Problem lag wirklich daran, dass die mysql Verbindung auf Latin1 eingestellt war. Dies habe ich mit Hilfe der Funktion

$mysqli->set_charset("utf8");

auf UTF8 umgestellt, da die PHP und HTML Dateien alle auf UTF8 eingestellt sind. Das hat zwar nicht direkt das Problem gelöst, da wie Du bereits erwähnt hast, wurden ja alle Daten damals mit einer Latin1 MySqli Verbindung reingeschrieben. Die Daten habe ich nun neu, mit der UTF8 Verbindung reinschreiben lassen, jetzt funktioniert auch alles. Auch in der Datenbank, über MyPHP Admin sehen die Umlaute nicht kodiert aus.

Eine Verständnisfrage:
Wenn die PHP und HTML auf UTF8 eingestellt sind, dann stellt man logischerweise auch die Verbindung von MySQL auf UTF8. Aber die Tabellenspalte wurde ja als latin1 definiert, wieso funktioniert das trotzdem? Oder soll dann aber auch die Spalte auf UTF8 umgestellt werden?

Danke im Voraus für Deine HILFE!!!!

 

[sheel]

Gut dass es funktioniert
Die Daten neu inserten ist, wenn möglich, natürlich der einfachere Weg, (statt Umwandeln und mit schon richtigen Umlauten Probleme bekommen)

Ja, die Spalte auf Latin1 funktioniert. Mit der Verbindung auf UTF8 wird die DB-Seite das beim Auslesen passend umwandeln, und PHP merkt vom Latin1 nichts mehr.

Nur trotzdem, es gibt eigentlich 2017 nicht mehr viel Gründe Latin1 zu verwenden. Sobald jemand die "falschen" Zeichen eingibt (so ziemlich jede andere Sprache, Emoticons, und alle anderen hunderttausend-undnochwas Zeichen in Unicode), gibts Probleme weil das Zeichen in Latin1 einfach nicht vorkommt. Wenn man es sich aussuchen kann würd ich jedenfalls die Spalte auch auf UTF8 stellen.

...
Und, ich hab zwar grad UTF8 empfohlen, aber ... natürlich gibt es auch Nachteile. Weiterlesen auf eigene Gefahr Latin1 waren 255 Zuordnungen Bytenummer-Zeichen, und ein paar Spezielfälle in den Nummern 0-32. Das Prinzip von Unicode dagegen ist ein mehrere tausend Seiten langer Horror (noch ohne! die Liste der Zeichen), bei dem es weltweit vermutlich wenger als 10 Leute gibt die alles richtig in ihre Programme einbauen können. (Nicht weil die Erfinder so blöd waren, sondern weil sie zB. möglichst viel menschliche Sprachen und Schriftsysteme unterstützen wollten, und Sprachen können ganz schön seltsam sein).
Man kann von dem allen nichts wissen und trotzdem 99% funktionierende Programme schreiben, aber damits gesagt ist: Wenn man irgendwas anderes macht als Unicodetext bekommen und weitersenden, und Korrektheit ist wichtig, am Besten jemandem anders überlassen Sachen wie die Anzahl der Buchstaben (nicht Bytes) in einem String herausfinden, oder Strings vergleichen kann je nach Gründlichkeit und verfügbaren Libs schon ein eigenes Projekt werden. zB. weil ein sichtbarer Buchstabe irgendwas zwischen 0 und unendlich Byte hat, und das unter Anderem vom restlichen Text und Zufall abhängt; weil mehrere Bytekombinationen den selben Buchstaben meinen oder es gleich ausschauende Buchstaben gibt die was anderes bedeuten, usw.usw.usw.

.
.
Oder auch .d̴̜̲̼̼͔͙̈͌̔̔̊͡â͙̳͖̟͖̪͆̔̀̐̂̽͟s̻͚̻͖̝͇̊̀̈́̂͋̾ h̬̦͈̞̭̱͉͋͑͌̄͑͘ͅi̱͚͇̟̦͑̐͆͊̃͂e̸͙̘͎̜͇̔̀̉͊̈́r̴̡̺͙̘̠͆͊͒͐̕͟ͅ
.
.

Ja, das ist deutscher Text, eine Zeile davon. Unicode ist lustig:suspekt: