probléme generation de fichier doc en arabe

Salut tout le monde.
Je génére un document word en arabe à partir d'un programme java, mes variables statiques arabes (ex : titre, sous titre, ...) sont declarées dans une interface (UTF-8), j'utilise weblogic pour deployer l'application.
le probléme c'est que ces variables ne s'affichent pas correctement en arable lors de la generarion du doc.

N.B : les données arabes prevenant de la base s'affichent correctement.

Je genere le doc a travers un OutputStream de type ByteArrayOutputStream

code :

Code:

---

1 2 3 4 5 6 7 8

ByteArrayOutputStream os = new ByteArrayOutputStream();   // code pour generer le doc   JRRtfExporter exp = new JRRtfExporter(); exp.setParameter(JRExporterParameter.CHARACTER_ENCODING, "UTF-8"); return os.toByteArray();

---

Merci d'avance pour vos reponse.

Hum.

Ça donne quoi si tu essaies d'enregistrer des données arabes de la base dans un fichier base.txt encodé en UTF-8 ?

Et si tu essaies d'enregistrer les constantes en question dans un fichier constantes.txt encodé en UTF-8 ?

Avec ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public class StoreAsUtf8 { public static void store(String string, File file) throws IOException { Writer writer = null; try { writer = new OutputStreamWriter(new FileOutputStream(file), "utf-8"); writer.write(string); } finally { writer.close(); } } }

---

je n'ai pas de probléme avec les données prevenant de la base, et les constates sont enregistrées dans une interface codée UTF-8.

je n'utilise pas FileOutputStream, j'utilise ByteArrayOutputStream

