Problème d'accents base Firebird et UIB

Bonjour,

Je n'arrive pas à faire afficher les caractères accentués d'une base Firebird 2.5 en utilisant les composants UIB 2.5.

Style le caractère é est remplacé par ?

La base de données n'a pas de jeu de caractères et pour afficher un champ je fais

Code:

---

COMPOSQL.Fields.ByNameAsString['MONCHAMP'];

---

J'ai essayé avec différents jeu de caractères de la base, y compris avec les différentes possibilités de fields (ByNameAsAnsiString, ByNameAsUnicodeString, ...) et aussi en utilisant UTF8toAnsi en utilisant le jeu de caractères UTF8 dans la base.

Je développe avec Lazarus 0.9.30 et FPC 2.4.2 sous Windows.

Je n'ai rien trouvé sur le net me permettant de résoudre mon pb.

Mon programme de tests donc le plus mini possible ne fait rien de particulier si ce n'est (sur un clic d'un bouton) :

Code:

---

1 2 3 4

BDD.Connected := True; SQL_UIB.Open; CHAINE := SQL_UIB.Fields.ByNameAsString['LIB_PARAMETRE']; RESULTAT.Lines.Add(CHAINE);

---

La requête défini dans SQL_UIB est :

Code:

---

select * from PARAMETRES

---

et la table ne contient qu'un seul champ et qu'un seul enregistrement, enregistrement qui été ajouté directement avec IBExprt. Je précise que les caractères sont comme avec IBExprt correctement affichés avec FlameRobin (aussi bien avec Windows qu'avec Ubuntu) ...

Si quelqu'un a une idée, je suis preneur ...

D'avance merci.

Bonne soirée.

Laurent

Le '?' doit remplacer un caractère non compris dans un CharSet UTF8, ce qui est le cas de caractères accentués en ANSI, qui ont je crois un bit de poids fort setté qui ne plaît pas en UTF8...

Essaye Chaine:=AnsiToUtf8(Chaine) car Lazarus doit attendre de l'UTF8 et InterBase fournir de l'ANSI

Bonjour,

Citation:

---

Envoyé par inforock

La base de données n'a pas de jeu de caractères

---

Cela n'a pas de sens, il y a forcément un jeu de caractère.
Beaucoup de SGBD continuent à créer par défaut des bases en jeu de caractère ISO.

Citation:

---

Envoyé par tourlourou

Le '?' doit remplacer un caractère non compris dans un CharSet UTF8

---

Non, l'UTF8 inclut tous les caractères des jeux ANSI ou ISO (l'inverse est faux).

Par défaut, un nouveau source Lazarus attend de l'UTF8.
Si, pour raison ou une autre, vous devez impérativement lire une base de données non-UTF8, il faut alors convertir à l'affichage en utilisant xxxxtoUTF8. Plus précisemment :

Code:

---

Edit1.Text := ISO8859ToUTF8(COMPOSQL.FieldByName['MONCHAMP'].AsString);

---

C'est à l'enregistrement qu'on fait l'inverse.

Parfois, un source Lazarus (notamment venant d'une vieille version de Delphi) peut être enregistré en ISO8859, et là il attend alors ce jeu de caractères. Dans ce cas, il faut mieux convertir le fichier source, une fois pour toutes, en UTF8.

Le plus simple reste de créer une base et des sources en UTF8, il n'y a alors rien à faire ensuite !

Ton problème n'est pas avec les UIB mais avec Firebird . Il n'est pas recommandé de créer une Base de Données en CharSet=NONE
mais plutôt ISO8859_1 ou UTF8

je n'ai malheureusement pas de UIB installé sur la version de Lazarus, sur le poste d'où j'envoie le message, mais je suis sur que dans les propriétés de connexion il y a un Charset , lequel as tu indiqué ? il me semble que c'est UTF8 par défaut dans ce cas mets le a NONE

Citation:

---

Le '?' doit remplacer un caractère non compris dans un CharSet UTF8

---

Citation:

---

Envoyé par tintinux

Non, l'UTF8 inclut tous les caractères des jeux ANSI ou ISO (l'inverse est faux).

---

Bien sûr, tu as raison : je me suis mal exprimé en utilisant le mot "compris" comme "décodé" :

'é' se code 11000011 10101001 en UTF8 et 11101001 en ISO/CEI 8859-1

or 11101001 en UTF8 annonce un caractère codé sur 3 octets : 1110xxxx 10xxxxxx 10xxxxxx : c'est là qu'il affiche un '?' à la place, pour peu que les 2 octets suivants ne soient pas cohérents avec le pattern

Bonjour,

En effet le problème vient très probablement du jeu de caractères NONE des champs à lire.
Avec Firebird il y a 2 jeux de caractères importants (sans compter celui par défaut de la base): celui de la connexion et celui des champs de texte (chaque champ pouvant avoir son propre jeu et sa propre collection).
Celui de la connexion permet de convertir les chaînes dans le jeu de caractères utilisé par le logiciel. Lazarus travaillant maintenant en UTF8 il me semble préférable de choisir le jeu UTF8 pour la connexion.
Si par exemple le champ est en ISO8859_1, le texte sera traduit en UTF8 lors de la lecture et pour l'écriture, l'UTF8 de Lazarus sera traduit en ISO8859_1 pour être stocké.
Il y a cependant 2 lacunes dans ce mécanisme:
- il n'y a pas de transcodage si les 2 codes de caractères sont identiques
- il n'y a pas de transcodage si un des jeux est NONE.
Dans le premier cas çà autorise le stockage de caractères inexistants dans le jeu du champ. Çà peut paraître sans inconvénient tant que le jeu de la connexion restera le même. Mais le jour où vous devrez en changer (c'est le cas par exemple si vous passez de Delphi7 ISO8859_1 ou WIN1258 à Lazarus UTF8) une erreur sera provoquée lors du transcodage par Firebird s'il rencontre ces caractères. J'ai ainsi le cas d'une base utilisée avec Delphi 7 où tout était en ISO8859_1 qui a permis de stocker des caractères du jeu WIN1258 de Windows français, inexistants dans l'ISO8859_1.
Dans le second cas, celui d'inforock, les caractères étant stockés et lus sans transcodage, il est nécessaire qu'il fasse lui-même la conversion entre le jeu "d'origine" des données s'il le connait et l'UTF8 de Lazarus (AnsiToUTF8(x)?).

André

Bonjour,

Merci à tous pour vos réponses qui m'ont mises sur la voie ...

Maintenant, lors de la création de la base de données avec IBExpert, je mets le jeu de caractères à UTF8 et l'option "Police : jeu de caractères" avec la valeur DEFAULT_CHARSET.

Ce qui donne pour les Metadata au niveau de la base :

Code:

---

DEFAULT CHARACTER SET UTF8 COLLATION UTF8;

---

Et pour les champs des tables, cela donne :

Code:

---

CHARACTER SET UTF8 COLLATE UTF8

---

Ainsi, en utilisant les composants UIB, en écrivant :

Code:

---

CHAINE := SQL_FIREBIRD.Fields.ByNameAsString['CHAMP'];

---

On récupère correctement les caractères accentués et spéciaux.

La base que je créais était avec

Code:

---

DEFAULT CHARACTER SET NONE

---

. Donc grosse erreur de ma part :oops:

Bonne journée