Skip to content

check the first two characters for invalid xml chars in cdata save - #136

Merged
pjfanning merged 1 commit into
apache:trunkfrom
aizu-m:cdata-leading-bad-char
Oct 16, 2026
Merged

pjfanning merged 1 commit into
apache:trunkfrom
aizu-m:cdata-leading-bad-char

Conversation

@aizu-m

@aizu-m aizu-m commented Oct 15, 2026

Copy link
Copy Markdown
Contributor

Saving text that trips the CDATA heuristic (more than 32 chars and more than 5 </&) with a C0 control in the first or second position:

XmlObject xo = XmlObject.Factory.newInstance();
try (XmlCursor c = xo.newCursor()) {
    c.toNextToken();
    c.insertElementWithText("a", "\u0001<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<");
}
XmlObject.Factory.parse(xo.xmlText());

error: An invalid XML character (Unicode: 0x1) was found in the CDATA section.

The CDATA branch of TextSaver.entitizeContent splices the first character into <![CDATA[, reads the second one only to seed the ]]> tracking, and starts its isBadChar loop at the third. So the first two characters are written raw, while the same character at position three or later becomes ?, as it does in the non-CDATA branch. The fix replaces a bad first character in the prefix and starts the loop at the second character. The buffer wrap check now also runs before that read, not after it. Valid text saves exactly as before.

Added CDataTest.badCharInCData for positions 0, 1 and 2. Positions 0 and 1 fail without the fix. ./gradlew test passes.

@pjfanning
pjfanning merged commit bfc7d66 into apache:trunk Oct 16, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants