fix(sql): enforce UTF-8 when loading keyword resources #1260
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Keywords.readLines previously relied on the JVM default charset, which could mis-parse the word list on non-UTF-8 systems (e.g. CP1252). Changes: • Pass StandardCharsets.UTF_8 to InputStreamReader • Add KeywordsEncodingTest to guard against regressions Cross-platform behaviour is now deterministic.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
📝 Pull-Request Description
What & Why
Keywords.readLinesloaded SQL keyword lists with the JVM’s default charset.On environments configured for non-UTF-8 encodings (e.g. Windows CP-1252) this silently corrupted any keyword containing non-ASCII characters, leading to parsing errors in templates that rely on those lists.
This patch forces UTF-8 decoding for every
/keywords/*resource, guaranteeing identical behaviour on all platforms.Changes in this PR
Compatibility
Non-breaking – internal implementation detail only; public API unchanged.
Applies uniformly to all dialects that depend on
Keywords.Tests & CI
New JUnit test verifies UTF-8 decoding.
All existing tests continue to pass locally.
Current CI hiccup around
easy-jacoco-maven-pluginresolution is unrelated; if desired I can follow up with a version pin or mirror configuration.Related
Inspired by common cross-platform issues with default charset usage (no open upstream ticket).
🤝 Thanks for reviewing!