-
Notifications
You must be signed in to change notification settings - Fork 38.5k
Refine UriUtils#decode
and StringUtils#uriDecode
implementation and documentation
#34673
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
Conversation
eec755b
to
037a4ec
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kilink Could you please add a Signed-off-by trailer to your commit message as described in https://spring.io/blog/2025/01/06/hello-dco-goodbye-cla-simplifying-contributions-to-spring?
Optimize the StringUtils.uriDecode method in the following ways: - Use a StringBuilder instead of ByteArrayOutputStream, and only decode %-encoded sequences. - Use HexFormat.fromHexDigits to decode hex sequences. - Decode to a byte array that is only allocated if encoded sequences are encountered. Signed-off-by: Patrick Strawderman <pstrawderman@netflix.com>
037a4ec
to
f3e2a6a
Compare
Done. |
UriUtils#decode
and StringUtils#uriDecode
implementation and documentation
Refine the StringUtils#uriDecode method in the following ways: - Use a StringBuilder instead of ByteArrayOutputStream, and only decode %-encoded sequences. - Use HexFormat.fromHexDigits to decode hex sequences. - Decode to a byte array that is only allocated if encoded sequences are encountered. Signed-off-by: Patrick Strawderman <pstrawderman@netflix.com> See spring-projectsgh-34673
Merged with some additional optimizations + a Javadoc update, thanks a lot @kilink. |
Optimize the StringUtils.uriDecode method in the following ways:
Using a StringBuilder and decoding to a temporary byte buffer are inspired by how JDK's URLDecoder works; HexFormat was added in JDK17 and should be more performant than Integer.parseInt as it uses lookup tables.
I initially looked at this as an easy optimization opportunity, but it appears this also resolves the issue raised in #34570; I've added a test case to exercise the problem described in that issue.