Discussion :

[frantzgac]

Bonjour

pourquoi l'insertion suivante

Code :

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

1
2
 
insert into utf8 values ('oe','œ')

ou

Code :

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

insert into utf8 values ('œ','oe')

dans un table firebird 2.1 donne-t-elle le message d'erreur "

Error IBPP LogicException
Context:Statement Prepare
Message SQL statement can't be 0"

DDL de la table

Code :

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

1
2
3
4
5
CREATE TABLE UTF8
(
  TEXTE char(5) CHARACTER SET UTF8,
  ISO char(5) CHARACTER SET UNICODE_FSS
);

Ni les champs unicode ni les champs UTF8 n'acceptent 'œ'

[Artemus24]

Salut frantzgac.

Bien sûr que cela fonctionne !
Est-ce que ton script a été encodé en utf8 (sans bom) ?
Si tu es sous notepad++, il suffit de regarder en cliquant sous l'onglet "encodage".

Et voici l'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
23
24
CREATE DATABASE '..\Data\Base.fdb' page_size 4096 DEFAULT CHARACTER SET UTF8;
 
SET NAMES UTF8;
 
create table test (
id  int      not null primary key,
lib char(20) not null collate UTF8);
 
insert into test (id,lib) values (1, 'ça marche');
insert into test (id,lib) values (2, 'cœur');
insert into test (id,lib) values (3, '€uro');
 
select * from test;
 
          ID LIB
============ ====================
           1 ça marche
           2 cœur
           3 €uro
 
 
exit;
 
Appuyez sur une touche pour continuer...

@+

[frantzgac]

Bonjour

mon script a été directement tapé sur l'éditeur de Flamerobin avec la combinaison Alt + 0156 pour obtenir "œ"

je constate que tu as créé la Database avec le Charset UTF8 puis la table avec Collate UTF8

Est-ce que SET NAMES UTF8 est une précaution ou une nécessité ?

Je testerai dans ces conditions mais je ne souhaite pas modifier le Char Set de ma base qui sert à d'autres usages.

Merci

[SergioMaster]

Bonjour,

mon script a été directement tapé sur l'éditeur de Flamerobin avec la combinaison Alt + 0156 pour obtenir "œ"

C'est un des petits défauts de Flamerobin
le meilleur moyen, avec flamerobin, est de passer par la fonction ASCII()

[frantzgac]

Bonjour,

C'est un des petits défauts de Flamerobin
le meilleur moyen, avec flamerobin, est de passer par la fonction ASCII()

fonction ASCII() ? je ne connais pas. La doc évoque ASCII_VAL() et ASCII_CHAR()

j'ai naïvement essayé

Code :

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

insert into utf8 values (ascii('œ'),'ascii')

qui donne le même message d'erreur

[SergioMaster]

fonction ASCII() ? je ne connais pas. La doc évoque ASCII_VAL() et ASCII_CHAR()

Méa culpa, retour de thalasso lénifiante

je pensais bien évidemment ASCII_CHAR(156) mais il me vient un doute car le résultat est normalement un [VAR]CHAR(1) CHARACTER SET NONE et je l'avais toujours fait pour des bases en Charset NONE

ceci étant, avec FB 2.5 et une table

Code :

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

1
2
3
4
5
6
 
CREATE TABLE LIGATURES
(
  ENDEUX Char(2),
  LIG Varchar(4)
);

dans une base UTF8
le INSERT INTO LIGATURES (ENDEUX, LIG) VALUES ('oe','œ') le deuxième étant obtenu par le Alt+156 fonctionne parfaitement avec Flamerobin

[Artemus24]

Salut Frantzgac.

je constate que tu as créé la Database avec le Charset UTF8 puis la table avec Collate UTF8
Est-ce que SET NAMES UTF8 est une précaution ou une nécessité ?

Il vaut mieux mettre partout la même chose. Je dirai une précaution.
Je n'aime pas trop les valeurs par défaut et du coup, j'ai tendance à trop déclarer.

@+

[frantzgac]

Salut Frantzgac.


Il vaut mieux mettre partout la même chose. Je dirai une précaution.
Je n'aime pas trop les valeurs par défaut et du coup, j'ai tendance à trop déclarer.

@+

Oui je comprends. ça se plaide !

