Problème d'encodage - UTF8 vers ANSI

Version imprimable

Bonjour,

La mise à jour vers la version 2.24 64 bits continue à poser des problèmes :

Dans mon projet, je suis amené à créer une base de données avec des champs noms et prénoms. Les noms étant stockés en majuscule et la première lettre des prénoms en majuscule et les autres en minuscule (ce qui fait par une fonction spécifique qui fonctionne bien). Jusqu'à présent, la séquence de code suivante (expl pour le nom) fonctionnait sans problème Laz Util étant dans la options du projet et LazUTF8 dans Uses :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 procedure TF_Gene.DB_NaissNomEnftExit(Sender: TObject); Var NomEnfant : String ; begin NomEnfant := Upcase(Utf8ToWinCP(DB_NaissNomEnft.Text)) ; DB_NaissNomEnft.text := NomEnfant ; DB_NaissPnomEnft.SetFocus ; end; procedure TF_Gene.DB_NaissNomEnftKeyPress(Sender: TObject; var Key: char); begin if Key = #13 Then DB_NaissPnomEnft.setFocus ; end;
par exemple si j'entrais comme nom "estÉve" ( le É étant entré par la touche Alt144) je récupérais dans le champ "NomEnfant" de la base "ESTÉVE". Depuis le passage à la version 2.24 il est impossible de traduire en Ansi les entrées faites dans les contrôles qu'il s'agisse du type TDB_edit ou simplement Ed_Edit et que l'on utilise UTF8ToANSi, UTF8ToSys ou UTF8ToWinCp. Actuellemnt je récupère NomEnfant = $000000000E318CB8^: 'EST'#$C9'VE'
Comment se sortir de ce mauvais pas ?

01/02/2023, 09h49
acaumes

Bonjour,

Pour moi, cela est bon (Un E avec accent encodé en ANSI western European vaut bien C9).
Ce que tu vois, c'est dans le débogueur? Si oui c'est normal. Que dit ta base de données (avec un autre outil?)

Personnellement dans mon appli depuis le passage du compilateur à UTF8 qui a fait que les fonctions UTF8toSys sont neutralisées (en leur faisant retourner sans conversion) j’utilise UTF8ToWinCP et WinCPToUTF8.

Cordialement
01/02/2023, 10h19
alanglet

Bonjour,

Dans les TdbEdit c'est même EST?VE qui doit s'afficher. Tout ceci est normal puisque seul l'UTF8 est affiché correctement par Lazarus et que le code $c9 n'est pas un caractère normal en UTF8.
Pour la liaison à la base, le "CharacterSet" de connexion à utiliser doit être UTF8. Si le champ correspondant dans la base est du WIN1252, le transcodage doit se faire automatiquement, à condition que le caractère existe dans les 2 jeux de caractères.
UTF8UpperCase devrait suffire pour mettre le nom en majuscules.

André
01/02/2023, 11h37
OR34a

Affichage et encodage UTF8-Ansi

Bonjour,

J'utilise Zeos pour communiquer avec la base de données. Dans le ZC_Naiss la propriété Controlcodepage est bien Ccp-UTF8.
A l'affichage dans le TBD_Edit j'ai bien EST?VE ainsi d'ailleurs que dans le champ correspondant de la base que j'ai vérifié en utilisant sqliteadmin .
C'est extrêmemnt génant alors que cela fonctionnait bien avec la version 2.0 32 bits de Lazarus que j'utilisais il n'y a pas si longtemps.
01/02/2023, 11h57
OR34a

même problème

Bonour,

En complément de ma réponse : j'ai testé l'option UTF8Uppercase (...) . J'ai bien un afichage ESTÉVE mais par contre la récupération dans le champ de la base de données donne : ESTÃƒâ€°VE.
donc le problème reste entier .
01/02/2023, 13h00
acaumes

Ça

Citation:

ESTÃƒâ€°VE.

c'est parce que c'est encodé en UTF8.
Pour autant que j'ai vu cpp_UTF8 ne fait rien! C'est à dire (si j’ai bien lu car je ne suis pas spécialiste de ZEOS) que ce que as dans ta base, tu le reçois dans ton application.

Pour info avant d'arriver à la version 2.24 tu venais de quelle version? Car depuis au moins la version 2 c'est comme ceci?

Donc soit
* (tu dois connaître ZEOS mieux que moi) tu trouves ce qui te permet un transcodage ANSI en base vers UTF8 sur ton programme
* tu transforme ta base en UTF8
* Tu utilises les fonctions UTF8toWincp (de ton programme vers la base) et WinCptoUTF8 (de ta base vers ton programme)

Il te faut aussi savoir que le codage ANSI dépend de la zone où tu es et que le É se transforme en Iota en Grèce (par exemple)
02/02/2023, 08h57
bb84000

Bonjour !

Citation:

Envoyé par OR34a

En complément de ma réponse : j'ai testé l'option UTF8Uppercase (...) . J'ai bien un affichage ESTÉVE mais par contre la récupération dans le champ de la base de données donne : ESTÃƒâ€°VE.
donc le problème reste entier .

Acaumes a tout expliqué. Mais de toutes façons, où est le problème puisque vous savez comment l'afficher correctement dans votre application ?

