I have tried searching for the answer to this question but have not been
able to find the answer: In xerces-j the Base64 encoding scheme appends
"pad" bytes at the end of every call to "encode". However when decoding the
"pad" bytes are not considered. To get around this I have written my code
as follows:
// Write the binary info
StringBuffer sBuf = new StringBuffer();
// Declare an encoder
Base64 encoder = new Base64();
// Declare a buffer
byte[] buf = new byte[fileIn.available()];
// read each chunk
bufferedFileIn.read(buf);
// add the text to the StringBuffer (this is ugly!)
sBuf.append(new String(encoder.encode(buf)));
// Clip the pad bytes...
sBuf.setLength(sBuf.length()-2);
// Now that we have a string buffer let's set the element content
root.appendChild(doc.createTextNode("" + sBuf));
This code works-- but when encoding a large data file, such as an image, the
entire file must be read into memory. I at first attempted to read and
write in small chunks (64 bytes) but couldn't resolve the pad bytes well
without consistently clipping and recreating new strings. I admit I am not
great at this and don't have a lot of history with Base64 encoding, so I am
wondering if anyone has a more elegant solution. On the flip side my
decoding method also has problems as it takes the entire encoded element
content and attempts the reverse without breaking it into chunks:
// Get the Content (uh... do this better)
Node content = root.getFirstChild();
// Declare an encoder
Base64 encoder = new Base64();
// Declare a buffer
byte[] buf = content.getNodeValue().getBytes();
// Write the decoded value
bufferedFileOut.write(encoder.decode(buf));
bufferedFileOut.flush();
So I essentially have the same problem going in the reverse order. I know I
should probably be using SAX to stream the content as well-- and that the
DOM is holding the whole text node in memory anyway, this just demostrates
what is going on with the base64 encoding. I am also not seeking to find
out whether or not placing an encoded image into an XML file is good
practice-- that answer has been well documented elsewhere.
Thanks in advance,
Jeff Rafter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
