You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Alexander Hvostov <al...@aoi.dyndns.org> on 2003/11/01 12:22:49 UTC
[codec] My own little base64 implementation, as an {Input,Output}Stream.
A little while ago, I wrote a base64 {en,de}coder in Java. Huzzah. Since I've
found out that you guys wrote one too, I thought I should submit mine. It's
implemented as an OutputStream and InputStream pair, though, so it's a bit
different from yours, which is why I thought to send mine. It's public
domain, so do whatever you want with it. The two source files are attached.
Alex.
Re: [codec] My own little base64 implementation, as an {Input,Output}Stream.
Posted by Konstantin Priblouda <kp...@yahoo.com>.
> By which I think you're referring to
> org.xml.sax.ContentHandler? If the
> contents of an element includes a large blob of
> continuous text, the
> parsers are free to deliver this to your application
> in little chunks
> (and in fact do break it into chunks) so as to save
> on the maximum
> amount of memory the parser might be forced to
> allocate. Theoretically,
> it is then *your* problem to figure out whether or
> not it is a good idea
> to bundle all of the data up into a giant String or
> StringBuffer before
> you process it.
Well, that exactly the problem.... And another proble
is that I have to gather those chunks together ( for
current implementation of base64 ) , and to organize a
tstream out of them which I pass to create BLOB.
( and they are big... )
So content handler delivering a stream of characters
to me ( reader? ) , which I could chain with base64
streaming decoder would save a lot on memory
allocation / deallocation. And this allocating
busyness is a wrong way - data amounts tend to
explode. And there will be big flash simulations or
PDFs in your knowlege management system... I know
those editors :)
> Nobody said the SAX API makes life easy. An
> interesting point, at least
> in the context of this discussion thread, is that
> you'd then need to
> pass the *characters* off to the base64 decoder, but
> in chunks of a size
> that the parser chooses, which unfortunately might
> not line up with the
> four-character chunks that a base64 decoder wants
>
> Hope that helps.
This problem can be solved though. Current codec
implementation works buffer-buffer with padding,
( and is basically stateless ) - streaming will
gobble all up available data, and then just signal an
end when
padding reached...
( and of course it has to be able to read off reader
:) )
regards,
=====
----[ Konstantin Pribluda ( ko5tik ) ]----------------
Zu Verst�rkung meines Teams suche ich ab Sofort einen
Softwareentwickler[In] f�r die Festanstellung.
Arbeitsort: Mainz
Skills: Programieren, Kentnisse in OpenSource-Bereich
----[ http://www.pribluda.de ]------------------------
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [codec] My own little base64 implementation,
as an {Input,Output}Stream.
Posted by Eric Johnson <er...@tibco.com>.
Konstantin,
Konstantin Priblouda wrote:
>--- Alexander Hvostov <al...@aoi.dyndns.org> wrote:
>
>
>>A little while ago, I wrote a base64 {en,de}coder in
>>Java. Huzzah. Since I've
>>found out that you guys wrote one too, I thought I
>>should submit mine. It's
>>implemented as an OutputStream and InputStream pair,
>>though, so it's a bit
>>different from yours, which is why I thought to send
>>mine. It's public
>>domain, so do whatever you want with it. The two
>>source files are attached.
>>
>>
>
>That's really cool. I was playing with the same
>thoughts - I have
>to import / export binary content in XML, so it's
>really interesting.
>
>
>BTW, does somebody know XML parser, which works like
>SAX,
>but provides input stream of characters instead
>callbak with a StringBuffer? Allocating big
>strings/arrays is somehow uncool when you are about
>to save binary result into BLOB...
>
>
>
>
By which I think you're referring to org.xml.sax.ContentHandler? If the
contents of an element includes a large blob of continuous text, the
parsers are free to deliver this to your application in little chunks
(and in fact do break it into chunks) so as to save on the maximum
amount of memory the parser might be forced to allocate. Theoretically,
it is then *your* problem to figure out whether or not it is a good idea
to bundle all of the data up into a giant String or StringBuffer before
you process it.
Nobody said the SAX API makes life easy. An interesting point, at least
in the context of this discussion thread, is that you'd then need to
pass the *characters* off to the base64 decoder, but in chunks of a size
that the parser chooses, which unfortunately might not line up with the
four-character chunks that a base64 decoder wants
Hope that helps.
-Eric.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [codec] My own little base64 implementation, as an {Input,Output}Stream.
Posted by Konstantin Priblouda <kp...@yahoo.com>.
--- Alexander Hvostov <al...@aoi.dyndns.org> wrote:
> A little while ago, I wrote a base64 {en,de}coder in
> Java. Huzzah. Since I've
> found out that you guys wrote one too, I thought I
> should submit mine. It's
> implemented as an OutputStream and InputStream pair,
> though, so it's a bit
> different from yours, which is why I thought to send
> mine. It's public
> domain, so do whatever you want with it. The two
> source files are attached.
That's really cool. I was playing with the same
thoughts - I have
to import / export binary content in XML, so it's
really interesting.
BTW, does somebody know XML parser, which works like
SAX,
but provides input stream of characters instead
callbak with a StringBuffer? Allocating big
strings/arrays is somehow uncool when you are about
to save binary result into BLOB...
regards,
=====
----[ Konstantin Pribluda ( ko5tik ) ]----------------
Zu Verst�rkung meines Teams suche ich ab Sofort einen
Softwareentwickler[In] f�r die Festanstellung.
Arbeitsort: Mainz
Skills: Programieren, Kentnisse in OpenSource-Bereich
----[ http://www.pribluda.de ]------------------------
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org