[
https://issues.apache.org/jira/browse/CAMEL-8079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Ohr updated CAMEL-8079:
---------------------------------
Attachment: PATCH-8079.diff
> Provide possibility to delegate charset evaluation of a HL7 message to
> HL7DataFormat
> ------------------------------------------------------------------------------------
>
> Key: CAMEL-8079
> URL: https://issues.apache.org/jira/browse/CAMEL-8079
> Project: Camel
> Issue Type: New Feature
> Components: camel-hl7
> Reporter: Christian Ohr
> Fix For: 2.14.1, 2.15.0, 2.13.4
>
> Attachments: PATCH-8079.diff
>
>
> The HL7Codec directly creates a String from the message, using the charset
> hardcoded in its HL7MLLPConfig. This is too static.
> * The field MSH-18 of the message may contain the charset in which the
> message is encoded (much like encoding=... in the XML header) and which shall
> be used for decoding.
> * Other information nested the exchange may also be usable to derive the
> appropriate charset if MSH-18 is empty.
> The attached patch improves the behavior in a backwards-compatible way.
> * HL7MLLPCodec has a new property named "produceString" (default true). If
> set to false, the codec sends a byte array into the route instead of a
> string. In this case, no charset is evaluated yet.
> * the HL7DataFormat checks the field MSH-18 for the charset to be used for
> marshalling and unmarshalling. If MSH-18 is empty, it uses the standard
> Camel charset properties/headers by default. If MSH-18 was populated, the
> value is copied to a new message header "CamelHL7Charset"
> * the HL7DataFormat also offers an extension point in order to "guess" the
> charset from the byte array content (e.g. using ICU4J's CharsetDetector).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
