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: Tim Ruehsen
Subject: Re: [Bug-wget] patch: Stored file name coversion logic correction
Date: Thu, 16 Feb 2017 13:04:09 +0100
User-agent: KMail/5.2.3 (Linux/4.9.0-1-amd64; KDE/5.28.0; x86_64; ; )

On Thursday, February 16, 2017 4:10:22 PM CET YX Hao wrote:
> My bad! I made a stupid mistake!
> Then, how can Tim's case pass the 'iconv' function? Maybe the
> 'from_encoding' in 'convert_fname' function is the same as the
> 'to_encoding'. Did he download from a same encoding server???
> 在2017年02月16 14时07分, "Eli Zaretskii"<address@hidden>写道:
> > Date: Thu, 16 Feb 2017 12:42:23 +0800 (CST)
> > From: "YX Hao" <address@hidden>
> > 
> > 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 ...
> 
> Maybe I misunderstand, but ISO-8859-1 (a.k.a. "Latin-1") is NOT
> compatible with UTF-8.  Trying to decode Latin-1 text as UTF-8 will
> get you errors from the conversion routines, because Latin-1 byte
> sequences are generally not valid UTF-8 sequences.

Meanwhile I could reproduce the issue with a very short test case, your patch 
fixes it. And you are right, there is no memleak.

I pushed the patch under your name (no FSF copyright assignment needed).

Thanks for your contribution !

Regards, Tim

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

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