[Oracle Text]Problème d'encodage pour lire un document grec

Version imprimable

Bonjour,

Ci-dessous le corps d'une procédure stockée permettant de transformer en HTML un document (ici un document Word) enregistré dans une colonne de type BLOB ((j'ai omis le prototype de la procédure volontairement)) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
 
...
 
   ctx_doc.markup (index_name      => 'documents_indx',
                   textkey         => p_doc_id,
                   text_query      => p_texte,
                   restab          => 'my_markup_table',
                   plaintext       => FALSE,
                   starttag        => '<FONT COLOR="RED"><B><A NAME=HIT%CURNUM HREF=#HIT%NEXTNUM>',
                   endtag          => '</A></B></FONT>',
                   prevtag         => '',
                   nexttag         => ''
                  );
 
...

J'ai un problème pour récupérer dans un encodage correct (j'ai des ??? à l'envers alors que je m'attends à voir du texte en grec (que je ne comprends pas plus ;)) ) le contenu d'une colonne de type BLOB, le résultat de la procédure ci-dessus produit ce HTML dans ma table de destination my_markup_table :

Code:

1
2
3
4
5
6
7
8
9
10
11
 
 
...
 
<p><font face="Times New Roman" size="3">¿¿¿¿¿¿</font>
<p><font face="Times New Roman" size="3"><b>¿¿¿¿¿¿¿ ¿¿¿ ¿¿¿¿¿¿¿¿¿</b></font>
<p><font face="Times New Roman" size="3"><b>¿¿¿</b></font>
<p><font face="Times New Roman" size="3"><b>¿¿¿ ¿¿¿ ¿¿¿¿¿¿¿¿¿¿¿ ¿¿¿ ¿¿¿¿¿¿¿ 2002/72/¿¿ ¿¿¿¿¿¿¿ ¿¿ ¿¿ ¿¿¿¿¿¿¿¿ ¿¿¿¿¿ ¿¿¿ ¿¿¿¿¿¿¿¿¿¿¿ ¿¿¿ ¿¿¿¿¿¿¿¿¿¿¿¿ ¿¿ ¿¿¿¿¿¿ ¿¿ ¿¿¿¿¿ ¿¿ ¿¿¿¿¿¿¿ </b></font>
<p><font face="Times New Roman" size="3">(¿¿¿¿¿¿¿¿ ¿¿¿ ¿. ¿. ¿¿¿¿¿¿¿¿¿)</font>
 
...

Pour informations :

Version Oracle avec la commande :

Code:

SELECT * FROM SYS.V_$VERSION;

Code:

1
2
3
4
5
6
 
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
PL/SQL Release 10.2.0.3.0 - Production                          
CORE	10.2.0.3.0	Production                                      
TNS for Solaris: Version 10.2.0.3.0 - Production                
NLSRTL Version 10.2.0.3.0 - Production

Encodage de la base avec la commande :

Code:

1
2
select * from nls_database_parameters
where parameter='NLS_CHARACTERSET'

Code:

NLS_CHARACTERSET AL32UTF8

Le code de la procédure stockée permettant d'enregistrer les documents (j'ai omis le prototype de la procédure volontairement) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
 
...
 
INSERT INTO VIS_DOCUMENTS_T (doc_id, doc_name, doc_contents, doc_title, doc_type, doc_format, doc_language, doc_size, doc_number, doc_version, doc_part, doc_lang_source, trans_int_ext, req_date, req_code, req_year, req_service)
  VALUES (doc_seq.NEXTVAL , p_file_name, EMPTY_BLOB(), v_DOC_TITLE, v_DOC_TYPE, v_DOC_FORMAT,  v_DOC_LANGUAGE, v_DOC_SIZE, v_DOC_NUMBER, v_DOC_VERSION,v_DOC_PART, v_DOC_LANG_SOURCE, v_TRANS_INT_EXT, v_REQ_DATE, v_REQ_CODE, v_REQ_YEAR, v_REQ_SERVICE)
  RETURN doc_contents INTO v_blob;
 
  v_bfile := BFILENAME('DOCUMENTS_IN', p_file_name);
  Dbms_Lob.Fileopen(v_bfile, Dbms_Lob.File_Readonly);
  Dbms_Lob.Loadfromfile(v_blob, v_bfile, Dbms_Lob.Getlength(v_bfile));
  Dbms_Lob.Fileclose(v_bfile);
 
...

