Base64 encoding question

[Jeff Rafter <je...@earthlink.net>]

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: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org

Re: Base64 encoding question

[Paul Warren <pd...@decisionsoft.com>]

On Thu, Apr 26, 2001 at 01:52:22AM -0700, Jeff Rafter wrote:
> 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. 

Are you referring to the "=" characters at the end of the string?  If
so, these are a required part of base64 encoding.  A base64 string must
be a multiple of 4 bytes in length.

>           // Clip the pad bytes...
>           sBuf.setLength(sBuf.length()-2);

I don't think this is correct - depending on the length of the input
string, there will be 0, 1 or 2 pad characters at the end of the encoded
string.

I have to say, I don't understand the rest of your problem.  The decoder
will correctly discard the pad characters at the end of a string.  Is
this not what is happening?

Paul
-- 
DecisionSoft Limited           Office:  +44-1865-203192
www.decisionsoft.com           Fax:     +44-1865-203194

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org