pjfanning opened a new pull request, #1415: URL: https://github.com/apache/poi/pull/1415
Fixes #1410 (options 1 and 2). **Option 1: helpers.** `XSSFRichTextString.utfDecode(String)` is now public, and there is a new public `XSSFRichTextString.utfEncode(String)`. It escapes the leading underscore of every `_xHHHH_` sequence as `_x005F_`, as Excel does. A lookahead pattern catches overlapping sequences such as `_x0041_x0042_`, which would otherwise be decoded once the first one is escaped. `utfDecode(utfEncode(s)) == s` holds. **Option 2: workbook flag.** `XSSFWorkbook` and `SXSSFWorkbook` (which delegates to its `XSSFWorkbook`) get `setEscapeLiteralUnicodeSequences(boolean)` and `isEscapeLiteralUnicodeSequences()`. The flag defaults to `false`, so deliberate escapes like `_x000D_` keep working. When it is on, these are escaped: - XSSF: `setCellValue(String)`, cached formula string results, and non-XSSF `RichTextString`s - SXSSF: plain string values (shared strings table and inline), inline strings, and cached formula string results `XSSFRichTextString` values are stored unchanged, because the object already holds the stored form of its text: its `getString()` decodes `_xHHHH_`. Encoding it again would double-escape rich text that was copied from another cell. To put literal text into rich text, callers use `utfEncode` on the text they pass in. The javadoc explains this. `setCellType(STRING)` is not encoded either, because it copies the already-stored value. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
