IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Bases de données Delphi Discussion :

DELPHI MSSQL sous WIN10 Unicode UTF8


Sujet :

Bases de données Delphi

  1. #1
    Membre averti
    Avatar de Pascal Fonteneau
    Profil pro
    gérant
    Inscrit en
    février 2007
    Messages
    136
    Détails du profil
    Informations personnelles :
    Âge : 58
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : gérant
    Secteur : Bâtiment

    Informations forums :
    Inscription : février 2007
    Messages : 136
    Points : 345
    Points
    345
    Par défaut 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

  2. #2
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    13 233
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Industrie

    Informations forums :
    Inscription : janvier 2007
    Messages : 13 233
    Points : 35 952
    Points
    35 952
    Billets dans le blog
    54
    Par défaut
    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 Voir le message
    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
    Nom : Capture.PNG
Affichages : 111
Taille : 3,6 Ko


    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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
    Delphi installés : D3,D7,D2010,XE4,XE7,D10 (Tokyo, Rio, Sidney) ,D11 (Alexandria)
    SGBD : Firebird 2.5, 3, SQLite
    générateurs Etats : FastReport, Rave, QuickReport
    OS : Window Vista, Windows 10, Ubuntu, Androïd

  3. #3
    Expert éminent sénior
    Avatar de ShaiLeTroll
    Homme Profil pro
    Développeur C++\Delphi
    Inscrit en
    juillet 2006
    Messages
    12 261
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Développeur C++\Delphi
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2006
    Messages : 12 261
    Points : 21 665
    Points
    21 665
    Par défaut
    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.
    Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
    Attention Troll Méchant !
    "Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
    Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
    L'ignorance n'excuse pas la médiocrité !

    L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
    Il faut avoir le courage de se tromper et d'apprendre de ses erreurs

  4. #4
    Membre averti
    Avatar de Pascal Fonteneau
    Profil pro
    gérant
    Inscrit en
    février 2007
    Messages
    136
    Détails du profil
    Informations personnelles :
    Âge : 58
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : gérant
    Secteur : Bâtiment

    Informations forums :
    Inscription : février 2007
    Messages : 136
    Points : 345
    Points
    345
    Par défaut suite et fin
    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

  5. #5
    Expert éminent sénior
    Avatar de ShaiLeTroll
    Homme Profil pro
    Développeur C++\Delphi
    Inscrit en
    juillet 2006
    Messages
    12 261
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Développeur C++\Delphi
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2006
    Messages : 12 261
    Points : 21 665
    Points
    21 665
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 dfm : Sélectionner tout - Visualiser dans une fenêtre à part
    Caption = 'mots accentu'#233's'
    Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
    Attention Troll Méchant !
    "Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
    Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
    L'ignorance n'excuse pas la médiocrité !

    L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
    Il faut avoir le courage de se tromper et d'apprendre de ses erreurs

  6. #6
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    13 233
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Industrie

    Informations forums :
    Inscription : janvier 2007
    Messages : 13 233
    Points : 35 952
    Points
    35 952
    Billets dans le blog
    54
    Par défaut
    Citation Envoyé par Pascal Fonteneau Voir le message
    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) ?
    Delphi installés : D3,D7,D2010,XE4,XE7,D10 (Tokyo, Rio, Sidney) ,D11 (Alexandria)
    SGBD : Firebird 2.5, 3, SQLite
    générateurs Etats : FastReport, Rave, QuickReport
    OS : Window Vista, Windows 10, Ubuntu, Androïd

  7. #7
    Membre averti
    Avatar de Pascal Fonteneau
    Profil pro
    gérant
    Inscrit en
    février 2007
    Messages
    136
    Détails du profil
    Informations personnelles :
    Âge : 58
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : gérant
    Secteur : Bâtiment

    Informations forums :
    Inscription : février 2007
    Messages : 136
    Points : 345
    Points
    345
    Par défaut MSSQL et Win10 UTF- suite++
    Citation Envoyé par SergioMaster Voir le message
    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
    Nom : driver17.png
Affichages : 106
Taille : 25,1 Ko.

    -> ShaileTroll

    Je n'ai pas la compétence pour répondre à tes points d'interrogation . 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

  8. #8
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    13 233
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Industrie

    Informations forums :
    Inscription : janvier 2007
    Messages : 13 233
    Points : 35 952
    Points
    35 952
    Billets dans le blog
    54
    Par défaut
    Ok, je comprends mieux cette histoire d'ODBC.

    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 mais, sans MSSQL installé, n'ayant pas de base de données je n'avais aucune possibilité de tester
    Delphi installés : D3,D7,D2010,XE4,XE7,D10 (Tokyo, Rio, Sidney) ,D11 (Alexandria)
    SGBD : Firebird 2.5, 3, SQLite
    générateurs Etats : FastReport, Rave, QuickReport
    OS : Window Vista, Windows 10, Ubuntu, Androïd

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Applications DELPHI HYPER LENTES sous WIN10
    Par zouriteman dans le forum Delphi
    Réponses: 17
    Dernier message: 03/08/2020, 10h05
  2. [i18n][utf8] Outils pour convertir iso8859-1 en unicode/utf8
    Par co2 dans le forum API standards et tierces
    Réponses: 5
    Dernier message: 07/11/2005, 10h56
  3. Réponses: 1
    Dernier message: 16/10/2005, 21h17
  4. Réponses: 21
    Dernier message: 02/10/2005, 20h05
  5. Lenteur InterBase / Firebird avec delphi 7 sous XP
    Par obione dans le forum Bases de données
    Réponses: 3
    Dernier message: 28/11/2004, 21h22

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo