[Bug-wget] Discussion for [PATCH] Add-local-filesystem-encoding-options

[Bykov Aleksey]

Greetings all.

Please leave Your's suggestion, commentaries or anything other about this
variant of patch to SUBJ.

* Solves - http://savannah.gnu.org/bugs/?37564 and
http://savannah.gnu.org/bugs/?27126 Some discussion at
http://lists.gnu.org/archive/html/bug-wget/2012-10/msg00041.html thread.
* Application range - mostly non-English Win32 system (Sorry, don't now,
how in other systems. At least *nix easily read filenames in UTF-8).
* Description and backgrounding - in Win32 systems yet using filesystems
with limitation of chars and one-byte text encoding (Win32 filesystem do
not support UTF-8). So tries to download file with national char in name
give two variants of result (example URL - "http://www.apexx.ru/Logo
текст.jpg". To download need "--local-encoding=CP1251")
1) as default - "Logo С%82екС%81С%82" - (can be recieved in *nix by
"LANG=C ls" in folder with national filenames)
2) with "--restrict-file-names=windows,ascii" it gave URI-encoded name
("Logo %D1%82%D0%B5%D0%BA%D1%81%D1%82.jpg" that is unreadable and often
break filesystem rule "max 256 char to full filename" )
After implementing that path with option
"--local-filesystem-encoding=CP1251" result is "Logo текст.jpg"
* Principe - during parsing of filename tries to convert it to given
encoding. If successful, use converted name.
* Testing status - looks like work. Tested by me and by men, that
(ask?)/(bespod?) it. Standard function unharmed. Tested both in
single-file and recursive mode.
* Possible limitation - now "--local-filesystem-encoding" enabled if
"--local-encoding" option is present (and set to it's value). For Win32
system this is normal (because command prompt and filesystem encoding is
same). But how it will work in other systems?

Thanks in advise
Sorry for bad English.

--
Best regars, Alex

0001-Add-local-filesystem-encoding-options.patch
Description: Binary data