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 02:02:43 UTC
DO NOT REPLY [Bug 38271] New: - 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
Summary: Token filtering during copy ignores encoding
Product: Ant
Version: 1.6.2
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: Core tasks
AssignedTo: dev@ant.apache.org
ReportedBy: kk@kohsuke.org
Files are conceptually a sequence of bytes, and tokens are strings. So when you
talk about "replacing tokens inside a file", those tokens have to be first
turned into sequences of bytes, then those sequences have to be matched against
file images.
But the current implementation is wrong in two ways:
1. it turns file images to sequence of chars, instead of turning tokens into
sequence of bytes. This corrupts binary files (or a binary portion of otherwise
text file, such as control characters.)
2. one needs to be able to specify the encoding of token->byte sequence
conversion, so that (for example) UTF-8 encoded XML files can be correctly filtered.
--
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
DO NOT REPLY [Bug 38271] - Token filtering during copy ignores encoding
Posted by bu...@apache.org.
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