We've done detection before...its always a huge performance and memory hog.
In any case, I don't think this method has been tried. So go for it and see
what happens.
-Andy
On 9/3/03 5:18 PM, "A. Rothman" <[EMAIL PROTECTED]> wrote:
> Hey guys,
>
> After experiencing some unicode trouble with HSSF today, namely setting the
> cell encoding before setting it's text (or lack thereof...), I figured since
> Java is unicode based it's not too friendly to require users to set unicode
> flags explicitly in order for unicode to work. I traced the problem down to
> UnicodeString.serialize(), and found some rather strange code that seems to do
> nothing (decomposing and creating a string, try and catch blocks that are
> identical...anyone have any ideas?), and thought we should have the serializer
> (or perhaps the constructor?) detect the case where the String contains
> non-ascii/iso-latin chars and set the encoding automatically. This can be as
> simple as a
>
> if (str.equals(new String(str.getBytes("iso8859_1"),"iso8859_1"))) // string
> can be compressed
> ...
>
> what do u say? any implications I didn't think of?
>
>
> -Amichai
>
--
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI
http://jakarta.apache.org/poi
For Java and Excel, Got POI?
The views expressed in this email are those of the author and are almost
definitely not shared by the Apache Software Foundation, its board or its
general membership. In fact they probably most definitively disagree with
everything espoused in the above email.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
