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.
In dem Suchfeld hatte ich ö eingegeben und habe dann halt alle einträge mit ö bekommen. Also like "ö%". Aber das erwähnte Linkproblem im Tabellencontent habe ich auch bei L wit Lautsprecher. Da ist auch ein Link zu Elektrogeräte. Der Link ist auch kaputt. Wobei das beim normalen Tabellenaufbau ohne ajax nicht passiert.
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.
Stimmt natürlich. Aber mit der Fehlermeldung denke ich dass die Daten selbst schon als german codiert sind.
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.
Es wäre vermutlich so einfach wenn es am Anfang jedes Strings ein oder mehrere Codierungszeichen gäbe die einfach den Zeichensatz angeben. Dann bräuchte man sich mit so etwas auch nicht rumschlagen weil alles automatisch erkannt werden könnte.
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.
Hab ich gemacht. Das Ergebnis ist:
ABC_Titel%3A+Abbeizer+ABC_Text1%3A+-+station%E4re+Annahmestelle%3A%0D%0A--%3E+Firma+ETG+%0D%0A-+mobile+Problemstoffsammlung%3A+%0D%0A--%3E+Abfuhrtermine%0D%0A+ABC_Text2%3A+Abbeizmittel+geh%F6ren+zur+Gruppe+der+Gef%E4hrlichen+Abf%E4lle+und+d%FCrfen+nicht+im+Hausm%FCll+entsorgt+werden.%0D%0A%0D%0AWeitere+Informationen+siehe+--%3E+Problemabf%E4lle+ABC_Titel%3A+Abflussreiniger+ABC_Text1%3A+-+station%E4re+Annahmestelle%3A%0D%0A--%3E+Firma+ETG++%0D%0A-+mobile+Problemstoffsammlung%3A+%0D%0A--%3E+Abfuhrtermine%0D%0A+ABC_Text2%3A+Haushaltschemikalien+geh%F6ren+zur+Gruppe+der+Gef%E4hrlichen+Abf%E4lle+und+d%FCrfen+nicht+im+Hausm%FCll+entsorgt+werden.%0D%0AWeitere+Informationen+siehe+--%3E+Problemabf%E4lle+ABC_Titel%3A+Allibert+ABC_Text1%3A+--%3E+Hausm%FCllabfuhr%0D%0A--%3E+Sperrm%FCllabfuhr%0D%0A--%3E+Wertstoffzentrum%0D%0A++%0D%0A+ABC_Text2%3A+Badezimmerschr%E4nke+bestehen+haupts%E4chlich+aus+Kunststoff+und+werden+als+Rest-%2FSperrm%FCll+entsorgt.%0D%0ADie+Anlieferung+von+brennbarem+Restm%FCll+im+Wertstoffzentrum+und+im+M%FCllheizkraftwerk+ist+geb%FChrenpflichtig.+ABC_Titel%3A+Altakten+ABC_Text1%3A+--%3E+Firma+Fetzer%0D%0A-+Entsorgungsfirmen%2C+die+%0D%0A++Aktenvernichtung+anbieten.+ABC_Text2%3A+-+Datenschutzpapier+muss+von+++%0D%0A++++++++Spezialfirmen+behandelt+werden.%0D%0A-+Im+M%FCllheizkraftwerk+werden+Akten+%0D%0A++++++++nicht+angenommen.%0D%0A-+Gesetzliche+Grundlage%3A++++++++++Bundesdatenschutzgesetz+%0D%0A+++++und+DIN+32757.%0D%0A-+Geschnetzeltes+Papier+aus+Haushalten%0D%0A++++++kann%2C+separat+verpackt%2C+in+den++++++++++++Wertstoffh%F6fen+und+im+Wertstoffzentrum++++++abgegeben+werden.+ABC_Titel%3A+Altfett+ABC_Text1%3A+--%3E+Wertstoffh%F6fe%0D%0A--%3E+Wertstoffzentrum+ABC_Text2%3A+Fette+bitte+lose+oder+in+Kunststoffgebinden%2C+auf+keinen+Fall+in+Glasbeh%E4ltern+abgeben%21%0D%0A+
Der Code in php dazu ist: ~~~php
if(isset($_GET['ajaxquery'])){
$query = "SELECT ABC_Titel, ABC_Text1, ABC_Text2 from $dbtable order by ABC_Titel limit 5";
if (! $rs2 = mysql_query($query)) {
die("Ausführen der Abfrage nicht möglich: ".mysql_error());
}
while ($ar2 = mysql_fetch_assoc($rs2)) {
echo urlencode('ABC_Titel: '.$ar2['ABC_Titel'].' ABC_Text1: '.$ar2['ABC_Text1'].' ABC_Text2: '.$ar2['ABC_Text2'].' ');
}
exit;
> > 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.
Ja nur was tut man wenn man nicht weiß wo es mal eingesetzt wird. Das was ich mache ist zB eine Typo3-Extension. Ob die noch mal woanders eingesetzt wird weiß ich nicht aber grundsätzlich muss es da doch eine Lösung geben. Ansonsten müssten ja beim jeweiligen User der sich die Extension installiert alle Codecs stimmen. Oder zumindest müsste der User einstellen können in welchem Format die Daten in der Datenbank liegen...