Re: base64 feature request / enhancement ideas

[Pádraig Brady]

On 18/11/2023 09:07, Sadi Yumuşak wrote:
> I've recently experienced some difficulties in decoding/saving several
> inline attachments in an EML (Internet Message Format) file saved from
> Thunderbird (same for GMail web client) using the command "base64 --decode
> <input> <output>". I've finally managed to do this after some trial and
> error, some research, and some additional operations before that command
> work. So I thought maybe base64 could be improved so that it could work
> without all this additional work. If such features are beyond the scope of
> coreutils, which should actually be offered via some other utility using
> "base64" (and "dos2unix" as well as others), please forgive this novice.
> 1. Support CRLF line endings as well as LF.

I agree with this.
The base64 RFC references SMTP RFC which mentions native line end 
representation,
but with a default of CRLF.
So we should probably accept both, and I don't see any ambiguity issues etc.
with accepting both.

> 2. Support for base64-encoded blocks of text with some header lines usually
> containing the type and name of the base64-encoded file, and using that
> information for the name of the output file.

I'm not sure about this, as there may be some ambiguity with
what is/isn't a header etc.

> 3. Support decoding a file (such as eml files) containing multiple
> base64-encoded blocks of text.

Similarly there are lots of processing options here.

So for 2 and 3 at least it seems like a separate tool is best.
Looking for existing tools for this I see `ripmime`.
For example to save out attached files from a saved thunderbird email I used:

  ripmime -i file.eml -d . --recursion-max 2 --no-nameless

cheers,
Pádraig.