encodage récalcitrant :(

Bonsoir,

me revoila déjà vers vous pour un nouveau défi ...

dans ma base de donnée, je vais bien sûr rentrer ma collection de sable, mais j'envisage aussi d'y intégrer des sables disponibles sur des liste d'échange d'autres collectionneurs ...
Je vais donc récupérer ces listes d'échange sur le net. Avec la méthode get() du composant indy TIdHTTP j'arrive à récupérer le contenu d'une page .html. Mon problème vient des pages encodées en UTF-8 que je n'arrive pas à convertir au format UnicodeString utilisé par défaut par le Builder XE :(

Selon la doc Embarcadero la methode IdHTTP->get() me retourne un String

Citation:

---

(function Get(
AURL: string
): string; overload;

---

A propos que signifie le overload ?

Je suppose que si la page .html est déclarée en UTF-8 mon string doit aussi être en UTF-8 ... "Naïvement", je pensais donc qu'après un UTF8ToUnicodeString(maPage) tout irait bien : ERREUR !!
Quoi que je fasse, si je met ma page dans un mémo par exemple tous les caractères accentués sont mal restitués - exemple : é à la place de é :(

Quelqu'un a-t-il déjà été confronté à ce genre de problème, et comment faire pour récupérer mes données correctement encodées ?

overload est un mot clé Delphi indiquant qu'il existe plusieurs formes de la même fonction avec différents paramètre, la surcharge
Ne pas confondre avec override, pour la rédéfinition de méthodes déclaré en virtual !

Après pour le problème de IdHttp, ne l'ayant utilisé qu'en Delphi 7, je n'ai pas trop de réponse !

tu peux toujours tenter UFT8Decode sur la chaine reçue pour la convertir !

Bonsoir,

j'avais déjà testé UTF8Decode comme à peu prés toutes les fonctions permettant de prés ou de loin le codage/décodage des chaines.

J'ai repris mes tests en tout sens et j'ai fini par trouver une solution. En fait le problème ne vient pas directement de la fonction utilisée mais de la bonne déclaration de la variable ... Je crois que le nouveau type de chaine UnicodeString n'a pas finie de me faire m'arracher des cheveux ! Dans la doc on trouve : "Le nouveau type string par défaut de RAD Studio est le type UnicodeString... Pour RAD Studio, le format de AnsiString a changé, cela rend le format identique pour AnsiString et pour le nouveau type UnicodeString..."
Et pourtant dans mon cas, UnicodeString var = UTF8Decode(utfvar); ne fonctionne pas alors que AnsiString var = UTF8Decode(utfvar); donne enfin le résultat attendu !

La doc Embarcadero annonce UTF8Deconde comme étant dépréciée (UTF8Decode [[deprecated("Use UTF8ToWideString or UTF8ToString")]]). En pratique ces trois fonction fonctionnent avec une bonne déclaration des variables.

Voila, au final j'ai retenu UTF8ToString et tout fonctionne :)

UTF8Decode fonctionne avec des UT8String et WideString en BSD2007
Suprise en BSD2009, c'est RawByteString et WideString

Le vrai type de var devrait même être WideString !
Tu as de la chance de n'avoir que du Latin1 dans ton UTF8 car sinon AnsiString ne pourrait pas accepter des caractères en dehors de ce charset !

Le type implique de la conversion implicite si tu n'utilises pas le bon !
Effectivement, étant en Delphi, je suis très rigoureux avec mes types et j'utilise ceux des prototypes de fonctions, cela évite souvent des surprises !
Mais si chez CodeGear, il chance les types selon les versions, ça n'aide pas !