Discussion :

[alanglet]

Bonjour Serge,
Cela fait plusieurs fois que je vous vois écrire ça.

il faut savoir que ISO8859_1 de Firebird n'est pas celui de la norme ISO car contenant (entre autre) le caractère € donc pour un "puriste" (par exemple le programme Flamerobin le symbole de l'euro ne passe pas dans une base ISO8859_1) l'ISO8859_1 de Firebird est en fait l'ISO8859_15 aussi connue comme Latin 9 (ou encore non officiellement latin 0) donc plus proche de WIN1252 que de l'ISO8859_1 normalisé
les différences se situent ensuite dans la tranche x80 à xBE et des caractères comme par exemple : ¼½¾©®

Comme j'ai quelques doutes j'ai voulu exécuter la requête suivante:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
execute block returns(
i smallint,
lettre char(1) character set iso8859_1)
as
begin
  i=0;
  while (i<=255) do
  begin
    lettre=ascii_char(i);
    suspend;
    i=i+1;
  end
end

en étant connecté à une base, la connexion à cette base étant définie dans un character set différent de l'iso8859_1.
Cette expérience j'ai pu la faire avec IBExpert qui accepte les requêtes execute block (pas flamerobin), avec Delphi7 et Lazarus en utilisant des composants qui acceptent aussi ce type de requête.
Si les jeux de caractères de "lettre" et de la connexion sont les mêmes, il n'y a pas de problème, puisque Firebird ne fait pas de translittération. Mais s'ils sont différents, Firebird émet un message "Cannot transliterate character between character sets", et la lecture pas à pas dans IBExpert permet de constater que l'erreur se produit lors de la translittération du caractère 128, même lorsque le jeu de caractères de connexion est le win1252, jeu qui comprend bien ce caractère.

Amicalement
André
PS: essais faits avec FB server 2.5

[SergioMaster]

Bonjour,

@alanglet j'ai préféré en faire une discussion à part

Cette expérience j'ai pu la faire avec IBExpert qui accepte les requêtes execute block (pas flamerobin),

FlameRobin accepte les execute block, une seule nécessité rajouter un SET TERM ^; avant la définition du block et conclure par un SET TERM ;^
donc action j'ai fait cette manipulation avec (je n'avais jamais pensé à la faire)

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
 
SET TERM ^;
execute block returns(
i smallint,
lettre char(1) character set iso8859_1)
as
begin
  i=0;
  while (i<=255) do
  begin
    lettre=ascii_char(i);
    suspend;
    i=i+1;
   -- pour passer le 128
   WHEN ANY DO
     BEGIN
       i=i+1;
     END 
  end
end^
SET TERM ; ^

avec Flamerobin pas d'erreur de translittération mais lettre est proposé selon le charset de la base le lettre char(1) character set iso8859_1 passe sur une base UTF8, plante effectivement sur le 128 avec une base WIN1252 (d'où ma modification)

j'ai ensuite transformé de la manière suivante pour essayé de comparer les deux

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
SET TERM ^;
execute block returns(
i smallint,
lettre varchar(4) character set iso8859_1,
lettrew varchar(4) character set Win1252)
as
begin
 
  i=0;
  while (i<=255) do
  begin
    lettre=ascii_char(i);
    lettrew=ascii_char(i);
    suspend;
    i=i+1;
    WHEN ANY DO 
    BEGIN 
     i=i+1; 
    END   
  end
 
end^
SET TERM ; ^

moralité : sous flamerobin j'ai le même affichage , ascii_char ne serait pas le bon choix ?
[edit] selon mes lectures le résultat de ascii_char est de type: [VAR]CHAR(1) CHARACTER SET NONE c'est peut être pour ça

[alanglet]

