Ich bin etwas genervt:
Ich habe mich beim Überarbeiten meiner Homepage auch gleich an das Umstellen auf UFT8 gemacht. Doch bislang produziert das Ganze mehr Probleme als es löst.
MySQL Datenbanken sind auf UTF8 eingestellt, Header ebenfalls, Formulare auch.
Wenn ich jetzt einen Satz mit Sonderzeichen aus der DB lese, dann wird das nur mit Rechteck, Fragezeichen und sonstigem Müll ausgegeben.
Jeden String in PHP muss zusätzlich noch mit utf8_encode() verwendet werden…, wobei ich zwischendurch wieder decodieren muss, weil sonst bei doppeltem Aufruf von utf8_encode noch mehr Müll produziert wird.
Irgendwie sehe ich den Sinn nicht, die ganze Arbeit zu machen, wenn es sowieso nicht wirklich etwas bringt…
Bist du sicher, dass in der Datenbank alles auch UTF-8 reingeschrieben wurde oder sind die Tabellen nur UTF-8 umgestellt, der Inhalt aber ANSI (oder sowas).
Bei einem Menu von CSSPlay wird nur noch die Hälfte ausgeführt (das Hauptmenü funktioniert, aber die Untermenüs werden nicht mehr eingeblendet).
Und das alles nur, weil ich die PHP Dateien mit den Klassen für das CMS von ASCII auf UTF8 geändert habe (mit Programmers Notepad 2 erstellt).
Das ist absolut unlogisch. Habt ihr da auch schon ähnlihce Erfahrungen gemacht?
Oder Wie könnte man das Problem umgehen?
Also, es sollten folgende Dinge auf „UTF-8“ stehen:
[ol]
[li]Charset/collation der Datenbank-Tabellen. utf8_general_ci ist in der Regel passend, grundsätzlich ist aber alles mit utf8_* möglich.[1][/li][li]Charset der Datenbank-Verbindung. PDO::MYSQL_ATTR_INIT_COMMAND oder mysqli::set_charset oder mysql_set_charset oder SET NAMES utf8.[/li][li]HTTP-Header Content-Type charset: header(‚Content-Type: text/html; charset=UTF-8‘); und/oder AddDefaultCharset UTF-8 in .htaccess, … I18n Checker zum Überprüfen.[2][/li][li]Charset der Source-Code-Dateien beziehungsweise der HTML-Templates. UTF-8 (ohne BOM). Das sollte in den Editor-Optionen einstellbar sein.[/li][/ol]
Achtung: Ein im HTML-Code ist häufig bedeutungslos, da es von einer Servereinstellung (Header) überschrieben wird! Die Angabe wird meist nur dann interessant, wenn eine Seite auf dem eigenen Rechner gespeichert und von dort als lokale Datei im Client geöffnet wird, da in diesem Fall kein Server existiert, der Header mitschickt.
Die Dateien habe ich alle neu im UTF-8 Format MIT BOM erstellt. Als ich sie auf die Verion ohne BOM geändert habe, lief alles wieder.
Laut W3C:
[ol]
[li]http://validator.w3.org/images/info_icons/warning.png [SIZE=4]Byte-Order Mark found in UTF-8 File.[/SIZE][/li] The Unicode Byte-Order Mark (BOM) in UTF-8 encoded files is known to cause problems for some text editors and older browsers. You may want to consider avoiding its use until it is better supported.
[/ol]
Ältere Browser?? Ich nutze FF 6.0.2 und FF ist normalerweise ja nicht ein Browser, der alles sehr spät einführt. Aber ja, jetzt läufts.
Aber an so einer Kleinigkeit kann man ja dann sehr sehr lange basteln und schliesslich verzweifeln.
Achja, wieso soll die BOM noch nicht angegeben werden? Da ja alles immer weiter entwickelt wird, wird UTF-8 sicher einmal in UTF-16, UTF32 geändert werden, wodurch dann wieder die BOM angegeben werden muss. Wenn jetzt schon die Browser und Editoren kompatibel sind, dann muss später nicht wieder eine grosse Umstellung gemacht werden, oder?
Aber an so einer Kleinigkeit kann man ja dann sehr sehr lange basteln und schliesslich verzweifeln.
Ja, allerdings. Ich habe beispielsweise ewige Zeit nicht gewusst, dass es Punkt 3 aus meinem letzten Post gibt, also dass die Angabe des Charsets in aller Regel eine serverseitige Header-Einstellung ist. Das führt zu dem Effekt, dass Code auf einem zufällig passend konfigurierten Server funktioniert, aber auf einem anderen – warum auch immer – nicht.
Die BOM ist ihrerseits so tückisch, da sie in einem Editor, der die Datei als UTF-8 anzeigt, nicht dargestellt wird, am Dateianfang jedoch trotzdem als drei Bytes vorhanden ist. Die stehen etwa vor einem einleitenden <?php und sind Ausgabe, was ständig zu „Headers already sent…“-Problemen führt (Stichwort Sessions) oder eben zu solchen Effekten, wie du sie beobachtet hast.
Das muss man wissen. Von alleine kommt man da wohl kaum drauf.
Da ja alles immer weiter entwickelt wird, wird UTF-8 sicher einmal in UTF-16, UTF32 geändert werden, wodurch dann wieder die BOM angegeben werden muss.
Diese drei Zeichensätze sind unterschiedliche Kodierungsmöglichkeiten für dieselben konkreten Unicode-Zeichen („Characters“).
Die genauen Eigenschaften werden bei Wikipedia erklärt.