Sur cette page web http://taj.chass.ncsu.edu/Hindi.Less.05/dialog_script.html , firefox et opera fonctionnant sous windows et linux affichent le code source HTML parsemé de caractères incohérents (pour moi, ils apparaissent sous forme de losanges noirs avec des points d’interrogation), par opposition à une page Web rendue.
Parmi tous les navigateurs que j'ai essayés, seul Internet Explorer affiche correctement la page. J'aimerais beaucoup pouvoir utiliser le site Web avec Firefox sous Linux. Pour essayer d’afficher correctement la page, j’ai tenté de définir manuellement le codage des caractères sur chaque valeur disponible, mais sans succès. Avez-vous d'autres suggestions?
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:
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
charsetdevrait ê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écimaux3C 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.
la source