You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by bu...@apache.org on 2006/01/14 13:15:02 UTC
DO NOT REPLY [Bug 38271] - Token filtering during copy ignores encoding
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38271>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38271
jkf@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
Status|NEW |RESOLVED
Resolution| |INVALID
------- Additional Comments From jkf@apache.org 2006-01-14 13:15 -------
One and the same string may in the same encoding be represented by different
sequences of bytes. So converting the string to a sequence of bytes will not
work for all encodings.
The current implementation can handle TEXT files, as documented, in all
encodings supported by your java platform. For this the "encoding" attribute is
present on the copy task.
Ad 1) True, but it is clearly stated in the manual.
Ad 2) UTF-8 XML Files are text files with a certain encoding, so one can use the
encoding attribute of the copy task.
Text files with control sequences or non text files would be tricky anyway, what
if part of the control sequence would match the token start and the rest would
be part of the plain text. In non text files probably also items like offsets,
lengths and checksums would go haywire.
Translating the token to a byte array and matching the byte array is not
reliable, decoding and encoding the text file was chosen, with the possibility
to specify both the encoding used to read the file and to specify the encoding
used to write the file, the sole drawback is that binary -non text- files cannot
be handled.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org