This repository was archived by the owner on Mar 5, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Mar 5, 2025. It is now read-only.
Support Files in Base64 Cmdlets #16
Description
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'
Activity
[-]Support File Files in Base64 Cmdlets[/-][+]Support Files in Base64 Cmdlets[/+]SteveL-MSFT commentedon Nov 26, 2020
If there was simply a
-Pathparameter 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-OutFileneeded if you can just redirect to a file? Currently you can do:I would agree that it's more intuitive to have a
-Path(and-LiteralPath) parameters than for users to know they also need the-asbytestreamswitch.markekraus commentedon Nov 26, 2020
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
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 commentedon Nov 26, 2020
RE:
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 commentedon Nov 26, 2020
Thinking about
-OutFilefurther. 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 commentedon Nov 28, 2020
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 likeConvert-FileEncodingGKTheOne commentedon Feb 6, 2025
fyi, (mainly documenting for my own reference and future travellers)
I was able to losslessly encode + decode a binary rsa key using:
Get-Content .\private_key.der -AsByteStream | ConvertTo-Base64 -InsertBreakLines | Set-Content .\private_key.b64(Set-Content can be replaced with>)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 😁
🙏