IBExpert permettant d'exécuter une procédure pas à pas, j'ai mis la requête sous la forme d'une procédure et vérifié qu'il n'y a pas d'erreur lors de l'exécution de la fonction ascii_char. Il me semble donc que ascii_char ne fait pas de contrôle de l'existence dans le jeu, il affecte simplement le code au caractère.
J'ai refait l'expérience de la requête execute block avec le When any qui permet de simplement sauter la ligne résultat en erreur, mais avec une seule lettre (s'il y a plusieurs "lettre", on ne sait pas laquelle est la cause de l'erreur).
Si connexion est en win1252 et la lettre en ISO8859_1, toutes les lignes de 128 à 159 sont absentes.
Si connexion est en ISO8859_1 et la lettre en win1252, dans la même tranche de codes n'apparaissent que les codes 129, 141, 143, 144 et 157 mais avec la lettre vide. Ça me semble cohérent avec la définition du win1252 https://fr.wikipedia.org/wiki/Windows-1252.
Si connexion et lettre appartiennent au même jeu, qu'il soit ISO8859_1 ou win1252, tous les codes apparaissent, ce qui confirme que dans ce cas Firebird n'exécute aucun contrôle.
Cette dernière particularité est à l'origine de bases que certains considèrent comme corrompues. Champs et connexion ISO8859_1 et utilisées depuis un logiciel Delphi7 sous Windows (donc win1252) les utilisateurs pouvaient y écrire sans inconvénient des caractères de win1252 n'existant pas le jeu ISO comme nos Œ et œ. Lorsqu'on veut se connecter à ces bases depuis Lazarus avec une connexion en UTF8 (pour éviter de programmer la translittération à chaque lecture), Firebird émet une erreur à chaque fois qu'on lit un champ contenant un caractère absent de l'ISO8859_1.

André

[SergioMaster]

Bonjour,

Si connexion est en win1252 et la lettre en ISO8859_1, toutes les lignes de 128 à 159 sont absentes.
Si connexion est en ISO8859_1 et la lettre en win1252, dans la même tranche de codes n'apparaissent que les codes 129, 141, 143, 144 et 157 mais avec la lettre vide.

qu'à cela ne tienne on peut contourner ainsi

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
26
SET TERM ^;
execute block returns(
i smallint,
lettre varchar(4) character set iso8859_1,
lettrew varchar(4) character set Win1252)
as
begin
 
  i=0;
  while (i<=255) do
  begin
    lettre=ascii_char(i);
    lettrew=ascii_char(i);
    suspend;
    i=i+1;
    WHEN ANY DO 
    BEGIN 
     lettre='Err';
     lettrew='Err';
     suspend;
     i=i+1; 
    END   
  end
 
end^
SET TERM ; ^

je ne pense pas, hélas, que l'on puisse distinguer entre lettre et lettrew celui qui renvoi l'erreur quoique ....

[alanglet]

Bonjour,

Peu importe que les lignes vides soient remplacées par "Err", le test démontre que les caractères 128 à 159 sont bien absents du jeu ISO8859_1 de Firebird conformément à la norme.
Il démontre aussi que préconiser d'utiliser l'ISO8859_1 pour des champs pouvant contenir nos caractères bien français comme les €, Œ et œ est une erreur.
Ces caractères figurent dans l'ISO8859_15 et le WIN1252, mais dans l'ISO8859_15 (qui garde la tranche vide de 128 à 159) des caractères de nos claviers AZERTY comme la barre verticale | et le symbole monétaire ¤ sont absents. C'est pourquoi, à moins de mettre un filtre ou un format sur chaque champ de saisie alphabétique dans l'interface utilisateur, je pense qu'il est préférable d'utiliser le WIN1252.
Certains diront sans doute que l'UTF8 permet de se débarrasser de ces contraintes. C'est sans doute vrai, mais alors au détriment de la vitesse et de la taille de la base.

André

[SergioMaster]

Re,

