unicode use cases/fr
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.
Firebird database path
When passing a connection string through the sqldb components to a Firebird database server, Firebird expects the path to the database to be encoded in the filesystem encoding of the server. So connecting from e.g. Windows to a typical Linux server (which has the UTF8 character set) would require converting the path to UTF8.
Note that this is a weakness in the Firebird design itself (you have to know the Firebird server db filesystem encoding, which is slightly ridiculous) but this limitation did not appear when everybody spoke ASCII ;)
- to do: find mantis bug id where this problem was described ***
ODBC support for SQL_WVARCHAR string fields
See [1] Note: that bug has a patch attached to support the *W functions; it has not been applied.
