Discussion :

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

@+

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

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

@+

[SergioMaster]

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

Comme déjà indiqué Flamerobin ne connait pas ces caractères (et pour moi il s'agit bien d'un bug de Firebird : un problème de dialogue de sourd)
après modification par Delphi

...
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 ils utilisent une correspondance Stricte

tu remarqueras que le ç apparait

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

pour confirmer, l'image avec l'ISQL est parlante (post d'hier), une image avec Rapid SQL

ou avec un programme Delphi donc Unicode où j'ai édité les descriptions (avec fermeture puis réouverture de la table également )

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

C'était pour démontrer que passer par la fonction Firebird ASCII_CHAR fonctionne sur une base ISO8859-1 et ce n'est pas la même chose que de le passer par hexadécimal

[Artemus24]

Salut SergioMaster.

Récapitulons les trois exemples (j'ai conservé le même ordre que toi) :

1) l'image ci-après est parlante !

tu remarqueras que le ç apparait

Tu es sous ISO_8859_1, puisque seul le caractère "ç" s'affiche pour les trois lignes de la sélection Windows-1252.
Les autres codes n'existant pas dans ce charset, il m'était difficile de te les donner.
Il est vrai que j'aurai pu sélectionner un ou deux autres codes afin de faire la distinction des charset.

2) l"image de hier, avec la console windows, quand tu fais "chcp 1252", tu es sous windows-1252 et les trois caractères s'affichement correctement.



Pour moi, cet exemple n'est pas parlant, vu que tu forces le charset.

3) l'exemple avec un programme delphi :



C'est du windows-1252.

Conclusion :
Ce que tu prends pour de l'ISO_8859_15 est en réalité du windows-1252.

Comme déjà indiqué Flamerobin ne connait pas ces caractères

C'est normal car sous FlameRobin, le charset est de l'ISO_8859_1 !
Normalement, il doit y avoir quelque part dans FlameRobin, un paramétrage à faire pour mettre du windows-1252.
Ou bien, comme tu as déclaré ta base de données avec le charset FireBird ISO8859_1, FlameRobin reprend le même charset pour l'affichage, c'est-à-dire de l'ISO_8859_1.

Je pense que ton problème est plutôt une mauvaise interprétation que tu fais, qu'un véritable bug.

Si tu veux afficher les trois caractères, dans ce cas, il faut déclarer le charset FireBird "WIN1252" dans ta base de données.
C'est ce qui est le plus près de l'ISO_8859_15 sous Windows.

C'était pour démontrer que passer par la fonction Firebird ASCII_CHAR fonctionne sur une base ISO8859-1 et ce n'est pas la même chose que de le passer par hexadécimal

"156" en décimal, c'est "9C" en hexadécimal, donc c'est équivalent et le code reste le même, quelque soit le charset utilisé.
Inversement, si tu passes par le clavier, je ne sais pas si le caractère ne sera pas codifié autrement.

@+

[SergioMaster]

Pour le 1) je me tue à le dire les concepteurs de flamerobin applique pour leur affichage la norme ISO_8859_1
pour le 2) il s'agit de Rapid SQL, il n'y a là aucun forçage de charset , quand je parlais de l'image d'hier c'était celle de l'ISQL sous mode console
pour le 3) Delphi n'affiche pas en Win1252 mais en unicode_fss ce qui fait que ce qui apparait via le programme sur windows se verra de manière identique sur Android ou mac

Si tu veux afficher les trois caractères, dans ce cas, il faut déclarer le charset FireBird "WIN1252" dans ta base de données.
C'est ce qui est le plus près de l'ISO_8859_15 sous Windows.

là on est d'accord, il vaudrait mieux utiliser WIN1252 pour Firebird cependant WIN1252 n'est pas connu par LINUX par exemple d'où le recours à UTF8 dans ces cas là

[Artemus24]

Salut SergioMaster.

Pour le 1) je me tue à le dire les concepteurs de flamerobin applique pour leur affichage la norme ISO_8859_1

Ce que je n'ai pas compris, si c'est tout le temps que FlameRobin affiche dans le charset ISO_8859_1 ?
Donc si tu mets de l'UTF8 pour ta base de données, il va quand même afficher de l'ISO_8859_1 ?
Est-ce bien cela ?

@+

[SergioMaster]

