Discussion :

[Mercenary Developer]

Bonjour,

J'ai une base en ASCII, et une autre en UTF-8.
Je copie une table de la permière vers la deuxième via un dblink du genre:

Code :

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

INSERT INTO TABLE_UTF8 ( MONCHAMP ) SELECT MONCHAMP FROM DBLINK.TABLE_ASCII

Problème, dans le champs de la table source ascii j'ai un 'é', codé sur 1 octet 0xE0.
Dans ma seconde table, au lieu de me le convertir en UTF-8 sous la forme 0xC3A9 (2 octets représentant le 'é' en UTF-8), il me le converti en 0xEFBFBD (15712189 en décimal) et me le représente comme un carré dans SQLDevelopper.

J'ai essaye UNISTR(), CONVERT() mais rien n'y fait.

Une recherche de '15712189' sous Google donne plein de résultats mais pas de réponse à ce problème.

Avez_vous une idée ?

Cordialement.

[Mercenary Developer]

Re,

Pour info je suis en:

Code :

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

NLS_LANG=FRENCH_FRANCE.WE8MSWIN1252

Mais le problème est identique en;

Code :

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

NLS_LANG=FRENCH_FRANCE.AL32UTF8

Ce qui serait normal d'après:

http://www.oracle.com/technology/tec...lang%20faq.htm

car ils dient:

The NLS_LANG on the server (or client) has no influence on character set conversion through a database link.

et les requètes suivantes donnent:

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
select chr(15712189) as caractere from dual;
 
CARACTERE 
--------- 
�         
 
1 rows selected
 
select chr(50089) as caractere from dual;
 
CARACTERE 
--------- 
é         
 
1 rows selected

Bon chez moi le � (et#65533point_virgule) est représenté par un carré dans SQL Developper...

Cordialement.

[sgora]

Tu utilises des varchar2 ou des nvarchar2 en type de données ? Et en mode char ou byte ?

[Mercenary Developer]

Bonjour,

J'utilise des VARCHAR2(xx char) sinon j'ai des dépassements de longueur de chaine de caractère car en bytes oracle n'utilise qu'un octet par caractère.

Cordialement.

[sgora]

Tu pourrais nous faire voir un exemple de ce que tu as tenté avec la fonction convert avec le résultat ?

[Mercenary Developer]

Re,

J'ai trouvé une solution, mais pas top, à savoir:

- Recreer la table source ASCII sur le serveur UTF-8 en remplacant les varchar(XX byte) par varchar(xx char)

- Exporter avec exp la table de la base ASCII en positionnant

Code :

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

NLS_LANG=AMERICAN_AMERICA.US7ASCII

- Modifier le fichier dump en remplacant le 3eme octet de 0x01 en 0xb2, en effet le deuxieme et troisieme octet du fichier dump correspond à l'encodage, on change donc 0x0001 (US7ASCII) en 0x00b2 (WE8MSWIN1252)

- importer avec inp dans "le clone" de la table de la base ASCII recréer sur la base UTF-8 en positionnant

Code :

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

NLS_LANG=FRENCH_FRANCE.WE8MSWIN1252

Et la je retrouve bien mes caractères accentués encodés en UTF8 ( 'é' = 50089 ).

Cordialement.

[Mercenary Developer]

Re,

Juste pour ceux que cela interresse un script Perl pour patcher le fichier DUMP expliqué précédemment:

Code :

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

1
2
3
4
5
6
#!/usr/bin/perl
open my $fichier, '+<', "sauvegarde.dmp" or die "Impossible d'ouvir le fichier!\n";
my $octet;
seek( $fichier, 2, 0 );
syswrite( $fichier, chr(hex("B2")) ) == 1 or die "Erreur d'ecriture!\n";
close $fichier or die "Erreur de fermeture!\n";

Cordialement.