In order to get the FFASM encoding bug looked at, Microsoft Support asked me to call an 0800 number and provide payment info :-(
Since I am still convinced every bug should be reported I will try again next month when I have my client's support contract details (the guy with the info is on a very long summer holiday :).
In the mean time I have developed a custom fix which you may use at your own risk...
This TranscodingStream class is a binary transformation stream decorator: while reading, the underlying bytes are transcoded on the fly from a source to a target encoding. Both source and target encoding are configurable.
You can make your own pipeline component that replaces the incoming message its bodypart stream by this TranscodingStream (and a context property to dynamically set the target encoding). In fact I have built it already, if you want it just let me know.
This way you can leave the FFASM to its default (UTF8) and let this new component do the work right-after. Also mind that the TranscodingStream doesn't prefix a BOM, which could be problem for UTF-16 (for the simple reason I didn't need it, like in YAGNI).
In retrospect my stream decorator could have been done a bit better. It violates the single responsibility principle since it does decoding + encoding in 1 step. This explains the Read's method cyclomatic complexity being too high. A cleaner design would have been: DecodingStream decorator that translates whatever source encoding to Unicode + EncodingStream decorator that translates Unicode to whatever target encoding.
|