livicitu opened a new pull request, #2698: URL: https://github.com/apache/activemq/pull/2698
Relates to #2658 and #2644. `MarshallingSupport.convertUTF8WithBuf`, the decoder behind `readUTF8` and `readShortUTF8`, now accepts a standard four-byte UTF-8 sequence and decodes it to the surrogate pair modified UTF-8 would have produced. Non-Java OpenWire clients such as ActiveMQ-CPP send supplementary characters this way, so today a Java consumer's `getText()` fails on them with `UTFDataFormatException`, and Artemis rejects the send. Every lead byte the new branch handles (`0xF0` to `0xF7`) threw before, so no input that decodes today decodes differently. The writer is unchanged and still produces modified UTF-8. Malformed four-byte input still throws: a sequence cut short, a bad continuation byte, an overlong form, and a code point above U+10FFFF. **Tests** - `testConvertUTF8WithBufDecodesStandardFourByteSequences` and `testReadUTF8AcceptsStandardFourByteSequences` are new, and both fail without the change. - `testConvertUTF8WithBufRejectsMalformedSequences` listed the standard four-byte encoding of U+1F603 as malformed. That case moves to the new test, and malformed four-byte cases take its place. - The rest of `activemq-client` passes on Windows, except `CidrListLoaderTest.testFileUriWithTripleSlash`, which fails there with or without this change. This does not replace the conversion STOMP and AMQP consumers need, or the move to standard UTF-8 with new OpenWire and KahaDB versions. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
