Assignee: please_see_bug_288433 → nobody
This seems similar to Bug 337434 -- all of the octets in the range 128-255 are being replaced by a single character (in this case, 0x3f). The resulting data file also has a spurious newline. This is most likely the result of a charset conversion that should not be performed on binary files.
The documentation for readFile clearly states that if you don't specify an encoding, it'll use the Java default encoding for the system, or optionally you can specify an encoding. This means it's meant as a method for reading textual, and not binary content. The problem is twofold: reading the file unchanged and writing it unchanged. Even if you can get readFile() to read the file using some encoding that maps bytes 0x00-0xff to Unicode characters U0000-U00FF, the print() function will always use the system default character encoding, and if it doesn't have the same property (namely, maps U0000-U00FF to 0x00-0xff), you're stuck. Actually, it'd be sufficient if whatever is the system encoding has bijective mapping for all bytes 0x00-0xff to and from the character set, but again, it's hardly portable as you depend on the system default character encoding. I'll therefore to mark this as INVALID -- yes, it "munges" binary output, because both print() and readFile() are written to operate on textual content, not binary.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID
Thanks for the explanation. That said, is there any way to read binary content into Rhino? thanks.
You need to log in before you can comment on or make changes to this bug.