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