Base64 encoding in I/O statements

[ivan-pi]

Popular visualization formats like the VTK XML File Format use Base64 encoding of numerical data as text. This slightly increases the amount of storage, but proves to be more reliable when distributing data via channels that predominantly support text (e.g. the internet). Another example use case would be embedding binary data (e.g. images, other binary assets) in HTML reports generated by a Fortran program.

The idea was suggested here:

• https://fortran-lang.discourse.group/t/writing-a-binary-file-in-little-endian/719/3

As the user "rwmsu" has stated in that thread:

This would be a big help for writing things like the VTK XML format files where you want to mix base64 encoded binary with standard text. I presume it would have to be an option on the read and/or write statement. something like

Write(iunit, *) ‘’
Write(iunit, *, ENCODE=“base64”) some_real_array

etc.

Having that capability in a compiler would have saved me the time and the almost 1000 lines of code it took to develop my own base64 encoding/decoding package.

Right now, available libraries for Base64 encoding include:

• https://github.com/szaghi/BeFoR64 (in Fortran)
• https://github.com/tobiaslocker/base64 (via C binding)
• https://github.com/aklomp/base64 (via C binding)
• https://github.com/zhicheng/base64 (via C binding, suggested here: https://stackoverflow.com/questions/73452098/fortran-write-base64-string-of-binary-to-file)

[klausler]

When the need for a feature can be addressed in portable open-source libraries that are available today (or in a few years), experience shows that that's a much better solution than trying to change the language. A "standard" feature is likely to be an incomplete solution -- you'll want some means to deal with endianness, and the standard language doesn't even provide that today for unformatted I/O despite near-universal CONVERT= extensions. It won't appear in a standard until 2028 at the earliest, and it won' be widely available until the 2030's. Since the current process does not generate any conformance tests, portability across implementations won't be assured, and since the process doesn't involve prototyping, any ambiguity or contradictions in the feature's description will lurk in the document until implementors try to make sense of it after publication.

If you have a library implementation today, and it's portable and universally available, you already have the best solution. Second-best would be a pilot extension to an open-source Fortran compiler and I/O runtime library.

[certik]

since the process doesn't involve prototyping

The Fortran standard process must involve prototyping.

Second-best would be a pilot extension to an open-source Fortran compiler and I/O runtime library.

Yes, that has to be a prerequisite for any proposal.

[certik]

Another idea: if Fortran had a way to hook in user-defined readers/writers and still use the built-in Fortran syntax to open and read from files (see #331), then one could define a "Base64Writer" as a user library, and still use the write syntax.

[ivan-pi]

The hook you propose seems related to Section 2.3.9 of the coroutine proposal: https://j3-fortran.org/doc/year/19/19-169.pdf (I haven't dived into the details yet, just noticed it has a similar purpose)