Gerade habe ich wieder etwas dazu gelernt. Das man bei UTF achten muss, dass man die Dateien in UTF-Modus ohne BOM (Byte-Order Mark) abspeichern soll, war mir schon seit längerer Zeit klar. W3C sagt folgendes dazu:
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.
Allerdings war mir nicht klar was es für Konsequenzen geben könnte. Heute ist mir aber aufgefallen, dass wenn man die Template-Dateien eines WordPress-Themes versehentlich in UTF mit BOM abspeichert der Internet Explorer 7 sich daran “verschluckt”.
Die Startseite wird normal angezeigt, sobald man aber einen internen Link anklickt “verliert” der IE7 einen Großteil der CSS-Regeln und die Seite erscheint zum großen Teil ungestylt. Lädt man die Seite neu, so ist alles in Ordnung. Der IE7 hat wieder Kontakt zu der CSS-Datei.
Danach habe ich alle Dateien in UTF ohne BOM abgespeichert und alles ist wieder in Ordnung. Man lernt nie aus :-). Allerdings weiß ich jetzt nicht ob das nur eine Eigenheit von Microsofts IIS-Servers ist.
Wir arbeiten seit 20 Jahren mit WordPress und bieten diverse Dienstleistungen rund um das System an. Kontaktiere uns für weitere Informationen oder für ein Angebot.
Liegt nicht am IIS. Ich hab ähnliche spannende Erfahrungen mit dem BOM und IE7 gemacht, auch auf dem Apachen. Bei mir hat es immer Teile des Designs verschoben, ohne das der Grund ersichtlich war. Ich hab alle bekannte IE-Hacks probiert, ohne Resultat. Erst danach hab ich das Problem mit dem BOM gefunden.
Die Suche erschwert hat die Tatsache, dass die Probleme im IE6 anders auftraten als im IE7, und eine paar der Fehler tauchten auch in Opera9 auf, aber nicht alle. Das kann einem dann schon einen Tag kosten.
Also ganz klare Aussage meinerseits: UTF prinzipiell nur ohne BOM. ❗
Gruß
Lothar
Hallo,
ist doch klar wenn du versch. templates oder css mit utf-8 & BOM speicherst hast du immer 2 Sonderzeichen in der Ausgabe falls du nicht diese z.B. mit PHP entfernst.
Mit dem Web Server kann das NULL zu tun haben da ein BOM für deine Client Anwendung (Internet Explorer) gedacht ist damit dieser utf-8 erkennt. Das encoding wird aber bereits per HTTP Header mitgeteilt oder notfalls mit META Tag.
Das encoding kannst du bei css auch im code angeben:
@charset ‘UTF-8’;
@Lothar
Deine Aussage ist so leider absolut falsch. Bei UTF-8 kein BOM aber UFT-16 etc… unbedingt mit BOM!
Hallo,
in meinem neuen WordPress-Projekt scheine ich in so eine BOM-Falle gelaufen zu sein: IE 6 und 7 stellen Buchstaben in Kombination mit Punktuationszeichen nicht korrekt dar. Und der BOM-Hinweis scheint mir am ehesten zu einer Lösung zu führen.
Nun stellt sich die Frage, wie man den/das BOM aus den Dateien entfernt? Ich habe mir nicht zuletzt aufgrund deiner Empfehlung den WeBuilder zugelegt – bin auch sehr zufrieden – finde aber da keinen Weg …
Kannst du oder ein Leser mir einen Tipp geben? Danke im Voraus fürs Lesen, beste Grüße
Raimund
@Raimund,
ich würde an deiner Stelle alle Template-Dateien des jeweiligen Themes öffnen und noch einmal abspeichern aber als UTF ohne BOM.
Hallo Perun,
manchmal sitzen mir doch die Tomaten auf den Augen … Dass im Save as-Dialog das noch mal gesetzt werden kann, war mir bisher völlig entgangen – Danke! Ich hoffe, dass das meine Probleme löst.
Raimund
hi perun,
danke für den hinweis. habe auch nochmal alle meine dateien überprüfen müssen. einzig bei der index-datei war kein utf ohne bom 😈
grüße
mayo
[…] Und bei utf-8 sollte man, wenn zur Auswahl angeboten wird, immer als utf-8 without BOM abspeichern. Warum dieses BOM nicht gut ist, habe ich vor mehr als vier Jahren beschrieben. Diesen Artikel […]