DELPHI MSSQL sous WIN10 Unicode UTF8

Bonjour à tous

Microsoft semble envisager de mettre l'Unicode-UTF8 en standard de replacement de l'ANSI.
Pour s'en rendre compte, allez voir sous WIN10 la case à cocher dans Panneau de Configuration\Horloge et région \modifier les formats dates et heures puis Onglet Administration.
La notion de BETA amène à penser que cela va devenir un standard un jour ou l'autre.
ATTENTION en activant cette option pour tester , vous allez perdre dans DELPHI tous les caractères accentués de vos sources (commentaires et texte de constantes)
si vous de le convertissez pas avant en UTF8-BOM (avec le notepad ++)

Après avoir reglé le problème des sources, des fichiers INI et XML en ANSI contenant des accents, il me reste un souci avec MSSQL
Configs testés SQL SERVER 2014 et 2019 avec DEPHI 10.0 et 10.3
Avec chaque fois les accents ne sont pas correctement traités depuis mes programmes
Exemple : "Le bras armé" devient "Le bras armée"

Je précise qu'avec SSMS tout va bien, ce n'est qu'avec DELPHI et les composants FIREDAC que mon souci se révèle !

Quelqu’un a t il rencontré et traité le problème ?

Merci de votre aide

Pascal

Bonjour,

Merci pour l'information, cela pourrait s'avèrerer crucial un jour. Je pense même que ce jour là il y aura pleurs et grincements de dents.

Citation:

---

Envoyé par Pascal Fonteneau

ATTENTION en activant cette option pour tester , vous allez perdre dans DELPHI tous les caractères accentués de vos sources (commentaires et texte de constantes)
si vous de le convertissez pas avant en UTF8-BOM (avec le notepad ++)

---

à moins que ces fichiers soient déjà sauvegardés en UTF8, la 10.4 arrive donc bien avec sa petite barre indiquant l'encodage
Pièce jointe 594563

Code:

---

Je précise qu'avec SSMS tout va bien, ce n'est qu'avec DELPHI et les composants FIREDAC que mon souci se révèle !

---

