nicht angemeldet
Hi!
ich habe nun meines wissens nach überall utf-8 eingestellt, auch in den entsprechenden db-feldern in der datenbank.
Bitte beschreibe das was du gemacht hast genauer, so dass man aus den Details eventuelle Fehler erkennen kann.
Die Einstellungen der Felder ist der erste Schritt. Der sorgt dafür, dass MySQL intern in der Lage ist, das volle Spektrum der UTF-8-Möglichkeiten zu speichern. Wie schaut es mit der Schnittstelle zu anderen Systemen aus? Hast du die Kommunikation auch definiert auf UTF-8 gestellt?
Ein Hilfsmittel, um die Korrektheit der Daten zu überprüfen ist der phpMyAdmin. Der kann ordnungsgemäß mit den Kodeirungen umgehen. Wenn der alles richtig anzeigt, kann man davon ausgehen, dass die Daten ordnungsgemäß abgelegt wurden. Wenn nicht, hat MySQL aufgrund der vermutlich nicht ausgehandelten Verbindungskodierung die Daten anders interpretiert als du es dir gedacht hast.
jetzt kommt es zu folgenden ungereimtheiten: im safari/mac sind die umlaute der get-parameter durch diverse kryptische zeichen vertreten, auch im dokument selbst werden sie so dargestellt.
Das ist eine Browser-Geschichte. Hast du diesem gesagt, welche Kodierung du verwendest? Verwendest du diese Kodierung tatsächlich?
Die charset-Angabe im HTTP-Header Content-Type ist die maßgebliche Stelle. Fehlt dort ein Eintrag, darf der Browser diese Information aus dem gleichnamigen Meta-Element nehmen. Prüfen welche Kodierung vorliegt, kann man, indem man dem Browser (meist) im Menü Ansicht die Zeichenkodierung händisch einstellt. Werden dann alle Zeichen richtig dargestellt, kann man davon ausgehen, dass die Daten in dieser Kodierung vorliegen.
Wie die GET-Parameter im Browser aussehen, ist erstmal zweitrangig. Er wird normalerweise die Kodierung der Seite verwenden, in der das abzusendende Formular liegt. (Das accept-charset-Attribut arbeitet browserübergreifend nicht hinreichend zufriedenstellend.)
Was sieht das empfangende Programm? Wenn du die ankommenden Daten mal durch url_encode() geschickt anzeigen lässt, siehst du unter anderem auch für die Umlaute die Bytewerte. Als Faustregel: UTF-8-Umlaute verwenden zwei %XX-Werte, ISO-8859-1-Umlaute nur einen.
Den url_encode()-Trick kannst du auch auf die zum Browser zu senden Daten anwenden oder aber auch schon an der Stelle, an der sie aus dem DBMS kommen, um Rückschlüsse auf die vorliegende Kodierung zu ziehen.
im firefox/mac sind sowohl in der url-zeile, als auch im dokument die umlaute zu sehen. kann es sein, dass der safari die umlaute anders codiert, obwohl immer utf-8 angegeben ist?
Er rät vielleicht anders als die anderen. Wenn alle Angaben richtig gesetzt wurden, macht eigentlich kein Browser was verkehrt.
Lo!