[Artemus24]

Salut à tous.

Quand vous tapez au clavier un alt + 0156, ce n'est pas un caractère UTF8 qui apparait, mais un caractère windows-1252.
La grosse différence est que le caractère 'œ' sous windows-1252 est codé en décimal "156" ou en hexadécimal "0x9c" mais ce code en utf8 ne correspond à rien du tout.

Pourquoi cela fonctionne dans nos exemple ?
Nous passons par un éditeur de nom "notepad++" et nous précisons dans l'éditeur, le type de conversion "Encoder en UTF8 (sans bom)".
La conversion se fait automatiquement dans l'éditeur !

Mettre "ascii_char(156)" ne fonctionne pas !

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
CREATE DATABASE '..\Data\Base.fdb' page_size 4096 DEFAULT CHARACTER SET UTF8;
 
SET NAMES UTF8;
 
create table test (
id  int      not null primary key,
lib char(20) not null collate UTF8);
 
insert into test (id,lib) values (1, ascii_char(156));
Statement failed, SQLSTATE = 22000
Malformed string
After line 7 in file 4.Base.sql
 
select * from test;
 
exit;
 
Appuyez sur une touche pour continuer...

Comme je l'ai dit ci-dessus, le caractère codé 0x9C ou en décimal 156 n'existe pas sous UTF8.

Comment procéder pour saisir ce caractère récalcitrant, dans votre exemple ?

1) j'ai cherché sur le net, à quoi correspond le caractère "œ" en UTF8.
--> http://www.utf8-chartable.de/unicode...codeinhtml=hex
J'ai trouvé la codification UNICODE qui est en haxadecimal "0xC593".

2) voici un exemple de la codification de ce caractère indépendant de tout éditeur de text.

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
CREATE DATABASE '..\Data\Base.fdb' page_size 4096 DEFAULT CHARACTER SET UTF8;
 
SET NAMES UTF8;
 
create table test (
id  int      not null primary key,
lib char(20) not null collate UTF8);
 
insert into test (id,lib) values (1, 's' || x'C593' || 'urs');
 
select * from test;
 
          ID LIB
============ ====================
           1 sœurs
 
 
exit;
 
Appuyez sur une touche pour continuer...

@+

[SergioMaster]

Mettre "ascii_char(156)" ne fonctionne pas !

Avec FlameRobin (c'est la question de frantzgac) je te garanti que si ! j'ai fait les essais

[Artemus24]

Salut SergioMaster.

Je te crois car nous ne sommes pas dans le même environnement.
Ce qui signifie qu'il y a bien une conversion, sous FlameRobin, qui se fait.

Par contre, même si ma solution fonctionne, je ne la trouve pas sioux.
En fait, le problème de frantzgac est concerne la conversion implicite dans l'environnement FlameRobin.
Et vu que je ne l'utilise pas, je ne sais pas le résoudre.

Y-a-t-il un paramétrage quelque part, pour indiquer que l'on travaille avec windows-1252, mais que le résultat doit être du UTF8 ?

@+

[SergioMaster]

Ce qui signifie qu'il y a bien une conversion, sous FlameRobin, qui se fait.
...
Y-a-t-il un paramétrage quelque part, pour indiquer que l'on travaille avec windows-1252, mais que le résultat doit être du UTF8 ?

Oui la conversion se fait, comme elle se ferait avec un TIBQuery ou tout autre composants Delphi de connexion aux SGBD
si la question porte sur Flamerobin : Aucun
s'il s'agit de ISQL : pas la moindre idée

[frantzgac]

Bonsoir

merci de vos tests. Désolé j'aurais pu produire l'installeur de FB 2.1.

J'ai refait les commandes de Sergio Master après avoir créée la table de la même façon (je l'ai nommé VILLES_FRANCE_SM pour la distinguer)

Voici l'image des résultats

