2010/7/2 Eduardo Pérez Ureta <edp...@gmail.com>:

> So I suggest any of these three options:
> - deprecate 
> org.apache.commons.fileupload.util.Streams.asString(java.io.InputStream
> pStream) that uses the platform default character encoding and
> deprecate not calling
> org.apache.commons.fileupload.FileUploadBase.setHeaderEncoding(String
> encoding) by issuing a warning.

I see no reason for deprecation. You are, of course, right that it is
inappropriate for the case of an international application. But, it
usually works perfectly for those applications, which aren't. And I
believe that the latter are still the majority. UTF8 definitely is the
better way in the long term, but it requires carefulness on all sides.


> - use UTF-8 by default in both
> org.apache.commons.fileupload.util.Streams.asString(java.io.InputStream
> pStream) and 
> org.apache.commons.fileupload.FileUploadBase.setHeaderEncoding(String
> encoding) as it is common nowadays.

Definitely not. This would be an incompatible change. I might agree
with you, that choosing the default for a new application would be
subject to discussion, but not for an existing library, which is in so
broad use like commons-fileupload.


> - use the default servlet container character encoding, as used in
> javax.servlet.ServletRequest.getParameter(String name), in both
> org.apache.commons.fileupload.util.Streams.asString(java.io.InputStream
> pStream) and 
> org.apache.commons.fileupload.FileUploadBase.setHeaderEncoding(String
> encoding) as users expect.

Same idea, same reply: Incompatible change, thus forbidden.


Sorry,

Jochen


-- 
Germanys national anthem is the most boring in the world - how telling!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to