-
Notifications
You must be signed in to change notification settings - Fork 13.3k
base64::encode() borks on some strings (0x03 End TX character?) #3194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This is fixed in master, see #2883. |
Hi igrr, Thanks for getting back to me so quickly (and thanks for all the work on esp8266/Arduino!). Unfortunately this issue is not fixed by #2883. A deeper look suggests this is intended behavior for lib64. Commenting out this code block fixes my issue. |
Apologies, i misread your post, i thought it was about decoding and ETX character appearing in the output. I understand that newlines are not needed for some cases, but it's hard to guarantee that removal of newlines will not break applications which depend on them. How about introducing another function into lib64, which takes line width as an argument (with 0 meaning no line breaks)? And then implementing the existing one as a call to the new one, with line width set to the current value. |
Yes - I had it wrong. Technically what lib64 is spitting out is not base64 encoded (\n is not in the base64 alphabet). This behavior breaks both uris and json. Reading up more on lib64 this may relate to historical pop/smtp server limitations. That said, you have a point that someone out there probably relies on this behavior. I can just String = String.replace("\n", ""), but that seems like a massive waste of RAM and CPU cycles. |
Basic Infos
Hardware
Hardware: Wemos D1 mini (hardware v2.1.0)
Core Version: 2.3.0
Description
I am base64 encoding some raw binary data (actually AES128 CBC cipher output).
base64::encode() appears to break on some data (other data works fine) adding non printable characters.
I haven't yet managed to pin this on the String libraries, lib64, or something else.
That said, swapping out the C lib64/base64 implementation makes the problem go away.
The same input string (hex escaped the same way) works fine when encoded with other platform implementations (eg. php base64_encode).
Looks like lib64 itself is no longer maintained...
Example minimal repo is below.
In this particular example, the problem appears to relate to the ETX character in the input.
Settings in IDE
N/A - not an IDE problem.
I am actually using PlatformIO (under Linux Mint).
Same issue reproducable with Arduino IDE (Linux version 1.81) using below example.
Sketch
Using lib64 backend
Using another third party implementation for backend (same hardware device/environment)
The text was updated successfully, but these errors were encountered: