Pas d'inquiétude, avec PBAdonf, c'est dans la poche ! ^^

Le forum (ô combien francophone) des utilisateurs de Powerbuilder.

Recherche rapide

Annonce

Certaines rubriques, dont des cours, sont uniquement visibles par les membres du forum ^^.
Dans la rubrique Liens & Références, vous avez accès à un sommaire de téléchargement, profitez-en !
Il existe maintenant un nouveau TOPIC "Votre CV en Ligne" accessible uniquement par demande.

#1 24-03-2015 15:06:17

Marcus  
Membre Geek
Lieu: Namur
Date d'inscription: 20-06-2006
Messages: 39
Pépites: 258
Banque: 0

Importer fichier XML avec caractères cyrilliques et stocker en ORACLE

Bonjour à tous,

J'ai besoin de vos lumières
Nous sommes malheureusement en PB9. Aucune possibilité de migration.

Je dois importer des fichiers XML multilingues et enregistrer leur contenu dans une table ORACLE
Tout se passe bien pour les langues communes.
Le problème vient des contenus cyrilliques et certains caractères espagnols.

J'utilise un PBDOM_DOCUMENT pour importer le fichier. Ensuite, j'utilise de manière classique une fonction récursive pour récupérer tous les éléments
Les textes des langues grecques, espagnoles, bulgares, ... sont ignorés.

J'ai ensuite utilisé une autre possibilité.
Fileopen puis fileread pour stocker l'entièreté du XML dans un blob, puis le convertir en string.
Là aussi, c'est OK pour les langues "normales", mais j'obtiens des ? pour les caractères grecs notamment.

J'ai parcouru le forum, je pense bien qu'il s'agit d'un problème de code (utf-8, ansi, ...)
Mais je bloque.

Merci de votre aide  !!!

Hors ligne

 

#2 25-03-2015 02:49:42

seki  
0x73656B69
Award: bf
Lieu: Laquenexy & Luxembourg
Date d'inscription: 20-11-2008
Messages: 1118
Pépites: 4,296,080,204
Banque: 9,223,372,036,854,776,000
Site web

Re: Importer fichier XML avec caractères cyrilliques et stocker en ORACLE

Les encodages, c'est toujours un sujet épique , mais pas si compliqué. Il suffit d'être rigoureux et d'avancer pas à pas pour ne pas s'arracher trop de cheveux

Effectivement ça semble un problème d'encodage. Quelques pistes à vérifier :
- quelle est l'encodage retenu pour la base ? En fonction de la réponse, le stockage correct de caractères "exotiques" peut ne pas être possible (par exemple quand on utilise Latin-1 / ISO-8859-1, on ne peut pas stocker le caractère € (euro)). Si la base utilise utf-8 ou utf-16 ça devrait au moins être faisable
- quel est l'encodage des données au départ ? Est-ce qu'on maîtrise l'application qui les génére ?
- quel est l'encodage du fichier xml (indiqué sur la première ligne du fichier)
- normalement PB9 est "ansi". Il ne supporte pas nativement unicode et utilise l'encodage défini par le système -CP1252 dans nos régions-, mais comme Windows supporte unicode depuis fort longtemps, on peut toujours faire appel à l'API si on veut traduire des encodages, c'est "juste" un peu fastidieux (appels à MultiByteToWideChar et WideCharToMultiByte par exemple)


The best programs are the ones written when the programmer is supposed to be working on something else. - Melinda Varian

Mes réponses PB sur StackOverflow
http://stackoverflow.com/users/flair/317266.png

Hors ligne

 

#3 25-03-2015 12:57:22

Marcus  
Membre Geek
Lieu: Namur
Date d'inscription: 20-06-2006
Messages: 39
Pépites: 258
Banque: 0

Re: Importer fichier XML avec caractères cyrilliques et stocker en ORACLE

Merci pour la réponse !!
Effectivement, sujet épique pour moi. je n'ai jamais été confronté à ce genre de choses. Je bloque toujours.

L'encodage retenu pour la base est UTF-8. Pas de problème de ce côté. On a des application web qui enregistrent déjà des textes au format "exotiques" dans la base.

Les données XML sont aussi au format UTF-8

J'ai donc fait appel aux API, tels qu'expliqué sur le post http://pbadonf.fr/forum/viewtopic.php?id=4141&p=1


Voici le XML

Code: xml

<?xml version="1.0" encoding="utf-8"?>
<work xmlns="http://publications/resource/core-metadata" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ext="http://publications.europa.eu/resource/core-metadata/">
  <date_work>1986-02-14</date_work>
  <version_work>package</version_work>
  <expression>
    <language>FRA DAN SPA POR ELL</language>
    <title lang="DAN" from="final">FORSLAG TIL RÅDETS FORORDNING (EØF) om ændring af forordning (EØF) nr. 2727/75 om den fælles markedsordning for korn#FORSLAG TIL RÅDETS FORORDNING (EØF) om ændring af forordning ,(EØF) nr. 2731/75 om fastsættelse af standardkvaliteter for blød hvede, rug, byg, majs, sorghum og hård hvede#FORSLAG TIL RÅDETS FORORDNING (EØF) om almindelige regler for anvendelse af medansvarsafgiften for korn#FORSLAG TIL RÅDETS FORORDNING (EØF) om fastsættelse af de almindelige regler for intervention inden for kornsektoren#FORSLAG TIL RÅDETS FORORDNING (EØF) om særlige interventionsforanstaltninger for korn og om ophævelse#FORSLAG TIL RÅDETS FORORDNING (EØF) om ændring af forordning (EØF) nr. 3103/76 om støtte til hård hvede#FORSLAG TIL RÅDETS FORORDNING (EØF) om tilpasning af reglerne for fradrag i interventiosprisen for byg i Spanien#FORSLAG TIL RÅDETS FORORDNING (EØF) om ændring af forordning (EØF) nr. 1418/76 om den fælles markedsordning for rjs (forelagt Rådet af Kommissionen)</title>
    <title lang="FRA" from="final">PROPOSITION DE REGLEMENT (CEE) DU CONSEIL modifiant le règlement (CEE) n° 2727/75 portant organisation commune des marchés dans le secteur des céréales#PROPOSITION DE REGLEMENT (CEE) DU CONSEIL modifiant le règlement (CEE) n° 2731/75 fixant les qualités types du froment tendre, du seigle, de l'orge, du maïs, du sorgho et du froment dur#PROPOSITION DE REGLEMENT (CEE) DU CONSEIL portant règles générales pour l'application du prélèvement de coresponsabilité dans le secteur des céréales#PROPOSITION DE REGLEMENT (CEE) DU CONSEIL fixant les règles générales de l'intervention dans le secteur des céréales#PROPOSITION DE REGLEMENT (CEE) DU CONSEIL relatif aux mesures particulières d'intervention dans le secteur des céréales#PROPOSITION DE REGLEMENT (CEE) DU CONSEIL modifiant le règlement (CEE) n° 3103/76 relatif à l'aide pour le froment dur#PROPOSITION DE REGLEMENT (CEE) DU CONSEIL adaptant les modalités prévues pour l'application des réfactions au prix d'intervention de l'orge en Espagne#PROPOSITION DE REGLEMENT (CEE) DU CONSEIL modifiant le règlement (CEE) n° 1418/76 portant organisation commune du marché du riz (Présentées par la Commission au Conseil)</title>
    <title lang="POR" from="final">Proposta de REGULAMENTO DO CONSELHO que altera o Regulamento (CEE) n.° 2727/75 que estabelece a organização comum de mercados no sector dos cereais#Proposta de REGULAMENTO (CEE) DO CONSELHO que altera o Regulamento (CEE) n.° 2731/75 que fixa as qualidades-tipo do trigo mole, do centeio, do miIho, do sogro e do trigo duro#Proposta de REGULAMENTO (CEE) DO CONSELHO que estabelece as regras gerais para a aplicação da taxa de co-responsabilidade no sector dos cereais#Proposta de REGULAMENTO (CEE) DO CONSELHO que fixa as regras gerais de intervenção no sector dos cereais#Proposta de REGULAMENTO (CEE) DO CONSELHO que altera o Regulamento (CEE) n.° 3103/76 relativo à ajuda para o trigo duro#Proposta de REGULAMENTO (CEE) DO CONSELHO que adapta as modalidades de aplicação das reduções ao preço de intervenção da cevada em Espanha#Proposta de REGULAMENTO (CEE) DO CONSELHO que altera o Regulamento (CEE) n.° 1418/76 que estabelece a organização comum do mercado do arroz (apresentado pela Comissão ao Conselho)</title>
    <title lang="SPA" from="final">Propuesta de REGLAMENTO (CEE) DEL CONSEJO por el que se modifica el Reglamento (CEE) n° 2727175 por el que se establece la organización comùn de mercados en el sector de los cereales#Propuesta de REGLAMENTO (CEE) DEL CONSEJO por el que se modifica el Reglamento (CEE) n° 2731/75 que fija las calidades tipo del trigo blando, del centeno, de la cebada, del maiz, del sorgo y del trigo duro#Propuesta de REGLAMENTO DEL CONSEJO SOBRE REGLAS GENERALES PARA LA APLICACION DE LA TASA DE CORRESPONSABILIDAD EN EL SECTOR DE LOS CEREALES#Propuesta de REGLAMENTO (CEE) DEL CONSEJO por el que se fijan las reglas generales de intervención en el sector de los cereales#Propuesta de REGLAMENTO (CEE) DEL CONSEJO relativo a las medidas particulares de intervención en el sector de los cereales#Propuesta de REGLAMENTO (CEE) DEL CONSEJO por el que se modifica el Reglamento (CEE) n° 3103/76 relativo a la ayuda al trigo duro#Propuesta de REGLAMENTO (CEE) DEL CONSEJO por el que se adaptan las modalidades previstas para la aplicación de depreciaciones al precio de intervención de la cebada española#Propuesta de REGLAMENTO (CEE) DEL CONSEJO por el que se modifica el Reglamento (CEE) n° 1418/76, por el que se establece una organización com&#973;n del mercado del arroz (presentado por la Comisión al Consejo)</title>
    <title lang="ELL" from="final">&#928;&#929;&#927;&#932;&#913;&#931;&#919; &#922;&#913;&#925;&#927;&#925;&#921;&#931;&#924;&#927;&#933; (&#917;&#927;&#922;) TO&#933; &#931;&#933;&#924;&#914;&#927;&#933;&#923;&#921;&#927;&#933; &#947;&#953;&#945; &#964;&#951;&#957; &#964;&#961;&#959;&#960;&#959;&#960;&#959;&#943;&#951;&#963;&#951; &#964;&#959;&#965; &#954;&#945;&#957;&#959;&#957;&#953;&#963;&#956;&#959;&#973; (&#917;&#927;&#922;) &#945;&#961;&#953;&#952;. 2727/75 &#960;&#949;&#961;&#943; &#954;&#959;&#953;&#957;&#942;&#962; &#959;&#961;&#947;&#945;&#957;&#974;&#963;&#949;&#969;&#962; &#964;&#951;&#962; &#945;&#947;&#959;&#961;&#940;&#962; &#963;&#964;&#959;&#957; &#964;&#959;&#956;&#941;&#945; &#964;&#969;&#957; &#963;&#953;&#964;&#951;&#961;&#974;&#957;#&#928;&#929;&#927;&#932;&#913;&#931;&#919; &#922;&#913;&#925;&#927;&#925;&#921;&#931;&#924;&#927;&#933; (&#917;&#927;&#922;) TO&#933; &#931;&#933;&#924;&#914;&#927;&#933;&#923;&#921;&#927;&#933; &#963;&#967;&#949;&#964;&#953;&#954;&#940; &#956;&#949; &#964;&#951;&#957; &#964;&#961;&#959;&#960;&#959;&#960;&#959;&#943;&#951;&#963;&#951; &#954;&#945;&#957;&#959;&#957;&#953;&#963;&#956;&#959;&#973; (&#917;&#927;&#922;) &#945;&#961;&#953;&#952;. 2731/75 &#960;&#949;&#961;&#943; &#964;&#969;v &#960;&#959;&#953;&#959;&#964;&#953;&#954;&#974;&#957; &#964;&#973;&#960;&#969;&#957; &#964;&#959;&#965; &#956;&#945;&#955;&#945;&#954;&#959;&#973; &#963;&#943;&#964;&#959;&#965;, &#964;&#951;&#962; &#963;&#953;&#954;&#940;&#955;&#949;&#969;&#962;, &#964;&#951;&#962; &#954;&#961;&#953;&#952;&#942;&#962; &#964;&#959;&#965; &#945;&#961;&#945;&#946;&#959;&#963;&#943;&#964;&#959;&#965;, &#964;&#959;&#965; &#963;&#972;&#961;&#947;&#959;&#965; &#954;&#945;&#953; &#964;&#959;&#965; &#963;&#954;&#955;&#951;&#961;&#959;&#973; &#963;&#943;&#964;&#959;&#965;#&#928;&#929;&#927;&#932;&#913;&#931;&#919; &#922;&#913;&#925;&#927;&#925;&#921;&#931;&#924;&#927;&#933; (&#917;&#927;&#922;) &#932;&#927;&#933; &#931;&#933;&#924;&#914;&#927;&#933;&#923;&#921;&#927;&#933; &#963;&#967;&#949;&#964;&#953;&#954;&#940; &#956;&#949; &#947;&#949;&#957;&#953;&#954;&#959;&#973;&#962; &#954;&#945;&#957;&#972;&#957;&#949;&#962; &#947;&#953;&#945; &#964;&#951;&#962; &#949;&#966;&#945;&#961;&#956;&#959;&#947;&#942; &#964;&#951;&#962; &#949;&#953;&#963;&#966;&#959;&#961;&#940;&#962; &#963;&#965;&#957;&#965;&#960;&#949;&#965;&#952;&#965;&#957;&#972;&#964;&#951;&#964;&#945;&#962; &#963;&#964;&#959;&#957; &#964;&#959;&#956;&#941;&#945; &#964;&#969;&#957; &#963;&#953;&#964;&#951;&#961;&#974;&#957;#&#928;&#929;&#927;&#932;&#913;&#931;&#919; &#922;&#913;&#925;&#927;&#925;&#921;&#931;&#924;&#927;&#933; (&#917;&#927;&#922;) &#932;&#927;&#933; &#931;&#933;&#924;&#914;&#927;&#933;&#923;&#921;&#927;&#933; &#947;&#953;&#945; &#964;&#959;&#957; &#954;&#945;&#952;&#959;&#961;&#953;&#963;&#956;&#972; &#964;&#969;&#957; &#947;&#949;&#957;&#953;&#954;&#974;&#957; &#954;&#945;&#957;&#972;&#957;&#969;&#957; &#960;&#945;&#961;&#941;&#956;&#946;&#945;&#963;&#951;&#962; &#963;&#964;&#959;&#957; &#964;&#959;&#956;&#941;&#945; &#964;&#969;&#957; &#963;&#953;&#964;&#951;&#961;&#974;&#957;#&#928;&#929;&#927;&#932;&#913;&#931;&#919; &#922;&#913;&#925;&#927;&#925;&#921;&#931;&#924;&#927;&#933; (&#917;&#927;&#922;) TO&#933; &#931;&#933;&#924;&#914;&#927;&#933;&#923;&#921;&#927;&#933; &#963;&#967;&#949;&#964;&#953;&#954;&#940; &#956;&#949; &#949;&#953;&#948;&#953;&#954;&#940; &#956;&#941;&#964;&#961;&#945; &#960;&#945;&#961;&#941;&#956;&#946;&#945;&#963;&#951;&#962; &#963;&#964;&#959;&#957; &#964;&#959;&#956;&#941;&#945; &#964;&#969;&#957; &#963;&#953;&#964;&#951;&#961;&#974;&#957;#&#928;&#929;&#927;&#932;&#913;&#931;&#919; &#922;&#913;&#925;&#927;&#925;&#921;&#931;&#924;&#927;&#933; (&#917;&#927;&#922;) &#932;&#927;&#933; &#931;&#933;&#924;&#914;&#927;&#933;&#923;&#921;&#927;&#933; &#947;&#953;&#945; &#964;&#961;&#959;&#960;&#959;&#960;&#959;&#943;&#951;&#963;&#951; &#964;&#959;&#965; &#954;&#945;&#957;&#959;&#957;&#953;&#963;&#956;&#959;&#973; (&#917;&#927;&#922;) &#945;&#961;&#953;&#952;. 3103/76 &#960;&#949;&#961;&#943; &#964;&#951;&#962; &#949;&#957;&#953;&#963;&#967;&#973;&#963;&#949;&#969;&#962; &#947;&#953;&#945; &#964;&#959; &#963;&#954;&#955;&#951;&#961;&#972; &#963;&#943;&#964;&#959;#&#928;&#929;&#927;&#932;&#913;&#931;&#919; &#922;&#913;&#925;&#927;&#925;&#921;&#931;&#924;&#927;&#933; (&#917;&#927;&#922;) &#932;&#927;&#933; &#931;&#933;&#924;&#914;&#927;&#933;&#923;&#921;&#927;&#933; &#947;&#953;&#945; &#964;&#951;&#957; &#960;&#961;&#959;&#963;&#945;&#961;&#956;&#959;&#947;&#942; &#964;&#969;&#957; &#955;&#949;&#960;&#964;&#959;&#956;&#949;&#961;&#974;&#957; &#954;&#945;&#957;&#972;&#957;&#969;&#957; &#960;&#959;&#965; &#960;&#961;&#959;&#946;&#955;&#941;&#960;&#959;&#957;&#964;&#945;&#953; &#947;&#953;&#945; &#964;&#951;&#957; &#949;&#966;&#945;&#961;&#956;&#959;&#947;&#942; &#964;&#969;&#957; &#956;&#949;&#953;&#974;&#963;&#949;&#969;&#957; &#963;&#964;&#951;&#957; &#964;&#953;&#956;&#942; &#960;&#945;&#961;&#941;&#956;&#946;&#945;&#963;&#951;&#962; &#964;&#951;&#962; &#954;&#961;&#953;&#952;&#942;&#962; &#963;&#964;&#951;&#957; I&#963;&#960;&#945;&#957;&#943;&#945;#&#928;&#929;&#927;&#932;&#913;&#931;&#919; &#922;&#913;&#925;&#927;&#925;&#921;&#931;&#924;&#927;&#933; (&#917;&#927;&#922;) TO&#933; &#931;&#933;&#924;&#914;&#927;&#933;&#923;&#921;&#927;&#933; &#947;&#953;&#945; &#964;&#951;&#957; &#964;&#961;&#959;&#960;&#959;&#960;&#959;&#943;&#951;&#963;&#951; &#964;&#959;&#965; &#954;&#945;&#957;&#959;&#957;&#953;&#963;&#956;&#959;&#973; (&#917;&#927;&#922;) &#945;&#961;&#953;&#952;. 1418/76 &#960;&#949;&#961;&#943; &#954;&#959;&#953;&#957;&#942;&#962; &#959;&#961;&#947;&#945;&#957;&#974;&#963;&#949;&#969;&#962; &#945;&#947;&#959;&#961;&#940;&#962; &#964;&#951;&#962; &#959;&#961;&#973;&#950;&#951;&#962; (&#933;&#960;&#959;&#946;&#955;&#951;&#952;&#949;&#943;&#963;&#949;&#962; &#945;&#960;&#972; &#964;&#951;&#957; &#917;&#960;&#953;&#964;&#961;&#959;&#960;&#942; &#963;&#964;&#959; &#931;&#965;&#956;&#946;&#959;&#973;&#955;&#953;&#959;)</title>
  </expression>
</work>

Hors ligne

 

#4 25-03-2015 16:44:06

seki  
0x73656B69
Award: bf
Lieu: Laquenexy & Luxembourg
Date d'inscription: 20-11-2008
Messages: 1118
Pépites: 4,296,080,204
Banque: 9,223,372,036,854,776,000
Site web

Re: Importer fichier XML avec caractères cyrilliques et stocker en ORACLE

Hum, sur StackO, j'aurais commenté en disant "Et quelle est la question ?"

Bon, si la base utilise déjà utf-8, le plus gros est fait

Avec les encodages, il faut être un peu parano et vérifier si l'affichage que nous fait l'ordi des données est exact : çàd, pour être sûr de l'encodage effectif du fichier, il faudrait regarder avec un éditeur hexa (j'ai déjà vu des fichiers xml mentir )

Quand je sauve la première ligne en utf-8 (avec BOM, mais ce n'est pas important), voici ce que j'ai :

Code: Hexa montré par HxD

00000000  EF BB BF 46 4F 52 53 4C 41 47 20 54 49 4C 20 52 C3 85 44 45 54 53 20 46 4F 52 4F 52 44 4E 49 4E  FORSLAG TIL RÅDETS FORORDNIN
00000020  47 20 28 45 C3 98 46 29 20 6F 6D 20 C3 A6 6E 64 72 69 6E 67 20 61 66 20 66 6F 72 6F 72 64 6E 69  G (EØF) om ændring af forordni
00000040  6E 67 20 28 45 C3 98 46 29 0D 0A                                                                 ng (EØF)..

Ce qui est important c'est que les caractères "Å" sont bien en réalité "Ã…" ou les "EØF" -> "EØF".

Donc au début (fichier) et à la fin (database), ça serait ok...

Je ne sais pas si le fil cité en exemple peut t'aider tel-quel (le message important c'est http://pbadonf.fr/forum/viewtopic.php?pid=34769#p34769 parce que le reste c'était un peu du bricolage ), mais dans ce fil il fallait traduire des caractères utf-8 "bruts" (avec plusieurs octets pour véhiculer 1 caractère) en caractères "ansi" uniques (par exemple "€" est corrigé en "€", le "CP_ACP" indique que widechartomultibyte traduira si possible vers le bon caractère dans l'encodage spécifié dans les paramètres régionaux locaux au poste windows si le caractère est disponible, sinon avec un '?').

Mais toi tu as des caractères ut-8 "bruts" que PB9 ne sait pas interpréter, et tu veux les envoyer dans une base qui connait utf-8. Il suffit peut-être d'indiquer à la base que tu lui envoies de l'utf-8 ?

Comment le contenu du fichier est-il envoyé dans la base ? Mes souvenirs rouillés de PB+Oracle remontent à PB5 et Oracle 7.3 et à cette époque le problème de l'euro ne se posait pas encore


The best programs are the ones written when the programmer is supposed to be working on something else. - Melinda Varian

Mes réponses PB sur StackOverflow
http://stackoverflow.com/users/flair/317266.png

Hors ligne

 

#5 25-03-2015 19:57:40

Marcus  
Membre Geek
Lieu: Namur
Date d'inscription: 20-06-2006
Messages: 39
Pépites: 258
Banque: 0

Re: Importer fichier XML avec caractères cyrilliques et stocker en ORACLE

C'est vrai que la question est complexe.
Mais en phasant le problème, je dirais que la première question qui se pose est la suivante :

Comment récupérer un texte (qu'il vienne d'un XML ou non) qui contient des caractères cyrilliques ou autres ... (a priori codés utf-8) et le stocker dans une variable ou une datawindow sans transformation des caractères ??
... et tout çà en PB 9 bien sur !!

Hors ligne

 

#6 26-03-2015 10:56:29

seki  
0x73656B69
Award: bf
Lieu: Laquenexy & Luxembourg
Date d'inscription: 20-11-2008
Messages: 1118
Pépites: 4,296,080,204
Banque: 9,223,372,036,854,776,000
Site web

Re: Importer fichier XML avec caractères cyrilliques et stocker en ORACLE

Marcus a écrit:

C'est vrai que la question est complexe.

Le truc, c'est qu'il y a une succession d'étapes et que si on ne maîtrise pas, on peut introduire des ennuis à chaque étape.
C'est pour cela que j'insiste sur la décomposition et la vérification à chacune d'elles. Si on grille des étapes, parfois on se tire une balle dans le pied tout seul.

Marcus a écrit:

Mais en phasant le problème, je dirais que la première question qui se pose est la suivante :

Comment récupérer un texte (qu'il vienne d'un XML ou non) qui contient des caractères cyrilliques ou autres ... (a priori codés utf-8) et le stocker dans une variable ou une datawindow sans transformation des caractères ??
... et tout çà en PB 9 bien sur !!

Si tu ne veux pas transformer, il suffit de lire le fichier, comme PB9 ne connaît pas utf (8 ou 16) comme les autres PB à partir du 10, dans la variable string (ou blob suivant ton code) en interne les caractères exotique seront présents dans leur forme "brute" (par exemple si le caractère est "é" au départ, en utf-8 ça donne "é" mais ça reste du texte).
PB9 ne saura pas les afficher correctement (dans une DW ou même en regardant le contenu de la variable en debug) mais ça devrait pouvoir être transmis à la base correctement, sauf si il y a un transformation entre PB et Oracle. Comment tu passes les données à la base ?


The best programs are the ones written when the programmer is supposed to be working on something else. - Melinda Varian

Mes réponses PB sur StackOverflow
http://stackoverflow.com/users/flair/317266.png

Hors ligne

 

#7 27-03-2015 09:29:41

Marcus  
Membre Geek
Lieu: Namur
Date d'inscription: 20-06-2006
Messages: 39
Pépites: 258
Banque: 0

Re: Importer fichier XML avec caractères cyrilliques et stocker en ORACLE

Pas de solution semble-t-il pour importer du texte "exotique" dans une variable ou une datawindow en PB 9

J'ai donc importé une majorité du fichier, que je peux alors gérer et enregistrer en DB

Pour le reste, j'utilise un simple fileread pour stocker l'entièreté du fichier en format blob.
Ensuite avec l'utilisation de la fonction BlobMid, je peux isoler la partie contenant des caractères cyrillique.
Il suffit alors d'enregistrer cela dans un blob Oracle

Assez contraignant mais bon

Hors ligne

 

#8 27-03-2015 15:44:33

seki  
0x73656B69
Award: bf
Lieu: Laquenexy & Luxembourg
Date d'inscription: 20-11-2008
Messages: 1118
Pépites: 4,296,080,204
Banque: 9,223,372,036,854,776,000
Site web

Re: Importer fichier XML avec caractères cyrilliques et stocker en ORACLE

Marcus a écrit:

Pas de solution semble-t-il pour importer du texte "exotique" dans une variable ou une datawindow en PB 9 [...]

Il ne faut pas confondre les données et la représentation des données. Du texte utf-8 peut très bien être lu par pb sans que celui-ci soit capable de les afficher correctement, mais transmis sans l'altérer à la base qui sera capable de le restituer correctement.

Blobmid() pourquoi pas (même si j'ai un doute, ça ressemble au bricolage cité plus haut pour "corriger" l'euro), mais tu risques de ne traiter que quelques cas particuliers au cyrillique, et le jour où ce sera une autre langue... Par ailleurs, parser de l'xml à coup de blobmid quand il y a pbdom c'est aussi du bricolage.

Je veux bien essayer de t'aider, mais j'ai plusieurs fois demandé comment les données étaient envoyées dans la base et tu ne réponds pas à la question.


The best programs are the ones written when the programmer is supposed to be working on something else. - Melinda Varian

Mes réponses PB sur StackOverflow
http://stackoverflow.com/users/flair/317266.png

Hors ligne

 

#9 31-03-2015 14:19:29

Marcus  
Membre Geek
Lieu: Namur
Date d'inscription: 20-06-2006
Messages: 39
Pépites: 258
Banque: 0

Re: Importer fichier XML avec caractères cyrilliques et stocker en ORACLE

Merci Seki.

... J'avance
Effectivement, il ne faut pas confondre les données et leur représentation.
Et comment tu l'as bien dit, si le caractère est "é" au départ, en utf-8 ça donne "é" mais ça reste du texte.

Le problème avec PB 9, c'est que le cyrillique ou autre alphabet exotique est transformé quand lu en string et est donc irrécupérable (ex: '????TO ...')
La seule solution est donc de l'importer dans une variable de type blob

Bien sur, le pbdom ne fonctionne pas non plus avec les caractères cyrillques ou bizarres avec PB 9 et la pbdom90. Ce qui est dans la même logique
Donc, à partir de la variable blob, on doit donc faire du parsing. Soit on le fait dans PB 9 avec le blobmid, soit dans Oracle via une stored proc.

J'ai pris le parti de faire çà en PB. Je sais que les textes au format cyriliiques, arabes, russes, thai ou autres sont tous compris dans un tag "<title" avec code langue.
Ex : <title lang="ELL" from="final">ΠΡΟΤΑΣΗ ΚΑΝΟΝΙΣΜΟΥ (ΕΟΚ) TOΥ ΣΥΜΒΟΥΛΙΟΥ για την τροποποίηση του κανονισμού (ΕΟΚ) αριθ. </title>

Je peux donc faire du parsing avec blobmid et récupérer le texte dans une variable blob.
Il suffit ensuite d'enregistrer cette variable au niveau Oracle dans un BLOB ou CLOB

ET pour répondre à ta question. Comment les données sont envoyées à la base. Cà c'est très simple :
Je crée un record avec l'Id et le code langue, ... puis l'update pour le Blob
Ex : UPDATEBLOB COM_TITRE SET CTI_IMAGE = :lbl_Texte WHERE CTI_ID = :ll_Id ;

A noter que tout cela est complétement inutile avec PB10 puisque là le PBDom fonctionne correctement et le traitement des variables et la représentation du grec sont parfaits


Ultime question donc :
- Un moyen d'éviter ce parsing blob ou d'améliorer l'import (bricolage) ?

Hors ligne

 

Pied de page des forums

Propulsé par FluxBB 1.2.22