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.
