Problème d'encodage du caractère €

Bonjour à tous,

Je suis actuellement confronté à un problème d'encodage et j'avoue que je commence à sécher.... :?

Sur nos plateformes de dev et de test, aucun soucis, par contre, chez mon client, impossible d'avoir le symbole € dans certaine contexte.

Je m'explique, ils ont a disposition une application JSF hébergé sur un serveur Tomcat sous Debian... Cette application travail avec un serveur Oracle sous Fedora... Au niveau de l'application en elle même, aucun soucis, le symbole € apparait sans problème dans le navigateur. Cette application dispose de fonctionnalités permettant d'exporter certaine donnée au format RTF à l'aide de Jasper Report ou bien au format PDF à l'aide d'un serveur LifeCycle. Que ce soit au format RTF ou PDF, impossible d'avoir le symbole €, on se retrouve avec un "?" à la place... L'appication propose également la possibilité de faire des exports CSV et là, aucun soucis....

Je suis preneur de toutes idées permettant d'orienter un peu mes recherches !!!

Merci d'avance !

Un problème de charset certainement.

A+

Salut,

Une piste serait de vérifier quel est l'encodage par défaut du système.
Il se peut que les outils que tu utilises pour générer du RTF ou du PDF soient configurables pour ne pas utiliser l'encodage par défaut dans la génération de documents.

Je ne vois que ça, car ton problème a l'air d'être lié plutôt à l'environnement qu'au "code".

A+

Merci bien pour ces réponses :mrgreen:

J'ai fait quelques test chez moi, maintenant faut que le client test tout ca :lol:
Ca peut prendre un peu de temps, c'est pas des rapides :mouarf:

En gros, je leur demandé de me fournir l'encodage par défaut de leur serveur Debian à l'aide de la commande

Code:

---

1 2	locale charmap

---

Ainsi que de tenter de forcer l'encodage de Tomcat dans le catalina.sh de la façon suivante :

Code:

---

1 2	JAVA_OPTS="-Dfile.encoding=utf-8"

---

Affaire à suivre !

Visiblement forcer l'encodage de Tomcat dans le catalina.sh ne change rien...
Par contre la commande

Code:

---

1 2	locale charmap

---

retourne chez aux :
ISO-8859-1
Au lieu de UTF8 chez moi... peut etre que le problème vient de là...

Toujours affaire à suivre :P

Et bien pas mieux.... :aie:

Mes deux propositions n'ont aboutis à rien... Tous les caracères € déjà présent dans l'appli apparaisse avec des "?" à l'envers dans l'appli... si un nouveau caractère € est inséré, tout se passe bien... Mais toujours le problème avec les PDF et RTF... :evilred:

Il va falloir que tu fasses une modification de ton code, afin de forcer l'encodage en UTF-8 lors de la génération de ces documents.

Toujours rien...

Ouep pour l'encodage, c'est ce que j'ai fait... je leur ai livré une version de l'application où il peuvent eux même forcer l'encodage des documents avec le charset de leur choix....
Mais que ce soit (chez eux)
- Serveur en ISO-bidule, document en ISO-bidule
- Serveur en ISO-bidule, document en UTF-8
- Serveur en UTF-8, document en UTF-8
Toujours le même résultat... le caractère s'affiche à l'écran mes pas dans les éditions...
Le problème ne pourrait pas venir d'un proxy?

Comment récupèrent-ils le fichier ?
Si c'est via FTP en mode ASCII par exemple, il se peut que ça foire un max...
Il faut qu'ils récupèrent le fichier en mode binaire.

A+

non non le fichier est récupéré à travers le navigateur, on envoie le fichier dans la réponse http, qui permet à l'utilisateur d'avoir une popup permettant d'ouvrir ou d'enregistrer le fichier sur son poste

Je viens de résoudre le même problème auquel j'ai été confronté aujourdhui!

J'ai fait une check list détaillée des points à vérifier sur mon blog:

(http://haveacafe.wordpress.com/2008/...ponse-serveur/)

Sinon quand tu dis

Citation:

---

on envoie le fichier dans la réponse http

---

leur éditeur sauvegarde-t-il bien le fichier avec le bon charset... ?

Alors la réponse est ..................... roulement de tambour .....................
Que mon client est un gros boulet :mouarf:

Il a recu un dossier technique où c'était ecrit en gras, caractère de taille 52 :
"Base oracle à configurer en UTF-8 !!"
Ils avaient beau dire OUI OUI, c'est fait, après vérification, ca n'etait pas du tout le cas.... maintenant que tout est un UTF-8, ca fonctionne impec" ! :king:

c'est toujours la faute au client de toutes manières, non ? :yaisse2: