J'utilise wget pour télécharger une page html statique. Le validateur W3C m'indique que la page est encodée en UTF-8. Pourtant, lorsque je cat le fichier après le téléchargement, je reçois un tas de bêtises binaires. Je suis sur Ubuntu, et je pensais que l'encodage par défaut était UTF-8? C'est ce que mon fichier de paramètres régionaux semble dire. Pourquoi cela se produit-il et comment puis-je le corriger?
Aussi, ressemble Content-Encoding: gzip. Peut-être que cela fait un diff?
Voici la simple demande:
wget https://www.example.com/page.html
J'ai également essayé ceci:
wget https://www.example.com/page.html -q -O - | iconv -f utf-16 -t utf-8 > output.html
Qui a renvoyé: iconv: illegal input sequence at position 40
cat'ing le fichier retourne un binaire qui ressemble à ceci:
l�?חu�`�q"�:)s��dġ__��~i��6n)T�$H�#���QJ
Résultat de xxd output.html | head -20:
00000000: 1f8b 0800 0000 0000 0003 bd56 518f db44 ...........VQ..D
00000010: 107e a6bf 62d4 8a1e 48b9 d8be 4268 9303 .~..b...H...Bh..
00000020: 8956 082a 155e 7a02 21dd cbd8 3bb6 97ae .V.*.^z.!...;...
00000030: 77cd ee38 39f7 a1bf 9d19 3bb9 0bbd 9c40 w..89.....;....@
00000040: 2088 12c5 de9d 9df9 be99 6f67 f751 9699 .........og.Q..
00000050: 500d 1d79 5eee a265 faec 7151 e4ab 6205 P..y^..e..qQ..b.
00000060: 4dd3 0014 1790 e7d0 77c0 ef2f cbf8 cde3 M.......w../....
00000070: cf1f 7d6c 7d69 ec16 d0d9 c67f 7d7d 56c9 ..}l}i......}}V.
00000080: 04c5 eb33 35fc e49e 2563 e908 ca10 0d45 ...35...%c.....E
00000090: 31ce afcf a022 e77a 34c6 fa46 46be d88f 1....".z4..FF...
000000a0: a41e ab79 446d 76d6 702b cf45 9e7f ba77 ...yDmv.p+.E...w
000000b0: 7dc2 779c 274e cc18 483c 3a12 0f75 f07c }.w.'N..H<:..u.|
000000c0: 5e63 67dd b886 ab48 e550 b5c4 f0e3 db0d ^cg....H.P......
000000d0: 54c1 85b8 8627 2ff3 2ff3 17f9 0626 d31d T....'/./....&..
000000e0: d9a6 e5b5 4076 663f 94ec 7b5a 17cf 7ade ....@vf?..{Z..z.
000000f0: 00d3 0d9f 4fcc d733 ef8d a0bb 0a06 c7eb ....O..3........
00000100: b304 6fb1 b1cc 18ed 90e0 8710 43aa 424f ..o.........C.BO
00000110: 50c7 d0c1 2bac 09be 4d1c 2566 335e 666c P...+...M.%f3^fl
00000120: 1e20 951d 58fd 6774 f3e9 f317 749f 7fc4 . ..X.gt....t...
00000130: d651 cdca f5a7 b0a5 aea4 08ab 055c e4c5 .Q...........\..
Aussi, étrangement, le fichier de sortie semble s'ouvrir correctement dans TextWrangler!
la source
xxd dubious.file| tête -20` et l'inclure comme une mise à jour.Réponses:
Il s'agit d'un fichier compressé gzip . Vous pouvez le découvrir en exécutant la
filecommande, qui détermine le format de fichier à partir des nombres magiques dans les données (c'est ainsi que des programmes tels que Text Wrangler déterminent que le fichier est également compressé):Le serveur (je l'ai deviné à partir du contenu que vous avez montré) envoie des données compressées et définit correctement l'en-tête
mais wget ne supporte pas cela. Dans les versions récentes, wget envoie
Accept-encoding: identity, pour dire au serveur de ne pas compresser ou autrement encoder les données. Dans les anciennes versions, vous pouvez envoyer l'en-tête manuellement:Cependant, ce serveur particulier semble être en panne: il envoie des données compressées même lorsqu'on lui dit de ne pas coder les données de quelque manière que ce soit. Vous devrez donc décompresser les données manuellement.
la source
gunzipdiriger de la même manière que vous le faitesfile, si vous ne voulez pas stocker un temporaire. Vous voudrez peut-être passer-cou--to-stdout(ou l'appeler commezcat) pour l'insérer dans le pipeline de la question, entrewgeteticonv.Ce fichier est toujours compressé avec
gzip.Vous pouvez voir que les deux premiers octets 0x1f8b correspondent à la
gzipsignature . Donc, pour lire les données, vous devez les décompresser.Ou
la source