Closed Bug 332489 Opened 19 years ago Closed 19 years ago

Rhino munges binary output

Categories

(Rhino Graveyard :: Core, defect)

x86
Linux
defect
Not set
major

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: bugzilla, Unassigned)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060313 Debian/1.5.dfsg+1.5.0.1-4 Firefox/1.5.0.1 Build Identifier: Rhino 1.6r2 If you read a binary file (a PNG, say) with the readFile() function and write it using the print() function, you get a different file. (Noob warning: I'm not that familiar with Javascript in general, but it seems fairly strange that an elementary read and write would trash a file. My apologies if there's something obvious that I'm missing here.) I'm using the binary version of Rhino, rhino1_6R2. Reproducible: Always Steps to Reproduce: (livemarks16.png is http://www.mozilla.org/images/livemarks16.png) $ cat t.js print(readFile("livemarks16.png")) $ java -classpath js.jar org.mozilla.javascript.tools.shell.Main t.js > new.png $ cmp livemarks16.png new.png livemarks16.png new.png differ: char 1, line 1 Actual Results: As indicated, the files differ. If you want the actual files, they are: http://barillari.org/~jdb/bugzilla/livemarks16.png http://barillari.org/~jdb/bugzilla/new.png Note that these URLs may not be around forever. Expected Results: new.png should be the exact same file as livemarks16.png, right? (I can understand that a function called print() might pad the output with a newline, but I don't get the binary mangling part.)
Assignee: igor.bukanov → please_see_bug_288433
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
Closed: 19 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.