Difference between revisions of "unicode use cases/fr"
(→Cases) |
|||
| (7 intermediate revisions by one other user not shown) | |||
| Line 7: | Line 7: | ||
== Les cas == | == Les cas == | ||
| − | === Sqlite | + | ===La bibliothèque Sqlite requiert un nom de fichier encodé en UTF-8=== |
| − | + | La classe d'enveloppe sqlite3 fournie par FPC (TSqlite3Dataset) conserve propriété Filename dans un type chaîne (ansistring) et l'utilise pour ouvrir la base de données via une fonction (sqlite3_open) qui attend une chaîne encodée en UTF-8. Cela fonctionne très bien tant que la chaîne est UTF-8 ou a uniquement des caractères ASCII. Le problème est que le codage varie en fonction de la situation. la LCL et *nix RTLc retourne de l'UTF-8, la RTL Win32 l'encodage local actuel. Certaines solutions ont été essayées: | |
| − | * '' | + | * ''Appeler UTF8Encode dans le setter de la propriété FileName''<br>Cela fonctionnera quand la chaîne n'est pas UTF-8. Quand la chaîne l'est déjà, UTF8Encode va la corrompre. Comme il n'y a aucun moyen propre de deviner l'encodage, cette option n'est pas possible. |
| − | * '' | + | * ''Appeler UTF8Encode ou non dans la chaîne source, avant d'affecter la propriété FileName''<br> |
| − | + | Cela manipulera le cas "chaînes venant de la LCL", puisque c'est toujours de l'UTF-8. Mais utiliser une chaîne retournée par une fonction de la RTL comme GetAppConfigDir peut conduire à des problèmes, par exemple, dans les systèmes Win32 avec des caractères accentués dans la chemin d'accès retourné, il sera nécessaire d'appeler UTF8Encode alors que ce n'est pas nécessaire et même dangereux dans les systèmes *nix. | |
| − | + | Donc, dans ce cas, pour autant que je le sache, il n'y a pas de solution pour écrire une solution multi plate-forme sans employer des defines. | |
| − | |||
| − | |||
| − | + | ===Chemin d'une base de données Firebird=== | |
| − | + | En passant une chaîne de connection par les composants sqldb vers un serveur de base de données Firebird, ce dernier s'attend à ce que le chemin à la base de données soit encodé selon l'encodage du système de fichier du serveur. | |
| + | Ainsi, se connecter depuis, par exemple, un poste Windows vers un serveur Linux (qui a un jeu de caractère UTF8) nécessitera une conversion du chemin en UTF8. | ||
| − | === ODBC | + | Remarquer qu'il s'agit d'un faiblesse dans lma conception même de Firebird (vous devez connaître l'encodage du système de fichier du serveur Firebird, ce qui est assez amusant), mais cette limitation n'apparaît pas quant otut le monde parle ASCII ;) |
| − | + | # # #A faire: Trouver un identifiant de bug mantis où le problème à été décrit. # # # | |
| − | Note: | + | |
| + | NDT : cette limitation peut être contournée en mettant en place des [http://www.firebirdsql.org/manual/isql-connect-database.html#isql-connect-alias| alias de nom] de bases de données dans le serveur, ce qui améliore de surcroît la sécurité (cela dissimule l'emplacement du fichier de la base de données et cache aussi le type du système de fichier). | ||
| + | |||
| + | ===Support par ODBC des champs chaîne SQL_WVARCHAR=== | ||
| + | Voir [http://bugs.freepascal.org/view.php?id=22095] | ||
| + | Note: Ce bug a un correctif associé pour supporter les fonctions *W ; il n'a pas été appliqué. | ||
== See Also == | == See Also == | ||
| − | *[[FPC Unicode support]] | + | *[[FPC Unicode support/fr|Support de l'Unicode par FPC]] |
| − | [[Category:Unicode]] | + | [[Category:Unicode/fr]] |
Latest revision as of 20:11, 20 July 2015
Introduction
Actuellement, il y a un grand intérêt dans l'implémentation du support complet de l'Unicode dans FPC. Cette page est destinée à décrire des situations où le développeur est confronté à des problèmes en travaillant avec les caractères/chaînes Unicode. En vue de rendre l'information utile, la description doit être aussi détaillée que possible et fournir des exemples réels de code quand ils sont disponibles.
Les cas
La bibliothèque Sqlite requiert un nom de fichier encodé en UTF-8
La classe d'enveloppe sqlite3 fournie par FPC (TSqlite3Dataset) conserve propriété Filename dans un type chaîne (ansistring) et l'utilise pour ouvrir la base de données via une fonction (sqlite3_open) qui attend une chaîne encodée en UTF-8. Cela fonctionne très bien tant que la chaîne est UTF-8 ou a uniquement des caractères ASCII. Le problème est que le codage varie en fonction de la situation. la LCL et *nix RTLc retourne de l'UTF-8, la RTL Win32 l'encodage local actuel. Certaines solutions ont été essayées:
- Appeler UTF8Encode dans le setter de la propriété FileName
Cela fonctionnera quand la chaîne n'est pas UTF-8. Quand la chaîne l'est déjà, UTF8Encode va la corrompre. Comme il n'y a aucun moyen propre de deviner l'encodage, cette option n'est pas possible.
- Appeler UTF8Encode ou non dans la chaîne source, avant d'affecter la propriété FileName
Cela manipulera le cas "chaînes venant de la LCL", puisque c'est toujours de l'UTF-8. Mais utiliser une chaîne retournée par une fonction de la RTL comme GetAppConfigDir peut conduire à des problèmes, par exemple, dans les systèmes Win32 avec des caractères accentués dans la chemin d'accès retourné, il sera nécessaire d'appeler UTF8Encode alors que ce n'est pas nécessaire et même dangereux dans les systèmes *nix.
Donc, dans ce cas, pour autant que je le sache, il n'y a pas de solution pour écrire une solution multi plate-forme sans employer des defines.
Chemin d'une base de données Firebird
En passant une chaîne de connection par les composants sqldb vers un serveur de base de données Firebird, ce dernier s'attend à ce que le chemin à la base de données soit encodé selon l'encodage du système de fichier du serveur. Ainsi, se connecter depuis, par exemple, un poste Windows vers un serveur Linux (qui a un jeu de caractère UTF8) nécessitera une conversion du chemin en UTF8.
Remarquer qu'il s'agit d'un faiblesse dans lma conception même de Firebird (vous devez connaître l'encodage du système de fichier du serveur Firebird, ce qui est assez amusant), mais cette limitation n'apparaît pas quant otut le monde parle ASCII ;)
- # #A faire: Trouver un identifiant de bug mantis où le problème à été décrit. # # #
NDT : cette limitation peut être contournée en mettant en place des alias de nom de bases de données dans le serveur, ce qui améliore de surcroît la sécurité (cela dissimule l'emplacement du fichier de la base de données et cache aussi le type du système de fichier).
Support par ODBC des champs chaîne SQL_WVARCHAR
Voir [1] Note: Ce bug a un correctif associé pour supporter les fonctions *W ; il n'a pas été appliqué.
