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()

[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]

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

[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 !

[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 SergioMaster.

je pensais bien évidemment ASCII_CHAR(156) ...

C'est quoi ça, un ASCII_CHAR(156) ? La table ASCII compte normalement 128 caractères, numéroté de 0 à 127 !
Si tu peux accéder au caractère numéroté 156 (ou 0xC9), qui lui-même correspond à "œ", c'est que tu utilises le charset "windows-1252".
Surtout que tu récupères ce caractère à partir de ton clavier, en tapant "ALT 156".

Il y a un abus de langage.

@+

[SergioMaster]

C'est quoi ça, un ASCII_CHAR(156) ? La table ASCII compte normalement 128 caractères, numéroté de 0 à 127 !
Il y a un abus de langage.

dis ça à la syntaxe ASCII_CHAR de Firebird

[frantzgac]

Bonjour
Désolé du gap de quelques mois mais entre temps j'ai déménagé deux fois. Bon.
Je reviens à mon sujet de 'o' e dans l'o car ça ne s'est pas arrangé tout seul...
Je précise que j'utilise Firebird 2.1

Si j'entre dans Flamerobin la chaîne suivante

Code :

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

insert into VILLES_FRANCE (ville_id,ville_nom_simple,ville_code_commune) values (1,'œ',0)

J'obtiens ce message :

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

A l'origine du problème il s'agit d'insérer dans une table un fichier de communes de france. Certaines d'entre elles s'écrivent avec le caractère "œ" (ALT 0156). Mais en réalité dans le fichier (en UTF8 d'après sa doc) œ est codé parfois

Code :

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

0xc2 0x8c

(Notepad en option Hexadécimal)
et d'autre fois

Code :

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

0xc5 0x92 0xc2 0x8c

Dans ce deuxième cas il est à noter que même Notepad en mode UTF-8 ne reconnait pas le second code.

Cette chaine s'insère sans difficulté dans Firebird (avec un TIBQuery) mais en revanche lors de la lecture de la table par Select et dès que j'atteins la première ligne contenant ce code sur 16 bits j'obtiens le message d'erreur

SQL Message -802
Arithmetic overflow or division by zero occured
Cannot transliterate character between character sets

Le DDL de la table atteste

CHARACTER SET UTF8

pour les champs concernés

[SergioMaster]

Bonjour,

Désolé du gap de quelques mois mais entre temps j'ai déménagé deux fois. Bon.
Je reviens à mon sujet de 'o' e dans l'o car ça ne s'est pas arrangé tout seul...
Je précise que j'utilise Firebird 2.1

j'ai eu quelques difficultés à retrouver un firebird en 2.1 sous windows (faut-il le préciser ?) , je viens de faire un test avec la version 2.1.3.18185

Si j'entre dans Flamerobin la chaîne suivante

Code :

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

insert into VILLES_FRANCE (ville_id,ville_nom_simple,ville_code_commune) values (1,'œ',0)

la description de la table eut été la bienvenue mais bon , peut importe.
J'ai créé une nouvelle base (UTF8) avec une table
CREATE TABLE VILLES_FRANCE
(VILLE_ID INTEGER,
VILLE_NOMSIMPLE VARCHAR(30),
VILLE_CODE CHAR(5)
)
puis fait un Insert avec FlameRobin (ver 0.9.3.1870)

Code :

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

insert into VILLES_FRANCE (ville_id,ville_nom_simple,ville_code_commune) values (1,'œ','0')

pas d'erreur, bon effectivement en relisant je vois que ta colonne ville_code_commune semble être numérique contrairement à ma colonne VILLE_CODE
mais je pense pas que cela joue
[Edit] effectivement cela ne joue pas j'ai mis la colonne VILLE_CODE en integer toujours pas d'erreur.
j'en ai même profité pour tester la syntaxe avec ASCII_CHAR(156)

Code :

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

1
2
insert into VILLES_FRANCE (ville_id,ville_nom_simple,ville_code_commune) values (2,'œ',0);
insert into VILLES_FRANCE (ville_id,ville_nom_simple,ville_code_commune) values (3,ASCII_CHAR(156),0);

[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 ....