bug-gnulib
[Top][All Lists]
Advanced

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

Re: uuencode: multi-bytes char in remote file name contains bytes >0x80


From: ��叁
Subject: Re: uuencode: multi-bytes char in remote file name contains bytes >0x80
Date: Tue, 5 Jul 2011 21:44:13 +0800

Let me try to write something in English.
Please to correct my English. :-)

firstly, thanks to Korb for reading my ugly code. :)
Korb is

the problem is users using uuencode to
uuencode a file, he may expect every
btye is ASCII in encodeed file.
but when a NOT-ASCII file name apears,
the problem comes.

uuencode was designed many years ago.
So I belive it's a requirement not a bug.

Let's focus on this question before further discuss.

Q: Is it necessary to do this:
    add a option, make uuencode supports  the file name encoding.

I also post my code here, but it's still buggy.
1. strlen may be wrong to count how many bytes in argv[optind].
2. filename encoding may be better to bese on '-m'
3. as Korb says
4. and so on...

duhuanpeng


------




2011/7/5 Bruno Haible <address@hidden>
Eli,

> > An obvious problem with the patch is that it considers a file name to be a
> > byte sequence. But different users may work in different locales, with
> > different encodings.

And users want to see the original filenames. Users don't want to see mojibake,
that is, a mix of garbled characters (see attached screenshot).

> Doesn't the same problem exist with the file's data itself?

No, there is normally no problem with the contents of the files, because users
have learned to use file formats that are independent of locale. When users
send images (.jpeg or .png), text documents (.html, .odt, .rtf, even .doc),
presentations (.pdf, .odp), etc. they have no problem. And those few users who
receive plain text (.txt) files have the option to change the character
encoding in the browser they use to view the text file (in mozilla: via the
View > Encoding menu).

But when uudecode has created files with garbled names on the receiver's disk,
there is no program which will magically fix it.

> IMO, it's not uuencode's problem to solve.  The correspondents need to
> solve it "by some other means" (TM), for file data as for its name.

No, communication that matches users' reasonable expectations does not
work like this.

Bruno
--
In memoriam Yonatan Netanyahu <http://en.wikipedia.org/wiki/Yonatan_Netanyahu>

Attachment: uuencode.c
Description: Text Data


reply via email to

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