Discussion :

[bstevy]

Bonjour,


j'ai une analyse d'impact à réaliser sur une modification de fichier en terme de katakana single byte et double byte.
Pour ceux qui connaissent pas, il s'agit du même caractère mais écris différemment, l'un prenant deux bytes alors que l'autre n'en prend qu'un.
Par exemple : タ　et　ﾀ
Ces deux caractères sont les mêmes, mais n'ont pas le même code hexa derrière a priori.

Ma question porte sur la façon dont une base de données va stocker cela.
Quand on précise varchar(15), il s'agit de n'importe quel caractère ? Je pourrais donc avoir 15 double bytes et 15 single bytes dans mes champs ? Ou est-ce que cela peut avoir une influence sur la longueur de mon champ ?

Pour info, je connais déjà la réponse sur Oracle, j'ai pu tester le fait qu'un double byte prenait bien deux caractères. Autrement dit, un varchar(15) ne peut contenir que 7 double bytes... mais est-ce que c'est pareil pour les autres bases ? Vous auriez une idée ?


Merci d'avance pour votre réponse.

Steven

[SergioMaster]

Bonjour,

C'est une question d'encodage de la base de données et du champ à proprement parler.

Je ne maitrise bien que la Base de données Firebird et pas le japonais mais peu importe, cela donnera des pistes de travail

pour une Firebird encodée en UTF8
un varchar(15) peut contenir jusqu'à 15 caractères "affichables" mais la taille physique pourrait varié de 15 à 15*4 octets
si le champ est déclaré (CHARSET) WIN932 alors varchar(15) fera toujours au maxi 15 caractères katakana mais serait en fait de taille physique d'un maximum de 30 octets soit de 2 à 15*2
pour le Kanji? le champ serait déclaré (CHARSET) CP943C (tri possible via CP943C_UNICODE) ce que j'en ai lu indique que chaque caractère est sur 3 octets
=> une taille physique de 3 à 15*3 octets
il y a aussi l'encodage de la base en SJIS_0208 mais je serais incapable de dire à quoi il correspond si ce n'est à du japonais .....

cependant je suis presque sûr que cela dépend beaucoup du SGBD et donc les charsets indiqués ici ne sont valable que pour Firebird et peut être Interbase.

[skuatamad]

Pour info, je connais déjà la réponse sur Oracle, j'ai pu tester le fait qu'un double byte prennait bien deux caractères. Autrement dit, un varchar(15) ne peut contenir que 7 double bytes...

Specifying Column Lengths as Bytes or Characters

name VARCHAR2(32 CHAR)

The name column contains data in the database character set. If the database character set allows multibyte characters, then the 32 characters can be stored as more than 32 bytes.

[SQLpro]

Bonjour,


j'ai une analyse d'impact à réaliser sur une modification de fichier en terme de katakana single byte et double byte.
Pour ceux qui connaissent pas, il s'agit du même caractère mais écris différemment, l'un prenant deux bytes alors que l'autre n'en prend qu'un.
Par exemple : タ　et　ﾀ
Ces deux caractères sont les mêmes, mais n'ont pas le même code hexa derrière a priori.

Ma question porte sur la façon dont une base de données va stocker cela.
Quand on précise varchar(15), il s'agit de n'importe quel caractère ? Je pourrais donc avoir 15 double bytes et 15 single bytes dans mes champs ? Ou est-ce que cela peut avoir une influence sur la longueur de mon champ ?

Pour info, je connais déjà la réponse sur Oracle, j'ai pu tester le fait qu'un double byte prenait bien deux caractères. Autrement dit, un varchar(15) ne peut contenir que 7 double bytes... mais est-ce que c'est pareil pour les autres bases ? Vous auriez une idée ?


Merci d'avance pour votre réponse.

Steven

Question à la fois vaste et simple... D'abord ce que vous a dit SergioMaster est faux, ou tout au moins spécifique à Firebird...

La structuration des données dans les bases de données ne repose pas sur un jeu de caractères particulier, mais plus généralement sur la notion de collation.
Les types de données littéraux du SQL sont :

• le CHAR/VARCHAR dont l'encodage est "basé" sur l'ASCII (1 caractère = 1 octet) et considère les caractères comme latin (A, Z...), conventionnellement appelé INTERNATIONAL
• le NCHAR/NVARCHAR dont l'encodage est "basé" sur l'UNICODE (1 caractère = 2 octet) et considère la plupart des langues (latines, cyrillique, grecque, hébreu, arabe, japonais...), conventionnellement appelé NATIONAL puisque chacun y trouvera son "alphabet" national (le chinois y trouvera le mandarin par exemple).

Pour résoudre les problématiques spécifiques aux langues la norme SQL a apporter la notion de collation qui rend indépendante le "réglage" des effets littéraux des différentes langues par rapport à un encodage quel qu'il soit.

La collation permet donc :

• de tenir compte ou non de la CASSE (CI => Case Insensitive, CS => Case Sensitive) - exemple : 'A' = 'a'
• de tenir compte ou non des caractères diacritiques (accents, cédille, ligature...) (AI => Accent Insensitive, AS => Accent Sensitive) - exemple 'A' = 'À'
• de tenir compte de la "largeur" du caractère (WS => Wide Sensitive) - exemple '2' = '²'
• de tenir compte des kana type (KS => Kanatype Sensitive entre Katakana et Hiragana) exemple (voir image)

Condition du test des kana types :

Résultats des 5 requêtes


Hélas Oracle n'utilise pas la collation et considère un truc imbitable... le NLS !

Tous les autres SGBDR supportent les collations.

• MySQL c'est nullissime, farci d'erreurs et d’approximations
• PostGreSQL c'est embryonnaire
• IBM DB2 c'est déjà du costaud
• Sybase ASE c'est pas mal
• MS SQL Server c'est royal (plus de 4 000 collations différentes)

A +

[SergioMaster]

D'abord ce que vous a dit SergioMaster est faux, ou tout au moins spécifique à Firebird...

j'avais bien fait remarquer, il me semble, qu'il s'agissait de Firebird

Je ne maitrise bien que la Base de données Firebird et pas le japonais mais peu importe, cela donnera des pistes de travail

Ensuite pour moi, toujours dans mon trip Firebird, une base peut avoir un encodage par défaut, un champ avec un CHARSET (type d'encodage) différent de la base et/ou une COLLATION (mode de tri prenant en compte la casse et cie.)

Cependant je suis presque sûr que cela dépend beaucoup du SGBD et donc les charsets indiqués ici ne sont valable que pour Firebird et peut être Interbase.

Bien que Firebird (et Interbase) ne semblent pas très souvent citées par SQLPro (boutade) elles existent, mais du coup je suis "content" d'apprendre que Oracle n'est pas toujours le nec+ultra, que MySQL reste une daube à ses yeux et que SQL Server offre tant de collations