[Top][All Lists]
[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 11:13:45 -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 10:58 AM, Bruce Korb wrote:
> On 07/05/11 08:06, Eric Blake wrote:
>> I'm not quite sure what you are asking me to do here. Maybe it helps to
>> read the current POSIX requirements on uuencode output:
>>
>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/uuencode.html
>
> I read that, though I was sure not as carefully as someone regularly in
> on the meeting. :) Reading it again:
>
>> The pathname of the file into which the uudecode utility shall place
>> the decoded file. ... If there are
>> characters in decode_pathname that are not in the portable filename
>> character set the results are unspecified.
> ==>> ^^^^ needs a comma after "set".
>
> leads me to believe that this:
>
> begin 444 hex-encode-EN:414243
>
> can, for example, be validly used to create a file named "ABC"
> in the english language domain, with obvious extensions for CN.
> The ":" character being non-portable relieves the application from
> being required to create a file named "hex-encode-EN:414243".
You are correct that it would work. The ':' cannot appear in any file
created by a POSIX-compliant use of uuencode, therefore uudecode, upon
seeing a ':' in the file name position, can assume that the input file
must have been created by a uuencode version that was using an extension
to POSIX, and therefore uudecode can blindly try to decode that name
without violating POSIX.
> It is just that a new uudecode might surprise someone trying
> to create a file named "hex-encode-DE:BADF".
Under your encoding scheme for all possible filenames that fall outside
the bounds of the POSIX portable file name set, you merely encode such a
file name as:
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.
--
Eric Blake address@hidden +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
- Re: uuencode: multi-bytes char in remote file name contains bytes >0x80, (continued)
- Re: uuencode: multi-bytes char in remote file name contains bytes >0x80, Eli Zaretskii, 2011/07/04
- Re: uuencode: multi-bytes char in remote file name contains bytes >0x80, Bruno Haible, 2011/07/04
- Re: uuencode: multi-bytes char in remote file name contains bytes >0x80, Eli Zaretskii, 2011/07/04
- Re: uuencode: multi-bytes char in remote file name contains bytes >0x80, ��叁, 2011/07/05
- Re: uuencode: multi-bytes char in remote file name contains bytes >0x80, Bruce Korb, 2011/07/05
- Re: uuencode: multi-bytes char in remote file name contains bytes >0x80, Eric Blake, 2011/07/05
- Re: uuencode: multi-bytes char in remote file name contains bytes >0x80, John Cowan, 2011/07/05
- Re: uuencode: multi-bytes char in remote file name contains bytes >0x80, Eric Blake, 2011/07/05
- Re: uuencode: multi-bytes char in remote file name contains bytes >0x80, John Cowan, 2011/07/05
- Re: uuencode: multi-bytes char in remote file name contains bytes >0x80, Bruce Korb, 2011/07/05
- Re: uuencode: multi-bytes char in remote file name contains bytes >0x80,
Eric Blake <=
- Re: uuencode: multi-bytes char in remote file name contains bytes >0x80, Bruce Korb, 2011/07/05
- Re: uuencode: multi-bytes char in remote file name contains bytes >0x80, Eric Blake, 2011/07/05
- Re: uuencode: multi-bytes char in remote file name contains bytes >0x80, Bruce Korb, 2011/07/05
- Re: uuencode: multi-bytes char in remote file name contains bytes >0x80, ��叁, 2011/07/06
- Re: uuencode: multi-bytes char in remote file name contains bytes >0x80, Eli Zaretskii, 2011/07/06
- Re: locale encodings, Bruno Haible, 2011/07/05