Discussion :

[FOCUS77]

Bonjour à tous.

Les caractères accentués sont remplacés par des points d'interrogations
dans les SQLquery.
J'ai documenté sur le sujet et j'ai appris qu'il faut assigner ProcessUTF8 à
CharSet de IBConnection pour les faire apparaitre.
Mais comment configurer ProcessUTF8?

merci à tous.

[tintinux]

Bonjour

Si "Les caractères accentués sont remplacés par des points d'interrogations" c'est simplement parce que Lazarus attend des textes codés en UTF-8, alors que IB comme la plupart des SGBD ne les définissent pas par défaut en UTF-8, d'où ces problèmes récurrents.

La solution la plus simple, toujours à privilégier si elle est possible, et qui va dans le sens de l'histoire, serait de créer ses bases en UTF-8. Ceci peut se faire sous SQL avec une instruction DEFAULT CHARACTER SET UTF8 derrière CREATE DATABASE ou TABLE
ou bien interactivement d'une manière qui dépend de ce SGBD. Dans ce cas, il n'y aura jamais rien d'autre à faire, et les programmes fonctionneront avec toutes les langues sur tous les systèmes.

Si c'est impossible, parce que la base est encore utilisée par des vieux programmes, il y a d'autres solutions :

L'une d'elle est lourdingue, mais fonctionne et permet de mieux comprendre ce qui se passe : coder chaque chaîne lue par la fonction ISO8859ToUTF8, et chaque chaîne à enregistrer avec la fonction inverse UTF8ToISO8859 de l'unité LazUTF8. Pour les composants orientés données (TDbEdit), cela peut se faire dans les événements OnGetText/OnSetText des champs.

La solution nominale et optimale est plutôt de se débrouiller pour faire faire la conversion automatiquement, par des pilotes adhoc, soit par la configuration du SGBD, soit par les composants d'accès aux données. Le principe de base est de spécifier des jeux de caractères distincts pour le serveur et le client. Mais dans le cas d'Interbase, je ne sais pas comment on fait, désolé.

[FOCUS77]

Bonjour

merci pour votre aide Tintinux.

J'ai testé les deux fonctions:ISO8859ToUTF8() et UTF8ToISO8859() mais elles ne sont pas reconnues par Laz.
Les deux fonctions reconnues sont UTF8Decode() et UTF8Encode().
Cependant le code suivant n'a donné aucun changement.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
procedure FamillePrdsLIBELLE_CTGGetText(Sender: TField;
  var aText: string; DisplayText: Boolean);
begin
 aText:=UTF8Decode(FamillePrdsLIBELLE_CTG.Value) ;
 DisplayText:=True;
end;

ou est l'erreur?

merci.

[jurassic pork]

Hello,
d'où vient ton ProcessUTF8 ? ne serait pas plutôt UTF8 qui est utilisé comme ceci par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
const
  // Name for the database. Be sure to specify the same name in your database.ini
  DatabaseFile = 'test.fdb'; //Sensible name for a test database, right?
var
  Fire: TIBConnection;
 
begin
  //Connection to Firebird database
  // The next line is needed for quite old FPC versions
  // Newer versions will first look for fbembed.dll in the application directory automatically
  //UseEmbeddedFirebird:=true; // Using embedded (and fbembed.dll) or regular client/server (fbclient.dll), requires ibase60dyn in uses
  Fire:=TIBConnection.Create(nil);
  try
    Fire.HostName := ''; //must be empty for embedded Firebird; must be filled for client/server Firebird
    Fire.DatabaseName := DatabaseFile; //(path and) filename
    // Username and password do not matter for authentication, but you do get authorizations in the database
    // based on the name (and optionally role) you give.
    Fire.Username := 'SYSDBA';
    Fire.Password := 'masterkey'; //default password for SYSDBA
    Fire.Charset := 'UTF8'; //Send and receive string data in UTF8 encoding
    Fire.Dialect := 3; //Nobody uses 1 or 2 anymore.
    Fire.Params.Add('PAGE_SIZE=16384'); //I like a large page size (used when creating a database). Useful for larger indexes=>larger possible column sizes

Ami calmant, J.P

[FOCUS77]

Salut J.P et merci pour votre aide.

J'ai préféré l'idée de Tintinux qui est vraiment fructueuse en améliorant le code précédent en:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
procedure FamillePrdsLIBELLE_CTGGetText(Sender: TField;
  var aText: string; DisplayText: Boolean);
begin
  aText:=SysToUTF8(FamillePrds.FieldValues['LIBELLE_CTG']);
  DisplayText:=True;
end;

Merci à vous tous
et chapeau à Tintinux

[tintinux]

Ravi que vous ayez résolu votre problème.

En fait, j'avais manqué de précision : ce sont plutôt les fonctions de l'unité LConvEncoding qu'il faut utiliser;
Probablement ISO_8859_15ToUTF8 et son inverse, sachant que l'ISO8859_15 c'est un des jeux de caractère le plus répandu (_15 permet de coder le signe "€", ce que ne fait pas _1).
Pour être parfaitement rigoureux, il faut prendre exactement le jeu de caractère utilisé pour coder votre base de données existante.

