GitHub user livicitu added a comment to the discussion: Path forward for full UTF-8 correctness
One more case for this discussion: an OpenWire client that writes standard UTF-8 itself. Not every OpenWire client is Java. ActiveMQ-CPP writes a `TextMessage` body as the bytes the application gives it, so text with a supplementary character arrives as a standard 4-byte UTF-8 sequence, which modified UTF-8 never contains. - On Classic the broker stores those bytes as they are, and a Java consumer fails in `ActiveMQTextMessage.getText()`, in `MarshallingSupport.readUTF8`, with a `UTFDataFormatException`. - On Artemis the converter decodes the text on arrival with the same `readUTF8`, so the send itself is rejected ([ARTEMIS-6304](https://issues.apache.org/jira/browse/ARTEMIS-6304), closed so that Artemis can inherit the fix made here). This direction may be the easiest part to fix without breaking anyone: `readUTF8` could accept a well-formed 4-byte UTF-8 sequence and decode it to its surrogate pair. No valid modified UTF-8 contains such a sequence (lead bytes `0xF0` to `0xF4`), so every message that decodes today decodes the same way, nothing on disk needs rewriting, and no version negotiation is needed. It would also cover clients that can never negotiate a new OpenWire version, such as ActiveMQ-CPP. We will convert to modified UTF-8 on our side regardless. This is about the broker and the Java client accepting what non-Java OpenWire clients already send. GitHub link: https://github.com/apache/activemq/discussions/2658#discussioncomment-18930763 ---- 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