reste que si on a affaires à LINUX (je ne sais ce qu'il en est de OSX, IOS, ANDROID) l' ISO8859_1 ou _15 sera à retenir car cet OS dit ne pas connaître WIN1252

[alanglet]

reste que si on a affaires à LINUX (je ne sais ce qu'il en est de OSX, IOS, ANDROID) l' ISO8859_1 ou _15 sera à retenir car cet OS dit ne pas connaître WIN1252

L'OS peut-être, mais ici on s'intéresse aux champs de la base gérés par Firebird. Que ce soit sous Windows ou Linux, Firebird connaît toujours WIN1252. Même sous Linux (qui souvent utilise l'UTF8 me semble-t-il) on utilise chez nous des claviers AZERTY qui donnent l'accès direct aux caractères du jeu WIN1252 (ou qui en est très proche).
Comme dit précédemment, pour des logiciels développés sous Lazarus, la connexion utilise l'UTF8 même si les champs sont en WIN1252.

André

[ddaime]

Bonjour à tous.

J'ai toujours eu du mal avec les Charset et j'avoue que j'ai du mal à comprendre certain aspect. J'utilise pour ma part UTF8 pour mes bases et je n'ai aucun problème pour afficher mes caractères (é, €, ...). Je travail principalement sur Windows (C++, wxWidgets, IBPP ou wxDatabaseLayer).

Vous utilisez quoi comme charset (ISO8859_1, ISO8859_15, WIN1252 ou UTF8) ?

Et quel sont les différences fondamentales des ces différents charset ?

Merci.

[Artemus24]

Salut à tous.

J'ai repris votre discussion et il y a des points qui me paraissent suspectes.

1) la sélection du charset à l'affichage.
Pour ce faire, j’exécute le script sql de firebird en ouvrant une console batch, en précisant sous windows ceci :

--> chcp 1252 > nul
pour le charset 'windows-1252'.

--> chcp 28591 > nul
pour le charset 'iso-8859-1' ou 'latin1'.

--> chcp 28605 > nul
pour le charset 'iso-8859-15' ou 'latin9'.

--> chcp 65000 > nul
pour le charset 'utf-7'.

--> chcp 65001 > nul
pour le charset 'utf-8'.

Vous trouverez les explications dans ce lien : https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

2) l'affichage caractère '€'.

il faut savoir que ISO8859_1 de Firebird n'est pas celui de la norme ISO car contenant (entre autre) le caractère € ...

A vrai dire Sergiomaster, je n'avais pas vérifié tes propos.

J'ai repris l'affichage du charset à la console batch sous windows et j'ai cherché le caractère '€'.
--> pour 'windows-1252', il se trouve en position 128 (0x80).
--> pour iso-8859-1, je ne l'ai pas retrouvé.
--> pour iso-8859-15, il se trouve en position 164 (0xA4).

Donc non SergioMaster, les charset sont bien conforme à la norme !

3) j'ai utilisé le 'execute block' en modifiant le charset de la base et celui du 'lettre'.
J'ai testé à l'affichage les charset WINDOWS-1252, ISO-8859-1, ISO-8859-15 et UTF-7 avec ceux de FireBird.

--> avec 'chcp 1252 > nul'.
Que j'utilise win1252 ou iso8859-1 (sous firebird), j'obtiens exactement la même chose, à savoir le charset windows-1252 à l'affichage.

--> avec 'chcp 28591 > nul'. (iso-8859-1).
Que j'utilise win1252 ou iso8859-1 (sous firebird), j'obtiens exactement la même chose, à savoir le charset iso-8859-1 à l'affichage.

--> avec 'chcp 28605 > nul'. (iso-8859-15).
Que j'utilise win1252 ou iso8859-1 (sous firebird), j'obtiens exactement la même chose, à savoir le charset iso-8859-15 à l'affichage.

--> avec 'chcp 65000 > nul'. (utf-7).
Que j'utilise win1252 ou iso8859-1 (sous firebird), j'obtiens exactement la même chose, à savoir le charset utf-7 à l'affichage.

L'explication est facile à trouver.
Quand j'utilise dans le 'execute block' l'instruction "lettre=ascii_char(i);", il met dans un octet un nombre allant de 0 à 255.
Or cette codification correspond exactement à la codification des charset sur 1 octet, comme windows-1252, ISO-8859-1, ISO-8859-15 et utf-7.

Si je mets n'importe quel charset (de FireBird) ayant une codification sur 1 octet, à l'affichage, j'aurai le jeu de caractères utilisé sous ma console windows (chcp ... > nul).

4) mais quand est-il de UTF8 (de Firebird) ?
Il n'a pas la même codification que windows-1252, iso-8859-1 et iso-8859-15 ou utf-7, c'est-à-dire les charset sur 1 octet.
Et de ce fait, le caractère ne peut pas s'affiché correctement car il n'est pas reconnu par le charset de l'affichage.

--> http://www.destructor.de/firebird/charsets.htm

D'après "alanglet", j'ai aussi constaté ce "transliterate" que je traduirais plutôt par trans-codification !
Il semble exister, sous FireBird, des tables de conversions entre certains charset.
Il semble y avoir des trous que la trans-codification ne sait pas compléter par de bons codes pour l'affichage.
A ce sujet, je n'en sais pas plus.

Donc n'oubliez pas de choisir le bon charset à l'affichage pour être en conformité vis-à-vis de celui que vous utilisez dans vos bases.

@+

[alanglet]

Bonjour,

D'après "alanglet", j'ai aussi constaté ce "transliterate" que je traduirais plutôt par trans-codification !

