GitHub user livicitu added a comment to the discussion: Path forward for full UTF-8 correctness
@cshannon thanks. Two clarifications, because I think the read-side change is smaller than it sounds. **It adds no scan.** `convertUTF8WithBuf` already decodes byte by byte, choosing a 1-, 2- or 3-byte form from each lead byte, and a 4-byte lead (`0xF0` to `0xF4`) falls into the final `else` and throws: https://github.com/apache/activemq/blob/6475354a671ee9e02cd6eb34291e50470be0c107/activemq-client/src/main/java/org/apache/activemq/util/MarshallingSupport.java#L418-L438 The change is one more branch at that `else`, decoding the four bytes to a surrogate pair. A message that decodes today never reaches it, and two chars from four bytes still fit the existing `char[utflen]`. **It makes no client worse off.** An older Java consumer only meets standard 4-byte UTF-8 when a producer such as ActiveMQ-CPP already sent it, and it already fails on that message today. Updated clients and brokers would read it; everything else behaves exactly as now. Agreed that it does not replace the conversion STOMP and AMQP consumers need, or the longer-term move to standard UTF-8 with new OpenWire and KahaDB versions. It is a small step that could go into a minor release, since no input that works today decodes differently. GitHub link: https://github.com/apache/activemq/discussions/2658#discussioncomment-18955046 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
