Hi!
Passt denn der Inhalt zur Angabe? Zeigt phpMyAdmin alles (die Umlaute vor allem) richtig an?
Ich hatte nur zuletzt 2 Einträge, in denen diese typischen Umlautfehlerzeichen drin waren und bei denen ich keine Ahnung habe, woher sie kommen. Ich mutmaße auf falsch eingestellte Browserbeim User (bzw. falsches Zeichenkodierungsraten beim Browser).
Oder kein mysql_set_charset() respektive SET NAMES verwendet.
- Datenbankinhalt umkodieren, also jedes einzelne String-Feld. Wenn es nicht zu viele sind, mach es zu Fuß, ansonsten lass dir ALTER-TABLE-Statements erstellen.
Na, es sind schon zu viele. Könnte ich nicht auch einen Dump erzeugen und per Texteditor alle Kodierungen suchen und ersetzen?
Geht auch. Achte beim Export darauf, dass als Kodierung UTF-8 eingestellt ist, falls der PMA dich das wählen lässt. Wenn er da keine Auswahl hat (ist iconv nicht installiert und) das Ergebnis ist UTF-8-kodiert. Du kannst dann die Kollations- und charset-Angaben ändern und den Dump wieder importieren, wobei dort auf alle Fälle eine Kodierungsangabe gewählt werden kann und sollte - wieder UTF-8.
Zusätzlich kannst du noch die Angabe der Tabelle und die der Datenbank umstellen.
Wo genau macht man das bei phpmyadmin?
In der Lasche Operations/Operationen. Die gibts für jede Tabelle und für die Datenbank.
- Also, nach jedem mysql_connect (oder wenn du mysqli verwendest dessen Äquivalent) rufst du mysql_set_charset('utf8') auf
Ui, davon habe ich einige.
Keins vergessen!
Der legt nur die Default-Werte fest. Alles andere kannst du problemlos überschreiben. Im Falle der Verbindungskodierung ...
Welche relevanten für mein Problem gibt es denn noch?
Keine weiter. Wichtig sind die Feldkodierungen und die der Verbindung. Der Rest hat keine direkten Auswirkungen. (Ausnahme bei SET CHARACTER SET, aber das nimmt man ja zugunsten von mysql_set_charset() oder SET NAMES nicht. Was es damit auf sich hat, steht auf der bereits verlinkten Wiki-Seite.)
- PHP-Code-Dateien müssen nicht zwangsläufig bearbeitet werden. Wenn du nur Code drin stehen hast,
Nein, ich habe nicht nach Code und Templates getrennt, sondern alle Ausgaben im Code mit drin.
Dann musst du die im Falle von enthaltenen Nicht-ASCII-Zeichen umkodieren.
- PHP-Code. Wenn du die Daten nur vom DBMS zum Browser und wieder zurück durchreichst, ohne Stringverarbeitung anzuwenden, dann brauchst du nichts weiter zu machen.
Im Wesentliche nutze ichmysql_real_escape_string
htmlspecialchars
trim
nl2br
rawurlencode
Die sind alle unproblematisch. Sie behandeln nur ASCII-Zeichen. rawurlencode() kodiert byteweise und das passt für UTF-8.
- was sonst noch?
Welche Komponenten sind an deinem Projekt noch beteiligt? Textdateien? Dateinamen? Andere Server? Mailversand?
Ich includiere ein paar Textdateien, aus denen ich mir Konfigurationseinstellungen hole. Was ist mit denen?
Wenn da Nicht-ASCII-Zeichen drin sind, dann möchtest du die ebenfalls UTF-8-kodiert ausgeben klassen. Also umkodieren.
Dann natürlich CSS-Daten und ich versende über die php-funktion 'mail' Emails, sowie über die Klasse 'phpmailer'.
CSS kann Inhalte enthalten, meist jedoch nur ASCII-Zeug. Kodierungsangaben siehe Themen:Zeichencodierung/Webdokumente.
Auch EMails kennen den Content-Type-Header. Nimm text/plain als Typ für Textmails zuzüglich charset-Parameter. Ansonsten (für HTML) musst du ja sowieso schon den Content-Type angeben, der ebenfalls einen charset-Parameter benötigt.
Was meinst Du mit Dateinamen? Die sind alle a-z/0-9.
Dann sind die problemlos. In Richtung Dateisystem lässt sich nämlich keine Zeichenkodierung aushandeln. Da muss man probieren, welche es will, oder auf Umlaute etc. verzichten.
Lo!