Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Message-ID: <1769759010.13891265678012778.JavaMail.jira@brutus.apache.org>
Date: Tue, 9 Feb 2010 01:13:32 +0000 (UTC)
From: "Jim Gomes (JIRA)" <jira+amqnet@apache.org>
To: dev@activemq.apache.org
Subject: [jira] Resolved: (AMQNET-230) Xml Message Encoding should not add
 Byte Order Mark (BOM) into TextMessage field
In-Reply-To: <1572131733.13871265677772994.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


     [ 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.