Firefox affiche les caractères d'ordures au lieu de la page Web

Sur cette page Web http://taj.chass.ncsu.edu/Hindi.Less.05/dialog_script.html , firefox et l'opéra fonctionnant sous Windows et linux affichent la source html entremêlée avec des caractères d'ordures (pour moi, elles apparaissent comme noires Des diamants avec des points d'interrogation), par opposition à une page Web rendue.

Sur tous les navigateurs que j'ai essayés, seul Internet Explorer affiche la page correctement. J'aimerais beaucoup pouvoir utiliser le site Web avec Firefox fonctionnant sous Linux. Afin d'essayer d'afficher correctement la page, j'ai tenté de définir manuellement le codage des caractères à chaque valeur disponible, mais je n'ai pas eu de succès. Vous avez d'autres suggestions?

Dans Firefox, utilisez

Affichage-> Codage de caractères-> Encodages supplémentaires-> UTF-16.

J'espère que cela pourra aider.

La plupart des textes informatiques sont codés sous forme d' ascii ou de 8 bits Unicode (UTF-8)

Pour plus d'informations sur UTF-16, vérifiez ici .

En général, si vous voyez le dans firefox, utilisez une "estimation intelligente" et essayez de modifier les encodages de caractères. Habituellement, cela fonctionne, parfois, en particulier avec linux firefox, vous pouvez rencontrer des problèmes de police.

Bien que l'on puisse effectivement choisir un certain encodage (et ne pas oublier de le désactiver en visitant un autre site), le site Web devrait l'avoir spécifié correctement. Le serveur ou les pages Web elles-mêmes devraient spécifier quelque chose, car sinon tout le navigateur peut faire est de mieux comprendre. Et bien sûr, si un encodage est spécifié, le document HTML devrait en fait utiliser ce codage. Pas tellement pour le site Web de la question, comme indiqué ci-dessous:

Pour voir si le serveur Web spécifiait quelque chose, il faut regarder les en- têtes dits. En utilisant le service en ligne de web-sniffer.net pour révéler les en-têtes que vous obtiendrez:

  HTTP / 1.1 200 OK

 Date: lundi 17 août 2009 17:47:03 GMT   
 Serveur: Apache  
 Dernière modification: lun. 27 nov. 2006 23:38:49 GMT   
 ETag: "758b0606-1a316-4234309151440"  
 Accepter-Gammes: octets   
 Contenu Longueur: 107286  
 Connexion: fermer   
 Content-Type: text / html;  Charset = utf-8 (BOM UTF-16, litte-endian)

La dernière ligne semble un peu bizarre: comment le serveur peut-il prétendre être à la fois UTF-8 et UTF-16? La valeur de charset devrait être l'une de celles enregistrées avec IANA (par exemple, UTF-8 sans aucun commentaire). Cependant, l'utilisation du sniffer de paquets Wireshark plutôt que le service en ligne révèle que le texte (BOM UTF-16, litte-endian) est en fait un commentaire du service en ligne, non envoyé par le serveur Web.

Ainsi: le serveur web prétend qu'il nous enverra un document HTML codé UTF-8.

Toutefois, le document HTML qui suit est incorrect (édité pour la lisibilité):

  Ÿþ <! DOCTYPE html PUBLIC "- // W3C // DTD HTML 4.01 Transitional // EN">
 <Html>
   <Tête>
     <Titre> Leçon 5 </ title>
     <Meta http-equiv = "Content-Type" content = "text / html; charset = utf-8">
     <Link href = "main.css" rel = "stylesheet" type = "text / css">
   </ Head>
 ...

Au-dessus, la ligne spécifiant le type de contenu devrait être la première à apparaître dans la <head> , sinon le navigateur ne saurait pas comment gérer des caractères spéciaux dans le <title> . Plus important encore, les deux premiers caractères étranges, ÿþ , sont en fait les codes hexadécimaux FF et FE, qui, comme le service en ligne déjà noté, est la marque d'ordre d'octet pour UTF-16, litte-endian.

Donc: le serveur web a promis d'envoyer UTF-8, mais il a envoyé des marqueurs qui indiquaient UTF-16 LE. Ensuite, dans le document HTML, il prétend utiliser UTF-8 à nouveau.

En effet, Wireshark montre que le document HTML actuel est codé par UTF-16. Cela implique que chaque caractère est envoyé en utilisant au moins deux octets (octets). Comme les 6 caractères dans <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 même pourrait très bien avoir été ASCII simple, car il ne semble pas utiliser tous les caractères non ASCII. Au lieu de cela, la source HTML est pleine de références numériques de caractères ( NCR ), telles que:

 &#2351;&#2361; &#2342;&#2367;&#2354;&#2381;&#2354;&#2368; &#2358;&#2361;&#2352; &#2361;&#2376;&#2404;

Un navigateur affiche ci-dessus comme यह दिल्ली शहर है .. Cependant, en raison de l'utilisation de NCR et UTF-16, le caractère unique य ( Unicode U + 092F ) nécessite jusqu'à 14 octets en 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 du NCR lui-même sont codés en utilisant UTF-16. Lorsque vous n'utilisez pas de NCR, dans UTF-8, cet य unique nécessiterait 3 octets ( E0 A4 AF ) et UTF-16 deux octets ( 09 2F ).

Pour cette source HTML utilisant UTF-16 est un gaspillage total de bande passante, et le serveur n'utilise pas non plus de compression.