Script de création de la table MY_MARKUP_TABLE :

Code:

1
2
3
4
5
CREATE TABLE MY_MARKUP_TABLE
(
  QUERY_ID  NUMBER,
  DOCUMENT  CLOB
)

Auriez vous une solution pour résoudre mon souci ? des pistes ?

Merci d'avance

21/01/2008, 18h15
orafrance

c'est probablement le NLS_LANG du poste client qui pose problème non ?
21/01/2008, 23h37
elitost

Citation:

Envoyé par orafrance

c'est probablement le NLS_LANG du poste client qui pose problème non ?

Est ce que je trouverai de quoi tester ce comportement dans cet article ? :

http://fadace.developpez.com/oracle/nls/

Ou alors pourrais tu m'expliquer quoi vérifier pour qualifier le problème ?

Citation:

Envoyé par elitost

Est ce que je trouverai de quoi tester ce comportement dans cet article ? :

http://fadace.developpez.com/oracle/nls/

Ou alors pourrais tu m'expliquer quoi vérifier pour qualifier le problème ?

Pour information, le résultat de la la commande :

Code:

SELECT * FROM NLS_SESSION_PARAMETERS;

donne :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 NLS_LANGUAGE|AMERICAN NLS_TERRITORY|AMERICA NLS_CURRENCY|$ NLS_ISO_CURRENCY|AMERICA NLS_NUMERIC_CHARACTERS|., NLS_CALENDAR|GREGORIAN NLS_DATE_FORMAT|DD-MON-RR NLS_DATE_LANGUAGE|AMERICAN NLS_SORT|BINARY NLS_TIME_FORMAT|HH.MI.SSXFF AM NLS_TIMESTAMP_FORMAT|DD-MON-RR HH.MI.SSXFF AM NLS_TIME_TZ_FORMAT|HH.MI.SSXFF AM TZR NLS_TIMESTAMP_TZ_FORMAT|DD-MON-RR HH.MI.SSXFF AM TZR NLS_DUAL_CURRENCY|$ NLS_COMP|BINARY NLS_LENGTH_SEMANTICS|BYTE NLS_NCHAR_CONV_EXCP|FALSE
Une piste ?

22/01/2008, 12h11
orafrance

désolé mais la manipulation des NLS c'est pas trop mon fort :oops: l'article de fadace devrait t'aider ;)
22/01/2008, 13h19
elitost

Citation:

Envoyé par orafrance

désolé mais la manipulation des NLS c'est pas trop mon fort :oops: l'article de fadace devrait t'aider ;)

ok, à vrai dire je patauge même avec cet article...

Peut être qu'une bonne âme qui passe par là pourra m'éclairer ?
22/01/2008, 14h25
pifor

Il faudrait vérifier avec la fonction DUMP que le contenu de la colonne est correcte (ce qui suppose de connaître la représentation binaire des caractères grecs dans AL32UTF8: voir sur unicode.org):

Code:

select dump(<colonne>, 1017) from <table>;

NLS_LANG est une variable définie en dehors d'Oracle qui peut jouer un rôle.
Sous Unix, c'est une variable d'environnement et sous Windows c'est par défaut une clé de registre. La partie jeu de caractères est utilisée par le client Oracle pour savoir s'il faut éventuellement traduire les caractères stockés dans la base côté client. Peut-être qu'il faut positionenr la partie jeu de caractères de NLS_LANG à EL8ISO8859P7 ?(voir une liste des jeux de caractères dans le Globalization Guide).

Est-ce que vous pouvez afficher des caractères grecs dans votre environnement client ? Quel est l'outil utilisé pour afficher les données de la base ? Il est sans doute préférable d'utiliser un client de type SQL Developer plutôt que SQL*Plus.

Citation:

Envoyé par pifor

Il faudrait vérifier avec la fonction DUMP que le contenu de la colonne est correcte (ce qui suppose de connaître la représentation binaire des caractères grecs dans AL32UTF8: voir sur unicode.org):

Code:

select dump(<colonne>, 1017) from <table>;

NLS_LANG est une variable définie en dehors d'Oracle qui peut jouer un rôle.
Sous Unix, c'est une variable d'environnement et sous Windows c'est par défaut une clé de registre. La partie jeu de caractères est utilisée par le client Oracle pour savoir s'il faut éventuellement traduire les caractères stockés dans la base côté client. Peut-être qu'il faut positionenr la partie jeu de caractères de NLS_LANG à EL8ISO8859P7 ?(voir une liste des jeux de caractères dans le Globalization Guide).

