Zwar kann man tatsächlich eine Kodierung manuell auswählen (und nicht vergessen, diese bei einem Besuch einer anderen Website zu deaktivieren), aber eigentlich sollte die Website sie richtig angegeben haben. Entweder der Server oder die Webseiten selbst sollten etwas angeben. Andernfalls kann der Browser nur bestens 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 angegeben hat, muss man sich die sogenannten Header ansehen . Verwenden Sie den Onlinedienst von web-sniffer.net, um die Kopfzeilen anzuzeigen, die Sie erhalten:
HTTP / 1.1 200 OK Datum: Mo, 17 Aug 2009 17:47:03 GMT Server: Apache Zuletzt geändert: Mo, 27 Nov 2006 23:38:49 GMT ETag: 758b0606-1a316-4234309151440 Accept-Ranges: Bytes Inhaltslänge: 107286 Verbindung: schließen Inhaltstyp: Text / HTML; Zeichensatz = utf-8 (BOM UTF-16, kleiner Endian)
Die letzte Zeile scheint etwas seltsam: Wie kann der Server behaupten, sowohl UTF-8 als auch UTF-16 zu sein? Der Wert für charsetsollte einer der bei IANA registrierten sein (also beispielsweise UTF-8 ohne Kommentare). Die Verwendung des Wireshark Packet Sniffer anstelle des Onlinedienstes zeigt jedoch, dass der Text (BOM UTF-16, litte-endian) tatsächlich ein Kommentar des Onlinedienstes ist und nicht vom Webserver gesendet wird.
Also: Der Webserver behauptet, dass er uns ein UTF-8-kodiertes 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> <Kopf> <title> Lektion 5 </ title> <meta http-equiv = "Content-Type" 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. Andernfalls kann der Browser nicht mit Sonderzeichen im Code umgehen <title>. Wichtiger noch, die ersten beiden ungeraden Zeichen ÿþsind in der Tat die Hexadezimal-Codes FF und FE, die, wie bereits erwähnt, der Byte-Order Mark für UTF-16 (Litte-Endian) sind.
Also: Der Webserver versprach, UTF-8 zu senden, sendete dann aber Markierungen, die auf UTF-16 LE hindeuteten. Als nächstes behauptet es im HTML-Dokument, UTF-8 erneut zu verwenden.
Tatsächlich 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 <html>werden die 12 hexadezimalen 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 numerische Zeichenreferenzen ( NCRs ), z.
यह दिल्ली शहर है।
Ein Browser zeigt das oben als यह दिल्ली शहर है। an. Aufgrund der Verwendung von NCRs und UTF-16 erfordert das einzelne Zeichen य ( 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 keine NCRs verwendet werden, würde diese einzelne 3 in UTF-8 3 Byte ( E0 A4 AF) und in UTF-16 zwei Byte ( 09 2F) erfordern .
Für diese HTML-Quelle, die UTF-16 verwendet, ist insgesamt Bandbreite verschwendet, und der Server verwendet auch keine Komprimierung.