wget -k converte i file in modo diverso su Windows e Linux

Question

Ho GNU Wget 1.10.2 per Windows e Linux e l'opzione -k si comporta diversamente su quei due.

  

-k, --convert-links fa collegamenti nei file HTML scaricati a file locali.

Su Windows produce:

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

e su Linux produce:

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

Questo è problematico in Linux perché quando servo il mirror tramite Apache non distingue tra le 4 pagine generate poiché la parte dopo il punto interrogativo (? ) viene utilizzata come stringa di query per il file.

Qualche idea su come posso controllarlo?

grazie

Answer 1

Non è possibile utilizzare un punto interrogativo (?) in un nome file su NTFS o FAT32. Questo è il motivo per cui wget usa invece il simbolo at (@).

In Linux, solo una barra (/) è vietata sulla maggior parte dei filesystem, quindi wget usa il punto interrogativo (poiché fa parte dell'URI).

Puoi forzare entrambi i comportamenti usando --restrict-file-names=unix o --restrict-file-names=windows.

Dalla documentazione di wget:

  

Quando la modalità è impostata su & # 8220; unix & # 8221 ;, Wget   sfugge al carattere & # 8216; / & # 8217; e il   caratteri di controllo negli intervalli 0 & # 8211; 31   e 128 & # 8211; 159. Questa è l'impostazione predefinita attivata   Sistemi operativi simili a Unix.

     

Quando la modalità è impostata su & # 8220; windows & # 8221 ;, Wget   sfugge ai caratteri & # 8216; \ & # 8217 ;, & # 8216; | & # 8217 ;, & # 8216; / & # 8217 ;,   & # 8216;: & # 8217 ;, & # 8216;? & # 8217 ;, & # 8216; & Quot; & # 8217 ;, & # 8216; * & # 8217 ;, & # 8216; & Lt; & # 8217 ;, & # 8216; & Gt; & # 8217; e il   caratteri di controllo negli intervalli 0 & # 8211; 31   e 128 & # 8211; 159. Inoltre, Wget   in modalità Windows utilizza & # 8216; + & # 8217; invece di   # 8216 &; & # 8217; per separare host e porta in locale   nomi di file e utilizza & # 8216; @ & # 8217; invece di   # 8216 &;? & # 8217; per separare la porzione di query di   il nome del file dal resto.   Pertanto, un URL che verrebbe salvato   come   # 8216 &; & www.xemacs.org:4300/search.pl?input=blah # 8217;   in modalità Unix verrebbe salvato come   # 8216 &; & www.xemacs.org+4300/search.pl@input=blah # 8217;   in modalità Windows. Questa modalità è la   impostazione predefinita su Windows.

Answer 2

  

Questo è problematico in Linux perché quando servo il mirror tramite Apache non distingue tra le 4 pagine generate poiché la parte dopo il carattere punto interrogativo (?) viene utilizzata come stringa di query nel file.

Per includere un punto interrogativo in una parte del percorso URL, è possibile evitarlo:

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

--convert-links dovrebbe fare questo per te, penso & # 8201; & # 8212; & # 8201; in caso contrario potrebbe essere un bug

Answer 3

vedi --restrict-file-names=windows

Answer 4

  

Questo è problematico in Linux perché quando servo il mirror attraverso   Apache non distinguerà tra le 4 pagine generate dal   parte dopo il carattere punto interrogativo (?) viene utilizzata come stringa di query   al file.

Se è già tardi, questo comando sed mi ha aiutato:

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

Sostituisce? nei tag href = o src = con% 3F. (\ x27 è il segno di spunta singolo)