-
Notifications
You must be signed in to change notification settings - Fork 159
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
Memo check doesn't take into account ASCII encoding #257
Comments
A memo could also use another encoding that isn't ASCII or UTF-8, so I'm unconvinced we should limit to decoding the data with just those two. Java String's are UTF-16, so unfortunately the moment we decode the memo from bytes into the String we're possibly changing the string. Could we instead change how memos are decoded so that the |
Yes, you are right and memo could use any encoding. Currently, there are 2 places where
So, regarding your comment.
Yes, that's true, so for user input we can ask for byte string representation. (Q: how do we encoded it? Using UTF-8/ASCII? Using user-provided encoding?)
But we still need to convert it to string to submit to Horizon, don't we? Should we use ASCII?
Won't there be a problem with string that are too long in UTF-8 encoding but are short enough in ASCII encoding? (As in example transaction) Thanks! |
Another question why can't we simply use memo from XDR as ground truth on decoding stage? |
@inkon the fix was included in the 0.12.0 release |
@tamirms thank you very much! 🙏 |
When this transaction was decoded from Json using SDK it failed with following Exception:
As text memo could use either UTF8 or ASCII encoding second option should be checked as well, when decoding transactions from json.
The text was updated successfully, but these errors were encountered: