XMLEncode: encode illegal XML control characters

[elharo]

XMLEncode.xmlEncodeTextAsPCDATA() passes characters in the range U+0000–U+001F (excluding TAB, LF, CR) through unencoded in the default branch of its switch statement. These characters are illegal in XML 1.0 and cause XML parsers to reject the output.

Additionally, needsEncoding() only checked for & and <, so text containing only control characters was written directly without reaching the encoding method at all.

Fix:

• Throw IOException for completely illegal characters that cannot appear in XML
• In needsEncoding(), added a check for illegal control chars so they're routed through the encoding path

Fixes #390

[slachiewicz]

Merged current master into this branch to clear the conflict.

The conflict looked worse than it was: #382 and this branch each appended a test method at the same point in PrettyPrintXmlWriterTest, so git could not tell them apart. Both are kept as-is -- nothing semantic was resolved and no assertion was changed. master also now carries the #422 fix, so the branch builds green again.

XMLEncode itself is untouched.

Verified: mvn -B verify on JDK 17 -> Tests run: 789, Failures: 0, Errors: 0. Spotless clean.

This is still a draft. From here it looks ready to mark for review unless you had more planned for the C0 control character handling.

This comment was created with AI assistance.

[elharo]

This PR is a work in progress. I simply haven't decided what should happen in this case. A good approach that maintains API compatibility is not obvious.

[elharo]

OK, I think we can just throw an IOException here and then never emit unencodable characters

[slachiewicz]

Not mergeable yet: the CDATA path still passes the characters through. xmlEncodeText routes any text longer than 12 characters without ]]> to xmlEncodeTextAsCDATABlock, which never reaches the new check, so the writer emits the control character inside a CDATA block with no exception. CDATA does not make U+0001 legal in XML 1.0.

Reproduction on this branch: writeText("hello" + (char) 1 + "world, this is longer than twelve chars") → <div><![CDATA[hello{U+0001}world, ...]]> and no exception; the same text cut to three characters throws as intended. The check needs to sit before the CDATA branch, or in xmlEncodeText itself.

Two smaller points. The needsEncoding javadoc still says the characters are encoded as numeric references producing XML 1.1 output, which the last commit replaced with a throw. On the open exception-type thread, IllegalArgumentException fits better: the input is wrong rather than the stream, and callers of XMLWriter already handle IOException for other reasons, so a bad input would go unnoticed.

This comment was created with AI assistance.