[rabbitmq-discuss] Unicode handling changed between 2.5.1 and 2.6.1?

[Toby Corkindale]

On 16/09/11 19:28, Marek Majkowski wrote:
> On Fri, Sep 16, 2011 at 08:31, Toby Corkindale
> <toby.corkindale at strategicdata.com.au>  wrote:
>> On 16/09/11 17:20, Toby Corkindale wrote:
>>>
>>> Hi,
>>> I upgraded from RabbitMQ + STOMP plugin, from version 2.5.1 to 2.6.1.
>>>
>>> Now I am seeing a bunch of double-encoding of unicode characters.
>>>
>>> I wondered if there have been any changes to RabbitMQ or the STOMP
>>> plugin between those versions that could have caused this?
>>>
>>> (It's possible it's coming from somewhere else, but I didn't change much
>>> else here..)
>>
>> I found a place in my code where I was doing UTF8 conversion, and after
>> removing that, I'm not getting double-encoded UTF8 any more. However the
>> code definitely used to require it.
>>
>> I guess something relating to unicode was fixed in the stomp or rabbit
>> layer?
>
> See this discussion:
> http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2011-August/014412.html
>
> AFAIR nothing substantial was changed, only the fact that we don't
> add content-type by default.
>
> Is it possible that this is what you see?

Hmm.. I am using Lionel's Net::STOMP::Client module. The version of it 
hasn't changed, but I wonder if it uses the STOMP header to determine 
how to decode the message to/from utf8 automatically? If so, maybe it 
used to be en/decoding it, but is now treating it as binary.. although 
the actual behaviour seems to be opposite to that.

The module's documentation doesn't mention anything about Unicode. I'll 
cc: the author and ask him.

Lionel, hope you don't mind answering - what's the best-practice way to 
send UTF8 characters in the body of FRAMEs via your module - convert the 
unicode strings to byte streams and send it as a binary frame, or leave 
it as a perl unicode string, and set a content-type header to match?

Cheers,
Toby