bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] patch: Stored file name coversion logic correction


From: YX Hao
Subject: Re: [Bug-wget] patch: Stored file name coversion logic correction
Date: Thu, 16 Feb 2017 12:42:23 +0800 (CST)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]