On voit donc que dans ma configuration la syntaxe incluant le caractère 'œ' provoque une erreur (j'ai testé la même requête avec un espace dans ville_nomsimple qui est acceptée)

On voit aussi que la syntaxe ASCII_CHAR(156) ne provoque pas d'erreur mais un "select *" montre un champ code_villesimple vide. Elle n'est pas tout à fait vide puisque char_length(code_villesimple) retourne 1. ASCII_VAL retourne 156. Donc dans mon environnement ce code Ascii n'est pas transformé en 'œ'.

Ma version de FlameRobin est 0.9.3 (je n'en connais pas de supérieure).

Pour le moment je ne vois pas d'explication à ce que nos tests provoquent des résultats divergents.

Mais il se peut que cela vienne du DEFAULT_CHARACTER SET de la base (ISO_8859_1) (déjà signalé dans les premiers échanges).

[SergioMaster]

Bonjour,

Mais il se peut que cela vienne du DEFAULT_CHARACTER SET de la base (ISO_8859_1) (déjà signalé dans les premiers échanges).

Ah, mais cela change tout ! mes tests ont été effectués sur une base UTF8 pas une ISO8859_1 ce qui n'est pas la même chose

un petit retour en arrière à cette discussion qui va une fois de plus faire réagir Artémus
1- La norme ISO_8859_1 ne permet pas l'€ ni le œ ni le ç contrairement à la norme ISO_8859_15 (j'ai mis exprès des _ entre ISO et 8859
2- le Jeu de caractères ISO8859-1 de Firebird correspond en fait à la Norme ISO_8859_15

ceci étant posé, les auteurs de Flamerobin n'ont jamais voulu appliquer ce fait (ils sont obtus, pourtant ce "bug" a été remonté plusieurs fois toujours clos comme inadéquat), ce qui fait que avec une base ISO8859-1 il utilisent une correspondance Stricte (c'est à dire la norme ISO_8859_1) d'où le problème

That's understandable, as the € sign is not part of the ISO8859_1
character set, it's only in ISO8859_15. Not much we can do about it in
FlameRobin.
Maybe we should handle that kind of error more gracefully, and show a
better error message instead of feeding an empty statement to IBPP, but
this would be a feature request.

de fait, après nouveau tests sur une base ISO8859_1 et flamerobin l'insertion d'un enregistrement avec un œ fonctionne avec ASCII_CHAR(156) (vérifié par un programme tiers) mais ce dernier ne s'affichera pas avec un SELECT (toujours pour les raisons évoquées plus haut)
Pour moi il s'agit bien d'un bug de Flamerobin (confirmée par le fait que d'autres GUI comme RapidSQL ou IBExpert comme mes programmes retourne bien le œ ou le €)
l'utilisation d'un Insert avec de l'hexadécimal comme indiqué par Artémus par contre ne fonctionne pas (toujours via flamerobin)
INSERT INTO VILLE(ID,NOM) VALUES (1,'x'BD') donnera en affichage 1,¼ ! (eh, oui, revoilà notre ISO_8859_1 encore une fois, CQFD)

Que faire ? reporter à nouveau le bug aux auteurs (qui risquent une fois de plus de le rejeter, même en indiquant la différence entre le jeu de Firebird et celui de la norme) , modifier le source du programme flamerobin et recompiler (dur dur) ou faire avec

[Artemus24]

Salut SergioMaster.

Comme je l'ai déjà dit précédement, le charset ISO8859_1 de FireBird me rejette bien le caractère "œ" ainsi que "€".
Et c'est normal car ces caractères ne font pas parties du charset ISO8859_1. Voici ce que j'ai chez moi :

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
23
24
CREATE DATABASE '..\Data\Base.fdb' page_size 4096 DEFAULT CHARACTER SET ISO8859_1;
 
SET NAMES ISO8859_1;
 
create table test (
id  int      not null primary key,
lib char(20) not null collate FR_FR);
 
insert into test (id,lib) values (1, 'ça marche');
insert into test (id,lib) values (3, '?uro');
insert into test (id,lib) values (2, 'c?ur');
 
select * from test;
 
          ID LIB
============ ====================
           1 ça marche
           3 ?uro
           2 c?ur
 
 
exit;
 
Appuyez sur une touche pour continuer...

Le problème n'est pas aussi simple qu'on peut le croire. Pourquoi ?
Il y a sous windows quatre environnements qu'il faut tenir compte pour afficher et gérer correctement les charset :

1) Le fichier de stockage des scripts FireBird.
Comme c'est un fichier text, le jeu de caractères doit être sélectionné avant de faire la moindre saisie.
Pour cela, j'utilise NotePad++ avec comme encodage "ISO-8859-1" (je l'ai écrit avec un tiret car c'est ainsi qu'il est codifié dans NotePad++).

A ce niveau, il ne faut pas confondre :
--> ansi
--> windows-1252
--> iso-8859-1

Il n'y a pas beaucoup de différences, et choisir l'un ou l'autre ne va rien changer.

2) La console windows (l'invite commande).
Quand j'exécute un script, je le lance dans une invite commande et de ce fait, je dois spécifier le jeu de caractères qui va s'afficher.
Ici, j'utilise le jeu de caractères Windows-1252.

Windows se débrouille pour faire la correspondance entre le charset du caractère stocké et le charset affiché à la console.

3) La base de données FireBird.
Le stockage étant fait dans une base de données, il faut aussi spécifier le jeu de caractères utilisés.