Sans avoir à lire dans une boule de cristal, je présume qu'il s'agit d'une connexion déjà existante.
Le CharacterSet de celle-ci est-il bien renseigné ? (par défaut c'est souvent NONE)

Code:

---

Quelqu’un a t il rencontré et traité le problème ?

---

Pas moi, puisque je n'utilise pas MSSQL, non installé je ne peux même pas tester. Ce qui est au dessus n'est donc qu'une suggestion.
J'espère avoir vu juste

Cette option "Beta: Use Unicode UTF-8 for worldwide language support". concerne les programmes non Unicode par exemple un programme en D7 et D7 lui même

Pourquoi cela impacte donc DEPHI 10.0 ?
Est-ce que cela modifie le comportement des API d'écriture de fichier texte ... et si l'on a besoin de stocker explicitement un fichier ANSI pour un programme tiers tournant sur un autre OS, quand je dis ANSI, je ne parle pas forcément de Windows-1252 mais ISO 8859-1, voir CP437 ... ou est-ce seulement SetWindowTextA par exemple et les API liés au controles Windows ... encore une fois, Delphi 10 devrait utiliser les versions unicode même si le fichier source est ANSI.
Un programme Unicode ne devrait pas être concerné par cela

Pour les INI, comme c'est encapsulé par une seule série d'API, ce n'est pas problématique si le programme est le seul a les gérer mais que ce passe-t-il entre l'avant et après l'utilisation de cette case à cocher, comment est géré la transition ?


D'ailleurs, Delphi, pas besoin de Notepad++, clic droit "Format Fichier", tu peux choisir ANSI, UTF, UTF16, UTF32
Cette option de Microsoft est une GROSSE erreur si cela impacte les fichiers d'une application Unicode ... c'est peut-être ça le bug qui fait que ça reste en BETA

Faudrait connaître tous les fonctions patchées par cette case à cocher pour au moins les identifier de les programmes et se préparer à la standardisation de cette grosse betise.


MSSQL mais avec ADO, à l'occasion, si j'ai une WM un jour, je ferais le test, aucune envie de pourrir mon PC avec option.

Bonjour

Merci à vous 2 pour vos réponses. La nuit portant conseil, je me suis dis ce matin que le pilote ODBC n'était peut-être plus à jour et c'est bien le cas. Il fallait la version 17 pour MSSQL. De nouveaux soucis de curseurs (Fetch) sont apparus, mais c'est surement un vieux bug non levé par l'ancien pilote.

Je reviens sur l'option WIN10 Unicode-UTF8. Peu de développeurs ont conscience des conséquences leurs applications de l'activation de cette case à cocher.

Voici mes constations

Même les applications Unicode sont touchées (avant la 10.4 TOUT DU MOINS ) a partir de la 10.4, je ne sais pas.

Dans le code source

Dans les .pas -> remplacement des caractères accentuées par un carré blanc puis un losange noir avec un ? dans les exécutables (voir plantage).
L'enregistrement au format UTF8 n'a pas suffit avec ma 10.1. J'ai du passer par la conversion du notepad++ pour utiliser un tag BOM en plus de UTF8.
les DFM ne sont pas impactés car au format UTF8 (l'ancestral non unicode)

La doc de la 10.4 traite enfin du sujet et j'espère qu'une meilleure compatibilité est maintenant présente

http://docwiki.embarcadero.com/RADSt...chiers_Unicode

Avec une utilisation incomplète ou inadaptée des fonctions

Les fonctions TStrings.SaveToFile sont impactées si l'encodage n'est pas précisé. Et que dire si le fichier produit sur le disque est partagé en réseau avec une application sur une win10 non calé sur unicode.UTF8
Cela m'amène a penser que tant que Win8 (encore totalement ANSI) sera maintenu nous devrions être tranquille et profiter de ce temps pour lancer vérifications et modifications.
Attention également avec les fichiers XML. Ils doivent avoir été crées avec un TXMLDoc bien calé car sinon lors de l'ouverture le TXMLDOC il y a incohérence ( et bug ) avec la 1ere ligne qui décrit l'encodage.

Pour finir, je pense qu'un sujet sur ce thème serait le bienvenu. Nous pourrions y partager nos trucs et expériences.

Pascal

TStrings.SaveToFile(FileName) en D10 c'est implicitement via un overload un appel à TStrings.SaveToFile(FileName, Encoding) avec Encoding la propriété de la TStrings mis par défaut par le constructeur à TEncoding.Default soit donc ANSI pour Windows et UTF8 pour POSIX
En D10, cela converti donc le contenu du TStrings de l'Unicode vers ANSI par défaut, une compatibilité avec les anciennes versions, au développeur de prendre en charge le fait de migrer ses fichiers (si il le peut) vers un nouvel encodage de son choix.

Alors pour les programmes récents, on peut facilement expliciter l'Encoding, c'est justement l'une de mes taches, migrer des applications D7 ou DXE2 vers D10.0, le passage à l'UTF8-BOM en fait parti !
Sauf que le programme sait lire l'ANSI et l'UTF8 pour gérer la compatibilité avec d'autres applications ou avec des fichiers non migrés ce qui est fréquent lorsque l'on déploit chez des milliers de client.

Comment se comporte un TStrings.LoadFromFile depuis un fichier ANSI et un fichier UTF8-BOM ?
Le cas du UTF8 sans BOM ce n'est pas un problème puisque le programmeur dans ce cas indiqué l'encoding manuellement.
Que de vient le "é" dans une simple ligne contenant "mots accentués" ?

Sinon pour le XML, j'ai toujours du mal entre l'encodage du fichier pouvant être UTF-8 et l'encodage XML vient s'ajouter dessus, je n'ai jamais bien compris cette histoire
Et j'ai eu des programmes avec des XML en ISO-8859-1
Si le programme DOIT générer un fichier en ISO-8859-1 parce qu'un programme tiers n'accepte que le ISO-8859-1, Windows n'a pas à se mêler du Bazard !


Tient, comment se comporte cette fonction ?
Pour lire de l'ANSI ou un BOM supporté par TEncoding ?
C'est du code D10.0, l'article "Utilisation de TEncoding pour les fichiers Unicode" n'a rien de neuf, il a plus de 10 ans, j'utilisais déjà TEncoding en XE2 lors de mon passage de D7 à C++Builder XE3 avec les wchar_t + c_str() puis retour à DXE2, j'ai eu une phase de paranoïa, j'explicitais partout l'Encoding pour les fichiers envoyés depuis ou vers une source extérieure par prudence avec l'Unicode et l'ANSI justement

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

function LoadFromFile(const AFileName: string): string; var VFileStream: TFileStream; VSize: Integer; VPreamble: TBytes; VPreambleSize: Integer; VEncoding: TEncoding; VMemStream: TBytesStream; begin VFileStream := TFileStream.Create(AFileName, fmOpenRead or fmShareDenyWrite) ; try SetLength(VPreamble, 4); // 2 pour UTF-16, 3 pour UTF-8 et 4 pour UTF-32 VPreambleSize := VFileStream.Read(VPreamble, 4); if VPreambleSize >= 2 then begin VEncoding := nil; VPreambleSize := TEncoding.GetBufferEncoding(Copy(VPreamble, 0, VPreambleSize), VEncoding, TEncoding.ANSI); VSize := VFileStream.Size - VPreambleSize; end else begin VEncoding := TEncoding.ANSI; VPreambleSize := 0; VSize := VFileStream.Size; end;   VFileStream.Seek(VPreambleSize, soBeginning);   VMemStream := TBytesStream.Create(); try VMemStream.CopyFrom(VFileStream, VSize); Result := VEncoding.GetString(VMemStream.Bytes); finally VMemStream.Free(); end; finally VFileStream.Free; end; end;

---

même question pour cette fonction ?
Pour écrire de l'ANSI ou un BOM supporté par TEncoding ?
Note que par défaut, c'est UTF8 mais parce que justement c'est un soin que l'on apporte à nos applications, et comme tout ne se fait pas d'un coup, le plan de migration à un ordre à respecter en commençant par la fin de chaine, les programmes qui lisent pouvant supporter l'ancien et nouvel encodage, la file de dépendance est remonté ainsi de suite.

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

procedure SaveToFile(const AFileName: string; const AContent: string; AEncoding: TEncoding = nil); var VFileStream: TFileStream; VPreamble: TBytes; VMemStream: TStringStream; begin if AEncoding = nil then AEncoding := TEncoding.UTF8;   VFileStream := TFileStream.Create(AFileName, fmCreate) ; try VPreamble := AEncoding.GetPreamble(); VFileStream.Write(VPreamble[0], Length(VPreamble));   VMemStream := TStringStream.Create(AContent, AEncoding); try VFileStream.Write(VMemStream.Bytes[0], VMemStream.Size); finally VMemStream.Free(); end; finally VFileStream.Free(); end; end;

---

Ce genre de modification de Windows, c'est un coup à devoir tout gérer en binaire pour tout ceux qui ne pourront pas acheter le dernier Delphi compatible.


les DFM ne sont pas en UTF8 mais en ANSI avec un échappement des caractères même si Delphi arrive à lire quand mêmes les accents, ce n'est pas le format de la DFM qui se présente ainsi pour "mot accentués"

Code:

---

Caption = 'mots accentu'#233's'

---

Citation:

---

Envoyé par Pascal Fonteneau

Merci à vous 2 pour vos réponses. La nuit portant conseil, je me suis dis ce matin que le pilote ODBC n'était peut-être plus à jour et c'est bien le cas. Il fallait la version 17 pour MSSQL. De nouveaux soucis de curseurs (Fetch) sont apparus, mais c'est surement un vieux bug non levé par l'ancien pilote.

---

Là, j'ai un peu de mal à comprendre ODBC ? On parlait de Firedac, à moins que l'accès à MSSQL se fasse via ODBC (on n'a normalement pas besoin d'ODBC pour se connecter avec Firedac le FDPhysMSSQLdriver est là pour ça).
Ou alors, c'est le driver (la dll) qui n'était pas à la bonne version (ce qui est toujours possible au fil du temps) ?

Citation:

---

Envoyé par SergioMaster

Là, j'ai un peu de mal à comprendre ODBC ? On parlait de Firedac, à moins que l'accès à MSSQL se fasse via ODBC (on n'a normalement pas besoin d'ODBC pour se connecter avec Firedac le FDPhysMSSQLdriver est là pour ça).
Ou alors, c'est le driver (la dll) qui n'était pas à la bonne version (ce qui est toujours possible au fil du temps) ?

---

->Sergio
Je pense que l'installation du pilote ODBC (V17 en mon cas) doit aussi installer de nouvelles DLL permettant de gèrer l'Unicode UTF-8 et peut-être aussi à FIREDAC un accès Natif avec la 10.4. Mais l'accès par ODBC fonctionne deja , la propriété Combo "DRIVER ODBC" du FDPhysMSSQLdriver fait apparaître le pilote
Pièce jointe 594608.

-> ShaileTroll

Je n'ai pas la compétence pour répondre à tes points d'interrogation :oops:. Par contre, si tu as besoin de tester quelque chose rapidement. je peux le faire avec toi avec teamviewer . Contact moi en PV si besoin;).

Pascal

Ok, je comprends mieux cette histoire d'ODBC.

Citation:

---

Le CharacterSet de celle-ci est-il bien renseigné ?

---

CharacterSet est présent pour les SGBD que j'utilise le plus souvent Firebird,Interbase ou moins MySQL,PG je ne pensais pas qu'une usine à gaz comme MSSQL ne l'avais pas !
J'aurai certainement du faire un essai de création d'un FDConnection. Je me serai alors apperçu que ce n'est pas un paramètre de connexion de type MSSQL :oops: mais, sans MSSQL installé, n'ayant pas de base de données je n'avais aucune possibilité de tester