wget -k convertit les fichiers différemment sous Windows et Linux

StackOverflow https://stackoverflow.com/questions/629831

  •  08-07-2019
  •  | 
  •  

Question

J'ai GNU Wget 1.10.2 pour Windows et Linux et l'option -k se comporte différemment sur ces deux systèmes.

  

-k, --convert-links crée des liens HTML téléchargés vers des fichiers locaux.

Sous Windows, cela produit: 

www.example.com/index.html
www.example.com/index.html@page=about
www.example.com/index.html@page=contact
www.example.com/index.html@page=sitemap

et sur linux cela produit: 

www.example.com/index.html
www.example.com/index.html?page=about
www.example.com/index.html?page=contact
www.example.com/index.html?page=sitemap

Cela est problématique sous Linux car lorsque je sers le miroir via Apache, il ne fera pas la distinction entre les 4 pages générées, car la partie située après le caractère d'interrogation (? ) est utilisée comme chaîne de requête du fichier.

Avez-vous des idées sur la façon dont je peux contrôler cela?

merci

Était-ce utile?

La solution

Vous ne pouvez pas utiliser de point d'interrogation (?) dans un nom de fichier sous NTFS ou FAT32. C'est pourquoi wget utilise à la place le symbole at (@).

Sous Linux, seule la barre oblique (/) est interdite sur la plupart des systèmes de fichiers. wget utilise donc le point d'interrogation (car il fait partie de l'URI).

Vous pouvez forcer l'un ou l'autre comportement en utilisant --restrict-file-names=unix ou --restrict-file-names=windows.

À partir de la documentation wget:

  

Lorsque le mode est défini sur & # 8220; unix & # 8221 ;, Wget   échappe au caractère & # 8216; / & # 8217; et le   Caractères de contrôle dans les plages 0 & # 8211; 31   et 128 & # 8211; 159. C'est la valeur par défaut sur   Système d'exploitation de type Unix.

     

Lorsque le mode est défini sur & # 8220; windows & # 8221 ;, Wget   échappe aux caractères & # 8216; \ & # 8217 ;, & # 8216; | & # 8217 ;, & # 8216; / & # 8217 ;,   & # 8216;: & # 8217 ;, & # 8216;? & # 8217 ;, & # 8216; & "; & # 8217 ;, & # 8216; * & # 8217 ;, & # 8216; & Lt; & # 8217 ;, & # 8216; & Gt; & # 8217 ;, et le   Caractères de contrôle dans les plages 0 & # 8211; 31   et 128 & # 8211; 159. En plus de cela, Wget   en mode Windows utilise & # 8216; + & # 8217; au lieu de   & # 8216;: & # 8217; séparer l'hôte et le port en local   noms de fichiers et utilise & # 8216; @ & # 8217; au lieu de   & # 8216;? & # 8217; pour séparer la partie requête de   le nom du fichier du reste.   Par conséquent, une URL qui serait enregistrée   comme   & # 8216; www.xemacs.org:4300/search.pl?input=blah & # 8217;   en mode Unix serait enregistré en tant que   & # 8216; www.xemacs.org+4300/search.pl@input=blah & # 8217;   en mode Windows. Ce mode est le   par défaut sous Windows.

Autres conseils

  

Ceci est problématique sous Linux car lorsque je sers le miroir via Apache, il ne fera pas la distinction entre les 4 pages générées, car la partie située après le caractère questionmark (?) est utilisée comme chaîne de requête dans le fichier.

Pour inclure un point d'interrogation dans une partie du chemin de l'URL, vous pouvez l'échapper: 

www.example.com/index.html%3Fpage=about

- convert-links devrait le faire pour vous, je pense que & # 8201; & # 8212; & # 8201; peut être un bug si ce n'est pas le cas.

  

Ceci est problématique sous linux car quand je sers le miroir via   Apache, il ne fera pas la distinction entre les 4 pages générées depuis le   une partie après le caractère questionmark (?) est utilisée comme chaîne de requête   vers le fichier.

S'il est déjà trop tard, cette commande sed m'a aidé: 

find . -type f -name "*html*" -exec sed -i -r 's/(src|href)=(["\x27])(.*?)(\?)(.*?)\2/\1=\2\3%3F\5\2/g' {} +

Il remplace? dans href = ou src = balises avec% 3F. (\ x27 est le tick simple)

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top