Kommt Ihnen obiger Text bekannt vor? Manchmal gibt es Websites, Browser und Editoren in denen die verflixte codierung von Umlauten falsch angezeigt wird. Das verwenden der ¨ Syntax ist eigentlich obsolet. UTF-8 hat genug Platz um auch die abgefahrensten Zeichen codieren zu können.
Doch beginnen wir einmal von vorne. Eine UTF-8 Datei kann aber muss nicht mit einer vorgestellten byte-order-mark (BOM) markiert sein. Visual Studio 2010 kann dies über Optionen beim speichern realisieren.
Wenn man das erkannt hat, ist es natürlich leicht die Datei mit BOM zu speichern. Aber erstens gibt es Empfehlungen auf BOM zu verzichen und zweitens erkennen das manche Editoren nicht richtig. So sieht die Datei mit Notepad geöffnet richtig aus, weil ich ein deutsches OS verwende.
Im Browser siehts komischerweise am selben System ganz anders aus.
Auch nicht schön und doch seiht man das täglich, weil die Einstellungen des Webservers Auswirkung haben können. Wenn un der Admin ein neues System aufsetzt kann die Website solcherart verunstaltet sein.
Ein möglicher Workaround ist in der web.config einfach die Codierung einzustellen und so den IIS zu motivieren mitzuteilen welche codierung er verwendet.
UTF-8 without siganute Codepage 65001 im Chrome Browser
Die gleiche ASPX Seite mit folgender Änderung in Web.config. Wesentlich ist das FileEncoding Attribut.
<globalization fileEncoding="utf-8"
requestEncoding="utf-8" responseEncoding="utf-8"
culture="auto" uiCulture="auto"
Alternativ gibt es auch die Möglichkeit per Metatag dem Browser mitzuteilen welches Encoding vorliegt.
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
Auch das funktioniert. Wenn ein Benutzer mit einem anderen Editor die Seiten aufruft, ist allerdings der Ärger vorprogrammiert. Daher auch die Motivation für den Artikel. Manche von unseren Marketing Mitarbeitern editieren die Websites mit Expression Web 4.
Der beobachtet Effekt ist, das die Umlaute in der Seite durch seltsame Zeichen ersetzt werden und Expression Web die Größe der Website vervielfacht mit jedem öffnen und speichern Vorgang, Man findet zu diesem Problem unzählige Postings im Web. Nun halte ich das durchaus für einen Fehler, den man allerdings elegant umgehen kann. Nur um das festzuhalten. Der Fehler tritt auf, wenn die HTML oder ASPX Datei ohne BOM angelegt wurde. Expressen Web erzeugt die BOM entsprechend seiner Einstellungen in den Page Editor Optionen mit Signatur, den HTML Entitäten für die Umlaute und dem Meta Tag. Sozusagen dreifach gesichert. Das Problem entsteht wenn man per Datei oder FTP Zugriff eine UFT-8 codierte Datei ohne mit einem englischen Expression Blend öffnet. Expression Web ändert die Codierung nicht und erzeugt kein BOM.
Die gleiche Datei mit Visual Studio 2010 geöffnet wird so angezeigt wie erwartet, also korrekt. Der Meta Tag Content-type verhindert diesen Effekt. Entsprechend mein Tipp immer den Metatag (eventuell in Master Page) einbauen wenn mit Visual Studio und Expression Web gemischt an der Web Präsenz gearbeitet wird.
Ganz böse geht das ganze aus, wenn sich die Encodings wiedersprechen (Meta, Web.config und BOM) und man diese Dateien in verschiedenen Editoren öffnet. Dann ist die Datei auch schon mal korrupt und muss vom Backup zurück gespielt werden.