Insertion des champs écrits en arabe dans une base de données avec c++ builder

Version imprimable

08/10/2011, 13h31
Mariness

Insertion des champs écrits en arabe dans une base de données avec c++ builder

Bonjour tout le monde,

Je viens d'apprendre à utiliser le C++ builder 2011, je suis amenée à manipuler des enregistrement en arabe dans une base de données. Mais je rencontre des problèmes de codage les champs en arabe que j’insère dans la base devient des "??????". Je sais que le C++ builder 2011 traite l'unicode mais je parviens pas à le toucher :(

J'ai essayé d'utiliser wchar_t et de déclarer mes chaines (que j'insère dans la BD) comme UnicodeString mais en vain!

Si vous pouvez me donner une idée, une solution SVP!
09/10/2011, 08h47
DjmSoftware

Salut
Avec quelle type de base de donnée, et moyens de connections a tu fait tes essais(Orace,MSSQL,Interbase,BlackFish,Access..)(DbExpres,ADO,BDE)
cordialement
09/10/2011, 15h41
Mariness

Salut DjmSoftware

J'ai utiliser une base paradox (DataBase Desktop ) et je la manipule au moyen DbExpres.

Exemple du code:
Table->FieldByName("Nom")->Value=NomEdit->Text;
Table->FieldByName("Prenom")->Value = PrenomEdit->Text ;

j'ai essayé de récupérer les contenus de mes champs en arabe (objet TEdit) dans des variables de types UnicodeString et wchar_t * et ça n'a pas marché j'ai toujours des ???? dans la base.
09/10/2011, 17h07
DjmSoftware

Salut
Pour autant que je me rappelle PARADOX ne supporte pas l'unicode

j'ai fait un simple essai avec le moteur de base de donnée BlackFishSQL fournit avec C++Builder 2010 et je n'ai eu aucune problème d'utilisation des caractères arabes avec DBexpress.
Je pense qu'il doit en être de même avec d'autre type de base de donnée.
tu peux également faire un test avec une base de donnée de type Access via le moteur ADO

cordialement
09/10/2011, 20h11
Mariness

Salut

Merci bien pour votre réponse je vais essayé donc avec un autre type de base de données. Espérons bien que ça va marcher ;)
10/10/2011, 09h02
DjmSoftware

Bonjour
n'oublie pas de marquer ce Post comme [RESOLU]
merci
10/10/2011, 09h20
Mariness

Bonjour

A ce propos, une autre question. J'ai essayé de mettre le contenu d'un TEdit en arabe dans l'action d'un bouton mais lors de l'appui sur le bouton le champs m'affiche ???????

Voila le code si simple:

Citation:

void __fastcall TForm1::Button1Click(TObject *Sender)
{
UnicodeString us= "حنان";
Edit1->Text=us;
}

Y'a t'il une fonction pour la conversion qui me manques peut être !!!
Merci infiniment :)
10/10/2011, 10h18
ShaiLeTroll

essaye d'ajouter un L devant la chaine comme ceci

Citation:

UnicodeString us = L"حنان";

Avec ton code, tu n'aurais pas un avertissement indiquant une conversion implicite ?
10/10/2011, 13h12
Mariness

Salut ShaiLeTroll
Je n'ai pas un avertissement indiquant une conversion implicite, j'ai un message d'erreur '????' is not a valid floating point value.
Et lors ce que j'ai ajouté le L j'ai remarqué que ce message est devenu 'حنان' is not a valid floating value. Les caractères arabes sont reconnus mais comment peut on débrouiller envers cette erreur ??
10/10/2011, 14h17
ShaiLeTroll

Tu utilise XE ou XE2 ?
Très étrange ton erreur, tu utilises bien " et pas ' comme délimiteur, le premier pour les chaines, le second pour les caractères (pouvant aller jusqu'à 4 octets)

Sinon pour Paradox, cela ne fonctionnera jamais sans utiliser quelques astuces !

Tu pourrais tenter de stocker tes chaines en UTF8 ou utiliser le CharSet arabe de la AnsiString<1256> au lieu de AnsiString<1252>
l'utilisation de UTF8 sera pénible avec Paradox, faut tout faire à la main !

