Lorsqu'il y a des échanges de données entre différentes plateformes (Windows, Linux, Android, iOS...), il est très fréquent de devoir effectuer un décodage. Le plus souvent, la plateforme émettrice va par exemple envoyer des données dans un fichier XML enregistré en ANSI et encodé en ISO-8859-1, et l'application de traitement des données a été prévue par défaut pour de l'UNICODE. Ou l'inverse. Ou plus simplement, dans une seule application, une saisie a été faite dans un format, mais le stockage n'est pas fait dans un format adapté. Plusieurs billets abordent déjà ce thème :

Voici sur ce sujet l'ensemble des points qui entrent en ligne de compte :

  • La configuration courante qui permet de générer l'application, le site, le webservice (...) est-elle configurée avec des chaînes en exécution en ANSI ou en UNICODE ?



    Dès que deux projets qui échangent n'ont pas les configurations avec des chaînes identiques en exécution, leurs échanges pourront nécessiter des conversions avec AnsiVersUnicode ou UnicodeVersAnsi.

  • Dans la description du projet, pour la langue concernée, les paramètres "Divers" sont-ils configurés pour suivre le système, ou au contraire un réglage spécifique a été sélectionné ?



  • Dans le cas du traitement d'un document ou fichier d'échange (HTML, XML, JSON …), son encodage annoncé est-il bien celui réellement utilisé ?
    En effet il n'est pas rare de devoir traiter un fichier d'un prestataire indiquant un certain "charset", mais dans la pratique ayant ses données encodées dans un autre charset ! Une bonne astuce ici est d'afficher le fichier à traiter dans un navigateur. Si déjà dans un navigateur les accents ne sont pas correctement affichés, le fichier est à la base mal encodé. Il est préférable de demander une version corrigée à son éditeur, plutôt que de coder une "fausse conversion", car elle ne fonctionnera plus le jour ou le fichier sera corrigé !

  • Dans les traitements des données, les chaînes sont-elles bien déclarées dans le format des données ?
    Si la configuration du projet est en UNICODE, la déclaration "MaVariable est une chaine" va implicitement déclarer une chaine UNICODE. Il faut explicitement déclarer "MaVariable est une chaine ANSI" si la variable doit recevoir des données à traiter obtenues par une application en ANSI.

  • Dans le cas d'un stockage dans une base HFSQL :
    • le format des rubriques est-il bien conforme aux données saisies ? Pour chaque rubrique texte, il est possible d'indiquer "texte" ou "texte unicode" en fonction du besoin :



    • les caractéristiques du champ de saisie à l'origine de l'ajout ou modification des données sont-elles en phase avec le type de la rubrique ? Suivant la plateforme la coche UNICODE de la description d'un champ de saisie peut être déterminante.

  • Lors d'un affichage de données à l'utilisateur, la conversion nécessaire est-elle faîte ?
    Par exemple pour le traitement de données XML, si elles sont traitées au travers d'une variable du type avancé XMLDocument, les décodages nécessaires sont effectués automatiquement grâce au charset du document XML. Mais si le XML est traitée au travers d'une variable déclarée dans un type simple chaîne, il pourra être nécessaire d'effectuer une conversion (UTF8VersChaîne...)...

  • Lors d'une saisie de données dans les applications multilingues, l'alphabet courant est-il le bon ?
    Lorsqu'une application s'utilise dans différentes langues qui n'ont pas les mêmes alphabets, si la configuration du projet est en ANSI pour les chaines, des conversions peuvent être nécessaires (fonction TableAjoute, SQLTable, affectation d'un mémo texte...). Dans ce cas la conversion se fait avec l'alphabet courant indiqué par la fonction ChangeAlphabet. Si l'affichage ou le stockage d'une saisie n'est pas celui attendu, il peut donc s'agir d'un alphabet erroné donné à ChangeAlphabet.

 

En cas de doute sur le bon traitement de conversion à effectuer, ou si malgré une conversion le résultat n'est pas celui attendu, n'hésitez pas à exposer votre cas à notre support. Attention cependant, de bien décrire tous les points de configuration évoqués ci-dessus. Joindre un projet exemple avec libellés explicatifs ("cliquez ici...", "observez que"...) avec les données à traiter est vivement recommandé. Ce type de difficulté n'a jamais une origine unique, mais trouve son explication dans une combinaison d'options retenues ...

 

 

< Retour

Publier un commentaire : 
Votre adresse email ne sera pas publiée