Problèmes d'encodage Windows/Linux avec Tomcat/JDBC
4 réponses
p0psy
Bonjour,
J'explique un petit peu le sujet de ce mail, j'ai actuellement une
application web (Java 1.5, Tomcat 5.5) qui expose un webservice (Axis
1.3). Ce webservice récupère une String et la compare avec une récupérée
de la base de données (MySQL 4.0, vieux driver org.gjt.mm.mysql, les
champ sont en "latin-1").
Mon appli web est "full UTF-8" et fonctionne bien sous windows. Lorsque
je la lance sur linux, ben ça ne marche plus.
En affichant ce que j'ai comme données, je récupère apparemment la bonne
chaine de carcatères depuis le web, par contre celle lue depuis la base
de données n'as pas l'air valide (caractères accentués remplacés par des
trucs bizarres, typique d'une mauvaise conversion unicode/iso-9959-1)...
Je n'avais pas le problème sur mon application avant (qui tourne en prod
sur du linux), mais elle n'était pas en unicode (mais je ne vois pas le
rapport entre la "présentation" en unicode et l'accès à la base de données).
Si quelqu'un a une idée ou a déjà rencontré le problème, je suis très
preneur :-).
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
TestMan
p0psy wrote:
Bonjour,
J'explique un petit peu le sujet de ce mail, j'ai actuellement une application web (Java 1.5, Tomcat 5.5) qui expose un webservice (Axis 1.3). Ce webservice récupère une String et la compare avec une récupérée de la base de données (MySQL 4.0, vieux driver org.gjt.mm.mysql, les champ sont en "latin-1"). Mon appli web est "full UTF-8" et fonctionne bien sous windows. Lorsque je la lance sur linux, ben ça ne marche plus.
En affichant ce que j'ai comme données, je récupère apparemment la bonne chaine de carcatères depuis le web, par contre celle lue depuis la base de données n'as pas l'air valide (caractères accentués remplacés par des trucs bizarres, typique d'une mauvaise conversion unicode/iso-9959-1)...
Je n'avais pas le problème sur mon application avant (qui tourne en prod sur du linux), mais elle n'était pas en unicode (mais je ne vois pas le rapport entre la "présentation" en unicode et l'accès à la base de données).
Si quelqu'un a une idée ou a déjà rencontré le problème, je suis très preneur :-).
Merci.
Est-il indiqué clairement quelque part que tes champs sont en Latin1 ? (Si, non, est-tu essayé de forcer la connexion à identifier les champs comme latin1 ?)
Perso s'il est possible de passer la base en UTF-8, je te le conseille car celà évite beaucoup de prises de tête. Quand on commence avec l'unicode, il vaut mieux tout passer une fois pour tout, celà évite des surprises ...
A+
TM
p0psy wrote:
Bonjour,
J'explique un petit peu le sujet de ce mail, j'ai actuellement une
application web (Java 1.5, Tomcat 5.5) qui expose un webservice (Axis
1.3). Ce webservice récupère une String et la compare avec une récupérée
de la base de données (MySQL 4.0, vieux driver org.gjt.mm.mysql, les
champ sont en "latin-1").
Mon appli web est "full UTF-8" et fonctionne bien sous windows. Lorsque
je la lance sur linux, ben ça ne marche plus.
En affichant ce que j'ai comme données, je récupère apparemment la bonne
chaine de carcatères depuis le web, par contre celle lue depuis la base
de données n'as pas l'air valide (caractères accentués remplacés par des
trucs bizarres, typique d'une mauvaise conversion unicode/iso-9959-1)...
Je n'avais pas le problème sur mon application avant (qui tourne en prod
sur du linux), mais elle n'était pas en unicode (mais je ne vois pas le
rapport entre la "présentation" en unicode et l'accès à la base de
données).
Si quelqu'un a une idée ou a déjà rencontré le problème, je suis très
preneur :-).
Merci.
Est-il indiqué clairement quelque part que tes champs sont en Latin1 ?
(Si, non, est-tu essayé de forcer la connexion à identifier les champs
comme latin1 ?)
Perso s'il est possible de passer la base en UTF-8, je te le conseille
car celà évite beaucoup de prises de tête. Quand on commence avec
l'unicode, il vaut mieux tout passer une fois pour tout, celà évite des
surprises ...
J'explique un petit peu le sujet de ce mail, j'ai actuellement une application web (Java 1.5, Tomcat 5.5) qui expose un webservice (Axis 1.3). Ce webservice récupère une String et la compare avec une récupérée de la base de données (MySQL 4.0, vieux driver org.gjt.mm.mysql, les champ sont en "latin-1"). Mon appli web est "full UTF-8" et fonctionne bien sous windows. Lorsque je la lance sur linux, ben ça ne marche plus.
En affichant ce que j'ai comme données, je récupère apparemment la bonne chaine de carcatères depuis le web, par contre celle lue depuis la base de données n'as pas l'air valide (caractères accentués remplacés par des trucs bizarres, typique d'une mauvaise conversion unicode/iso-9959-1)...
Je n'avais pas le problème sur mon application avant (qui tourne en prod sur du linux), mais elle n'était pas en unicode (mais je ne vois pas le rapport entre la "présentation" en unicode et l'accès à la base de données).
Si quelqu'un a une idée ou a déjà rencontré le problème, je suis très preneur :-).
Merci.
Est-il indiqué clairement quelque part que tes champs sont en Latin1 ? (Si, non, est-tu essayé de forcer la connexion à identifier les champs comme latin1 ?)
Perso s'il est possible de passer la base en UTF-8, je te le conseille car celà évite beaucoup de prises de tête. Quand on commence avec l'unicode, il vaut mieux tout passer une fois pour tout, celà évite des surprises ...
A+
TM
p0psy
Est-il indiqué clairement quelque part que tes champs sont en Latin1 ? (Si, non, est-tu essayé de forcer la connexion à identifier les champs comme latin1 ?) J'ai essayé avec et sans... je n'ai pas vu la différence.
Perso s'il est possible de passer la base en UTF-8, je te le conseille car celà évite beaucoup de prises de tête. Quand on commence avec l'unicode, il vaut mieux tout passer une fois pour tout, celà évite des surprises ... Je suis tout à fait d'accord, malheureusement mon application n'est pas
la seule à aller taper dans la base de données et si je change tout en unicode je vais me faire engueuler ;-).
Bon, après quelques autres test, ça fonctionne sur un de mes serveurs linux, c'est donc bien lié à la configuration de la machine... Alors je croyais faire du Java et de ce fait ne pas être "lié" à la machine de la sorte... Maintenant il faut que je trouve la différence de configuration entre mes serveurs, je vais bien m'amuser :-/.
Merci quand même pour la réponse. D'ailleurs si quelqu'un connaît le paramètre machine susceptible d'agir de la sorte...
Est-il indiqué clairement quelque part que tes champs sont en Latin1 ?
(Si, non, est-tu essayé de forcer la connexion à identifier les champs
comme latin1 ?)
J'ai essayé avec et sans... je n'ai pas vu la différence.
Perso s'il est possible de passer la base en UTF-8, je te le conseille
car celà évite beaucoup de prises de tête. Quand on commence avec
l'unicode, il vaut mieux tout passer une fois pour tout, celà évite des
surprises ...
Je suis tout à fait d'accord, malheureusement mon application n'est pas
la seule à aller taper dans la base de données et si je change tout en
unicode je vais me faire engueuler ;-).
Bon, après quelques autres test, ça fonctionne sur un de mes serveurs
linux, c'est donc bien lié à la configuration de la machine... Alors je
croyais faire du Java et de ce fait ne pas être "lié" à la machine de la
sorte...
Maintenant il faut que je trouve la différence de configuration entre
mes serveurs, je vais bien m'amuser :-/.
Merci quand même pour la réponse. D'ailleurs si quelqu'un connaît le
paramètre machine susceptible d'agir de la sorte...
Est-il indiqué clairement quelque part que tes champs sont en Latin1 ? (Si, non, est-tu essayé de forcer la connexion à identifier les champs comme latin1 ?) J'ai essayé avec et sans... je n'ai pas vu la différence.
Perso s'il est possible de passer la base en UTF-8, je te le conseille car celà évite beaucoup de prises de tête. Quand on commence avec l'unicode, il vaut mieux tout passer une fois pour tout, celà évite des surprises ... Je suis tout à fait d'accord, malheureusement mon application n'est pas
la seule à aller taper dans la base de données et si je change tout en unicode je vais me faire engueuler ;-).
Bon, après quelques autres test, ça fonctionne sur un de mes serveurs linux, c'est donc bien lié à la configuration de la machine... Alors je croyais faire du Java et de ce fait ne pas être "lié" à la machine de la sorte... Maintenant il faut que je trouve la différence de configuration entre mes serveurs, je vais bien m'amuser :-/.
Merci quand même pour la réponse. D'ailleurs si quelqu'un connaît le paramètre machine susceptible d'agir de la sorte...
olivier de SEDE
Est-il indiqué clairement quelque part que tes champs sont en Latin1 ? (Si, non, est-tu essayé de forcer la connexion à identifier les ch amps comme latin1 ?)
J'ai essayé avec et sans... je n'ai pas vu la différence.
Perso s'il est possible de passer la base en UTF-8, je te le conseille car celà évite beaucoup de prises de tête. Quand on commence ave c l'unicode, il vaut mieux tout passer une fois pour tout, celà évit e des surprises ...
Je suis tout à fait d'accord, malheureusement mon application n'est p as la seule à aller taper dans la base de données et si je change tout en unicode je vais me faire engueuler ;-).
Bon, après quelques autres test, ça fonctionne sur un de mes serveu rs linux, c'est donc bien lié à la configuration de la machine... Alor s je croyais faire du Java et de ce fait ne pas être "lié" à la machin e de la sorte... Maintenant il faut que je trouve la différence de configuration entre mes serveurs, je vais bien m'amuser :-/.
Merci quand même pour la réponse. D'ailleurs si quelqu'un connaît le paramètre machine susceptible d'agir de la sorte...
Bonjour,
Voici une proposition a mettre dans le script de lancement de tomcat:
LC_ALL=fr_FR.ISO8859-1;export LC_ALL
-- Olivier
Est-il indiqué clairement quelque part que tes champs sont en Latin1 ?
(Si, non, est-tu essayé de forcer la connexion à identifier les ch amps
comme latin1 ?)
J'ai essayé avec et sans... je n'ai pas vu la différence.
Perso s'il est possible de passer la base en UTF-8, je te le conseille
car celà évite beaucoup de prises de tête. Quand on commence ave c
l'unicode, il vaut mieux tout passer une fois pour tout, celà évit e
des surprises ...
Je suis tout à fait d'accord, malheureusement mon application n'est p as
la seule à aller taper dans la base de données et si je change tout en
unicode je vais me faire engueuler ;-).
Bon, après quelques autres test, ça fonctionne sur un de mes serveu rs
linux, c'est donc bien lié à la configuration de la machine... Alor s je
croyais faire du Java et de ce fait ne pas être "lié" à la machin e de la
sorte...
Maintenant il faut que je trouve la différence de configuration entre
mes serveurs, je vais bien m'amuser :-/.
Merci quand même pour la réponse. D'ailleurs si quelqu'un connaît le
paramètre machine susceptible d'agir de la sorte...
Bonjour,
Voici une proposition a mettre dans le script de lancement de tomcat:
Est-il indiqué clairement quelque part que tes champs sont en Latin1 ? (Si, non, est-tu essayé de forcer la connexion à identifier les ch amps comme latin1 ?)
J'ai essayé avec et sans... je n'ai pas vu la différence.
Perso s'il est possible de passer la base en UTF-8, je te le conseille car celà évite beaucoup de prises de tête. Quand on commence ave c l'unicode, il vaut mieux tout passer une fois pour tout, celà évit e des surprises ...
Je suis tout à fait d'accord, malheureusement mon application n'est p as la seule à aller taper dans la base de données et si je change tout en unicode je vais me faire engueuler ;-).
Bon, après quelques autres test, ça fonctionne sur un de mes serveu rs linux, c'est donc bien lié à la configuration de la machine... Alor s je croyais faire du Java et de ce fait ne pas être "lié" à la machin e de la sorte... Maintenant il faut que je trouve la différence de configuration entre mes serveurs, je vais bien m'amuser :-/.
Merci quand même pour la réponse. D'ailleurs si quelqu'un connaît le paramètre machine susceptible d'agir de la sorte...
Bonjour,
Voici une proposition a mettre dans le script de lancement de tomcat:
LC_ALL=fr_FR.ISO8859-1;export LC_ALL
-- Olivier
p0psy
Voici une proposition a mettre dans le script de lancement de tomcat: LC_ALL=fr_FR.ISO8859-1;export LC_ALL Je cherchais quelque chose dans ce genre, donc là je pensais que ça
allait être bon... mais non :-(.
Sinon j'ai trouvé la solution mais il faut que je regarde plus en profondeur. Dans le script de lancement de tomcat, dans les paramètres de la JVM j'ai rajouté : -Dfile.encoding=ISO-8859-1
Et ça marche. Le paramètre parle de lui-même, étant sous un linux j'imagine que l'approximation: socket = fichier est correcte, non ? Et donc avec ce paramètre l'encodage par défaut d'une socket est ISO-8859-1.
Sinon j'ai essayé avec : -Dsun.jnu.encoding=ISO-8859-1 Et ça marche aussi, mar contre je n'ai pas trouvé d'info sur ce paramètre, qu'est-ce que c'est ?
Donc, je continue mes questions (promis c'est la dernière) : Faut-il mieux utiliser file.encoding ou sun.jnu.encoding ?
Merci encore.
Voici une proposition a mettre dans le script de lancement de tomcat:
LC_ALL=fr_FR.ISO8859-1;export LC_ALL
Je cherchais quelque chose dans ce genre, donc là je pensais que ça
allait être bon... mais non :-(.
Sinon j'ai trouvé la solution mais il faut que je regarde plus en
profondeur.
Dans le script de lancement de tomcat, dans les paramètres de la JVM
j'ai rajouté :
-Dfile.encoding=ISO-8859-1
Et ça marche. Le paramètre parle de lui-même, étant sous un linux
j'imagine que l'approximation: socket = fichier est correcte, non ? Et
donc avec ce paramètre l'encodage par défaut d'une socket est ISO-8859-1.
Sinon j'ai essayé avec :
-Dsun.jnu.encoding=ISO-8859-1
Et ça marche aussi, mar contre je n'ai pas trouvé d'info sur ce
paramètre, qu'est-ce que c'est ?
Donc, je continue mes questions (promis c'est la dernière) :
Faut-il mieux utiliser file.encoding ou sun.jnu.encoding ?
Voici une proposition a mettre dans le script de lancement de tomcat: LC_ALL=fr_FR.ISO8859-1;export LC_ALL Je cherchais quelque chose dans ce genre, donc là je pensais que ça
allait être bon... mais non :-(.
Sinon j'ai trouvé la solution mais il faut que je regarde plus en profondeur. Dans le script de lancement de tomcat, dans les paramètres de la JVM j'ai rajouté : -Dfile.encoding=ISO-8859-1
Et ça marche. Le paramètre parle de lui-même, étant sous un linux j'imagine que l'approximation: socket = fichier est correcte, non ? Et donc avec ce paramètre l'encodage par défaut d'une socket est ISO-8859-1.
Sinon j'ai essayé avec : -Dsun.jnu.encoding=ISO-8859-1 Et ça marche aussi, mar contre je n'ai pas trouvé d'info sur ce paramètre, qu'est-ce que c'est ?
Donc, je continue mes questions (promis c'est la dernière) : Faut-il mieux utiliser file.encoding ou sun.jnu.encoding ?
