base64: Decoding error on Windows (CRLF?)
Windows 7 x64, base64 0.5.2
$ base64 in.bin > in.bin.b64
$ base64 -d in.bin.b64 > out.bin
in.bin.b64: decoding error
and
$ coreutils base64 in.bin > in.bin.b64
$ base64 -d in.bin.b64 > out.bin
$ xxhash *.bin
e368ab052d14607e in.bin
8f8f125c8e4305a3 out.bin
$ coreutils base64 -d in.bin.b64 > out.bin
$ xxhash *.bin
e368ab052d14607e in.bin
e368ab052d14607e out.bin
$ busybox base64 in.bin > in.bin.b64
$ base64 -d in.bin.b64 > out.bin
$ xxhash *.bin
e368ab052d14607e in.bin
8f8f125c8e4305a3 out.bin
$ busybox base64 -d in.bin.b64 > out.bin
$ xxhash *.bin
e368ab052d14607e in.bin
e368ab052d14607e out.bin
_Originally posted by @sergeevabc in https://github.com/aklomp/base64/issues/126#issuecomment-1913442453_
About this issue
- Original URL
- State: closed
- Created 5 months ago
- Comments: 18 (13 by maintainers)
Commits related to this issue
- base64: windows: ensure stdout is binary-clean Ensure that stdout is binary-clean and does not silently change newlines to CRLFs when they occur at the end of a write buffer. Resolves #137. — committed to aklomp/base64 by aklomp 5 months ago
- base64: windows: ensure stdout is binary-clean Ensure that stdout is binary-clean and does not silently change newlines to CRLFs when they occur at the end of a write buffer. Resolves #137. — committed to aklomp/base64 by aklomp 5 months ago
- #137: bin/base64: windows: ensure stdout is binary-clean In some Windows environments, `stdout' automatically changes newlines to CRLFs. This is bad when encoding, because the encoded file will have ... — committed to aklomp/base64 by aklomp 5 months ago
My contribution to the project is sugar-free feedback, revealing flaws that obviously cast a shadow over everything you brag about on the frontpage. The errors I report are reproducible not only on Windows 7, but also on Windows 10 and 11. If you are not ready for feedback, then you should have stayed under the rock and not come out to the public at all. The fact that you do this in your free time and for free does not relieve you of basic human responsibility, just as a musician playing on the street for free cannot take off his pants and poop without at least receiving a reprimand, if not a fine. Cheer up, roll up your sleeves and start improving the solution, rather than whining that you are being offended. However if you didn’t come here to create and improve, but to fool around and pollute Github with sloppy code, then it’s really my mistake that I mistook you for a developer.
I confirm that this error is no longer reproducible according to my initial report, i.e. encoding and decoding of binary files on Windows 7 matches the results of other well-known base64 apps.
But to be honest, there is something disturbing about this story. It seems to me that you did not fully realize that we were dealing here with a top-priority bug. And you blamed the popular OS and offered to replace it, not the lack of your own knowledge about that OS peculiarities. Hence the question: what else could you have missed?
(Looking ahead, I will say that I found another fundamental issue.)
You see, base64 is both a simple and a complex thing. Its simplicity lies in the fact that only two operations are performed, encoding and decoding. And the complexity is that these operations must be performed the same everywhere, because base64 is used in e-mail, armored crypto, data URI scheme, etc.
I received several complaints that people could not decode files and we searched for the culprit in various places, but it turned out to be your app. I welcome efforts to optimize things so that they work faster, consume less memory and take up less space, but in the pursuit of optimization, it is important to cherish the foundation.