[ 
https://issues.apache.org/activemq/browse/AMQCPP-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51117#action_51117
 ] 

Martin Schlapfer commented on AMQCPP-235:
-----------------------------------------

With respect to a TextMessage, it looks like longer strings (>65535) are 
supported. The length is encoded with 4 bytes rather than 2 bytes.

For character values greater than 127 contained in a text message:
(1) C++ to C++ Client: the (un)marshalling works (except in the case of a null 
character), because there is no UTF8 encoding/decoding performed.
(2) C++ to Java Client: the Java client throws a java.io.UTFDataFormatException 
when getText is called on the text message (at this point it is "unmarshalled" 
using UTF8 decoding, see 
java.org.apache.activemq.util.MarshallingSupport.readUTF8).

So it looks like an implementation for UTF8 encoding/decoding for the 
TextMessage is necessary to be interoperable with the Java client with 
character values larger than 127.

> UTF8 length marshalling bug in openwire readString and writeString.
> -------------------------------------------------------------------
>
>                 Key: AMQCPP-235
>                 URL: https://issues.apache.org/activemq/browse/AMQCPP-235
>             Project: ActiveMQ C++ Client
>          Issue Type: Bug
>          Components: Openwire
>         Environment: Windows XP / Visual Studio 2005
>            Reporter: Martin Schlapfer
>            Assignee: Timothy Bish
>            Priority: Minor
>         Attachments: OpenwireStringSupport.cpp.patch, 
> OpenwireStringSupportTest.cpp.patch, OpenwireStringSupportTest.h.patch
>
>
> In investigating a bug for the check "if( str->size() > 65536 )" which should 
> be "if( str->size() > 65535 )" in writeString() , I found a couple of other 
> problems:
> (1) The OpenwireStringSupport::readString method should read the utf8 length 
> as an unsigned short rather than short.  The problem is that utf8 encoded 
> strings (using writeString) longer than 32768 will become truncated when read 
> back using readString().
> (2) The writeString() method should also check the value of utflen after 
> determining the UTF8 length of the encoded string, since with the support of 
> characters greater than value 127, encodings of 2 UTF8 bytes per byte can 
> exist.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to