[ASE 12.5.2]Gestion multi langue dans un type varchar() [Résolu]

[gcouvez]

Bonjour,

Un de mes utilisateurs voudrait stocker dans une colonne de type varchar(255) du texte en japonais ou en grec.

La procedure sp_helpsort sur mon serveur (ASE 12.5.2) retourne que mon character set est ISO 88591 :

Code :

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
Collation Name	Collation ID
defaultml	20
thaidict	21
iso14651	22
utf8bin	24
BINARY	25
altnoacc	39
altdict	45
altnocsp	46
scandict	47
scannocp	48
dict	51
nocase	52
nocasep	53
noaccent	54
espdict	55
espnocs	56
espnoac	57
rusnocs	59
cyrnocs	64
elldict	65
hundict	69
hunnoac	70
hunnocs	71
turknoac	73
turknocs	74
 
 
Loadable Sort TABLE Name	Collation ID
cp932bin	129
dynix	130
gb2312bn	137
cyrdict	140
turdict	155
euckscbn	161
gbpinyin	163
rusdict	165
sjisbin	179
eucjisbn	192
big5bin	194
 
Sort ORDER Description	
 
 
Character SET = 1, iso_1	
    ISO 8859-1 (Latin-1) - Western European 8-bit character SET.	
Sort ORDER = 54, noaccents_iso_1	
    Case-insensitive dictionary sort ORDER FOR USE WITH several We	
    stern-European languages including English, French, AND German	
    .  Uses the ISO 8859-1 character SET.  Diacritical marks are i	
    gnored.	
Characters, IN ORDER	
 
 
    ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | }	
  ~   ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬ * ® ¯ ° ± ² ³ ´ µ ¶ · ¸ ¹ º » ¼ ½ ¾	
  ¿ × ÷ 0 1 2 3 4 5 6 7 8 9 A=a=À=Á=Â=Ã=Ä=Å=à=á=â=ã=ä=å Æ=æ B=b C	
 =c Ç=ç D=d E=e=È=É=Ê=Ë=è=é=ê=ë F=f G=g H=h I=i=Ì=Í=Î=Ï=ì=í=î=ï J	
 =j K=k L=l M=m N=n=Ñ=ñ O=o=Ò=Ó=Ô=Õ=Ö=Ø=ò=ó=ô=õ=ö=ø P=p Q=q R=r S	
 =s ß T=t U=u=Ù=Ú=Û=Ü=ù=ú=û=ü V=v W=w X=x Y=y=Ý=ý=ÿ Z=z Ð=ð Þ=þ	
 
(return status = 0)

Comment gérer une telle demande?

Solution 1 :
Changement du default character set pour de l'unicode => lourd a gerer? Pour moi oui car cela suppose de ré encoder tous les types char et varchar sur 2 octets au lieu d'un seul et donc d'avoir un impact désastreux sur la volumétrie de notre base.
Solution 2 :
Gestion des libelles spéciaux avec ajout d'une colonne de type binaire et l'application cliente gére comme une grande?

Merci d'avance de vos éventuels retour sur le sujet

[mpeppler]

Si il n'est question que d'une colonne alors il faudrait peut-être considérer l'utilisation du type "univarchar()", qui permet de stocker des données Unicode quel que soit le charset par défaut du dataserver.

Michael

[gcouvez]

Je viens en effet de proposer l'utilisation du type univarchar()

Mais comment démontrer à mon utilisateur que son texte est bien stocké en grec et que l'ASE ne déforme rien?

En gros comment paramétrer un client pour insérer et lire du grec?

[fadace]

Avec un Windows avec du Grec comme language et le fichier locales.dat configuré correctement (sur le client ET sur le serveur)

[gcouvez]

Problème résolu avec l'option -J de isql

[fadace]

Envoyé par gcouvez

Problème résolu avec l'option -J de isql

Ce n'était donc qu'un problème de paramétrisation client... Pour info, c'est correct, mais il y a aussi possibilité de changer le comportement en modifiant le fichier locales.dat