Caractère non UTF-8 toujours présent ?

Bonjour à tous,

j'ai un fichier XML que je dois transformer en plusieurs fichiers XML, jusque là rien de très nouveau.

J'ai un champ "title" et un champ "description" dans le fichier source que je récupère via OmniXML en méthode SAX.

Je procède de la manière suivante pour écrire mon info dans mon fichier de sortie:

Code:

---

1 2 3

s := ' <field name="ti"><![CDATA[' + UTF8Encode(fTitle) + ']]></field>'+#13; fStreamOutPut.Write(PChar(s)^, Length(s));

---

Cela fonctionne très bien dans 95% des cas, mais dans 5% j'ai encore des caractères non UTF-8 présent dans mon fichier
de sortie dans le champ "title" et/ou "Description"

De ce que je peux voir ce sont les caractères 0080 et 0094 qui ne sont pas virés (ou encodés)

Y a-t-il un moyen de virer ses caractères définitivement ?

D'avance merci pour votre aide,

Cdlt,
Bruno

En regardant le fichier source de plus prêt je m'aperçois que c'est cette ligne qui pose problème (parmi tant d'autres...mais avec les mêmes entités)

Code:

---

<p id="P-0010" num="0010"> DE 100 05 898 A1 describes a thus far unexploited concept&#x2014;referred to as nucleation collision&#x2014;for dispersing cold fog by employing dry ice jets, that is capable of efficiently, i.e. rapidly and cost-effectively, remove cold fog. </p>

---

c'est le — qui provoque l'erreur.

j'avance...

Je stocke le champ description dans un TStringList, serait il possible que cela soit quand je fais le ts.add(str); (où str contient —) qui pose problème ?
car je n'ai pas l'impression que cela soit un problème d'encodage utf-8 mais plutôt une conversion pendant le add, qu'en pensez vous ?

Moi fichier XML source possède bien la ligne <?xml version="1.0" encoding="UTF-8"?>

retour en arrière.... la TStringList n'y est pour rien, même chose avec une simple string.

impossible pour moi de gérer certaines entités html comme cette fameuse

Code:

---

—

---

Est-ce que quelqu'un aurait une fonction pour convertir les Hex Code to Html Entity ?

cela pourrait résoudre mon problème non ?

Bon la conversion des entités ne résout pas mon problème....

je continue

Je ne connais comment on peut représenter les caractères Unicode en Delphi, mais as-tu testé une moulinette? :mrgreen: :mrgreen:

Entrée: 'une chaîne de caractère gentille X#2014; enfin presque' (<- Le X est l'esperluette)
Sortie: 'une chaîne de caractère gentille' + #2014 + ' enfin presque'

Ou 'une chaîne de caractère gentille \u2014 enfin presque'

Salut Foetus,

j'ai essayé pas mal de moulinettes faites maison comme par exemple:
remplacer: &#x2014; par --
mais hélas bizarrement cela n'a aucun effet, comme si il recherchait le _ (mdash) au lieu du &#x2014;
et pourtant mon fichier source contient bien le text &#x2014;

je retrouve encore en sortie un caractère non utf-8 qui me plante mon import dans ma base en m'indiquant invalif utf-8...

je vais déjà chercher pourquoi je n'ai pas le search remplace qui ne fonctionne pas, surement que dans ma TStringList où je stoque ma ligne
le &#x2014; est converti, ou pas j'en sais plus rien...

la misère, une journée de perdu pour cette m.... :)

c'est bien ça ma ligne un fois lu est stockée déjà avec les _ (mdash) et non le code &#x2014;

c'est donc omniXML qui traduit direct :

' DE 100 05 898 A1 describes a thus far unexploited concept—referred to as nucleation collision—for dispersing cold fog by employing dry ice jets, that is capable of efficiently, i.e. rapidly and cost-effectively, remove cold fog. '

alors que dans mon fichier source j'ai:

<p id="P-0010" num="0010"> DE 100 05 898 A1 describes a thus far unexploited concept&#x2014;referred to as nucleation collision&#x2014;for dispersing cold fog by employing dry ice jets, that is capable of efficiently, i.e. rapidly and cost-effectively, remove cold fog. </p>


Mais alors comment lui dire de me garder la forme &#x2014; ?

Parce que ton problème est simple :mrgreen: X&<code caractère>; ( X est l'esperluette), c'est juste l'échappement XML d'un code Unicode.

En C/ C++ il y a '\x<code caractère>', '\u<code caractère>' et '\U<code caractère>'
En Perl, apparemment c'est juste '\x<code caractère>'

Donc simple. Reste juste à trouver l'échappement Unicode de Delphi.

Simple, sauf si tu as une merdouille comme omniXML :whistle:

je viens d'utiliser un composant de la suite Alcinoe et j'ai une option ignoreXMLReferences et là je garde bien les &#x2014; que je peux donc garder ou virer ou remplacer,

je vais creuser cette piste !

bien voilà plus d'erreur lors de l'indexation mais bien sûr impossible de faire des recherches dans ma base sur les infos qui contiennent
des &#x....;

par exemple:

je recherche l'auteur "Delev Mötter" mais comme il est indexé sous la forme "Delev M&#xf6;tter" ben je le trouve pas...

aarrgghht...j'en peux plus de ces codages...:aie:

Non c'est un truc de dév poilu, un vrai 8-) :mouarf:

Il faut, par exemple, que tout l'interne de ton programme manipule de l'UTF-8 et que tu fasses les conversions UTF-8 <-> UTF-16 lorsque tu passes des données à la couche "Windows" (cela peut-être une IHM)

Dans ton cas, ton "Delev Mötter" devrait est stocké en UTF-8 dans ta base de données, et faire une conversion pour la recherche parce que l'utilisateur saisie un utilisateur en UTF-16.

bien pour résoudre le problème, j'ai viré le CDATA du fichier dest que j'importe dans ma base et là c'est tout fonctionne !