En Delphi7, il était facile d'avoir de l'arabe dans une table Paradox stocké en Latin-1 et grâce à l'option "Langue pour les programmes non-unicode", cela utilisait le CharSet Arabe au lieu du Latin-1 !
Par contre, l'application ne pouvait être QUE arabe et bcp de personne ont des soucis avec ce mode de fonctionnement

En XE+, tu dois explicitement convertir car l'application est Unicode (donc n'est plus affectée par cette option en théorie), ça c'est à vérifier !

Sinon le plus simple et efficace, mais qui peut être déroutant, c'est de jouer avec le TDBEdit et la Font.Charset,
tu dois pouvoir stocker dans du Paradox de l'Arabe en utilisant le Windows-1256, le Module de Base de Données, lui affichera la correspondance en Windows-1252 qui sera une suite de caractère sans sens évidemment mais dans ton application, avec le Charset ARABIC_CHARSET, fera la traduction

J'avais évoqué cela dans le sujet
Probleme avec l'Unicode et Non Unicode dans la meme table

Bon, ce n'est que de la théorie, je n'ai jamais pratiqué autre chose que le Latin-1, mais semble que la plupart ont solutionné leur problème avec l'une ou l'autre des solutions !

Sinon utilise FireBird, MySQL\MariaDB ... qui gère l'Unicode sera NETTEMENT plus pratique !
Pense que le BDE à installer, cela peut-être pénible (et obsolète depuis 10 ans)
10/10/2011, 16h12
DjmSoftware

Hello

Citation:

UnicodeString us= L"حنان";
Edit1->Text=us;

est parfaitement fonctionnel sous RadStudio 2010

cdlt
10/10/2011, 17h41
Mariness

Merci bcp ShailLeTroll

J'utilise l'XE, le problème est à moitié résolu, j'ai pu enfin affecter une chaine en arabe à un TEdit et c'est avec l'utilisation du charset ARABIC_CHARSET, mais concernant la base paradox j'ai utiliser la fonction UTF8Encode lors de l'ajout dans la base et UTF8Decode lors de l'extraction des données et ça n'a pas marché :(
Je vais essayer de travailler avec Interbase qui supporte normalement l'unicode.
10/10/2011, 17h50
Mariness

Salut DjmSoftware,

Je travaille sous C++ builder 2011 et le code qui a enfin fonctionné est:

Citation:

UnicodeString us= L"حنان";
Edit1->Font->Charset= ARABIC_CHARSET ;
Edit1->Text=us;

Cordialement
10/10/2011, 18h23
ShaiLeTroll

La méthode du Charset c'était pratique avec Delphi 7 !
Avec l'unicode par défaut, je ne sais pas que cela donne, il faudrait manuellement dire que la AnsiString est du charset 1256 et non 1252, cela risque d'être complexe !

FireBird serait moins "cher" qu'InterBase !
11/10/2011, 08h40
DjmSoftware

Bonjour

Citation:

FireBird serait moins "cher" qu'InterBase !

cela dépend de la version de C++Builder ou Radstudio achetée, car en principe Interbase fait partie de la distribution.
d'autre part seul XE2 contient les drivers d'accès pour DBExpress

Citation:

New in XE2! Included dbExpress drivers available for OS X – InterBase, Firebird, Oracle, MySQL, SQL Anywhere and Informix (Professional only includes InterBase local and MySQL)

cordialement
11/10/2011, 10h11
Mariness

Bonjour

Je veux faire une dernière tentative avec paradox avant de changer l'SGBD, j'ai penser donc à utiliser le fameux L avant la variable dont le contenu est un champs écrit en arabe dans ma BD, j'ai essayé ce code:

Citation:

UnicodeString us= L Table1->FieldByName("Nom")->AsAnsiString;
Edit1->Font->Charset=ARABIC_CHARSET;
Edit1->Text=us;

J'ai constaté que L est peut être à utiliser seulement avec une chaîne de caractères constante :( y'a t'il une astuce ou un moyen de le faire !!
Merci bien

Cordialement
11/10/2011, 11h17
ShaiLeTroll

Citation:

Envoyé par Mariness

Bonjour
J'ai constaté que L est peut être à utiliser seulement avec une chaîne de caractères constante :( y'a t'il une astuce ou un moyen de le faire !!
Merci bien

le L indique que la constante est Unicode