Est-ce que vous pouvez afficher des caractères grecs dans votre environnement client ? Quel est l'outil utilisé pour afficher les données de la base ? Il est sans doute préférable d'utiliser un client de type SQL Developer plutôt que SQL*Plus.

En executant la commande sous SQL*Plus sur ma colonne DOCUMENT de type CLOB , j'ai une erreur :
Code:

1 2 3 4 5 SQL> select dump(DOCUMENT, 1017) from MY_MARKUP_TABLE; select dump(DOCUMENT, 1017) from MY_MARKUP_TABLE * ERROR at line 1: ORA-00932: inconsistent datatypes: expected - got CLOB
Dans SQL*Plus j'ai tenté de connaître la valeur de NLS_LANG avec la commande :

Code:

SQL>@.[%NLS_LANG%]

Qui m'a renvoyé :

Code:

Unable to open file ".[%NLS_LANG%]."

J'ai alors ajouté une variable d'environnement NLS_LANG avec comme valeur GREEK_GREECE.EL8MSWIN1253

Maintenant j'ai :
Code:

1 2 SQL> @.[%NLS_LANG%] SP2-0310: õÕÝ Õ▀ÝßÚ õ§Ýß¶³ ¶´ ▄Ý´ÚÒýß ¶´§ ß±¸Õ▀´§ ".[GREEK_GREECE.EL8MSWIN1253]"
Et quand je tente de voir mon CLOB :
Code:

1 2 SQL> SET LONG 32000 SQL> select DOCUMENT from MY_MARKUP_TABLE;
Code:

1 2 3 4 5 6 ... an" size="2">¤╔┼╠(T)= 6 mg/kg (36) (ßÛ±§ÙÚÛ³ ´¯²) </div> </td> </tr> ...
Quand j'utilise TOAD pour visualiser le contenu de la colonne CLOB j'ai :
Code:

