wget -k convierte archivos de manera diferente en Windows y Linux

Question

Tengo GNU Wget 1.10.2 para Windows y Linux y la opción -k se comporta de manera diferente en esos dos.

  

-k, --convert-links hacen que los enlaces en HTML descargado apunten a archivos locales.

En 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

y en 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

Esto es problemático en Linux porque cuando sirvo el espejo a través de Apache, no distinguirá entre las 4 páginas generadas, ya que la parte posterior al carácter de signo de interrogación (? ) se utiliza como la cadena de consulta para archivo.

¿Alguna idea sobre cómo puedo controlar esto?

gracias

Answer 1

No puede usar un signo de interrogación (?) en un nombre de archivo en NTFS o FAT32. Es por eso que wget utiliza el símbolo at (@) en su lugar.

En Linux, solo una barra diagonal (/) está prohibida en la mayoría de los sistemas de archivos, por lo que wget usa el signo de interrogación (ya que es parte del URI).

Puede forzar cualquier comportamiento utilizando --restrict-file-names=unix o --restrict-file-names=windows.

De la documentación de wget:

  

Cuando el modo se establece en & # 8220; unix & # 8221 ;, Wget   escapa del carácter & # 8216; / & # 8217; y el   caracteres de control en los rangos 0 & # 8211; 31   y 128 & # 8211; 159. Este es el valor predeterminado en   Sistemas operativos tipo Unix.

     

Cuando el modo se establece en & # 8220; windows & # 8221 ;, Wget   escapa a los caracteres & # 8216; \ & # 8217 ;, & # 8216; | & # 8217 ;, & # 8216; / & # 8217 ;,   & # 8216;: & # 8217 ;, & # 8216;? & # 8217 ;, & # 8216; & Quot; & # 8217 ;, & # 8216; * & # 8217 ;, & # 8216; & Lt; & # 8217 ;, & # 8216; & Gt; & # 8217 ;, y el   caracteres de control en los rangos 0 & # 8211; 31   y 128 & # 8211; 159. Además de esto, Wget   en modo Windows usa & # 8216; + & # 8217; en vez de   & # 8216;: & # 8217; para separar host y puerto en local   nombres de archivo y utiliza & # 8216; @ & # 8217; en vez de   & # 8216;? & # 8217; para separar la parte de consulta de   El nombre del archivo del resto.   Por lo tanto, una URL que se guardaría   como   & # 8216; www.xemacs.org:4300/search.pl?input=blah & # 8217;   en modo Unix se guardaría como   & # 8216; www.xemacs.org+4300/search.pl@input=blah & # 8217;   en modo Windows Este modo es el   predeterminado en Windows.

Answer 2

  

Esto es problemático en Linux porque cuando sirvo el espejo a través de Apache, no distinguirá entre las 4 páginas generadas, ya que la parte posterior al carácter de signo de interrogación (?) se usa como la cadena de consulta del archivo.

Para incluir un signo de interrogación en una parte de la ruta URL, puede escapar:

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

--convert-links debería estar haciendo esto por usted, creo que & # 8201; & # 8212; & # 8201; puede ser un error si no.

Answer 3

vea --restrict-file-names=windows

Answer 4

  

Esto es problemático en Linux porque cuando sirvo el espejo a través de   Apache no distinguirá entre las 4 páginas generadas ya que   parte después del carácter de signo de interrogación (?) se utiliza como la cadena de consulta   al archivo.

Si ya es demasiado tarde, este comando sed me ayudó:

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

¿Reemplaza? en href = o src = etiquetas con% 3F. (\ x27 es la marca única)