activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Schlapfer <mar...@schlapfer.com>
Subject Re: ActiveMQcpp cms::Session::createTextMessage() function usage question with ISO-8859-1 strings
Date Wed, 02 Sep 2009 03:10:09 GMT
The string representation remains the same, which is a std::string 
between C++ clients.  It is the *transmission* of the std::string on the 
wire between the client and the server that transforms the string from 
0-255 byte values to UTF-8.

So it should be transparent to the user.  Your example should still work 
when encoded to UTF-8, transmitted on the wire, and decoded back into a 
character string (ie. treat 0xC4 as one character and 0x84 as the 
subsequent character in the std::string).

Unless of course you are talking about a Java client transmitting a 
character value greater than 255 across the wire to a C++ client.  Then 
of course, this will not work.  It would not have worked in previous 
versions either.

rainy3 said the following on 9/1/2009 8:52 AM:
>> The CMS API doesn't currently have methods for dealing with multibyte C++ 
>> strings so strings are expected to be encoded with values from 0-255.
>>     
>
> So, with new ActiveMQcpp C++ consumer won't be able to reconvert a text
> message with UTF-8 char for example 0xC484 (this char stays for one letter
> which looks like 'A,'). It's kinda sad cause old consumer was able to deal
> with this (it was using iconv to reconvert text message from UTF-8 to proper
> charset and it was working like a charm). Now, i guess, only way to make
> this still possible is to rewrite both producer and consumer to use binary
> messages. Maybe, in a future releases of ActiveMQcpp, there would be a
> chance for some kind system dependend compilation to allow linux/unix
> systems with native iconv support to deal with those kind of text messages?
>   


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message