Difference between revisions of "unicode use cases/fr"

From Lazarus wiki
Jump to navigationJump to search
Line 7: Line 7:
 
== Les cas ==
 
== Les cas ==
  
=== Sqlite library requires filename to be encoded as UTF-8 ===
+
===La bibliothèque Sqlite requiert un nom de fichier encodé en UTF-8===
  
The sqlite3 wrapper class provided by FPC (TSqlite3Dataset) stores the FileName property into a String type (ansistring) and uses it to open the database through a sqlite function (sqlite3_open) that expects an UTF-8 encoded string. This works fine as long the string is UTF-8 encoded or has only ASCII characters. The problem is that the encoding varies according to the situation. LCL and *nix RTL return UTF-8, Win32 RTL returns the current locale encoding. Some workarounds were tried:
+
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:
  
* ''Call UTF8Encode inside FileName property method setter''<br>This will work when the string is not UTF-8. When the string is already encoded in UTF-8, UTF8Encode will corrupt the string. Since there's no clean way to guess encoding, this option is not feasible.
+
* ''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.
  
* ''Call UTF8Encode or not in the source string, before setting the FileName property''<br>This will handle the "strings coming from LCL" case, since that is always UTF-8. But using a string returned by a RTL function like GetAppConfigDir can lead to problems, e.g., in win32 systems with accented characters in the returned path, it will be necessary to call UTF8Encode while this is not necessary and dangerous in *nix systems.
+
* ''Appeler UTF8Encode ou non dans la chaîne source, avant d'affecter la propriété FileName''<br>
  
So, in this case, AFAIK, there's no way to write a cross platform solution without using defines.
+
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 ===
 
=== Firebird database path ===

Revision as of 20:28, 9 July 2014

English (en) | français (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.

See Also