Désolé, mais "transliterate" ne figure pas dans mon Robert & Collins
Je ne voudrais pas transformer ce forum en cours de français, mais "translittération" figure bien dans mon Petit Larousse (de 1995) avec cette définition: "Transcription faite en transposant lettre par lettre les signes d'un alphabet et ceux d'un autre alphabet".
Amusant, dans une autre discussion où un interlocuteur parlait de "transcodage" ("Traduction dans un code différent" ou "Traduction en code interne des instructions écrites par un programmeur, dans un ordinateur" selon mon Petit Larousse) on lui a fait remarquer qu'il s'agissait plutôt de "translittération".

André

[SergioMaster]

Bonjour,

je reprend ce point

A vrai dire Sergiomaster, je n'avais pas vérifié tes propos.

J'ai repris l'affichage du charset à la console batch sous windows et j'ai cherché le caractère '€'.
--> pour 'windows-1252', il se trouve en position 128 (0x80).
--> pour iso-8859-1, je ne l'ai pas retrouvé.
--> pour iso-8859-15, il se trouve en position 164 (0xA4).

Donc non SergioMaster, les charset sont bien conforme à la norme !

là encore il y a mésentente. le CHARSET ISO8859-1 nommé ainsi par Firebird est en fait plus proche de la norme ANSI ISO8859-15 que de la norme ANSI ISO8859-1 ou peu s'en faut. Très peu de temps après le passage à l'Euro (voire avant) le CHARSET ISO8859-1 de Firebird s'est vu "octroyé" de l'extension LATIN 1 ce qui permet ainsi les symboles comme l'euro non inscrit dans la norme ANSI sensu stricto. En étant très pointilleux je crois que l'on peut trouver des différences entre ce charset de Firebird et l'ISO 8859_15.

Où il y a suspicion c'est en fait sur l'outil utilisé pour l'affichage, là où Artémus utilise le mode console (et la possibilité de changer le charset de ce dernier) nous nous cantonnons à l'utilisation de GUI Windows où le charset d'affichage n'est pas modifiable.

Donc pour répondre à DDaime sauf si la base doit contenir des caractères non "latin" (par exemple arabe, chinois etc...) auxquels cas l'UTF8 est tout désigné, pour des raisons de facilité j'utilise soit l'ISO8859-1(+Latin1) soit WIN1252. En fait ma préférence pour la base va à WIN1252 par défaut en codant certaines colonne en ISO8859-1 pour des questions de tris (COLLATE)

[alanglet]

le CHARSET ISO8859-1 nommé ainsi par Firebird est en fait plus proche de la norme ANSI ISO8859-15 que de la norme ANSI ISO8859-1 ou peu s'en faut. Très peu de temps après le passage à l'Euro (voire avant) le CHARSET ISO8859-1 de Firebird s'est vu "octroyé" de l'extension LATIN 1 ce qui permet ainsi les symboles comme l'euro non inscrit dans la norme ANSI sensu stricto. En étant très pointilleux je crois que l'on peut trouver des différences entre ce charset de Firebird et l'ISO 8859_15.

J'avoue avoir du mal à comprendre ce qui vous permet de continuer d'affirmer ça alors que mes tests et ceux d'Artemus démontrent le contraire? A moins que l'absence de marteau...
S'il est encore possible de vous convaincre du contraire, voici en copie d'écran le test fait cette fois avec Flamerobin. La connexion en win1252 est choisie car j'utilise Windows et tous les codes de 0 à 255 y étant définis la ligne correspondante s'affichera si elle existe.

Vous pouvez constater que tous les codes de 128 à 159 (dont le 128 => € en WIN1252) sont absents et que pour les codes affichables mais modifiés dans l'ISO8859_15 comme ¤ en 164 remplacé par € (et d'autres trop loin sur ma copie d'écran comme ¼ en 188 remplacé par Œ et ½ en 189 remplacé par œ) s'affichent bien comme définis en ISO8859_1.
J'aurais bien fait le test avec l'ISO8859_15, mais comme il ne figure pas dans les listes de choix de Flamerobin, ni de IBExpert ni de composants récents comme les UIB, je suis allé voir dans la table RDB$CHARACTER_SETS de la base exemple EMPLOYEE de FB2.5. L'ISO8859_15 n'y figure pas non plus.
Vous avez raison de dire que le jeu ISO8859_1 dispose de beaucoup plus de collections que WIN1252, mais pour cette dernière la collection:
PXW_INTL est quasiment équivalente au FR_FR de l'ISO8859_1
PXW_INTL850 est quasiment équivalente au FR_CA de l'ISO8859_1 pour ce qui concerne l'ordre de tri et la mise en majuscules de nos lettres habituelles.

