I've just had a look at this myself, since I refactored some of the classes
involved recently. The proposed solution will work OK in a closed
system where you already know the encoding sent back by the server.
It may well break if you force the encoding to be something non-UTF
when it is really UTF, or vice versa.
There are four encodings involved:
1. The client write encoding
This is governed by XmlRpcClientResponseProcessor.getEncoding(),
which is usually XmlRpc.getEncoding().
2. The server read encoding (governed by XmlRpc.parse()).
There is no explicit read encoding - we allow the XML parser to
detect it.
3. The server write encoding
This is governed by XmlRpcRequestProcessor.getEncoding(),
which is usually XmlRpc.getEncoding().
4. The client read encoding (governed by XmlRpc.parse()).
There is no explicit read encoding - we allow the XML parser to
detect it.
In the case of a system that only uses our packages, this means that
setting the encoding on the client or the server will only set the encoding
for writing. The read encoding is left to the XML parser to decide. This
is desirable behaviour. The problem is that MinML doesn't seem to do
this (although I am open to corrections).
I think we should add a method setEncoding(String enc, boolean force) to
XmlRpc allow the encoding to be forced and modify parse(InputStream)
accordingly. The current setEncoding(enc) becomes setEncoding(enc, false).
This would effect parts 2 and 4, and have the same effect as the proposed
solution with no autodetection issues.
This preserves the current encoding neutrality, while allowing the encoding
to be forced if need be.
I think for version 2.0 it the server should write the response using the
encoding of the request, at least for encodings that maintain the lower
7 bits of ASCII. This would allow the client to specify the encoding.
Andrew.