Je te demande pas ce que ça donne quand tu fais autre chose (parce que bon, tu l'as déjà dit dans ton premier message, je sais lire merci,) je te demande ce que ça donne quand tu fais ce que je dis.

Cela nous permettra de vérifier si tes String constantes et des String venant de la base de données sont correctes.
Mon petit bout de code étant petit et simple, il est facile de vérifier qu'il est totalement exempt de bug. Donc si quelque chose ne va pas quand on s'en sert, c'est que les paramètres avec lesquels on l'a appelé ont un problème. Si tout va bien, c'est qu'ils n'en ont pas. Simple.

les caractéres s'affichent comme ça : "رقـم"

Bon ben voilà. Il est là le problème. C'est la BDD ou c'est les constantes qui font ça ?

Ah, et tu es sûr que tu ouvres le fichier en utf-8 ?

oui je travaille avec eclipse, le fichier s'ouvre en UTF-8.
je genere un ear que je deploie avec weblogic. sous eclipse tout va bien, mais avec l'ear tjrs des problémes
je crois que l'encoding du fichier des constates change aprés le build

Ok je ne comprends rien à ce que tu racontes. Je t'ai demandé de faire des trucs et de nous expliquer le résultat.

Tu l'as fait, oui / non ?

Si oui, tu pourrais nous donner la liste complète des résultats, avec quoi, etc ?

je ne vois pas ou je peux integrer ton code. !!!
je travaille avec la librairie iText

Citation:

---

Envoyé par yasworld

je ne vois pas ou je peux integrer ton code. !!!
je travaille avec la librairie iText

---

Je fais pas dans la divination. Pour résoudre un problème il faut le diagnostiquer.

En l'état ce que je peux te dire, c'est que tu as un conflit de charsets. Où ça, sur quoi ? N'importe où, absolument tout est possible.
J'ai essayé de te donner des moyens d'isoler la partie problématique, mais tu ne sais pas intégrer mon code.

C'est pourtant pas compliqué, il faut l'appeler une fois avec une des tes constantes, et une fois avec du contenu de la BDD.

Citation:

---

Envoyé par yasworld

je crois que l'encoding du fichier des constates change aprés le build

---

J'ai oublié de dire : cela est impossible. Une fois qu'un .class est compilé, il est compilé. L'encodage d'une String ne peut plus changer, c'est de l'UTF-16, pas le choix.

Au moment de la compilation, par contre, il faut effectivement savoir en quel encodage est le fichier .java. Si c'est de l'utf-8 ou autre chose.

Ok merci
je vais essayer de voir à quel moment je perd l'encodage de ma classe de constantes.

votre fichier java est codé en utf-8. Bien, mais êtes vous sur d'avoir bien configuré l'ide pour que le compilateur lsie les fichiers source en utf-8?


On peux voir le bout de code où sont déclarées les constantes? Et un exemple de fichier généré?

Citation:

---

Envoyé par tchize_

On peux voir le bout de code où sont déclarées les constantes? Et un exemple de fichier généré?

---

le code dans le fichier des constantes :

Code:

---

1 2 3 4 5 6 7 8 9 10

public interface IConstantesImpression { // exemple de variable public final static String CELL3_2 = "الســاعــة"; // ecrire en arabe et pas avec ces codes que vous vouyez . public final static String CELL3_3 = "رقـم"; public final static String TXT_LE = "فــي"; }

---

quelque contenu du fichier doc généré :

ال�قــــرة 1
رقـم :

Citation:

---

Envoyé par tchize_

votre fichier java est codé en utf-8. Bien, mais êtes vous sur d'avoir bien configuré l'ide pour que le compilateur lsie les fichiers source en utf-8?

---

Comment on peut faire ça, je génér l'ear avec Ant.?

Citation:

---

Envoyé par yasworld

Comment on peut faire ça, je génér l'ear avec Ant.?

---

Code:

---

<javac encoding="utf-8" srcdir="..." destdir="..."/>

---

Effectivement, c'est l'explication la plus probable, l'exécution dans Eclipse et l'exécution dans weblogic étant évidemment le résultat de deux builds différents.
J'aurais dû y penser, toutes mes confuses, tout ça.

aucune solution ne marche bien
j'ai inseré la ligne suivant au debut du fichier de build

Code:

---

<?xml version="1.0" encoding="utf-8"?>

---

et tjrs le même resultat

Si vous remplacez votre code par

Code:

---

1 2 3 4 5 6 7 8 9 10

public interface IConstantesImpression { // exemple de variable public final static String CELL3_2 = "\u0627\u0644\u0633\u0640\u0640\u0627\u0639\u0640\u0640\u0629"; public final static String CELL3_3 = "\u0631\u0642\u0640\u0645"; public final static String TXT_LE = "\u0641\u0640\u0640\u064a"; }

---

ca donne quoi? Histoire de confirmer ou non la culpabilité du compilateur.

Citation:

---

Envoyé par tchize_

Si vous remplacez votre code par

Code:

---

1 2 3 4 5 6 7 8 9 10

public interface IConstantesImpression { // exemple de variable public final static String CELL3_2 = "\u0627\u0644\u0633\u0640\u0640\u0627\u0639\u0640\u0640\u0629"; public final static String CELL3_3 = "\u0631\u0642\u0640\u0645"; public final static String TXT_LE = "\u0641\u0640\u0640\u064a"; }

---

ca donne quoi? Histoire de confirmer ou non la culpabilité du compilateur.

---

c'est quel type d'encodage celui la ?
je vais essayer cet solution demain et je vais vous repondre

Merci à vous tous pour vos reponses

c'est juste des caractère d'échappement unicode. C'est justement indépendant de l'encodage.

Citation:

---

Envoyé par tchize_

Si vous remplacez votre code par

Code:

---

1 2 3 4 5 6 7 8 9 10

public interface IConstantesImpression { // exemple de variable public final static String CELL3_2 = "\u0627\u0644\u0633\u0640\u0640\u0627\u0639\u0640\u0640\u0629"; public final static String CELL3_3 = "\u0631\u0642\u0640\u0645"; public final static String TXT_LE = "\u0641\u0640\u0640\u064a"; }

---

---

avec ce codage tout passe bien
donc comment je peux convertir tout le texte arabe en ce codage?
Merci

Chaque caractère est sous la forme \uXXXX où XXXX est un nombre de 4 chiffres hexadécimaux, qui représente le code point unicode du caractère.

Dans le cas de ا son code point unicode est 1575 (décimal), soit 627 (hexadécimal) il faut donc l'écrire \u0627 .

http://rishida.net/tools/conversion/ permet de faire la conversion facilement : copier-coller le texte arabe, cliquer sur "convert" et récupérer le résultat de "JavaScript escapes", qui sont les mêmes qu'en Java.

Note : d'ordinaire je ne recommande pas de faire ça, c'est illisible.
Quand on veut éviter de mettre du non-ASCII dans son code source Java, je recommande plutôt d'externaliser les textes dans des fichiers ressources en UTF-8, puis de dire à Java, au démarrage, d'ouvrir les fichiers ressources en UTF-8 et lire les textes de là. Comme ça, les textes restent lisibles, et ils ne sont pas dans les fichiers .java.
Mais bon, ici le principal problème de la personne, c'est qu'elle ne s'en sort pas pour vérifier si un fichier est bien en UTF-8 et pour dire à ses programmes de l'ouvrir comme tel.

ce n'est pas nécessaire. Ca démontre juste que vous écrivez votre code source dans un codage qui n'est pas le meme que celui que vous utilisez avec voter compilateur. Il suffit simplement d'être cohérent et d'utiliser le meme encodage des deux cotés (Compilateur et éditeur).

Merci beaucoup les amis, je vais essayer de convertir le texte mais je vais commenter chaque variable avec la signification en arabe du code générer