1 2 3 4 5 6 7 8 9 10 ... ¿¿¿¿¿¿¿ ¿¿¿ ¿¿¿¿¿¿¿¿¿ ¿¿¿ ¿¿¿ ¿¿¿ ¿¿¿¿¿¿¿¿¿¿¿ ¿¿¿ ¿¿¿¿¿¿¿ 2002/72/¿¿ ¿¿¿¿¿¿¿ ¿¿ ¿¿ ¿¿¿¿¿¿¿¿ ¿¿¿¿¿ ¿¿¿ ¿¿¿¿¿¿¿¿¿¿¿ ¿¿¿ ¿¿¿¿¿¿¿¿¿¿¿¿ ¿¿ ¿¿¿¿¿¿ ¿¿ ¿¿¿¿¿ ¿¿ ¿¿¿¿¿¿¿. (¿¿¿¿¿¿¿ ¿¿¿ ¿¿¿¿¿¿¿¿¿¿¿ ¿¿¿¿¿¿¿¿¿¿ ¿¿¿ ¿¿¿ ¿¿¿) ¿ ¿¿¿¿¿¿¿¿ ¿¿¿ ¿¿¿¿¿¿¿¿¿¿ ¿¿¿¿¿¿¿¿¿¿, ¿¿¿¿¿¿¿ ¿¿¿¿¿: ...
Au final, ce code HTML sera affiché dans un client Java (j'ai fais également des tests avec Java mais sans plus de succès) mais comme déjà je ne m'en sort pas du côté Oracle je préfère y aller étape par étape.

D'autres idées ?

22/01/2008, 17h37
mnitu
Pour l'instant laise TOAD à coté, utilisez SQL Plus sur le serveur de base de données.
Pour connaître les paramètres de ta session
Code:

1 2 SELECT USERENV('LANGUAGE') "Language" FROM DUAL;
25/01/2008, 16h00
elitost
Citation:
Envoyé par mnitu

Pour l'instant laise TOAD à coté, utilisez SQL Plus sur le serveur de base de données.
Pour connaître les paramètres de ta session

Code:

1 2 SELECT USERENV('LANGUAGE') "Language" FROM DUAL;
Pour le moment je n'ai pas les login/password pour ouvrir une session sur le serveur de base de données.

Par contre, en SQL Plus, dans une console DOS sur mon poste, j'ai ce résultat :
Code:

1 2 3 4 5 SQL> SELECT USERENV('LANGUAGE') "Language" FROM DUAL; Language ---------------------------------------------------- AMERICAN_AMERICA.AL32UTF8
ça peut vous aider à éclaircir mon pb ?
26/01/2008, 19h39
mnitu
Peut tu créer la table MY_MARKUP_TABLE comme indiquée plus bas et réessayer ?
Code:

1 2 3 4 5 6 CREATE TABLE MY_MARKUP_TABLE ( QUERY_ID NUMBER, DOCUMENT NCLOB )

Citation:
Envoyé par mnitu
Peut tu créer la table MY_MARKUP_TABLE comme indiquée plus bas et réessayer ?
Code:

1 2 3 4 5 6 CREATE TABLE MY_MARKUP_TABLE ( QUERY_ID NUMBER, DOCUMENT NCLOB )
J'ai donc recréé la table avec le type NCLOB mais maintenant je n'ai plus rien dans la colonne document (j'ai bien une ligne insérée pourtant ) que ce soit pour du grec ou de l'anglais quand j'execute ma procédure stockée :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ... ctx_doc.markup (index_name => 'documents_indx', textkey => p_doc_id, text_query => p_texte, restab => 'my_markup_table', plaintext => FALSE, starttag => '<A NAME=HIT%CURNUM HREF=#HIT%NEXTNUM>', endtag => '</A>', prevtag => '', nexttag => '' ); ...
D'autres idées ?

29/01/2008, 18h25
mnitu
Citation:
Envoyé par mnitu

Peut tu créer la table MY_MARKUP_TABLE comme indiquée plus bas et réessayer ?

Code:

1 2 3 4 5 6 CREATE TABLE MY_MARKUP_TABLE ( QUERY_ID NUMBER, DOCUMENT NCLOB )
Bref, j'ai passé un peu de temps à lire la doc et c'était un connerie. Désolé :cry:
29/01/2008, 18h35
elitost

Citation:

Envoyé par mnitu

Bref, j'ai passé un peu de temps à lire la doc et c'était un connerie. Désolé :cry:

Si tu as d'autres idées , je suis toujours preneur...
29/01/2008, 18h36
elitost

Juste comme ça, peut être que le souci est au moment de l'indexation du document ?
30/01/2008, 10h03
pifor

Est-ce que vous avez testé la possibilité d'insérer des caractères grecs et de pouvoir les afficher correctement dans le même environnement (même base, même client (SQL*Plus, Toad, ...), même valeur pour NLS_LANG) ?

Citation:

Envoyé par pifor

Est-ce que vous avez testé la possibilité d'insérer des caractères grecs et de pouvoir les afficher correctement dans le même environnement (même base, même client (SQL*Plus, Toad, ...), même valeur pour NLS_LANG) ?

Alors le résultat :
Dans une console DOS, voilà ce que j'ai fais :

1/passage du code page en Grec (737);
2/connexion à la base;
3/insertion de caractères grecs et commit;
4/select des valeurs
5/vue des paramètres de language de la session
6/vue des paramètres de language de la base de données
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 D:\Program\Console2>GRAFTABL 737 /STATUS Previous Code Page: 850 Active Code Page: 737 D:\Program\Console2>sqlplus SQL*Plus: Release 10.2.0.3.0 - Production on Wed Jan 30 11:43:27 2008 Copyright (c) 1982, 2006, Oracle. All Rights Reserved. Enter user-name: myuser Enter password: Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production With the Partitioning, OLAP and Data Mining Scoring Engine options SQL> INSERT INTO my_markup_table (query_id, document) VALUES ('10', 'τροποποιήθηκε'); 1 row created. SQL> commit; Commit complete. SQL> select * from my_markup_table; QUERY_ID ---------- DOCUMENT -------------------------------------------------------------------------------- 10 t??p?p??????e SQL> SELECT USERENV('LANGUAGE') "Language" FROM DUAL; Language ---------------------------------------------------- AMERICAN_AMERICA.AL32UTF8 SQL> select * from nls_database_parameters where parameter in ('NLS_LANGUAGE','NLS_TERRITORY','NLS_CHARACTERSET'); PARAMETER ------------------------------ VALUE -------------------------------------------------------------------------------- NLS_LANGUAGE AMERICAN NLS_TERRITORY AMERICA NLS_CHARACTERSET AL32UTF8
Après insertion, je vois toujours les caractères erronés, peut être ai je oublié qqch ou fait une erreur quelque part ?

Une idée ? explication ?

Merci d'avance

30/01/2008, 14h14
pifor
Je vois plusieurs problèmes:
Je ne suis pas sûr que sqlplus.exe arrive à afficher des caractères grecs même avec la commande graftabl et le bon NLS_LANG.

Vous utilisez un codage HTML qui ne peut pas être reconnu tel quel par Oracle comme codage de caractères. Si on ne pas entrer directement un caractère grec, il faut utiliser la fonction SQL UNISTR qui permet de choisir le caractère à partir de sa représentaion hexadécimale en Unicode.
Code:

1 2 unistr('\03A8') = PSI majuscule unistr('\03A0') = PI majuscule
J'arrive à afficher ces caractères s'ils sont insérés dans un CLOB d'une base 10.2 avec UTF8 comme jeu de caractères et si j'utilise SQL Developer (NLS_LANG=FRENCH_FRANCE.WE8MSWIN1252). Par contre ni sqlplus.exe ni TOAD 8.5 ne peuvent afficher ces caractères.
30/01/2008, 15h32
elitost

Je vais regarder plus en détail cette fonction unistr

Je crois qu'avec la version TOAD International je pourrais réussir à voir les caractères, mais ce n'est pas la version que nous utilisons.

De toute manière au final, ce sera un client Java qui va lire ces caractères, mais avant je voulais comprendre pourquoi ces caractères bizarroïdes.

Je reviendrai plus tard après quelques investigations.

C'est dur!
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 create table aa (a varchar2(100), b nvarchar2(100)) / insert into aa values (unistr('\0394'), unistr('\0394')) / commit / SQL> select dump(a), dump(b) from aa; DUMP(A) -------------------------------------------------------------------------------- DUMP(B) -------------------------------------------------------------------------------- Typ=1 Len=1: 191 Typ=1 Len=2: 3,148
Ensuite dans PuTTy, Windows/Translation: Received data assumed to be in UTF8.
Code:

1 2 3 4 5 6 7 8 9 10 export NLS_LANG=AMERICAN_AMERICA.UTF8 sqlplus mni/mni SQL> select b from aa 2 ; B -------------------------------------------------------------------------------- Δ
Voila le début de la solution.
Et après avoir fait "Prévisualisation du message" j'ajoute:
SQL> select b from aa
2 ;

B
--------------------------------------------------------------------------

Δ

Ha, Ha.

30/01/2008, 21h58
mnitu
Il semble que la seule application Windows (fournit par Oracle) capable d'afficher correctement unicode est Isql*Plus. Voila le résultat de la requête suivante exécute sur Apex en ligne
Code:

1 2 3 4 5 select unistr('\0394') from dual UNISTR('\0394') Δ
A voir aussi NlS_LANG FAQ
31/01/2008, 09h37
pifor

Citation:

Envoyé par mnitu

Il semble que la seule application Windows (fournit par Oracle) capable d'afficher correctement unicode est Isql*Plus.

Cela semble aussi marcher avec SQL Developer: outil gratuit développé en Java par Oracle qui ressemble assez à Toad.

C'est peut-être le cas d'autres applications qui utilisent JDBC car JDBC avec Oracle 10g ne prend pas en compte NLS_LANG.
31/01/2008, 11h07
mnitu

Citation:

Envoyé par pifor

Cela semble aussi marcher avec SQL Developer: outil gratuit développé en Java par Oracle qui ressemble assez à Toad.

C'est peut-être le cas d'autres applications qui utilisent JDBC car JDBC avec Oracle 10g ne prend pas en compte NLS_LANG.

C'est vrai et je le confirme. L'idée est que cela ne semble pas marcher ni avec sqlplus (DOS) ni avec sqlplusw (Windows).
31/01/2008, 12h12
elitost

Je vais télécharger SQL Developper pour voir ce que ça donne de mon côté, et avec un peu de chance je trouverai le code Java qui va bien en décompilant pour afficher mes caractère correctement.

Je vous tiens au courant.
06/02/2008, 14h59
elitost

Je viens d'installer SQL Developper 1.2.1 et j'arrive à voir parfaitement les caractères Grecs, maintenant il me reste à trouver la solution j'ai au niveau de mon code Java pour afficher correctement ces caractères, si SQL Developpez le peut mon client Java le pourra ;)

Je clos le sujet, et si vous avez d'autres infos, questions, n'hésitez pas.

Merci à tous pour votre aide.