DO NOT REPLY [Bug 25995] New: - [Codec] Default encoding logic broken

[bu...@apache.org]

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: commons-dev@jakarta.apache.org
        ReportedBy: olegk@apache.org


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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org