4) le transfert depuis FireBird vers votre application.
C'est le fameux "SET NAMES ISO8859_1" de mon exemple.
Sous MySql, la plupart du temps, les problèmes d'affichage concerne l'oubli de cette commande.

Concernant le caractère sous forme hexadécimal, il s'agit de son code et il n'est pas converti.
Il est normal qui si vous mettez 0xBD d'avoir à l'affichage le caractère correspondant au jeu d'essai utilisé.
Sous ISO_8859_1, il s'agit du caractère "½". Tandis que sous UTF8, le caractère n'existe pas.
Malheureusement, le charset ISO_8859_15 n'existe pas sous FireBird et en toute logique, il aurait dû afficher "œ".

@+

[SergioMaster]

Bonjour,

Comme je l'ai déjà dit précédement, le charset ISO8859_1 de FireBird me rejette bien le caractère "œ" ainsi que "€".

encore une fois, c'est un problème d'environnement , c'est la cas avec ISQL mais cela dépend autrement du GUI utilisé

I.M.O. c'est le SET NAMES de ISQL fait que le reste des commandes console se fait sur du ANSI ISO_8859_1 ce qui ne veut pas dire contrairement à ton interprétation que

Et c'est normal car ces caractères ne font pas parties du charset (firebird) ISO8859_1.

Code :

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

1
2
 
CREATE DATABASE '..\Data\Base.fdb' page_size 4096 DEFAULT CHARACTER SET ISO8859_1;

la base est bien en CHARSET Firebird ISO8859_1 qui correspond de fait à la norme ANSI ISO_8859_15
SET NAMES ISO8859_1; cette commande applique à l'environnement la Norme ANSI ISO_8859_15
c'est pour cette raison que j'ai dit et répète que le nom du CHARSET FIREBIRD ISO8859_1 est un faux ami et que ce dernier correspond de fait à la norme ISO 8859_15

Malheureusement, le charset ISO_8859_15 n'existe pas sous FireBird et en toute logique, il aurait dû afficher "œ".

en toute logique ils (les devs.) auraient dû, au moment de l'application de la norme ISO 8859_15, rajouter le charset et faire le nécessaire avec ISQL, mais ils ont préféré, certainement pour des raisons de compatibilité descendante ne pas le faire

toutefois voici une image qui ...

me et te contredit

base existante en charset Firebird ISO8859-1, mode console CHCP 1252 et ISQL, je n'ai pas fait de SET NAMES
par contre, pour cette base, j'ai rajouté un charset dans RDB$CHARACTERSETS

Code :

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

INSERT INTO RDB$CHARACTER_SETS ( RDB$CHARACTER_SET_NAME, RDB$FORM_OF_USE, RDB$NUMBER_OF_CHARACTERS, RDB$DEFAULT_COLLATE_NAME, RDB$CHARACTER_SET_ID, RDB$SYSTEM_FLAG, RDB$DESCRIPTION, RDB$FUNCTION_NAME, RDB$BYTES_PER_CHARACTER) VALUES ( 'ISO8859_15                     ', NULL, NULL, 'ISO8859_1                      ', '99', '1', NULL, NULL, '1');

je ne crois pas que cela joue mais ....

[frantzgac]

Pour information ma base est en ISO8859_1

mais la table a été créée en attribuant des CHARSET explicites