SysToUTF8 permet lui de traduire automatiquement depuis le jeu de caractère utilisé par le système d'exploitation courant, qui est l'ISO8859_15 sur beaucoup de versions de Windows.
Donc ça fonctionne sûrement très bien aussi, mais si vous faites une version de votre programme pour Linux, OSX ou autre, en lisant la même base de données, ça n'ira plus...
Cette fonction est faite uniquement pour convertir les noms de fichiers et de dossiers du système, en vue de les afficher en UTF8.

[FOCUS77]

voici un petit exemple: ( ajoutez LConvEncoding à uses)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
procedure FamillePrdsLIBELLE_CTGGetText(Sender: TField;
  var aText: string; DisplayText: Boolean);
begin
 if  FamillePrds.FieldValues['LIBELLE_CTG']<>Null then
 begin
 aText:=ISO_8859_15ToUTF8(FamillePrds.FieldValues['LIBELLE_CTG']);
  DisplayText:=True;
 end;
end;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
procedure FamillePrdsLIBELLE_CTGSetText(Sender: TField;
  const aText: string);
begin
FamillePrds.FieldValues['LIBELLE_CTG']:=UTF8ToISO_8859_15(aText);
end;

merci

[alanglet]

Bonjour,

voici un petit exemple: ( ajoutez LConvEncoding à uses)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
procedure FamillePrdsLIBELLE_CTGGetText(Sender: TField;
  var aText: string; DisplayText: Boolean);
begin
 if  FamillePrds.FieldValues['LIBELLE_CTG']<>Null then
 begin
 aText:=ISO_8859_15ToUTF8(FamillePrds.FieldValues['LIBELLE_CTG']);
  DisplayText:=True;
 end;
end;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
procedure FamillePrdsLIBELLE_CTGSetText(Sender: TField;
  const aText: string);
begin
FamillePrds.FieldValues['LIBELLE_CTG']:=UTF8ToISO_8859_15(aText);
end;

Tout ceci serait parfaitement inutile si vous aviez défini le Charset de la connexion à UTF8 comme l'a dit JP, la conversion des champs CHAR ou VARCHAR étant alors automatiquement faite en UTF8, quelque soit le Charset utilisé dans ces champs (sauf si NONE).
Si la translittération que vous présentez est nécessaire, c'est que le jeu de caractères de la connexion n'a pas été défini (ou est resté à NONE).
Si les jeux de caractères de la connexion et du champ sont définis, Firebird se charge de faire la translittération dans les 2 sens.
Je ne connais que deux cas où elle n'est pas faite:
-lorsque l'un des jeux n'est pas défini (=NONE)
-lorsque les deux jeux sont identiques. Ça parait logique, mais ça présente tout de même un petit inconvénient. Lorsqu'il y a translittération entre deux jeux différents, Firebird émet une erreur si un des caractères transmis n'existe pas dans les deux jeux. Mais lorsqu'il n'y a pas translittération, aucun contrôle n'étant effectué on peut mémoriser dans un champ un caractère n'existant pas dans son jeu de caractères. On peut alors parler de corruption de la base de données car il devient impossible de lire ces champs si le Charset de connexion n'est pas identique à celui du champ.
C'est une erreur assez fréquente de certains développeurs qui sous Delphi utilisaient l'ISO8859_1 pour la connexion et les champs alors que Windows utilisaient le CP1252. Il est ainsi possible de rencontrer dans d'anciennes bases des caractères du CP1252 comme le œ très fréquent dans notre langue, inexistant ISO8859_1.
Il est alors impossible de se connecter en UTF8 à ces bases.
Quand à utiliser l'UTF8 pour tous les champs texte, j'émettrai une certaine réserve. Cela fait beaucoup augmenter la taille de la base et la durée de certains traitements. Lors d'un test de recherche sur la liste des 40000 communes françaises, la durée était quasiment doublée.

André

[FOCUS77]

Bonjour à tous

En fait les méthodes Ongettext et OnSettext ont des limites car elles fonctionnent uniquement avec les champs de base mais pas avec les champs persistants.

J'ai tenté alors la deuxième alternative, c'est d'attribuer UTF8 à Charset, mais un message d'erreur apparaît toujours par la suite en indiquant un mauvais paramétrage de UTF8.

La troisième alternative est de transformer ma BDD Interbase en Firebird et de la reconfigurer, tout en conservant les données, à l'aide de 'FlameRobin' et voici la démarche que j'ai suivie.

J'ai ouvert FlameRobin et selectionné:
*Database/Actions/Backup database, et j'ai créer BackupFile.fbk.

*Database/Restore backup into new Database, et j'ai créer la nouvelle BDD firebird avec Charset:UTF8.
Une fois enregistrée, une nouvelle fenêtre m'a demandé le chemin de BackupFile.fbk je l'ai indiqué et cliqué sur le bouton 'start Restore'.
Un message apparaît en m'indiquant que le Char set a changé, 'would you like to be reminded next time?'
J'ai repondu par non.

Au niveau de mon application:
j'ai assigné le nouveau chemin à databaseName de IBConnection.
Et j'ai laissé Charset à Blanc.

J'ai supprimé et reconstruit tous les champs de type Char, devront recevoir des caractères accentués.
J'ai changé, dans les champs de base les points d'interrogations par les caractères accentués adéquats.
J'ai ré-exécuté mon application pour rafraîchir les champs persistants.

Maintenant le tout fonctionne à la perfection.

Merci à tous.