activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Gomes (JIRA)" <>
Subject [jira] Updated: (AMQNET-230) Xml Message Encoding should not add Byte Order Mark (BOM) into TextMessage field
Date Tue, 09 Feb 2010 22:03:32 GMT


Jim Gomes updated AMQNET-230:

    Fix Version/s: 1.2.1

> Xml Message Encoding should not add Byte Order Mark (BOM) into TextMessage field
> --------------------------------------------------------------------------------
>                 Key: AMQNET-230
>                 URL:
>             Project: ActiveMQ .Net
>          Issue Type: Bug
>          Components: NMS
>    Affects Versions: 1.2.0
>            Reporter: Jim Gomes
>            Assignee: Jim Gomes
>             Fix For: 1.2.1, 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 (
> {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.

View raw message