Tach!
ich bin nicht sicher ob die Kategorie "Datenbank" korrekt ist, denn möglicherweise ist es auch ein HTTP-Problem oder ein Browser-Problem oder gar ein HTML-Problem.
Ich habe nämlich Schwierigkeiten Umlaute aus einem Formular in meine Datenbank und zurück zu bringen.
Zwei Grundregeln beim Umgang mit Zeichenkodierungen gibt es:
- Jedes System muss mit der gewählten Kodierung umgehen können, oder es reicht die Daten nur unverändert durch.
- An jeder Schnittstelle zwischen zwei Systemen muss dem nachfolgenden System mitgeteilt werden, in welcher Kodierung die Daten vorliegen (oder zurückgeliefert werden sollen).
Alle meine Ausgaben werden ebenfalls als UTF-8 ausgeliefert (jede Seite die Ausgaben erzeugt beginnt mit
header('Content-Type: text/html; charset=utf-8');
und nahezu jede Ausgabe beginnt mit<!DOCTYPE html><html><head><title></title><style></style></head>
(...))
Wie das HTML beginnt, ist weniger interessant, wichtiger ist die Kodierungsangabe im Header. Die Angabe im HTTP-Header sticht zwar, wenn sie vorhanden ist, aber das ist sie nicht immer. Beim lokalen Speichern ist sie zum Beispiel nicht mehr da. Das ist zwar für dein aktuelles Problem nicht relevant, aber wenn du schonmal beim Korrigieren bist ...
Mein Eingabeformular ist so definiert:
<form action="./backend.php" method="post">
Hier könnte noch ein accept-charset-Attribut hinzugefügt werden, aber zumindest einige ältere Browser ignorieren das. Üblicherweise reicht die Kodierungsangabe im HTTP-Header oder HTML-Head.
mein SQL wird (beispielsweise) so erzeugt: [...]
und dann mitmysql_query($sql_query);
übergeben.
Und Regel 2? Wird immer wieder gern nicht beachtet. Woher soll MySQL wissen, was du ihm da übergibst?
Wenn in dem Request Umlaute vorkommen (und ich nehme an auch andere Sonderzeichen, "&" funktioniert aber z.B.)
Alles jenseits von ASCII. & ist in ASCII enthalten.
...gebe ich den Query einfach im HTML aus wird er korrekt angezeigt.
...schaue ich mir die Daten mit phpMyAdmin an steht da Ãœbersetzer
Das ist ein typischer Fall von: MySQL weiß nichts von deiner Kodierung und nimmt einen Default-Wert an. Wenn dieser und die Angabe der Feldkodierung unterschiedlich sind, kodiert es selbständig um. Da der PMA beide Regeln beachtet, sieht er korrekterweise das Ergebnis der ungewollten Umkodierung.
...lese ich sie mit meinem PHP aus der Datenbank wieder aus und schicke sie ins HTML (z.B. so:
echo '<input type="text" name="translator" id="translator" value="'.$sql_array['translator'].'" />';
werden sie wieder korrekt angezeigt.
Da fehlt noch die Kontextwechselbeachtung, also ein htmlspecialchars(). Ansonsten hebt hier derselbe Fehler beim Hin- und Rückweg das Problem teilweise wieder auf.
Soweit ich das sehe ist das alles nicht soooo tragisch, weil die Codierung scheinbar hin in die DB und zurück durchaus funktioniert.
Problematisch könnte es werden wenn man irgendwas auf der Datenbank direkt ändert (warum auch immer, aber kann ja mal nötig sein), dann kann man keine Umlaute verwenden oder muss sich irgendwie die entsprechenden Zeichen erst zusammen kramen.
Ja, dieses Problem bleibt und hinzu kommt, dass du keine gescheiten Stringoperationen im DBMS anwenden kannst. Nichtmal Sortieren geht richtig.
Also ich habe irgendwo Zeichensatz-Probleme aber ich weiß nicht wo. Kann mir jemand sagen wo ich suchen kann/soll. Oder kann aus den Angaben gar erkennen was bei mir schief läuft?
Derartige Probleme kommen recht häufig vor, weswegen ich im SELFHTML-Wiki einen Themenschwerpunkt zur Zeichenkodierung angefangen habe. Die wichtigsten für dich relevanten Teile sind schon ausgearbeitet.
dedlfix.