André

édit: correction des équivalences entre les collections.

[alanglet]

Si vous voulez vérifier l'effet des différentes collections du jeu win1252, voici comment j'ai fait avec une base à laquelle on se connecte en win1252.
Tout d'abord création d'une procédure TEST_LETTRE:

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
SET TERM ^ ;
 
CREATE OR ALTER PROCEDURE TEST_LETTRE 
returns (
    i smallint,
    lettre char(1) character set win1252)
as
begin
  i=0;
  while (i<=255) do
  begin
    lettre=ascii_char(i);
    suspend;
    i=i+1;
    WHEN ANY DO 
    BEGIN 
     i=i+1; 
    END   
  end
end^
 
SET TERM ; ^

ensuite exécution de la requête:

Code :

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

1
2
3
select i,lettre collate pxw_intl ,upper(lettre collate pxw_intl)
from test_lettre
order by 2

qui donne en résultats:

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
I	CAST	 UPPER
32		
0		
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		
26		
27		
28		
29		
30		
31		
33	!	!
34	"	"
35	#	#
36	$	$
37	%	%
38	&	&
39	'	'
40	(	(
41	)	)
42	*	*
43	+	+
44	,	,
45	-	-
46	.	.
47	/	/
48	0	0
49	1	1
50	2	2
51	3	3
52	4	4
53	5	5
54	6	6
55	7	7
56	8	8
57	9	9
58	:	:
59	;	;
60	<	<
61	=	=
62	>	>
63	?	?
64	@	@
97	a	A
225	á	A
224	à	A
226	â	A
227	ã	Ã
65	A	A
193	Á	Á
192	À	À
194	Â	Â
195	Ã	Ã
228	ä	Ä
196	Ä	Ä
98	b	B
66	B	B
99	c	C
231	ç	Ç
67	C	C
199	Ç	Ç
100	d	D
240	ð	Ð
68	D	D
208	Ð	Ð
101	e	E
235	ë	E
233	é	E
232	è	E
234	ê	E
69	E	E
203	Ë	Ë
201	É	É
200	È	È
202	Ê	Ê
102	f	F
70	F	F
103	g	G
71	G	G
104	h	H
72	H	H
105	i	I
239	ï	I
237	í	I
236	ì	I
238	î	I
73	I	I
207	Ï	Ï
205	Í	Í
204	Ì	Ì
206	Î	Î
106	j	J
74	J	J
107	k	K
75	K	K
108	l	L
76	L	L
109	m	M
77	M	M
110	n	N
241	ñ	Ñ
78	N	N
209	Ñ	Ñ
111	o	O
243	ó	O
242	ò	O
244	ô	O
245	õ	Õ
248	ø	Ø
79	O	O
211	Ó	Ó
210	Ò	Ò
212	Ô	Ô
213	Õ	Õ
216	Ø	Ø
246	ö	Ö
214	Ö	Ö
112	p	P
80	P	P
113	q	Q
81	Q	Q
114	r	R
82	R	R
115	s	S
83	S	S
223	ß	ß
116	t	T
84	T	T
254	þ	Þ
222	Þ	Þ
117	u	U
250	ú	U
249	ù	U
251	û	U
85	U	U
218	Ú	Ú
217	Ù	Ù
219	Û	Û
252	ü	Ü
220	Ü	Ü
118	v	V
86	V	V
119	w	W
87	W	W
120	x	X
88	X	X
121	y	Y
255	ÿ	Y
253	ý	Y
89	Y	Y
221	Ý	Ý
122	z	Z
90	Z	Z
229	å	Å
197	Å	Å
91	[	[
92	\	\
93	]	]
94	^	^
95	_	_
96	`	`
123	{	{
124	|	|
125	}	}
126	~	~
127		
230	æ	Æ
198	Æ	Æ
128	€	€
129		
130	‚	‚
131	ƒ	ƒ
132	„	„
133	…	…
134	†	†
135	‡	‡
136	ˆ	ˆ
137	‰	‰
138	Š	Š
139	‹	‹
140	Œ	Œ
141		
142	Ž	Ž
143		
144		
145	‘	‘
146	’	’
147	“	“
148	”	”
149	•	•
150	–	–
151	—	—
152	˜	˜
153	™	™
154	š	š
155	›	›
156	œ	œ
157		
158	ž	ž
159	Ÿ	Ÿ
160	*	*
161	¡	¡
162	¢	¢
163	£	£
164	¤	¤
165	¥	¥
166	¦	¦
167	§	§
168	¨	¨
169	©	©
170	ª	ª
171	«	«
172	¬	¬
173	*	*
174	®	®
175	¯	¯
176	°	°
177	±	±
178	²	²
179	³	³
180	´	´
181	µ	µ
182	¶	¶
183	·	·
184	¸	¸
185	¹	¹
186	º	º
187	»	»
188	¼	¼
189	½	½
190	¾	¾
191	¿	¿
215	×	×
247	÷	÷

