I hadn't realized the size of the can of worms I was opening. On Apr 10, 2005 3:07 PM, Nicko Cadell <[EMAIL PROTECTED]> wrote: > Mike, > > I have created an issue to track this. > > http://issues.apache.org/jira/browse/LOG4NET-22 >
>> For invalid characters such as 0x1e there are 3 possible solutions: >> 1) Discard the character from the output. >> 2) Replace the character with a numeric representation e.g. "0x1E". >> 3) Replace the character with an XML element e.g. <char code="30"/> > Nicko > >> favour option 3 above because information is not lost. In options 1 and 2 >> information is lost. In 2 the encoding is not reversible. With 3 the >> application reading the data requires additional smarts to pickup on >> the encoded values in element, but all the original information is >> preserved. If the app just asks for the text nodes, ignoring the >> child elements, then they will get back the same result as from 1. If the application just deserializes the string, they'll end up with a much more complex tree structure with a couple of text nodes, an attribute node, .... I don't see that the transport of binary data is a key purpose for log4net. Much as I dislike option proliferation, I wonder if would it be reasonable to have 3 as an optional behavior but 1 or 2 as a default? What does log4j do in this situation? -- Mike Blake-Knox
