Discussion :

[ApproxDev]

Bonjour,

j'ai décroché un peu de Lazarus. Le premier problème que j'ai rencontré est un problème d'UTF8.
Entre temps, j'ai utilisé un peu FMX et beaucoup Qt.

J'ai vu qu'on disposait de LazFileUtils en remplacement de FileUtils qui contient plein de méthodesUTF8. Donc si on les baptise encore xxxUTF8, c'est qu'il faut faire la différence. Le soucis ne me semble pas être Linux ni OS X, mais Windows.

Sous Windows, lorsque je travaille avec les noms de fichiers, quel est l'encodage natif (pas du fichier) mais de son nom ? Quand je définis une string avec Lazarus Windows c'est quel format nativement ? Est-ce que Lazarus.exe se débrouille enfin de manière autonome ?
Pour l'instant ce n'est pas très clair, pas plus que quand j'ai lâché prise avec Lazarus il y a 2 ou 3 ans. On en est où exactement avec le fpc 3.0 comme base ?

Merci. AD.

[FChrisF]

Avec les versions Lazarus 1.6 + FPC 3.0 (introduction du code page dans les types chaînes de caractères, et support des unicodestring dans la RTL):

- le type string est encodé par défaut en UTF8,

- FPC fait -normalement- une conversion automatique entre les différents codes page si cela est nécessaire (i.e. si les variables chaînes de caractères concernées ont des codes page différents),

- une partie de la RTL de FPC a déjà été adaptée pour supporter les codes page et les unicodestring (cf. http://wiki.freepascal.org/FPC_Unico...rt#RTL_changes pour FPC 3.0).



Quelques commentaires généraux (ce qui sous-entend qu'il y a bien sûr des exceptions, et/ou des conditions):

- Windows ou Linux, il n'y a normalement pas de différence. Les noms de fichiers sont encodés en UTF8 par défaut (pour répondre à votre question) si ce sont des string,

- compte tenu de "l'adaptation" qu'a fait Lazarus pour intégrer les codes page, le type ansistring est aussi encodé en UTF8 (sauf option DisableUTF8RTL). Il vaut donc mieux ne pas manipuler ce type de chaîne de caractères, sauf à savoir ce que l'on fait exactement (et à faire de nombreux tests),

- vous pouvez utiliser les fonctions xxxxUTF8 de LazFileUtils.pas pour les fichiers, mais aussi les fonctions correspondantes de la RTL de FPC 3.0+ si elles ont été adaptées: ainsi, "FileExists" ou "FileOpen" fonctionnent maintenant -normalement- sans problèmes et sans conversions. Exemple: FileExists('Fichier éàù.txt') devrait vous retourner true si ce fichier existe bien (avec un projet "standard" sous Lazarus).

[ApproxDev]

Bonjour,

Bon dans ce cas-là les problèmes devraient être minimisés : on va fait preuve d'optimisme : résolu.
Cordialement. AD.