et même chose en remplaçant pxw_intl par pxw_intl850.
Dans les 2 cas, l'ordre de tri est CI, mais avec pxw_intl les minuscules accentuées ne sont pas accentuées par la mise en majuscule par UPPER à l'exception des ~ et ¨.

André

[Artemus24]

Salut à tous.

dans une autre discussion où un interlocuteur parlait de "transcodage"

C'est la bonne désignation. Que ce soit ton exemple "execute block" ou tu utilises ceci :

Code :

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

lettre=ascii_char(i);

ou encore ce que tu mets dans tes chaînes de caractères, ce sont des codes et non des lettres.

Je prends la définition de l'ASCII :

L'American Standard Code for Information Interchange (Code américain normalisé pour l'échange d'information), plus connu sous l'acronyme ASCII ([aski?]) est une norme de codage de caractères en informatique ...

C'est une norme de codage ! Un ordinateur ne comprend que des codes.

Maintenant, beaucoup de gens confondent l'affichage qui reprend la même codification mais associe un glyphe, c'est-à-dire une représentation graphique du code utilisé.
Mais dans ce cas là, on parle plutôt de police de caractères et non de jeu de caractères ou charset.

La norme ISO 8859-1, dont le nom complet est ISO/CEI 8859-1, et qui est souvent appelée Latin-1 ou Europe occidentale, forme la première partie de la norme internationale ISO/CEI 8859, qui est une norme de l'Organisation internationale de normalisation pour le codage des caractères en informatique.

Bon, peu importe la discussion ne se porte pas sur la bonne sémantique à utiliser.

le CHARSET ISO8859-1 nommé ainsi par Firebird est en fait plus proche de la norme ANSI ISO8859-15 que de la norme ANSI ISO8859-1 ou peu s'en faut.

Non ! Firebird manipule que des codes pas des glypes ou autres caractères affichables.

Quand je travaille avec FireBird, je suis sous la console batch de windows que l'on nomme l'invite de commande.
Afin d'avoir la correspondance entre le jeu de caractères iso-8859-1 que j'utilise sous firebird avec les glyphes à l'affichage, je suis obligé de préciser la police de caractères que je vais utiliser.
Dans ce cas bien précis, j'utilise "chcp 28591 > nul" pour être en conformité entre le jeu de caractère et la police de caractères de l'iso-8859-1.

Si en affichant tes caractères, codifiés selon la norme iso-8859-1, tu obtiens un '€', c'est qu'à l'affichage tu as autre chose, soit iso-8859-15 ou soit du win1252.
Je parle que de ce que je connais, à savoir mon environnement sous windows 10. Ailleurs, je ne s'aurais dire comme vous faites l'association entre le jeu et la police des caractères.

nous nous cantonnons à l'utilisation de GUI Windows où le charset d'affichage n'est pas modifiable.

