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.
