allthingssecurity opened a new pull request, #27163:
URL: https://github.com/apache/camel/pull/27163

   # Description
   
   [CAMEL-25214](https://issues.apache.org/jira/browse/CAMEL-25214)
   
   `HL7Charset` maps the MSH-18 values of HL7 table 0211 to Java charsets for 
the HL7 data format. Four entries carry the wrong HL7 name (copy and paste from 
the entry above them), one is missing and one has no Java name:
   
   ```java
   ISO_8859_6("8859/1", "ISO-8859-6"),
   ISO_8859_7("8859/1", "ISO-8859-7"),
   ISO_8859_8("8859/1", "ISO-8859-8"),
   ISO_8859_9("8859/1", "ISO-8859-9"),
   ...
   GB_1830_2000("GB 18030-2000", ""),
   ```
   
   So MSH-18 `8859/6`, `8859/7`, `8859/8`, `8859/9` and `8859/15` are not 
found, and unmarshal and marshal fall back to the exchange charset (UTF-8 by 
default): Arabic, Greek, Hebrew, Turkish and Latin-9 text is silently decoded 
wrongly (`Παπαδόπουλος` in an `8859/7` message comes out as mojibake) and 
written as UTF-8 under the MSH-18 label. `GB 18030-2000` gives the Java charset 
name `""`, so unmarshal and marshal fail with `UnsupportedEncodingException`. 
The table has been like this since it was added (CAMEL-8079).
   
   This change: the right HL7 names for ISO-8859-6 .. ISO-8859-9, a new 
`ISO_8859_15("8859/15", "ISO-8859-15")` entry, and `GB18030` for `GB 
18030-2000`. These are the values of HAPI's `HL7Charsets` and of camel-mllp's 
`MllpProtocolConstants.MSH18_VALUES` (CAMEL-22712). The Japanese (`ISO IR14`, 
`ISO IR87`, `ISO IR159`) and `CNS 11643-1992` entries differ from HAPI too, but 
Japanese HL7 v2 uses ISO 2022 code extension (MSH-20), so they are left for a 
separate discussion.
   
   Messages with these MSH-18 values are now read and written in the charset 
they name, and `CamelCharsetName` is set to it on unmarshal, so the upgrade 
guide for 4.23 gets a short note.
   
   Tests:
   - `HL7DataFormatMsh18CharsetTest` (new): unmarshal of `8859/6`, `8859/7`, 
`8859/8`, `8859/9`, `8859/15` and `GB 18030-2000` messages encoded in their 
charset (checks `CamelCharsetName` and the patient name in QRD-8), marshal of 
`8859/7` and `GB 18030-2000` messages; control: an `8859/5` message.
   - Without the change, 8 of the 9 tests fail (6 failures, 2 errors with 
`UnsupportedEncodingException`); the `8859/5` control passes.
   - With the change, all camel-hl7 tests pass: 79 tests, 0 failures.
   
   # Target
   
   - [x] I checked that the commit is targeting the correct branch (Camel 4 
uses the `main` branch)
   
   # Tracking
   - [x] If this is a large change, bug fix, or code improvement, I checked 
there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for 
the change (usually before you start working on it).
   
   # Apache Camel coding standards and style
   
   - [x] I checked that each commit in the pull request has a meaningful 
subject line and body.
   - [ ] I have run `mvn clean install -DskipTests` locally from root folder 
and I have committed all auto-generated changes.
     (I built and tested the affected module, including the formatter and 
import-sort plugins. I did not run the full root build.)
   
   # AI-assisted contributions
   
   - [x] If this PR includes AI-generated code, commits have proper 
co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR 
description identifies the AI tool used.
     This PR was prepared with Claude Code (Claude Opus 5.5). The commit 
carries a `Co-Authored-By` trailer.
   
   _Claude Code on behalf of allthingssecurity_
   
   🤖 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]

Reply via email to