dedlfix: Charset UTF-8 Problem

Beitrag lesen

Hi!

Im Fall einer Ajax-Response jedoch, kann die charset-Angabe im Header durchaus als Pragma (unverbindlich) betrachtet werden, wenn eine transparente Übertragung sicherstellt, dass die Codierung der Zeichen nicht verändert wird.

Nur wenn man sich darauf verlässt, dass das Ziel schon alles so wie vorgestellt machen wird, kann man auf konkrete und verbindliche Angaben verzichten.

Fall 1: Das Zeichen wird als 'ä' übertragen, hier muss die Codierung im Ajax-Response-Header mitgegeben werden. Ein Header Content-Type: text/plain; charset=UTF-8 ist somit verbindlich.

Einfach und verbindlich für beide Seiten.

Fall 2: Das Zeichen 'ä' wird serverseitig als %C3%A4 encodet in die Ajax-Response gegeben. In diesem Fall ist die charset-Angabe im HTTP-Header der Ajax-Response unverbindlich, also nur noch ein Pragma.

Das kann ich nicht so sehen. Die charset-Angabe ist weiterhin verbindlich, denn auch %, C, 3, A und 4 werden durch bestimmte Bytes repräsentiert, die es richtig zu interpretieren gilt. Sie ist nur dann egal, wenn man Kodierungen verwendet, die im ASCII-Bereich gleich arbeiten. Das machen aber nicht alle (asiatischen) Kodiersysteme so. Sie verwenden teilweise die Bytes von x00 bis x7F anders oder in Kombination mit anderen Bytes, um andere Zeichen zu repräsentieren. Dein Ignorieren der charset-Angabe funktioniert nur im westlichen Kulturkreis problemlos. Die Ausnahmen mögen für deine Anwendungsfälle nicht relevant sein, zeigen jedoch einen prinzipiellen Fehler bei dieser Vorgehensweise.

Und warum willst du überhaupt in dem Fall URL-kodierte Daten senden? Weil du keine Lust hast, die Zeichenkodierung korrekt zu verwenden und anzugeben? Du nimmst lieber den Umweg und die damit verbundene erhöhte Komplexität in Kauf, noch eine Kodierung obendrauf zu setzen.

Erläuterung: Das Encoding im Fall 2 heißt URI-Escape, damit wird die Übertragung in den transparent mode geschaltet.

Damit schaltest du nichts, damit begibst du dich nur, wie gesagt, auf einen unnötigen Umweg.

Die Charset-Angabe im HTTP-Header kann in diesem Fall entfallen oder anders lauten.

Beliebig darf sie schon gar nicht sein und wenn du sie weglässt, verlässt du dich auf eine Default-Konfiguration des Browsers oder ein richtiges Raten seinerseits.

Transparent mode heißt technisch gesehen: Die Übertragung findet in einer 8-Bit-Umgebung statt, alle zu übertragenden Zeichen sind so encodet, dass im gesamten Content nur noch Zeichen sind, die 7 Bit benötigen (US-ASCII). Feilich muss in einem solchen Fall das URI-Escape im DOM wieder rückgängig gemacht werden, dazu gibt es die Funktionen decodeURI() und decodeURIComponent().

Umständlich und trotzdem nicht richtig, zeigt nur zufällig das gewünschte Verhalten.

URI-Escape ist keineswegs nur eine Spielerei.

Wenn man sie an der richtigen Stelle verwendet. Natürlich kann man sie auch an anderen, ursprünglich nicht vorgesehenden Stellen verwenden und wird bei richtiger Anwendung ein gewünschtes Ergebnis erzielen. Die Frage ist nur, ob das wirklich notwendig ist?

Für die Übertragung multipler Contents nach dem MIME-Standard in einer Ajax-Response ist der transparent mode, sichergestellt mit URI-Escape, von größter Bedeutung.

Achwas. Man kann es auch einfacher richtig machen.

Ab sofort auf der verlinkten Seite nachzulesen, Du bist schuld ;-)

Danke, lieber nicht.

Lo!