encodage utf-8 - je ne peux pas lire le HTML
Chers membres de la communauté,
j'essayais d'ouvrir la page amazon.co.uk de la manière suivante mais sans succès :
Names Default To Here( 1 );
webpage= Load Text File ("https://www.amazon.co.uk");
voici ce que j'obtiens dans le log :
JMP could not read all the text in 'www.amazon.co.uk' correctly.
The document might use a text encoding that JMP does not recognize; or JMP might have chosen the wrong encoding (utf-8). Text that JMP could not understand has been removed. The JMP character set preference is set to utf-8.
The location of the first read error is 4 and the byte at that location was 0. <BR /><BR />"��t������ ��`��L&��dv'�B^�V��f��<BR />�;�焎�3�=�wEG1E�����p��������!���m��X�f{����$�f���6=�ٓί�g!(j<BR />�ŨI*|T�M�[ٗ�\!"��HA��\��Y�$o������&����P����*K&�;\!"��C��G^b��� E�i J����f:{{�!7(G�A��U���z+�7�D�<�7U�Y<BR /><BR />......<BR />
si j'essaie la même commande avec amazon.com, tout va bien.
J'ai vérifié le code HTML de la page et il semble que ce soit le cas environ 7 fois. donc je suppose que c'est utf-8
meta charset="utf-8"
a également essayé de modifier les préférences Fichier de données texte >> Ouvrir le jeu de caractères du fichier texte >> Meilleure estimation mais cela ne fonctionne toujours pas
serait reconnaissant pour toutes les idées.
</CODE></P>
<P> </P>
<P> </P>
<P> </P></LINGO-BODY><LINGO-LABS id="lingo-labs-707036" slang="en-US" mode="NONE"><LINGO-LABEL>Accès aux données</LINGO-LABEL><LINGO-LABEL>les fenêtres</LINGO-LABEL></LINGO-LABS><LINGO-SUB id="lingo-sub-707056" slang="en-US" mode="NONE">Re : Encodage UTF-8 - Impossible de lire le HTML</LINGO-SUB><LINGO-BODY id="lingo-body-707056" slang="en-US" mode="NONE"><P>Intéressant. Amazon compresse les données. Deux façons de résoudre ce problème : la nouvelle méthode de requête http vous permet de vérifier si elle est compressée :</P>
<PRE><CODE class=" language-jsl">webpage = Load Text File( "https://www.amazon.co.uk", blob() );
webpage = Blob To Char( Gzip Uncompress( webpage ) );
Write( webpage );
// the better way...
request = New HTTP Request( URL( "https://www.amazon.co.uk" ), Method( "GET" ) );
fetch = request << Send;
Show( (request << Get Response Headers)["content-encoding"] );// gzip
webpage = Blob To Char( Gzip Uncompress( fetch ) );
Write( webpage );
Re : Encodage UTF-8 - Impossible de lire le HTMLMerci les experts !

Re : Encodage UTF-8 - Impossible de lire le HTMLLa ligne 1 crée un objet HTTP Request et le place dans la variable de requête. L'URL d'Amazon se trouve dans les données de l'objet, mais aucune communication n'a encore eu lieu, donc l'objet de requête ne sait pas ce qui va se passer.
La ligne 2 envoie la requête GET à Amazon ; la partie charge utile de la réponse d'Amazon est copiée dans la variable fetch. Vous verrez une note dans le journal indiquant qu'un blob a été stocké car les données étaient des données binaires plutôt que du Unicode approprié. Il existe également d'autres métadonnées d'Amazon ; les en-têtes renvoyés par Amazon sont conservés dans l'objet HTTP Request.
La ligne 3 imprime une valeur à partir des en-têtes stockés, en particulier l'en-tête de codage de contenu. Cela doit avoir plus de logique if(...) pour tester s'il existe un en-tête de codage de contenu dans le tableau associatif, puis si sa valeur est "gzip" avant de choisir de décompresser la charge utile.
La ligne 4 dépend de la récupération contenant un blob gzippé pour la charge utile. Cela dépend ensuite du fait que les données binaires qui ont été décompressées soient UTF-8 valides et peuvent être converties en caractères.
La ligne 5 imprime toutes les données utiles ; il y en a beaucoup et JMP le tronquera dans le journal si vous ne l'écrivez pas explicitement (...).
Re : Encodage UTF-8 - Impossible de lire le HTMLJ'ai envoyé une note à l'équipe d'assistance. Je pense que JMP aurait dû gérer cela, soit avec un meilleur message, soit en détectant la compression et en effectuant les étapes supplémentaires. C'est peut-être un peu problématique, mais cela fonctionnerait jusqu'à ce que quelque chose d'autre que du texte gzippé apparaisse... probablement à 99 %.