Sous windows (l'os) graphique, le jeu de caractères utilisé est le windows-1252.
On peut le modifier en allant dans les paramètres régionaux du panneau de configuration.

En fait ma préférence pour la base va à WIN1252 par défaut en codant certaines colonne en ISO8859-1 pour des questions de tris (COLLATE)

Pour être puriste, il faudrait aligner son jeu de caractères à celui d'affichage.
Si tu n'as pas besoin du chinois ou de l'arabe et que tu te comptentes du français et de l'anglais, le windows-1252 nommé sous firebird par win1252 est largement suffisant.

J'avoue avoir du mal à comprendre ce qui vous permet de continuer d'affirmer ça alors que mes tests et ceux d'Artemus démontrent le contraire?

Je pense qu'il ne doit pas avoir le même paramétrage que nous. C'est la seule explication qui peut marquer cette différence.
En allant dans "région" du panneau de configuration, chez moi, tout est "france".

Vous pouvez constater que tous les codes de 128 à 159 (dont le 128 => € en WIN1252) sont absents

Si l'€ est codé 128 (ou 0x80), c'est bien du window-1252 que vous utilisez.
Si l'€ est codé 164 (ou 0xA4), c'est bien du iso-8859-15.
Inversement, si vous avez ¤ dans le code 164, alors c'est de l'iso-8859-1.

@ alanglet : je devrais plutôt parler de caractères quand je parle de codification et de glyphe pour l'affichage.
Inutile de mettre les caractères < 128 car à l'affichage tu auras toujours les mêmes glyphes, quelque soit le jeu de caractères utilisés.
Car ceci correspond à l'ascii. La différence se fait sur les caractères >= 128 où les glyphes sont différents à l'affichage.

@+

[SergioMaster]

Bonjour

Si l'€ est codé 128 (ou 0x80), c'est bien du window-1252 que vous utilisez.
Si l'€ est codé 164 (ou 0xA4), c'est bien du iso-8859-15.
Inversement, si vous avez ¤ dans le code 164, alors c'est de l'iso-8859-1.

Si le CHARSET ISO8859-1 de Firebird permet (entre autre) le symbole € sans lever d'erreur c'est que ce charset n'applique pas la norme (j'insiste sur le mot norme) ANSI ISO8859-1 de 1987 mais sur la norme "améliorée" ANSI ISO8859-15
en fait il y aurait un travail, fastidieux, à faire pour en être absolument certain et vérifier que seul les changements apportés par la norme ISO8859-15 ont été appliqués (caractères en jaune dans le tableau de l'article) soit les 8 suivants

8859-1 ¤ ¦ ¨ ´ ¸ ¼ ½ ¾
8859-15 € Š š Ž ž Œ œ Ÿ

et aucun autre.

En fait c'est le "LATIN 1" qui peut prêter à confusion.
regardons ce qu'en dit IBExpert mais où est passé l'euro ?

maintenant, pour ce qui est de la représentation du code et donc de son affichage sur un écran (perso je travaille en Unicode) il ne faut pas oublier que la base ou la colonne est encodée d'une certaine manière mais que l'interface avec l'écran décode en fonction de l'affichage de celui-ci

donc pour reprendre Artemus :
Si l'€ est codé 128 (ou 0x80) dans la base alors son CHARSET est win1252 si le symbole s'affiche correctement c'est que l'ensemble de caractères employé pour l'affichage (le code page) contient lui aussi ce symbole (cela ne veut pas forcément dire que ce dernier est WIN1252, il pourrait aussi bien à mon avis être UTF8)

Si l'€ est codé 164 (ou 0xA4) dans la base alors son CHARSET est ISO8859_1 , correspondant AMA à la NORME ISO 8859-15
si vous avez d'affiché ¤ pour ce même code, alors c'est que le code page est de l'iso-8859-1 (pur et dur)

Voilà mon point de vue, c'est pour cela que j’écris que le CHARSET ISO8859_1 de Firebird correspond de fait (sous les réserves citée au dessus) à la NORME ISO8859-15

PS. en cherchant j'ai obtenu certaines pages d'IBEXPERT http://ibexpert.net/ibe/index.php?n=...codeInFirebirdhttp://ibexpert.net/ibe/index.php?n=...tionsToUnicode sur cette dernière page le test des caractères se fait via l'intermédiaire un BLOB et l'éditeur de BLOB

[Artemus24]

Salut à tous

Si le CHARSET ISO8859-1 de Firebird permet (entre autre) le symbole € sans lever d'erreur c'est que ce charset n'applique pas la norme (j'insiste sur le mot norme) ANSI ISO8859-1 de 1987 mais sur la norme "améliorée" ANSI ISO8859-15

Non. Je t'ai déjà donné l'explication :

Si en affichant tes caractères, codifiés selon la norme iso-8859-1, tu obtiens un '€', c'est qu'à l'affichage tu as autre chose, soit iso-8859-15 ou soit du win1252.

Tu as un problème d'affichage et non un problème de norme comme tu sembles l'indiquer.
Sinon explique moi pourquoi je n'ai pas ce "€" dans une chaîne de caractère en iso-8859-1 ?

Voici le batch qui ouvre la console windows. J'ai mis en rouge ce qui est spécifique, à savoir l'utilisation du charset iso-8859-1 sous windows et sous firebird.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
@echo off

chcp 28591 > nul

SET FIC=%~nx0
SET FIC=%FIC:bat=sql%