Code :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE VILLES_FRANCE
(
  VILLE_ID integer NOT NULL,
  VILLE_DEPARTEMENT varchar(3) DEFAULT NULL,
  VILLE_SLUG varchar(255) CHARACTER SET UTF8 DEFAULT NULL,
  VILLE_NOM varchar(45) CHARACTER SET UTF8,
  VILLE_NOM_SIMPLE varchar(45) CHARACTER SET UTF8 DEFAULT NULL,
  VILLE_NOM_REEL varchar(45) CHARACTER SET UTF8 DEFAULT NULL,
...

Pour le moment et pour exploiter la table j'ai supprimé les champs de la colonne VILLE_NOM_REEL qui comportait les séquences hexadécimales entraînant une exception à la lecture. Du genre $c5,$92,$c2,$8c. En revanche le champ VILLE_NOM_SLUG de la table de la même ligne comportant $6F, $65 ,$c2,$8c ou 'o', 'e' ,$c2,$8c ne s'affiche bien sûr pas correctement mais ne plante pas la lecture.

[SergioMaster]

@Artemus


j'ai rajouté le ASCII_CHAR P.S. note bien le chcp 1252 avant le lancement de ISQL sinon même l'affichage des 3 premiers records aurait été faux

Pour information ma base est en ISO8859_1
mais la table a été créée en attribuant des CHARSET explicites

la description de la table eut été la bienvenue mais bon , peut importe.

Comme quoi c'était important de tout dire !

je vais faire les tests [Edit] dans ce cas de figure je n'arrive à rien quelque soit le GUI

[Artemus24]

Salut SergioMaster.

Peux-tu tester ce script dans ton environnement ?
Au lieu de mettre des caractères, j'ai mis à la place le code hexadécimal des caractères : €, œ et ç.

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
23
24
25
CREATE DATABASE '..\Data\Base.fdb' page_size 4096 DEFAULT CHARACTER SET NONE;
 
SET NAMES NONE;
 
create table test (
id      int      not null primary key,
lib     char(50) not null,
carac   char(50) not null);
 
insert into test (id,lib,carac) values (10, 'Windows-1252 - 128 - euro     ', x'80');
insert into test (id,lib,carac) values (11, 'Windows-1252 - 156 - oe       ', x'9C');
insert into test (id,lib,carac) values (12, 'Windows-1252 - 231 - c cedille', x'E7');
 
insert into test (id,lib,carac) values (20, 'ISO_8859_15  - 164 - euro     ', x'A4');
insert into test (id,lib,carac) values (21, 'ISO_8859_15  - 189 - oe       ', x'BD');
insert into test (id,lib,carac) values (22, 'ISO_8859_15  - 231 - c cedille', x'E7');
 
 
insert into test (id,lib,carac) values (30, 'UTF8         - 164 - euro     ', x'E282AC');
insert into test (id,lib,carac) values (31, 'UTF8         - 189 - oe       ', x'C593');
insert into test (id,lib,carac) values (32, 'UTF8         - 231 - c cedille', x'C3A7');
 
select * from test;
 
exit;

Donc aucune conversion sera faite ! Et bien sûr, tu me donnes le résultat de l'affichage.

Je pense que cela va nous départager dans l'approche que nous avons de la gestion des charset sous FireBird.

@+

[Artemus24]

Salut SergioMaster.

Merci SergioMaster d'avoir pris le temps de faire le test !

Ce test a pour but de t'indiquer le charset qui est utilisé à l'affichage.

Il ne fallait pas le faire ainsi, en passant par la console windows.
Car si dès le départ, tu forces le chcp à windows-1252, seul ce jeu de caractères sera lisible et ce n'est pas ce que je recherche.

J'aurai aimé que tu le fasses dans FlameRonbin, sans forcer à l'affichage le charset, afin de connaitre celui qui est utilisé par défaut.

Si pour un charset donné, les trois caractères sont lisibles alors c'est ce charset qui est en vigueur.
Inversement, si aucun charset affiche correctement les trois caractères, mais que le "ç" s'affiche correctement, tu es en iso_8859_1.

C'est juste pour confirmer ou infirmer le fait que tu dises que iso_8859_1 (latin 1) sous FireBird, c'est du iso_8859_15 (latin 9).

P.S.: il n'était pas nécessaire de rentrer le code ascii_char(156) car celui-ci existe déjà pour la ligne "Windows-1252 - 156 - oe".

@+