Man kann zwar manuell eine Codierung auswählen (und nicht vergessen, diese zu deaktivieren, wenn man eine andere Site besucht), aber die Website sollte sie tatsächlich korrekt angegeben haben. Entweder der Server oder die Webseiten selbst sollten etwas spezifizieren, sonst kann der Browser nur raten. Und natürlich, wenn eine Codierung wird angegeben, dann das HTML - Dokument sollte in der Tat , dass die Codierung verwenden. Nicht so sehr für die Website aus der Frage, wie unten gezeigt:
Um zu sehen, ob der Webserver etwas spezifiziert hat, muss man sich die sogenannten Header ansehen . Verwenden Sie den Onlinedienst von web-sniffer.net , um die Header anzuzeigen , die Sie erhalten:
HTTP / 1.1 200 OK
Datum: Montag, 17. August 2009, 17:47:03 Uhr GMT
Server: Apache
Letzte Änderung: Montag, 27. November 2006, 23:38:49 Uhr GMT
ETag: 758b0606-1a316-4234309151440
Accept-Ranges: Bytes
Inhaltslänge: 107286
Verbindung: schließen
Inhaltstyp: Text / HTML; Zeichensatz = utf-8 (Stückliste UTF-16, litte-endian)
Die letzte Zeile scheint etwas seltsam zu sein: Wie kann der Server behaupten, UTF-8 und UTF-16 zu sein? Der Wert für charsetsollte einer der bei IANA registrierten Werte sein (z. B. UTF-8 ohne Kommentare). Die Verwendung des Wireshark- Paketsniffers anstelle des Onlinedienstes zeigt jedoch, dass der Text (BOM UTF-16, litte-endian) tatsächlich ein Kommentar des Onlinedienstes ist, der nicht vom Webserver gesendet wird.
Also: Der Webserver gibt an, dass er uns ein UTF-8-codiertes HTML-Dokument senden wird.
Das folgende HTML-Dokument ist jedoch falsch (zur besseren Lesbarkeit bearbeitet):
ÿþ <! DOCTYPE html PUBLIC "- // W3C // DTD HTML 4.01 Transitional // DE">
<html>
<head>
<title> Lektion 5 </ title>
<meta http-equiv = "Inhaltstyp" content = "text / html; charset = utf-8">
<link href = "main.css" rel = "stylesheet" type = "text / css">
</ head>
...
Oben sollte die Zeile, die den Inhaltstyp angibt, die erste sein, die in <head>der angezeigt wird, da der Browser sonst nicht weiß, wie Sonderzeichen in der behandelt werden <title>. Noch wichtiger ist, dass die ersten beiden ungeraden Zeichen ÿþdie Hexadezimalcodes FF und FE sind, die, wie der bereits erwähnte Onlinedienst, die Byte-Ordnungsmarke für UTF-16 (Little Endian) sind.
Also: Der Webserver hat versprochen, UTF-8 zu senden, aber dann hat er Markierungen gesendet, die UTF-16 LE anzeigen. Als nächstes wird im HTML-Dokument behauptet, wieder UTF-8 zu verwenden.
In der Tat zeigt Wireshark, dass das eigentliche HTML-Dokument UTF-16-codiert ist. Dies bedeutet, dass jedes Zeichen mit mindestens zwei Bytes (Oktetts) gesendet wird. Wie die 6 Zeichen in <html>werden als 12 hexadezimale Bytes gesendet 3C 00 68 00 74 00 6D 00 6C 00 3E 00. Dies könnte jedoch sehr Website sehr gut reine ASCII gewesen sein, da es nicht scheint verwendet überhaupt keine Nicht-ASCII - Zeichen. Stattdessen enthält die HTML-Quelle zahlreiche numerische Zeichenverweise ( NCRs ), z. B . :
यह दिल्ली
शहर है।
Ein Browser zeigt das Obige als as यह्दिल शहर है है an. Aufgrund der Verwendung von NCRs und UTF-16 erfordert das Einzelzeichen य ( Unicode U + 092F ) jedoch bis zu 14 Byte 26 00 23 00 32 00 33 00 35 00 31 00 3B 00, da es mit NCR geschrieben wird, यwährend die 7 ASCII-Zeichen des NCR selbst mit UTF-16 codiert werden . Wenn Sie keine NCRs verwenden, benötigt dieses einzelne य in UTF-8 3 Bytes ( E0 A4 AF) und in UTF-16 zwei Bytes ( 09 2F).
Für diese HTML-Quelle bedeutet die Verwendung von UTF-16 eine völlige Verschwendung von Bandbreite, und der Server verwendet auch keine Komprimierung.