bb84000
02/02/2023, 17h38
OR34a

Efectivement le problème n'en n'est pas réellement un

Bonjour,

J'ai supprimé toutes les instructions "UTF8toANSi" ou similaires de mon projet et l'affichage dans les formulaires du projet est alors correct quel que soit le caractère concerné. Dan les enregistrements de la base, les caractères accentués et autres continuent de s'afficher avec des codes particuliers, mais en réalité cela ne me gène pas vraiment car, pour communiquer avec mes correspondants j'ai l'obligation de transmettre des fichiers Excel et que, pour cela, j'ai intégré un transfert des tables vers des fichiers CSV et que j'utilise Notepad++ et sa possibilité d'encodage UTF8 vers ANSI pour construire en suite le fichier Excel.
CE qui me posait problème c'est que dans les versions précédentes j'utilisais les fonction de conversion et que l'affichage était correct, mais bon, le plus simple étant le mieux le problème est résolu.
Merci pour votre intérêt et vos suggestions.

R.O.
03/02/2023, 12h16
bb84000

Bonjour,

Le jeu de caractères par défaut d'une base SQLite3 est UTF8. Lazarus/FPC travaillant en UTF8, vous n'avez effectivement rien à faire. Il est possible que le logiciel avec lequel vous regardez les tripes de la base ne soit pas UTF8, ce qui explique que l'affichage des champs soit bizarre. Essayez avec DB Browser pour SQLite, pour voir.

bb84000
03/02/2023, 15h32
acaumes

Bonjour,

Citation:

Envoyé par bb84000

Le jeu de caractères par défaut d'une base SQLite3 est UTF8.bb84000

Oui, cela signifie que tout ce qui est traité par SQLite3 doit être en UTF8 (sauf cas particuliers sqlite3_open16 où le nom de la base doit être en UTF16.
Pour les données textuelles que tu mets dans la base (texte entre guillemets rien n'est vérifié tu peux utiliser le codage que tu désires rien ne se passera (et il n'y a aucune vérification).

Citation:

pour communiquer avec mes correspondants j'ai l'obligation de transmettre des fichiers Excel

As tu essayé avec FPSpreadsheet via OPM par exemple.

Cordialement
03/02/2023, 15h35
alanglet

Bonjour,

Citation:

Envoyé par bb84000

Le jeu de caractères par défaut d'une base SQLite3 est UTF8.

Vous êtes bien sûr de çà?
Je me suis aussi trompé en répondant précédemment:

Citation:

Envoyé par alanglet

Pour la liaison à la base, le "CharacterSet" de connexion à utiliser doit être UTF8. Si le champ correspondant dans la base est du WIN1252, le transcodage doit se faire automatiquement, à condition que le caractère existe dans les 2 jeux de caractères.

Utilisant habituellement Firebird, je pensais que c'était pareil avec SQLite.
Mais étonné par la réponse d'acaumes:

Citation:

Envoyé par acaumes

Pour autant que j'ai vu cpp_UTF8 ne fait rien! C'est à dire (si j’ai bien lu car je ne suis pas spécialiste de ZEOS) que ce que as dans ta base, tu le reçois dans ton application.

j'ai consulté la FAQ SQLite https://www.sqlite.org/faq.html#q3
et j'en conclu que SQLite enregistre dans ses champs "ce qu'on y met" sans aucun transcodage. Il ne le modifie pas, C'est pourquoi OR34a y trouvait du WIN1252 à l'époque où son logiciel travaillait en interne en WIN1252.
Conclusion annexe: pour transférer des données, une base chargée avec un logiciel Lazarus (UTF8) n'est pas utilisable directement sur un logiciel D7 (WIN1252), à moins de "transcoder" toute la base avant.

André

PS: acaumes vient juste de me griller... mais pour compléter sa réponse, il n'est pas sorcier de programmer une exportation en csv en transcodant en WIN1252.

Bonjour alanglet !

Dans le sujet Opening A New Database Connection

"The default encoding will be UTF-8 for databases created using sqlite3_open() or sqlite3_open_v2(). The default encoding for databases created using sqlite3_open16() will be UTF-16 in the native byte order."

Ceci étant, comme vous l'avez dit, dans une base existante, si on y a mis de l'ansi, on retrouvera de l'ansi. Donc si on travaille avec d'anciennes bases où le problème peut arriver, il faut savoir si on est en ansi ou en UTF8, convertir dans le premier cas et ne rien faire dans le second. A moins que cette fonction existe déjà, voici un code qui fait ça (uses LazUTF8 nécessaire) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 // Convert Ansi string to UTF8 string if string is ansi, do nothing if string is already UTF8 function IsAnsi2Utf8(st: string):string; var i: integer; b1, b2: byte; begin result:= st; // if length (byte) equal to UTF8 char number // Then we are in ANSI or pure ASCII if Length(st) = UTF8Length(st) then begin for i := Length(Result) downto 1 do if Result[i] >= #127 then begin b1 := $C0 or (ord(Result[i]) shr 6); b2 := $80 or (ord(Result[i]) and $3F); Result[i] := chr(b1); Insert(chr(b2), Result, i + 1); end; end; end;
bb84000