dedlfix: AJAX und Sonderzeichen

Beitrag lesen

Hi!

Mit nehmen meinte ich dass ich einen header setze in der php-Datei.
header('Content-type: text/html; charset=utf-8');

Das ist nur ein Teil und so wie etwas auf einen Briefumschlag drauf zu schreiben. Der zweite Teil ist, das Zeug auch in den Briefumschlag hinein zu legen oder in deinem Fall, die Daten auch tatsächlich nach UTF-8 zu kodieren (falls sie das noch nicht sind).

Ich habe mir das mal angesehen und versucht per mysql_set_charset('utf8', $conn); die Verbindung zur Datenbank auf utf8 zu setzen. Ergebnis war die Fehlermeldung:
Ausführen der Abfrage nicht möglich: Illegal mix of collations (latin1_german2_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation 'like'

Ich hatte gerade im Test kein Problem, mit einer UTF-8-kodierten Anfrage (inklusive Umlaut) Daten aus einem latin1_german2_ci-Feld über LIKE abzufragen. Was hast du für Zeichen in deinem LIKE-String gehabt, nur ASCII oder auch Umlaute und dergleichen? Wobei ich eigentlich eine andere Ursache für die Fehlermeldung annehme. Ich weiß nur nicht, welche Situationen zu dieser Meldung führen.

was dann wohl zeigt welche Codierung die Datenbank hat. (Mir fehlen im Moment die Zugangsdaten zu phpmyadmin aber bei dieser Codierung bin ich ziemlich sicher dass einfach die Standardcodierung genommen wurde)

Standard/default wäre latin1_swedish_ci. Die Datenbank-Kodierung ist auch nicht maßgeblich sondern die der einzelnen Felder.

Ich kenne jetzt keine Codierung die ich jetzt da für den Header nehmen könnte. Am Liebsten wäre es mir natürlich wenn die Livesuche mit jeder Art von Codierung umgehen könnte. Wäre es zB möglich einen String zu nehmen und per php-Funktion die Codierung zu bestimmen?

Nein, das geht nicht. Wenn du nicht weißt, was am Ende rauskommen soll, kannst du einen verschlüsselten (was anderes ist kodiert ja nicht) Text nicht dekodieren und dann prüfen, ob das nun das Original oder was anderes ist. Es gibt eventuell Indizien, die auf eine bestimmte Kodierung schließen lassen. Beispielsweise wenn nur gültige UTF-8-Sequenzen vorkommen, kann es sich mit einer gewissen Wahrscheinlichkeit um UTF-8 handeln. Es kann aber auch sein, dass einer "in ISO-8859-1 spricht" und zeigt, wie es aussieht, wenn UTF-8-Sequenzen als ISO gelesen werden.

Ich habe jetzt mal den header-tag weggelassen und das Ergebnis sieht genauso aus wie wenn ich utf8 verwendet hätte. Also text ok aber buchstabe nicht.

Machen wir es mal exakter und nachvollziehbarer. Das was du aus dem DBMS holst, schick mal durch urlencode() und zeig das Ergebnis. (Die Funktion ist zwar nicht zum Anzeigen von Hexwerten vorgesehen, zeigt aber einfacher lesbare Ergebnisse als bin2hex().) Mach das mal für beide Fälle. Abhängig vom Ergebnis kann man dann gezielter weiterüberlegen und mit einer Lösungsfindung fortfahren.

Schließlich wäre es ziemlich nervig wenn man bei einer neuen Implementierung das Ganze wegen anderer Codierung wieder per Hand umstellen müsste.

Deswegen ja die Empfehlung nur eine einzige Kodierung für ein Projekt zu verwenden und das vorzugsweise UTF-8. Wenn du mehrere Kodierungen verwendest, wirst du garantiert immer irgendwo ein Problem bekommen.

Lo!