Pb Encodage UTF-8 pour Ooo

Bonjour,

Je fais générer dans une appli XMLRAD, un flux XML qui est l'équivalent du fichier content.xml intégré dans un document OpenOffice Writer.
J'injecte ensuite ce flux dans un modèle OpenOffice (il suffit d'ajouter ce fichier content.xml dans le zip correspondant au doc Ooo).

Quand j'essaie d'ouvrir le doc Ooo, ce dernier me jète en disant qu'il y a une erreur de format à telle position p.
La raison est que le flux XML injecté n'est pas encodé UTF-8, car dans ce cas tout fonctionne ok.

Alors j'ai essayé de voir dans le framework ce qu'on pouvait paramétrer.
Par exemple XMLC_Encoding, sans succès.
Puis aussi partout dans le code source où j'ai vu ISO-8859-15, j'ai remplacé par UTF-8.
Et pour finir, j'ai activé la directive de compil {$DEFINE USE_STREAM}
et modifié le code

Code:

---

1 2 3 4 5

FWriter.Charset := 'UTF-8';   au lieu de :   FWriter.Charset := 'ISO-8859-15';

---

Toujours sans succès, XMLService.CreateDocument() me ressort toujours un flux XML pas encodé UTF8. Une idée alors ?

Sylvain
___________________
Delphi 7, XMLRAD 2005

pour avoir une sortie en encodage UTF-8 par le XSL il faut:
- Dans InitParams: XMLC_Encoding=UTF-8
- Utiliser USE_STREAM dans le XMLCursor.pas avec le

Code:

---

FWriter.Charset := 'UTF-8';

---

- dans le XSL:

Code:

---

<xsl:output encoding="UTF-8"/>

---

le résultat de la trasformation donnera alors une chaine de caractère XML:

Code:

---

1 2 3 4

<?xml version"1.0" encoding="UTF-8"?> <document> ... </document>

---

Ces points sont ok, et malgré tout ça continue à coincer.
J'ai peut-être une idée...

Quand XMLCLX génère un PDF, il passe par une procédure ConvertHTMLtoPDF qui elle même sauvegarde temporairement le flux XML produit par les instructions du XMLGram. Je suis sensé récupérer ce flux un peu plus tard, pour le réinjecter dans un document modèle OpenOffice.

Cette sauvegarde est effectuée via la fonction WriteAnsiStringToFile(Result, HTMLFileName); et à priori, c'est lors de cette sauvegarde que je perds mon encodage UTF-8.
Cette dernière procédure contacte l'API Win32 : CreateFile, qui manipule le fichier par défault en ANSI.

A partir de ce constat, vous en pensez quoi ?

avant le WriteAnsiStringToFile il faut que tu vérifies que tu as déjà l'encoding dans ta chaine. La fonction ne vas pas retirer l'encoding, elle ecrit le fichier tel quel.

Citation:

---

Envoyé par RDM

avant le WriteAnsiStringToFile il faut que tu vérifies que tu as déjà l'encoding dans ta chaine. La fonction ne vas pas retirer l'encoding, elle ecrit le fichier tel quel.

---

Avant de passer par WriteAnsiString, la chaîne est bien encodée.
Pour en être sur, j'ai modifié le code comme suit :

Code:

---

1 2 3 4 5

... try WriteAnsiStringToFile(Result, HTMLFileName); ExecuteCmdLine(HTML2PDF, ParamLine, Html2PdfPath); ...

---

par

Code:

---

1 2 3 4 5 6 7

... try tempXML := TXMLCursor.Create; tempXML.LoadXML(Result); tempXML.Save(HTMLFileName); ExecuteCmdLine(HTML2PDF, ParamLine, Html2PdfPath); ...

---

Avec mon patch (enregistrement via XMLCursor), je conserve un bon encodage, contrairement à la solution WriteAnsiStringToFile.
Ca parait logique puisque WriteAnsiStringToFile passe par l'API Win32 CreateFile. Et la doc sur CreateFile précise que pour l'unicode il faut appeller CreateFileW :

Citation:

---

Unicode

Implemented as CreateFileW (Unicode) and CreateFileA (ANSI). Note that Unicode support on Windows Me/98/95 requires Microsoft Layer for Unicode.

---

qu'est-ce que tu appelles "bon encodage" ? a quoi tu le voix ?
un CreatFile ne supprime pas <?xml version="1.0" encoding="UTF-8" ?>
cela fait partie de la chaine de caractère qui est erite sur disque.
le CreateFileW enregistre le texte en Unicode 16 bits
UTF-8 est un encodage 8 bits

Citation:

---

Envoyé par RDM

qu'est-ce que tu appelles "bon encodage" ? a quoi tu le voix ?
un CreatFile ne supprime pas <?xml version="1.0" encoding="UTF-8" ?>
cela fait partie de la chaine de caractère qui est erite sur disque.
le CreateFileW enregistre le texte en Unicode 16 bits
UTF-8 est un encodage 8 bits

---

Désolé pour le nombre de bits... m'a trompé :oops:
Mon problème se visualise de cette manière : les accents deviennent des rectangles, enfin tu vois un peu le genre.

Je décris à nouveau la chaîne de génération :

1. Je crée un modèle OpenOffice Writer
2. J'extrais de ce modèle le contenu xml (Content.xml), encodé en UTF-8, qui représente le document.
3. J'enveloppe ce modèle dans un xsl, comme ça de base le xsl fait un <xsl:copy-of>. Il devient ainsi possible via xsl de modifier le modèle original.
4. Lors du CreateContent, ce xsl (3.) génère le XML. Ce XML est toujours au format UTF-8, en suivant les recommandations que tu as posté plus haut.
5. Lorsque ce flux XML est sauvegardé via CreateFile, le drame se produit : il pète l'encodage, et je n'ai pas ce problème en enregistrant le même flux avec XMLCursor. Il doit bien y avoir une différence entre WriteFile et TXMLCursor.Save

le .XML remet peut être dans un autre encoding
essaye alors EncodeStringUTF8 qui se trouve dans XMLUtils

Citation:

---

Envoyé par RDM

le .XML remet peut être dans un autre encoding

---

hug ? moi y'en a pas comprendre 8O
Si tu parles de ma méthode d'enregistrement via XMLCursor, c'est la seule où je retrouve un encoding identique après enregistrement par rapport au flux de départ.
Via WriteFile, ça part en vrille.

Citation:

---

essaye alors EncodeStringUTF8 qui se trouve dans XMLUtils

---

A la sortie du XSL, le flux résultat est déjà en UTF-8. Je trouve dommage de sauvegarder en un autre encoding pour le réencoder via EncodeStringUTF8, surtout que rien ne me garantit que je vais retrouver proprement le document d'origine.

De toute façon, maintenant ça fonctionne bien, le pdf est bien généré. Il me reste un dernier détail innatendu : Au moment de renvoyer le fichier pdf au navigo (SendFile), ce dernier Freeze. Acrobat est instancié, mais la fenêtre n'affiche rien. Gloups, il a décidé de m'en faire baver décidemment, ça vaut cher la conversion PDF... :evil:

cf la FAQ :)
http://xmlrad.developpez.com/faq/?pa...portPDFAcrobat

C'est bien ça, il faut ajouter XMLC_GZIP=0 pour IE.
Merci,

Sylvain