Bien que l’on puisse effectivement choisir manuellement un codage (sans oublier de le désactiver lors de la visite d’un autre site), le site Web aurait dû le spécifier correctement. Le serveur ou les pages Web elles-mêmes doivent spécifier quelque chose, sinon le navigateur ne peut que deviner. Et bien sûr, si un encodage est spécifié, le document HTML doit en fait utiliser ce codage. Pas tellement pour le site Web de la question, comme indiqué ci-dessous:
Pour voir si le serveur Web a spécifié quelque chose, il faut regarder le soi-disant en-têtes . Utilisation du service en ligne de web-sniffer.net pour révéler les en-têtes que vous obtiendrez:
HTTP/1.1 200 OK
Date: Mon, 17 Aug 2009 17:47:03 GMT
Server: Apache
Last-Modified: Mon, 27 Nov 2006 23:38:49 GMT
ETag: "758b0606-1a316-4234309151440"
Accept-Ranges: bytes
Content-Length: 107286
Connection: close
Content-Type: text/html; charset=utf-8 (BOM UTF-16, litte-endian)
La dernière ligne semble un peu étrange: comment le serveur peut-il prétendre que quelque chose est à la fois UTF-8 et UTF-16? La valeur pour charset devrait être l'un de ceux inscrit avec IANA (donc, par exemple, UTF-8 sans aucun commentaire). Cependant, en utilisant le Wireshark renifleur de paquets plutôt que le service en ligne révèle que le texte (BOM UTF-16, little-endian) est en fait un commentaire du service en ligne, non envoyé par le serveur Web.
Ainsi: le serveur Web affirme qu'il va nous envoyer un document HTML codé en UTF-8.
Cependant, le document HTML qui suit est incorrect (modifié pour la lisibilité):
ÿþ<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Lesson 5</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link href="main.css" rel="stylesheet" type="text/css">
</head>
...
Ci-dessus, la ligne spécifiant le type de contenu doit être la première à apparaître dans la liste. <head>sinon, le navigateur ne saurait pas comment traiter les caractères spéciaux dans le <title>. Plus important encore, les deux premiers personnages impairs, ÿþ, sont en fait les codes hexadécimaux FF et FE qui, comme le service en ligne déjà noté, sont Byte-Order Mark pour UTF-16, little-endian.
Ainsi: le serveur Web a promis d’envoyer UTF-8 mais il a ensuite envoyé des marqueurs indiquant UTF-16 LE. Ensuite, dans le document HTML, il prétend utiliser à nouveau UTF-8.
En effet, Wireshark montre que le document HTML réel est codé en UTF-16. Cela implique que chaque caractère est envoyé en utilisant au moins deux octets (octets). Comme les 6 personnages de <html> sont envoyés en tant que 12 octets hexadécimaux 3C 00 68 00 74 00 6D 00 6C 00 3E 00. Cependant, ce site Web aurait très bien pu être en ASCII, car il ne semble pas utilisation des caractères non-ASCII du tout. Au lieu de cela, la source HTML est pleine de références de caractères numériques ( RCN ), tel que:
यह दिल्ली
शहर है।
Un navigateur affiche ce qui précède sous la forme de दिल्ली शहर है।. Cependant, en raison de l'utilisation des NCR et de l'UTF-16, le caractère unique ( Unicode U + 092F ) nécessite jusqu’à 14 octets dans 26 00 23 00 32 00 33 00 35 00 31 00 3B 00, car il est écrit en utilisant NCR य tandis que les 7 caractères ASCII de la NCR elle-même sont codés en UTF-16. Lorsque vous n’utilisez pas de NCR, en UTF-8, ce seul single nécessiterait 3 octets ( E0 A4 AF ) et en UTF-16 deux octets ( 09 2F ).
UTF-16 représente une perte totale de bande passante pour cette source HTML, et le serveur n’utilise aucune compression non plus.