IF EXIST ..\Data\Base.FDB  del /F ..\Data\Base.FDB

isql  -charset iso8859_1  -echo  -input %FIC%  -quiet  -password 'masterkey'  -role RDB$ADMIN  -user 'sysdba'

@echo.
pause
exit

Voici le compte-rendu d'une création de base en iso-8859-1 avec un affichage en iso-8859-1 :

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

Tu remarques que le '€' ainsi que le 'œ' ne s'affiche pas, ce qui prouve que ces deux caractères ne sont pas reconnus sous iso-8859-1.

Dans le lien que tu donnes, j'ai consulté la table des caractères de l'iso-8859-1.
Le caractère '€' ainsi que le 'œ' n'apparaissent pas, ce qui est normale.

Tout ce que je dis, c'est que tu dois avoir le même charset dans ta base de données et à l'affichage.
Je reprends le même script sql que ci-dessus mais avec un affichage en win1252 :

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
26
27
28
29
30
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');
Statement failed, SQLSTATE = 22018
arithmetic exception, numeric overflow, or string truncation
-Cannot transliterate character between character sets
After line 9 in file Base_2.sql
insert into test (id,lib) values (2, 'cœur');
Statement failed, SQLSTATE = 22018
arithmetic exception, numeric overflow, or string truncation
-Cannot transliterate character between character sets
After line 10 in file Base_2.sql
 
select * from test;
 
          ID LIB
============ ====================
           1 ça marche
 
 
exit;
 
Appuyez sur une touche pour continuer...

Cette fois-ci le caractère '€' s'affiche correctement mais est rejeté avec comme message d'erreur :

Code :

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

-Cannot transliterate character between character sets

@+

[looping]

Bonjour,

Je reviens un peu sur cette discussion, juste pour donner mon expérience, car je ne suis pas aussi calé que vous !

Cela fait 15 ans maintenant que je travaille avec des bases Firebird 2.1 encodées en ISO8859_1
Le tout piloté par Delphi 2007 + IBX

Jamais un problème d'affichage du symbole €

Au début je me suis posé la question et cela m'avait inquiété: pourquoi le symbole € s'affiche alors qu'il ne devrait pas; si on suis la logique de la norme ISO8859_1
Le temps à passé et tout fonctionne bien, et toujours pas d'explication nette et précise.

Et puis j'ai voulu migrer vers Delphi XE5 + IBX, et là problème: l'euro ne s'affiche plus ?
J'ai donc acheté les composant IBDAC à la place des IBX et tout refonctionne bien.

Je vais probablement passé à FB3.0 dans l'année prochaine.
Que me conseillez vous pour la migration: je reste sur ISO8859_1 ou je passe en WIN1252 ou UTF8
Je précise que mes applications sont uniquement en Français.

Cordialement

[Artemus24]

Salut Looping.

Attention à ne pas confondre encodage et affichage.

Comme je suis sous windows et non sous linux, je passe par un batch windows pour gérer mes scripts SQL de FireBird.
A l'affichage donc, je déclare "chcp 1252>nul" dans mon batch windows.
Je préfère utiliser le charset windows-1252 qui est pour les langues de l'Europe occidental.
Afin d'être en conformité avec l'affichage, j'encode mes chaines de caractères en utilisant le charset "win1252" dans FireBird.

Pourquoi le € s'affiche ?

Il s'affiche car tu utilises un charset à l'affichage qui va te le donner.
Pour connaitre le charset utilisé à l'affichage, il suffit de faire le test suivant :
--> si code 0xA4 alors l'affichage se fait en ISO-8859-15.
--> si code 0x80 alors l'affichage se fait en Windows-1252.
C'est ce code hexadécimal qui va te dire le charset utilisé à l'affichage.

Et peu importe que tu mettes "charset=none" ou "charset=iso8859-1" dans FireBird, l'important est le code utilisé !

Sous Windows, à l'affichage, l'équivalent du charset :
--> ISO-8859-1 ou latin1 est "chcp 28591"
--> ISO-8859-15 ou latin9 est "chcp 28605".

Je précise que mes applications sont uniquement en Français.

Français ou Anglais, tu peux utiliser Windows-1252 qui est complet.
Quel est la différence avec l'UTF-8 ?
Windows-1252 va utiliser un octet pour stocker un caractère.
Tandis que UTF-8 va utiliser jusqu'à 4 octets pour stocker un caractère.

Sous MySql, la norme utilisée est l'UTF8MB4.

Cordialement.
Artemus24.
@+