db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Derby and character set encodings
Date Thu, 06 Sep 2007 17:58:13 GMT
This is mixing a lot of things up.  I also may use the wrong
terminology here.

Character set encodings really only come into play with tools like
ij, and import getting the string from the environment into derby.  The more
standard interaction is using jdbc to load a java string into derby.
At that level we don't do anything with encodings.

We happen to use a modified utf8 to store stuff to disk, and this is
not configurable.  But no user interface should depend on this encoding, 
and Derby could change this storage in the future.

Logically all strings at runtime are converted to standard java char.

Before 10.3 we always used standard java string compare which did a 
numerical comparison of the unicode value of chars to arrive at 
ordering.  That is still the default.  In 10.3 an option was added to
set the territory based collation when the database is created such that 
comparison is dependent on the territory of the database.  For this 
standard java
rule based Collator interfaces are used.  This is documented in the latest
derby release.

David Van Couvering wrote:
> Hi, all.  I am getting some questions from Ken Frank NetBeans
> internationalization quality team about Java DB and character set
> encodings.  Rather than try and play go-between, I'm including him
> here so he can directly ask any follow-on questions.
> Ken would like to understand how Derby makes use of character
> encodings, and how it is affected by  various settings.  How does
> Derby handle things if the encoding is set to something different from
> our default of UTF-8?  Are we impacted, or do we rely on Java routines
> such as the Collator and Comparator class to handle this?
> Sorry if I'm talking out my ear, i18n is not one of my fortes.
> Thanks,
> David

View raw message