Je suis en train de mettre en place un système de traduction d'une appli web écrite en Java (Servlet / JSP).
base de donnée qui fait les correspondances suivantes :
ID Message + ID Langage => Libellé
Avec les langues qui ont un alphabet latin, tout roule.
Par contre, quand on veut traduire en Hébreux, Arménien, Japonais, etc... ça pose problème.
La colone de libellé est de type nvarchar (contient donc de l'Unicode, ce qui permet d'y mettre aussi bien des caractères latins que des caractères hébreux, japonais ou autre, sans se soucier du charset).
Le problème, c'est que, quand je tente de récupérer la valeur de ce champ, s'il contient des caractères latin, ça roule. Par contre, si j'y écrit des caractères hébreux ou autre, quand j'appelle le getString sur la colone concernée, je ne récupère que des ? et de espaces. Idem, si je récupère un tableau de byte, il contient les codes ascii de ? et d'espaces.
Des idées ?

quel db/driver?

(j'ai eu le probleme avec mysql, et en fait il faut spécifier l'encoding dans l'url de connection qu'on passe au driver jdbc)

euh bon, SQLServer, donc...
exemple, avec les drivers altinav:
http://www.atinav.com/products/ave [...] htm#feat17
(euh par contre faudra m'expliquer pourquoi ils veulent mettre des guillemets dans leurs urls, mais bon, passons)
 
autre driver, je sais pas de qui:
http://www.inetsoftware.de/English [...] Converting
 
bref, t'as pigé, va voir les docs de ton driver

Non, mais ce que je voudrais moi, c'est pouvoir stocker aussi bien des caractères chinois, hébreux, arménien, latins, etc, tout ça dans un même champ. Pour ça, nvarchar va m'etre utile.
En fait il permet de s'affranchire de l'encoding habituel, et de tout stocker en unicode.
A mon avis, l'option "encoding" à laquelle tu fais référence correspond à la propriété "charset" de mon driver :
http://jtds.sourceforge.net/faq.html
 
Voila une petite copie du passage qui nous interresse :

 
PS : désolé si je dis des conneries, mais je m'y perd un peu dans tout ça, ces histoires d'encodage, d'unicode, UTF-8, et tout ça.

essaie quand meme
et puis niveau client, il faut aussi lui dire quel est ton encodage, pas lui rebalancer tout ds la gueule pour qu'il devine

En fait je crois que j'ai compris.
SQL Server permet de stocker des caractères unicode, à l'aide de l'UCS-2
En Java, les caractères sont codés en unicode aussi, mais suivant la norme UTF-16.
D'ou problème quand j'essaye de stocker des caractères spéciaux depuis mon code Java, dans ma base de données SQL erver. (et pb dans l'autre sens aussi).
Il faudrait que j'arrive à convertir les bytes de ma chaines de char en UCS-2. Problème : la classe Charset n'inclus pas l'interprétation de l'UCS-2 en standard. :-(
 
(extrait de Javadoc : type d'encodages supportés en standard)

UCS2?
 
 
tu sais quoi? utilise un bete varchar et utilise le param dont tu me parlais plus haut

impossible. Avec un bête varchar, je peux pas faire d'unicode, donc pas d'idéogrammes chinois je crois, et en tout cas, je suis sur que je n'pourrais pas mettre ET des idéogrammes chinois ET des caractères hébreux, etc. Avec un varchar, on se limite à un charset particulier.

Brêve description des normes d'unicode :
http://alis.isoc.org/glossaire/unicode.fr.htm

t'as essayé? pq tu pourrais pas encoder de l'unicode dans un varchar?

Ben, c'est comme ça, j'y peux rien moi.
CF (voir varchar et nvarchar) :  
http://www.laltruiste.com/document [...] erver.html

je te parle d'encodage, pas des types natifs d'sqlserver.
 
re-t'as essayé ?

J'avoue, j'ai pas essayé...
 
J'vais manger un bout et j'essaye. Je vous (te) tiens au courant.

Un petit post, juste pour dire que j'ai tjs pas essayé du varchar, mais voici sur jguru un problème qui semble être le même que le mien. Sans réponse ! :-(  
http://www.jguru.com/faq/view.jsp?EID=114155

Au fait, j'ai essayé avec du varchar. Le problème est le même. Par contre j'arrive à un meilleur résultat en insérant mes données de cette manière (voir le N avant les données) :

 
Ce problème est donc résolu. Mais, ho ho, 'faudrait pas que je me croie tiré d'affaire moi ! :-/
 
Voir la suite ici :
http://forum.hardware.fr/forum2.ph [...] 0&subcat=0