AJAX und Sonderzeichen

[dedlfix]

Hi!

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.

Wenn der Client was anders macht als erwartet, ist das zu betrachten, was beim Client ankommt, um festzustellen, was da im Code falsch ist. Dann erst kann man auf Ursachensuche gehen, nach dem Programmteil, der den Code dafür zusammengebaut hat. Wenn du vermutest, dass die Zeichenkodierung den Browser zu Textverstümmlung veranlasst, lass das was du dem Browser sendest mal durch urlencode() laufen. Oder schalte in der Quellcode-Ansicht die Zeichenkodierung auf ISO-8859-1 oder Windows-1252, dann siehst für jedes Byte ein Zeichen. Bei ungültigen UTF-8-Sequenzen verschluckt sich ein Browser gern mal und dann fehlen ein oder zwei Zeichen von den folgenden.

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.

german2 ist nicht die Kodierung sondern hat mit dem Vergleichen von Zeichen zu tun. Die Kodierung steckt im ersten Teil, also latin1, was bei MySQL Windows-1252 entspricht, einer Abart von ISO-8859-1.

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.

Ja, aber das hätte man ungefähr zum Zeitpunkt der Computererfindung berücksichtigen müssen. Alles Jammern darüber ist nun zu spät. Die Zukunft lautet Unicode und seine Kodierungen. Wenn man konsequent alle anderen Zeichensätze und ihre Kodierungen aussterben ließe, wäre das Problem auch gelöst. Das wird aber nicht passieren - zumindest nicht auf absehbare Zeit - also werden wir uns insgesamt noch eine Weile mit den Unzulänglichkeiten und Fallstricken rumschlagen dürfen. Und wenn/weil du nicht wenigstens für dein Projekt umsteigen kannst, solltest du dir die Grundlagen der Zeichenkodierung ansehen, die Merkmale von ISO-8859-1 und UTF-8 verstehen, damit du sie und ihre Erscheinungsformen erkennen kannst.

[gekürzt:] station%E4re geh%F6ren Gef%E4hrlichen Abf%E4lle d%FCrfen Hausm%FCll

Du siehst da also, dass deine Umlaute von je einem Byte repräsentiert werden. Und wenn du dir die ISO-8859-1-Tabelle ansiehst, siehst du, dass deine Umlaute ISO-8859-1 entsprechen (= latin1).

Wenn du das nun als UTF-8 deklariert ausgeben willst, musst du das umkodieren: utf8_encode(). Oder du lieferst es als ISO-8859-1 deklariert aus. Wenn du nun in dem auszuliefernden Text auch noch Zeichen in UTF-8-Kodierung hast, wäre also ein utf8_encode() der Datenbankinhalte sinnvoll.

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...

Ich kenne Typo3 nicht. Wenn du dafür was schreiben willst, solltest du dich an dessen Philosophie und Gegebenheiten richten. Ich denke aber nicht, dass du der erste bist, der Zeichenkodierungsprobleme mit Typo3 hat, weswegen du zumindest generische Auskünfte über Typo3s Verhalten diesbezüglich finden dürftest.

Lo!