2010-12-29 1 views
1

Je suis un peu coincé sur celui-ci. Je ne suis pas un gourou Java ou Oracle, alors s'il vous plaît donner des réponses détaillées :)Problème d'encodage oracle + java lors de l'insertion

J'ai un service web qui insère quelque chose dans la DB. le web-service est hébergé sur l'axe. le db est oracle propriétés suivantes:

NLS_LANGUAGE AMERICAN 
NLS_TERRITORY AMERICA 
NLS_CHARACTERSET ZHS16GBK 

le service Web est hébergé sur Windows Server 2008, version anglaise, mais j'ai changé les paramètres régionaux du système chinois

maintenant les données après insertion a encodage problème et montre des caractères étranges comme ????, exxk ??

le fichier jws a un codage GBK. et les données qui sont insérées dans le DB sont codées en dur dans le fichier [nous ne le lisons pas à partir de REQUEST]

[edit] juste une chose, il n'est pas possible de changer le DB entier en utf-8 comme il a beaucoup de tables et des données

[modifier plus] pour rendre les choses plus claires

la machine accepte les données de deux sources. Fondamentalement, il est utilisé pour envoyer et recevoir des sms/mms à nos utilisateurs abonnés. principalement, il fonctionne avec le centre de contrôle d'opérateur de GSM où tous les codages sont manipulés en GBK. D'autre part, la machine accepte également les demandes du site Web pour envoyer des sms/mms aux utilisateurs. Ici, l'encodage est géré en UTF-8. Si le site veut envoyer un sms à l'utilisateur, il appellera un web-service sur cette machine qui va insérer des données dans db [notre problème est ici]. puis un service Windows vérifie continuellement la base de données et s'il trouve une nouvelle demande d'envoi de sms/mms, il envoie les sms/mms et supprime l'enregistrement. Tout fonctionnait correctement sur l'ancienne machine car elle avait la version chinoise de Windows 2003. Nous avons mis à jour vers un nouveau serveur et installé la version anglaise du serveur Windows 2008 dessus. et maintenant les données sont déformées après les insertions de service Web dans DB.

+0

Pouvez-vous mieux montrer l'ensemble pipeline de traitement à partir duquel les données proviennent, à l'endroit où il est traité, à l'endroit où il est stocké et, enfin, la façon dont il est examiné. Je ne vois pas très bien quel est le rôle du service Web. Pouvez-vous nous dire à quel moment dans le pipeline les données sont toujours correctes? Je doute que l'insertion elle-même soit le problème car Java et Oracle sont tous deux au courant des encodages et des jeux de caractères et se plaignent s'ils ne peuvent pas le convertir. – Codo

Répondre

1

Définissez le jeu de caractères sur UTF8.

+0

ce n'est pas une option faisable .. car il y a trop de tables et trop de données ... des outils pour l'automatiser? – Ahmad

0

Je recommande également de choisir UTF8 comme charset de base de données.

Attention, car Java utilise par défaut le codage UTF16. Pour définir l'encodage par défaut utilisé par java, utilisez le « file.encoding » drapeau:

java -Dfile.encoding = UTF8 ...

je jamais entendu parler du charset ZHS16GBK, mais il ne semble pas être pris en charge par java:

http://download.oracle.com/javase/1.4.2/docs/guide/intl/encoding.doc.html

+1

@arnaud - Java utilise toujours les chaînes UTF-16 et la définition de 'file.encoding' (ce qui ne devrait jamais être fait) ne changera rien; le codage de transcodage par défaut pour les E/S dépend de la plateforme. ZHS16GBK est chinois simplifié et il est pris en charge par Java. L'utilisation de l'UTF-8 est quelque chose avec lequel je serais d'accord. – McDowell

+0

@McDowell - Eh bien, si vous voulez lire/écrire correctement UTF-8 à partir de fichiers, de sockets, etc., c'est la manière la plus simple de le faire. Par curiosité, pourquoi cela serait-il mauvais? ... ouais, eh bien, sauf si vous voulez gérer plusieurs types d'encodage à la fois ce qui est pénible dans le ... ... et pourquoi ZHS16GBK n'apparaît-il pas dans la liste des encodages supportés? – dagnelies

+0

@arnaud - RE 'file.encoding': _La propriété" file.encoding "n'est pas requise par la spécification de la plateforme J2SE; c'est un détail interne des implémentations de Sun et ne doit pas être examiné ou modifié par le code utilisateur. Il est également destiné à être en lecture seule; il est techniquement impossible de prendre en charge le paramétrage de cette propriété à des valeurs arbitraires sur la ligne de commande ou à tout autre moment lors de l'exécution du programme._ http://bugs.sun.com/view_bug.do?bug_id=4163515 Vous pouvez le faire; vous pourriez avoir de la chance. – McDowell