[xubenqiang]

The bug

HOCON.md says quoted strings use JSON escaping, so a \u escape must be exactly four hex digits. Tokenizer read the four characters and passed them to Integer.parseInt(digits, 16), which also accepts a leading sign and any Unicode decimal digit:

input	before	after
a = "\u0041"	{a=A}	{a=A}
a = "\u+041"	{a=A}	ConfigException.Parse: Malformed hex digits
a = "\u-041"	IllegalArgumentException: Not a valid Unicode code point	ConfigException.Parse: Malformed hex digits
a = "\u００４１" (fullwidth)	{a=A}	ConfigException.Parse: Malformed hex digits
a = "\u٠٠٤١" (Arabic-Indic)	{a=A}	ConfigException.Parse: Malformed hex digits
a = "\u 041", a = "\u004"	ConfigException.Parse	unchanged

The fix checks that each of the four characters is an ASCII hex digit before parsing, so all malformed escapes take the existing Malformed hex digits path instead of being accepted or escaping as a bare IllegalArgumentException.

Tests

config/src/test/java/com/typesafe/config/impl/UnicodeEscapeParsingTest.java covers the sign, the two non-ASCII digit forms and the valid escape.

Verified locally by compiling config/src/main/java with JDK 21 and running the test class with JUnit 4.13.2: OK (2 tests). With the Tokenizer change reverted the test fails with expected a parse error for a = "\u+041".

Note: this repository asks contributors to accept the Typesafe CLA before a pull request can be accepted; I have not signed it.

Refs #884

[lightbend-cla-validator]

Hi @xubenqiang,

Thank you for your contribution! We really value the time you've taken to put this together.

Before we proceed with reviewing this pull request, please sign the Akka Contributors License Agreement:

https://contribute.akka.io/contribute/cla

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

[ekrich]

I'd like to point out here that this should consider that the value can be almost anything. The values parsed in Java Properties or by JSON parsers should be considered as these are parsed and used as well. Maybe the unicode parse should be more strict but then maybe the literal string lives on?