----- Original Message -----
From: Ari Halberstadt <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 25, 1999 1:34 PM
Subject: Re: HTMLEncode
> Taylor Gautier <[EMAIL PROTECTED]> wrote:
> >I have to concur, this is one of the more annoying things about building
> >dynamic pages with current Java solutions.
> >...
>
> Due to the lack of a standard API there must be quite a few HTMLEncode
> variants out there (including my own, with slight variations for cookies,
> urls, etc.)
Yep, I've got one too (detects urls also).
I think Sun should supply an interface defining an HTML utility like object,
that has functions such as HTML.encode(), HTML entity definitions and the
like. Then vendors or private parties can be free to implement their own
favorite methods, but they will all be interchangeable.
<sigh> What is the mantra, write once, run everywhere? Not yet anyway...
> >FYI, Myriam, for better efficiency (for the time being) you should use
the
> >toCharArray() function of a String (indexing into an array repeatedly is
far
> >faster than calling an API to do it for you) and also change res to be a
> >StringBuffer and use res.append("<"); etc.
>
> Is it more efficient to call toCharArray, which allocates a new array of
> characters, than to call charAt? It probably depends on how many times you
> encode strings and how long are the strings. You can actually improve
> memory allocation a bit by only allocating a string buffer and a new
string
> if the string contains characters that need encoding (contrast this with
> String.toLower, which always allocates a new String). For most
applications
> it probably hardly matters to performance provided you use a StringBuffer
> (as you suggest) and not the += operator.
>
You are probably mostly right, it will definitely depend on the size of the
strings and how often you encode them. Just as a test, I found that for a
string of length about 100 characters, using the toCharArray was about 33%
faster. For about 1000 characters, I found it to be about ~40% faster.
Tested on a 350 mhz Win98 system, with JDK 1.2.
Clearly this method uses approximately 3x the memory space (including the
original string itself, of course) of the original string, while the other
method only uses 2x. So I guess it would just depend on what you wanted to
achieve.
I was thinking about JNI'ing the sucker. It actually does consume a
non-trivial amount of processing time for my application.
-taylor
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
