For the most part setting the encoding (UTF-8, UTF-16, etc.) on a WCF service is pretty simple: set textEncoding on basicHttpBinding/wsHttpBinding or encoding on a textMessageEncoding in a customBinding. It works in almost all cases, but there’s a surprising number of ways of indicating the encoding of message:
- the content type of the message
- an XML declaration at the start of the message
- a BOM (byte order mark) that is the first 2 or 3 bytes (depending on encoding) of the message
Next an encoding of UTF-16 doesn’t specify a single encoding. It could be either big endian or little endian.
We can glean a few rules from RFC 3023 – XML Media Types:
- The encoding in the content type should take precedence over any other encoding indications. If the content type is UTF-8 but the XML declaration is UTF-16, the message should actually be UTF-8. For example, a router could receive a UTF-16 message and reencode it as UTF-8 to save bandwidth. The router would change the content type but would keep the actual text of the entire message unchanged.
- When the encoding is specified as UTF-16, there must be a BOM.
- When the encoding is specified as UTF-16LE or UTF-16BE, there must not be a BOM.
- An XML declaration is optional in the presence of other indications of encoding.
The TextMessageEncoder that ships with WCF is a little too strict in a couple of ways:
- When encoding is specified as UTF-16, it requires an XML declaration.
- The content type and the encoding specified in the XML declaration must be consistent.
This can lead to problems in interoperability. Other web service clients can produce messages violating those WCF restrictions and the result is a 400 Bad Request with no additional information. To work around this we will need a custom message encoder.
First we can start with the CustomTextMessageEncoder sample. This sample allows you to specify any .NET supported encoding for an endpoint instead of just UTF-8 and UTF-16 but doesn’t do anything about the restrictions above. Additionally it is necessary to specify which encoding you’ll use when deploying your endpoint.
The new text message encoder I’ll show will accept UTF-8 and UTF-16 encoded messages and workaround those restrictions. I’ll focus on the message encoder since that is where the action happens, but there is additional boilerplate necessary. You will also need a MessageEncoderFactory (called by the framework to create instances of the MessageEncoder), MessageEncodingBindingElement (used to plug this into the channel stack and allow the framework to create instances of the MessageEncoderFactory) and BindingElementExtensionElement (allows it to be used in config, this is optional). The CustomTextMessageEncoder sample has excellent examples of each of these.
Let’s start with ReadMessage:
This does a couple of things. It uses some helper functions to help determine the actual encoding of the message and stores that in the XmlWriterSettings that will be used in the response. Unfortunately, there isn’t an implementation of XmlReader that ships with .NET that will ignore the encoding specified in the XML declaration so if the content type and XML declaration disagree the message needs to be reencoded to match the XML declaration. Finally XmlDictionaryReader is the source of the restrictions above so we use XmlReader.Create to avoid that.
Now let’s look at the encoding helper functions:
GetXmlDeclEncoding tries to find an encoding pseudoattribute in a possible XML declaration at the beginning of the message. Since the message must be encoded as specified in the content type we use that encoding to decode the byte array. XmlReader provides ways to determine values specified in the XML declaration, but as mentioned above it will throw when it discovers the specified encoding doesn’t match the actual encoding. A regular expression match is used to avoid this. We only decode the first 100 bytes to minimize overhead.
GetEncoding is a fairly straightforward implementation of the rules above. For undifferentiated UTF-16 it checks the BOM and creates the proper encoding that will include a BOM. For UTF-16LE/BE it creates the proper encoding and suppresses the BOM (it ignores whether a BOM is included making a bit looser on read). This only recognizes UTF-8 and UTF-16, but it could be modified to call Encoding.GetEncoding to get any supported encoding.
Finally let’s look at writing a message:
These are actually identical to the WriteMessage implementations in the custom encoder sample. They simple use the writerSettings populated by ReadMessage to write out the message.
This will require a CustomBinding to use. It is possible to do it in code: