Discussion :

[Invité]

Bonjour,

je suis de plus en plus perplexe dans le gestion de la combinaison UTF8/ANSI avec le couple Lazarus/FreePascal. Et les "nouveautés" n'arrangent rien.

J'ai travaillé quelques heures sur un système de cryptage réversible compatible Win et Nux... Si je me sers de l'ANSI comme base, c'est portable sauf à l'affichage dans certains objets visuels... où il faut jouer de l'UTF8Encode(...).

Mais si je veux faire l'inverse, c'est-à dire prendre comme base l'UTF8, je n'arrive à rien... pas plus avec Lazarus 0.9.31/FPC 2.6.1 que quand j'avais fait un essai en Lazarus 0.9.28/FPC 2.2 ou 2.4.

J'en arrive à me demander si c'est jouable ? Et comment ? Depuis pas mal de temps déjà, il faut assez lourdement différencier l'écriture entre les environnements avec des objets qui réagissent différemment à l'affichage selon leur hétérogénéité de conception...

Même si Lazarus possède des ensembles de widgets Unicode, il est important de noter que tout n'est pas en Unicode. Il est de la responsabilité du développeur de connaitre l'encodage de ses chaines de caractère, et d'effectuer la conversion appropriée entre les bibliothèques qui attendent des encodages différents.

...sans compter...

La RTL et la FCL de FPC 2.4 attendent des chaines ANSI. FPC 2.5.x aussi actuellement.
Vous pouvez convertir entre unicode et ansi en utilisant les fonctions UTF8ToAnsi et AnsiToUTF8 de l'unité System, ou les fonctions UTF8ToSys et SysToUTF8 de l'unité FileUtil. Les deux dernières sont plus intelligentes mais engendrent plus de code dans votre programme.

Changer de librairie en attendant ?

Jusqu'à Lazarus 0.9.30, les routines de gestion de l'UTF-8 étaient dans la LCL dans l'unité LCLProc. Dans Lazarus 0.9.31 (et supérieur), les routines de LCLProc sont toujours disponibles pour la compatibilité ascendante, mais le vrai code (the real code dans la page anglaise que l'on peut supposer d'origine) qui gère UTF-8 est localisé dans le package lazutils, dans l'unité lazutf8.

Pour exécuter des opérations sur des chaines UTF-8, il est préférable d'utiliser les routines de l'unité lazutf8 plutôt que celles de SysUtils de Free Pascal, car SysUtils n'est pas encore prêt à travailler avec Unicode, alors que lazutf8 l'est. Substituez simplement les routines de SysUtils avec leur équivalent lazutf8, qui ont toujours le même nom exception faite du préfixe "UTF8" ajouté.

"Le vrai code ?" Est-ce que quelqu'un a une stratégie de développement en la matière ? LazUTF8 ? La RTL et la FCL restent en ANSI... Wait and see : trop tôt pour utiliser comme base UTF8 ?

Merci. Cordialement. Gilles

[Gouyon]

Je n'ai pas encore eu l'occasion de tester les nouvelles versions. Mais je dirais que si on veut faire de l'UTF8 il faut utiliser LazUTF8 avec les nouvelles versions.

[Invité]

Bonjour Rémi,

Sauf

• que comme il est précisé, ce n'est "qu'en attendant", pour revenir plus tard aux bibliothèques actuelles dont il est implicitement précisé que ces dernières ne donnent pas toujours satisfaction car "elles ne sont pas prêtes",
• que je n'arrive pas à déterminer quelle est interaction exacte -s'il y en a une- entre le fait que la RTL et la FCL de FPC attendent des chaines ANSI et mon incapacité à partir de l'UTF8 comme base de travail.

J'avoue que j'ai du mal à suivre. La révolution de la 0.9.26 c'est justement la prise en charge de l'UFT8 de "manière native"...

Unicode: Win32 widgetset and LCL in general are adopted to support only utf8 strings. Whatever you do with strings returned and passed from/to controls please know they are in utf8 encoding now.
Source officielle

Pour la LCL, c'est "en cours" et il est vrai que cela fonctionne mieux.. même si en ce qui concerne les composants, il est nécessaire de rester attentif. Mais pour le reste ? On ne peut pas se restreindre à l'usage de la LCL dans une application. Le problème devient sensible quand on développe en Win et en Nux. Les bibliothèques gérant les UTF8 ne sont pas simples d'accès (ie compréhensibles)... quand on pense à les appeler...

Donc finalement, ne vaut-il mieux pas attendre la vraie gestion... ce qui promet un retard considérable compte tenu du déverminage nécessaire par les utilisateurs... et de continuer à batailler "ferme" avec les SysToUTF8, les UTF8Encode et de différencier en permanence les variables pour préciser leur genre ? Bon, on a l'habitude... et quand on n'aura plus ce problème, cela nous manquera... un peu

Cordialement. Gilles

[Gouyon]

Donc finalement, ne vaut-il mieux pas attendre la vraie gestion... ce qui promet un retard considérable compte tenu du déverminage nécessaire par les utilisateurs... et de continuer à batailler "ferme" avec les SysToUTF8, les UTF8Encode et de différencier en permanence les variables pour préciser leur genre ?

Moi je suis pour attendre que ça soit mure. Quitte à gérer les problèmes de la manière habituelle.

Bon, on a l'habitude... et quand on n'aura plus ce problème, cela nous manquera... un peu

Mais non il y aura d'autres problèmes pour les remplacer. Faut pas s'inquiéter