[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.