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: Eric Blake
Subject: Re: uuencode: multi-bytes char in remote file name contains bytes >0x80
Date: Tue, 05 Jul 2011 14:13:52 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.10

On 07/05/2011 12:12 PM, Bruce Korb wrote:
> On 07/05/11 10:13, Eric Blake wrote:
>> begin 444 hex-encode-EN:6865782d656e636f64652d44453a42414446
>>
>> that is, presence of : in the desired output name implies that the file
>> name must be encoded, just the same as any 8-bit byte also makes that
>> implication.
> 
> Yep, but part of the whole point of uuencode is that the output is 7-bit
> ASCII,

"hex-encode-EN:6865782d656e636f64652d44453a42414446" _is_ 7-bit ASCII
encoded name, which when decoded will result in a filename that happens
to contain a single colon, namely "hex-encode-DE:BADF".  That is, if the
file name to be generated into the uuencode output contains any 8-bit
byte or contains any non-portable 7-bit file name character (newline,
colon, ESC, or even comma for that matter!), then uuencode instead
outputs "hex-encode-$LL:..." with $LL determined by the current locale
or encoding (at least, that appears to be how you were envisioning
things), followed by every other byte in the file name being output as
an encoded representation.

> meaning the output should not contain any funny characters at all,
> including
> the "begin" line.

Right - and by you making uuencode use "hex-encode:..." for all
filenames that would otherwise be funny, you've met that goal.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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