coreutils
[Top][All Lists]
Advanced

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

Re: Extensions to the `base64' Program


From: Pádraig Brady
Subject: Re: Extensions to the `base64' Program
Date: Mon, 31 Aug 2015 15:44:46 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

On 31/08/15 15:28, Stephane Chazelas wrote:
> 2015-08-31 14:39:57 +0100, Pádraig Brady:
> [...]
>>> The problem is that `base64' doesn't support the RFC 4648
>>> standard.  An obvious work around is to do something akin to
>>> "cat <file> | sed 's/-/+/' | sed 's|_|/|' | base64 --decode"
>>> or whatever (forgive the double sed please).  However, it
>>> would be more GNU-y I think to support the "web" or
>>> "url-safe" version of Base64 encoding directly in the
>>> program as an extension.
> [...]
>>   Generally we avoid adding functionality unless it gives
>>   a functional advantage to include. That's not the case here
>>   and even performance wise, base64 doesn't generally process
>>   large amounts of data where the extra data copy would be significant.
>>
>>   There's talk of adding base32 util, with which
>>   it would be nice to keep the same args as base64,
>>   and a --url option would be inappropriate there.
> [...]
> 
> Note that as per RFC 4648, that's a different encoding so if
> GNU's going to add another command for base32 encoding, another
> base64url one would be needed as well for base64url.

Yes that would be most consistent,
though again not warranted I think.

> Maybe GNU recode or iconv may be a better choice to add this
> kind of encoding functionality.
> 
> recode already does base64 encoding as well as others like
> quoted-printable.
> 
> $ echo test | base64 | recode /b64..
> test

Same argument for whether it's needed, but yes
the recode /b64_url interface is more amenable.

cheers,
Pádraig.




reply via email to

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