DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25995>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25995 [Codec] Default encoding logic broken Summary: [Codec] Default encoding logic broken Product: Commons Version: 1.2 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Codec AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] It looks like there are some changes made to the URLCodec class(rev 1.7 and 1.8) that do not seem quite right (in my opinion). http://cvs.apache.org/viewcvs.cgi/jakarta-commons/codec/src/java/org/apache/commons/codec/net/URLCodec.java?r1=1.7&r2=1.9 The ENCODING variable in my original patch was made final static for a good reason. It is not supposed to be anything but US-ASCII. After all, the whole point of URL encoding is to represent non-ASCII data using a limited set of ASCII characters only, hence, 'US-ASCII' as a final static variable ENCODING. With the present code, if US-ASCII incompatible encoding is used (such as UTF-16, EBCDIC), URLCodec may produce erroneous results. I understand that the intention of the revision 1.7 & 1.8 was to allow for user defined default encoding, but in its present form URLCodec does not seem to produce the desired results. The patch I am about to attach should take care of the problem while retaining the existing (intended) semantics of the URLCodec class. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
