Ben Bookey wrote:
> Hi Allistair, Nikola, et al.
>
> Allistair
> =========
>
>>>>>>what made you give up setting up the encoding via the -djvm ??
>
>
> Nikola
> ======
>
>>>>>>Since you have to support multiple character sets, it would be cleaner
>
> if you chose UTF-8 for your DB, in the first place. I do realise that data
>
>>>>>conversion can be a tremendous task, so your mileage may vary.
>
>
> Q. Do you mean in converting the data inside the database ? It sounds like
> you have experience --> what does it involve?
That is exactly what I mean. Converting data already inside might be
impossible. If the input data encoding and DB encoding mismatch, there
is no telling what is actually inside. It is best to start from a fresh
DB, create it/set right encoding and load the data. Don't forget to use
client encoding to match.
My field is with PostgreSQL. There I would create a DB with encoding
'UNICODE' (UTF-8) and load data with "psql" (Oracle has "sqlplus"). In
the "psql" session I would set the session encoding to match data on the
input. That way I was able to load "Windows-1250" data into "UTF-8"
database, since PSQL carries out the conversion.
> Q. Any idea to the extent to which oracle, sqlserver and mysql supports
> utf-8 ?
>
> DBname supports utf?
> ==============================================
> oracle8
Definitely no Unicode, but all ISO-8559-* are there.
> oracle9
> oracle10
Has Unicode.
> sqlserver2000
> sqlserver97
> mysql41
Don't know.
Nix.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
|