Support Files in Base64 Cmdlets

[markekraus]

More often than not, my use cases for base64 involve files. This leads to a large amount of boilerplate code. This could be reduced if support for reading from and writing to files is added to the Base64 cmdlets.

As a user, I would like to use ConvertFrom-Base64 to store the results in a file.

ConvertFrom-Base64 -Test 'This is a test' -OutFile 'test.base64.txt'

As a user, I would like to convert UTF-8 text contained in a file to Base64 using ConvertTo-Base64

ConvertTo-Base64 -TextFile 'I_Robot.txt'

As a user, I would like to convert a file containing binary data to Base64 using ConvertTo-Base64

ConvertTo-Base64 -BinaryFile 'kitten.png'

[SteveL-MSFT]

If there was simply a -Path parameter that took a file path, does it matter if it's a text file or binary file as it'll basically convert the file contents to a byte array. Is -OutFile needed if you can just redirect to a file? Currently you can do:

get-content 'kitten.png' -asbytestream | convertto-base64 > base64.txt

I would agree that it's more intuitive to have a -Path (and -LiteralPath) parameters than for users to know they also need the -asbytestream switch.

[markekraus]

does it matter if it's a text file or binary file

Maybe not. The only area I can see this being an issue is the txt file is encoded (for example CJK) and the user expecting base64 to be encoding the string contents of the file as UTF-8 for the destination. Base64 encoding the byte array would maintain CJK. Another concern is utf-8 BOM. In any case... if it is properly documented that -Path only encodes raw file bytes it could be acceptable.. or if a source encoding can be supplied and if present decode the file to a string and then utf-8+base64 encode.

This brings up another topic I debated mentioning.. which is destination encoding... a few endpoints I have worked with expect the base64 decoded string to be encodings other than utf-8. *shrugs

Is -OutFile needed if you can just redirect to a file?

Needed? No. But it is more convenient if I am dealing with nothing but files. But it's not a deal-breaker for me.

[markekraus]

RE:

get-content 'kitten.png' -asbytestream | convertto-base64 > base64.txt

That's my point... a ton of boilerplate code. I don't have as many scenarios where I'm just base64 encoding string from the run time. I'm primarily working with files. In my own cmdlets have made for this, I included file encoding to make the code much cleaner and easier to follow.

[markekraus]

Thinking about -OutFile further. I'm considering the memory and performance impact of piping out a large binary from base64 to >. One of the reasons IWR/IRM implemented -OutFile was memory consumption (the other being convenience because turning an HTTP response into a file is cumbersome).

Still not a deal-breaker, but something else to consider.

[SteveL-MSFT]

I think that's a good enough reason to have -OutFile. As for handling different file encodings, I feel that should be some different generic cmdlet. Something like Convert-FileEncoding

[GKTheOne]

fyi, (mainly documenting for my own reference and future travellers)
I was able to losslessly encode + decode a binary rsa key using:

• to encode: Get-Content .\private_key.der -AsByteStream | ConvertTo-Base64 -InsertBreakLines | Set-Content .\private_key.b64 (Set-Content can be replaced with >)
• to decode: Get-Content .\private_key.b64 | ConvertFrom-Base64 -AsByteArray | Set-Content .\private_key.other.der -AsByteStream (Set-Content cannot be replaced with '>')

+1 for input+output files support though. My uses are rare but I do pipe strings for base64 encode+decode the same amount as I base64 encode+decode binary files 😁
🙏