Man kennt es schon sehr gut. Man erstellt eine HTML-Seite und schreibt einen gewöhnlichen HTML-Source hinein. Man speichert ihn ab und öffnet die Datei mit einem Browser. Statt Umlaute wie ä und ü vorzufinden, entdeckt man Vierecke, verkehrte Fragezeichen und andere Zeichen.
Das Grundproblem liegt bei der Speicherung der Datei. In dem Moment in dem die Datei gespeichert wird, wird auch der Zeichensatz in den Header geschrieben. Zusätzlich gibt es noch einen meta-Tag, der den Zeichensatz nennt. Und zusätzlich schickt der Server noch Informationen dieser Art an den Client. Dadurch können kontroverselle Einstellungen entstehen und der Browser weiß nicht, wie er reagieren soll.
Rangfolge:
- Dateikonfiguration
- Serverkonfiguration
- Meta-Tag (<meta name=”Content-Type” content=”text/html; charset=ISO-8859-1″ />)
Dateikonfiguration
Bei Notepad: Speichern unter/Codierung/UTF-8
Bei Notepad++: Format/Kodiere als UTF-8
Bei vi: :set fileencoding=utf-8 encoding=utf-8
Serverkonfiguration (bzw. HTTP-Header)
PHP: default_charset = “iso-8859-1″
Des Problems Lösung
Wie oben erwähnt gilt diese Reihenfolge. Manche Browser lassen sich aus dem Konzept bringen, treten kontroverse Meinung auf. Die anderen Browser interessieren sich nur für den Dateiheader (zB Firefox). Man beachte also immer, in welchem Status sich die drei Angaben befinden, dann sollte es kein Problem mehr geben. 
(Beispiel: Bei uns ist das Forum in ISO-8859-1 geschrieben; der Blog in UTF8; wp-united [Verbindung zwischen phpbb und wordpress] in UTF-8. Deshalb haben wir auch ein Problem beim Speichern der Profildaten)
Auf der FH haben sie uns beigebracht, dass trotz Zeichensatz und Formatierung der Datei es immer noch klug ist, Umlaute und andere Sonderzeichen mit Entities zu ersetzen:
http://de.selfhtml.org/html/referenz/zeichen.htm
Ja sicher… es war ja auch die Grundidee von HTML “fremde Zeichen” in Entitäten zu schreiben, um die Verfügbarkeit aller Zeichen zugewährleisten (wenn ein Browser ein &-; Zeichen nicht kennt, braucht er es einfach nicht anzeigen). Wenig später ist natürlich Unicode gekommen, war aber noch unbekannt. Jetzt kommt UTF-8 immer mehr auf und somit ist die Internationalisierung leichter.
Wenn man eine Datenbank ausliest, ist es eh leicht ein str_replace einzufügen, aber wenn man einen Artikel in HTML (wie ich) schreibt, möchte man nicht daran denken. Und deshalb schreibt heutzutage eigentlich niemand mehr in Entitäten und verwendet lieber einen passenden Zeichensatz
hmm.. hab mit dem updaten auf WP 2.5.1 jetzt auch wieder ein umlaute Problem. Weiß aber nicht woran es liegen könnte, vll kannst mir ja mal helfen.