Hi Tim, I downloaded the 'mbox format' original, and found out the reason why you can't reproduce the issue. The non-ASCII characters you use is encoded in "iso-8859-1" in your email, and should be displayed correctly in your environment. So, your encoding is compatible with 'UTF8', which is the remote server's default encoding. That won't cause iconv error :) Think about 'UFT8' incompatible encoding envrionments ...
Regards, YX Hao -------------------------------------------------------------------------------- >Hi Tim, > >First, sorry for not subscribing the mailing lists. The reply is formatted >manually, trying to keep the style :) > >>> Hi there, >>> >>> >>> >>> I got this on a non-ASCII environment. The local path contains non-ASCII >>> characters with OEM ANSI encoded. So, we should convert the server responded >>> file name before it is concatenated to the local path. Not after that. Or, >>> it will cause error in the next 'iconv' function . >> >>Hi, >> >>sounds reasonable, but please provide further info to reproduce the issue. >> >>I have a non-ASCII environment as well, and moved the whole Wget project into >>some non-ASCII subdirectory (äöü/). At least some of the *-iri-* should have >>failed, but all succeeded. >> >Platform: Windows, console code page is 936 >'wget -V': >" >GNU Wget 1.19.1 built on mingw32. >-cares +digest -gpgme +https +ipv6 -iri +large-file -metalink -nls >+ntlm +opie -psl +ssl/openssl >" >iconv: win-iconv > >Attaching compiled file is not a good idea. And you are on Linux. Others can >get a substitute from https://eternallybored.org/misc/wget/ . >And a screenshot is attached :) > >>Btw, your patch introduces a memory leak (fname_len_check will be >>overwritten). And what about the 'else' case ? >> >I think: >'convert_fname' function will free the original memory when succeed. Same as >'fname' converted. leak? >If 'replaced_filename' is provided, get the 'else' case, it is the local >encoding and not need conversion. > >>Regards, Tim > >Regards, >YX Hao