[
https://issues.apache.org/activemq/browse/AMQNET-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Gomes resolved AMQNET-230.
------------------------------
Resolution: Fixed
Refactored the Xml serializers to not add a BOM to the TextMessage body.
> Xml Message Encoding should not add Byte Order Mark (BOM) into TextMessage
> field
> --------------------------------------------------------------------------------
>
> Key: AMQNET-230
> URL: https://issues.apache.org/activemq/browse/AMQNET-230
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: NMS
> Affects Versions: 1.2.0
> Reporter: Jim Gomes
> Assignee: Jim Gomes
> Fix For: 1.3.0
>
>
> The XmlSerializer in XmlUtl is adding a Byte Order Mark (BOM) as it is
> marshaling XML messages. The BOM is being added because it is using a
> MemoryStream as the underlying buffer mechanism. Technically, adding a BOM
> mark to a typed field is incorrect. The message body of a TextMessage is
> typed as a Unicode string, therefore no BOM should be added. Adding a BOM
> breaks inter-platform compatibility with other clients. The following is
> taken from the Unicode FAQ (http://unicode.org/faq/utf_bom.html):
> {quote}
> Q: Why wouldn't I always use a protocol that requires a BOM?
> A: Where the data is typed, such as a field in a database, a BOM is
> unnecessary. In particular, if a text data stream is marked as UTF-16BE,
> UTF-16LE, UTF-32BE or UTF-32LE, a BOM is neither necessary nor permitted. Any
> FEFF would be interpreted as a ZWNBSP.
> Do not tag every string in a database or set of fields with a BOM, since it
> wastes space and complicates string concatenation. Moreover, it also means
> two data fields may have precisely the same content, but not be binary-equal
> (where one is prefaced by a BOM).
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