Pour Paradox, tu vas galérer car il va affecter une AnsiString<1252>, la forcer en <1256> ça doit être possible pour la chaine Unicode contiennent bien de l'arabe !
Et tu devras probablement faire l'inverse !
Le CodePage 1252 \ 1256 doit pouvoir se configurer, pour dire quel CODEPAGE ton programme utilise par défaut, faudra cherche à ce sujet, cela pourrait simplifier si programme est totalement en arabe

Changer le CodePage SANS effectuer la traduction, je ne sais pas si ça existe

Unicode dans RAD Studio, tu notes StrRec.CodePage, si tu as le courage, tu peux modifier manuellement son contenu (nécessite transtypage et une petite connaissance des pointeurs), il y a la fonction de lecture StringCodePage, faudrait voir si il y a une fonction pour le modifier SANS conversion ou comment se comporte l'affectation d'une AnsiString<1256> à une AnsiString<1252>, ou alors en passant via une RawByteString qui ne provoquera pas de correspondance.

Encore une fois, c'est de la théorie, si cela se trouve, il y a une méthode NETTEMENT plus SIMPLE !
Appel aux Experts en "Arabe+Paradox+UnicodeString" dans Delphi 2009 à XE

Demande à messahel quelle méthode il a choisi après son sujet Probleme avec l'Unicode et Non Unicode dans la meme table

Oublie le BDE, ce n'est plus supporté depuis 10ans, c'est pénible à installer !
Passe à FireBird !

Citation:

Envoyé par DjmSoftware

Interbase fait partie de la distribution.

Tout à fait, la version pour le développement !
Il faut ajouter le déploiement pour chaque Serveur !
Donc si l'application est distribuée, ce coût est à prendre en compte !
FireBird n'a pas de coût supplémentaire !

FireBird peut être redistribué que le logiciel soit OpenSource ou non !

Contrairement à MySQL, par exemple avec sa double licence GPL
si l'on développe un produit OpenSource, la licence est gratuite,
si l'on développe un produit non-OpenSource, il faut payer, je peux te dire quand tu as déployé 5000 serveurs, le passage de MySQL4 à MySQL5, ben c'est pas si donné que cela !
Combien utilise MySQL sans savoir qu'il faut payer une licence si le produit n'est pas en GPL
Pour MariaDB c'est plus très subtile, cela dépend si l'on dépend exclusivement de LibMySQL.dll ou si l'on utilise un code plus générique via ODBC ou DBExpress !

Avec InterBase, c'était quasiment inabordable pour une petite société éditeur de logiciel (va faire comprendre au client qu'il doit payer une licence d'un tiers aussi cher quasiment que la mise à jour ton logiciel)
11/10/2011, 11h49
DjmSoftware

Merci pour ces préciseuses informations sur le coût de déploiemment des bases de données
cela pourrait par ailleurs faire l'object d'un tutoriel
cordialement
27/10/2011, 10h11
Mariness

problème avec RawByteString
Bonjour à tous,

Maintenant j'utilise Interbase 2009, et j'essaye avec la fonction UTF8Encode
Code:

1 2 Table1->FieldByName("NOM")->Value=UTF8Encode(nom->Text); Table1->FieldByName("PRENOM")->Value=UTF8Encode(prenom->Text);
et j'ai l'erreur de compilation E2034 Impossible de convertir 'RawByteString' en 'Variant' comment puis-je la corriger!!
Merci d'avance.
27/10/2011, 14h01
ShaiLeTroll
Ceci est amplement suffisant !
Code:

1 2 Table1->FieldByName("NOM")->AsString = nom->Text; Table1->FieldByName("PRENOM")->AsString = prenom->Text;
Pense qu'il existe le TDBEdit au lieu d'un TEdit !
Pense au LiveBindings aussi !

Avec XE et Interbase n'utilise plus UTF8Encode
Et n'utilise pas non plus le BDE mais DBExpress ou UIB
Evite les Tables au profit Query avec SQL SELECT ciblé sur un nombre restreints d'enregistrements.

Le composant héritant du TWideDataSet gère nativement le l'unicode (même si dans la base c'est stocké en UTF8, c'est le driver et le sgbd qui se mettent d'accord à ce sujet pour leur communication), toi tu ne gère que des variables du type String (UnicodeString)
Pense qu'en XE AsString c'est en fait AsUnicodeString