FlameRobin utilise le charset strict indiqué à la conception de la base , il n'y a acun problème d'affichage pour une base en WIN1252 ou en UTF8
le problème est juste avec l'ISO88559-1
je viens de faire le test sous Linux, pour ces caractères flamerobin(vieille version) montre un symbole (signe que la colonne n'est pas vide) mais pas Le symbole
contrairement à Windows ou rien n'est indiqué dans la colonne

[Artemus24]

Salut SergioMaster.

FlameRobin utilise le charset strict indiqué à la conception de la base ...

Le charset est celui de la base de données.
C'est ce que j'avais compris, mais vu tes explications, j'avais un doute !

..., il n'y a aucun problème d'affichage pour une base en WIN1252 ou en UTF8 ...

Bon, ça me rassure.

... le problème est juste avec l'ISO88559-1

Quel est la nature de ce problème ?
Est-ce sous Linux, ou sous Windows que tu rencontres ce problèmes ?
Ou encore un mauvais usage de ISO_8859_1 que tu fais ?

je viens de faire le test sous Linux, pour ces caractères flamerobin (vieille version) montre un symbole (signe que la colonne n'est pas vide) mais pas Le symbole

Bien sûr que la colonne n'est pas vide. Normalement, il contient le code du caractère correspond au charset que tu utilises.

Si tu prends le code x'80' (128 en décimal), avec le charset windows-1252, celui-ci correspond au caractère "€".
Si par contre, en ISO_8859_1, la plage allant de x'80' à x'9F' n'étant pas utilisé, et donc, il n'y a aucun caractère.

Mais ça, même si c'est important, c'est secondaire.
Ce qui est important, c'est comment va s'afficher le caractère que ce soit sous Windows ou sous Linux ?
Et l'affichage dépend de ton environnement.

C'est pourquoi, sous windows, j'utilise la console, et si j'utilise dans ma base de données le charset ISO_8859_1, je fais en sorte à l'affichage d'utiliser son équivalent, c'est-à-dire un chcp 28591.
Autrement dit, je fais en sorte de faire une correspondance entre le code utilisé et le code à l'affichage.
Je tiens à préciser que j'utilise la police de caractère de type "Déjà Vu sans Mono".

... contrairement à Windows ou rien n'est indiqué dans la colonne

Si tu n'as aucun caractère, ou plus précisément un carré sous la console windows, c'est l'affichage normal que tu obtiens.
Car ce code x'80', avec le charset ISO_8859_1 qui se codifie sous windows avec "chcp 28591" ne correspond à rien.
Iso_8859_1 correspond au "latin Alphabet No. 1".

Maintenant, la question est de savoir ce qui est utilisé à l'affichage sous Linux ?
Et plus précisément, le nom de la police de caractères.
Car il arrive que d'une police à l'autre, tu n'as pas toujours ni la même forme du glyphe mais parfois, pas du tout le même glyphe.

Ce qui est important dans la base de données, c'est que le caractère que tu veux afficher possède le bon code et correspond bien au charset utilisé.
Le problème de l'affichage du caractère dépend de l'environnement où tu te trouves.

@+

[Artemus24]

Salut SergioMaster.

Les contraintes sont les suivantes :
(1) --> utiliser un charset local (ISO) mais pas international (ou universel).
Autrement dit, on veut une codification du caractère sur un seul octet.
Le caractère codé avec l'UTF8 peut occuper 1, 2 ou 3 octets, ce qui augmente la volumétrie et on le rejette à cause de cela.

(2) --> la principale problématique vient de ces trois caractères spéciaux "œ", "ç" ou "€".
A priori, on les trouve dans les charset "windows-1252" et "iso_8859_15".

(3) --> pouvoir afficher aussi bien sous Windows que sous Linux.
Le problème est que les charset ne sont pas tous disponible avec ces deux environnements.
On rejette windows-1252 car il n'existe pas sous Linux. A priori, iso_8859_15 existe sous linux.

(4) --> sélectionner un charset présent dans FireBird : http://www.destructor.de/firebird/charsets.htm
Il se trouve que FireBird n'implémente pas le charset iso_8859_15. Ce n'est pas un problème car il suffit d'utiliser le charset "none".
Donc oui, on peut gérer iso_8859_15 dans FireBird, mais il ne sera pas reconnu en tant que tel.

(5) --> l'éditeur de texte.
Sous windows, j'utilise notepadd++ et le charset iso_8859_15 est bien présent.
Sous linux, il existe certainement un editeur implémentant ce charset.

(6) --> pouvoir gérer le charset dans certain utilitaire comme FlameRobin.
C'est un problème d'affichage, donc d'environnement.
Sous windows avec la console, c'est chcp 28605.

Pour tester sous windows, j'ai créé une base de données sous FireBird avec none comme charset.
J'ai saisie le texte sous Notepad++, puis sur encoder en sélectionnant ISO_8859_15.
Par exemple, je tape au clavier "alt+0156" (code du caractère "œ" sous windows-1252) puis ensuite conversion en passant à ISO_8859_15.

Sous la console windows, j'ai sélectionné chcp 28605 (ISO_8859_15) et j'ai fait un vidage (select *) de ma table.
Le résultat est que les trois caractères spéciaux s'affichent normalement.

Peux-tu faire la même chose sous linux pour voir si cela fonctionne de la même façon que sous windows (enfin, si tu n'es pas trop pris par ton travail) ?

@+

[SergioMaster]

(6) --> pouvoir gérer le charset dans certain utilitaire comme FlameRobin.
C'est un problème d'affichage, donc d'environnement.
Sous windows avec la console, c'est chcp 28605.

Flamerobin n'en a rien à faire du chcp et c'est là le problème
nb. je n'avais pas trouvé le code 28605 mais du coup avec ISQL pas de soucis sous windows

Peux-tu faire la même chose sous linux pour voir si cela fonctionne de la même façon que sous windows (enfin, si tu n'es pas trop pris par ton travail) ?

trop pris , et comme mon LINUX est sur une partition de mon pc et non en Virtual machine : pas le temps

[Artemus24]

Salut SergioMaster.

C'est pas grave si tu n'as pas le temps. Une autre fois.

@+