Hola !

J'explique mon problème, ou plutôt ce que je ne pige pas !

Le contexte est tel que voici :
A partir d'une saisie utilisateur (ou émulation de saisie), je récupère un mot de passe en C# que je vais ensuite crypter en C++ (Dll import C# string to C++ char*).

J'effectue mon test, je rentre la chaîne suivante : C€afé𠀀1622 (oui, je choisis des exemples bien étranges)

Côté C#, le log me ressort "C€afé𠀀  1622". Juste un espace en plus donc (pas compris d'où qu'il vient).

Côté C++, j'obtiens "C€afé??  1622".

Si j'ai pas trop lu en diagonal, je sais que :

Mon string C#, c'est par défaut de l'UTF16.

Mon char C++, c'est de l'ASCII.

Mon caractère chelou '𠀀', c'est compatible UTF8, UTF16 et gb18030. Mais incompatible ASCII (notamment). Tout s'explique donc sur le rendu de chaque côté.

Les questions étant :

• D'où vient cet espace côté C# ?
• L'ASCII n'est-il pas compatible avec l'UTF-8 de base ? J'ai lu que le seul intérêt de l'ASCII sur l'UTF8 était la rapidité qu'il apportait (sous réserve qu'on se limite aux 128 caractères qu'il propose).
• Pourquoi '€' et 'é' passent-ils alors qu'on a refus complet pour '𠀀' ?
• Au final, comment je peux supporter ce genre de caractères ?

Voilà ! Tout est pas encore très clair côté encoding. J'ai toujours eu du mal à assimiler le principe.
J'ai déjà une petite idée de réponses quant à toute ces questions mais je n'arrive pas à trouver un "chemin logique stable" de A à Z.
Arrive forcément un moment où les pistes de réflexion s'opposent. Plus je lis et plus je me dis que je dois comprendre un truc de travers.

Merci à vous.

-
Edité par Sillimon 21 août 2018 à 15:52:44

Salut,

Sillimon a écrit:

Mon caractère chelou '𠀀', c'est compatible UTF8, UTF16 et gb18030. Mais incompatible ASCII (notamment). Tout s'explique donc sur le rendu côté C#.

Tu as mis toi même le doigt sur le problème ;):

Quand tu utilises std::string  (ou std::cout pour l'affichage) en C++, tu manipules des chaines de caractères... ASCII...  Pour manipuler des chaines de caractères "multibytes" (UTF ou autres), tu dois utiliser std::wstring en C++ (et, accessoirement std::wcout pour l'affichage).

Le tout, en prenant en compte (si possible) que la console de windows utilise par défaut une table de caractères particulière

koala01 a écrit:

Quand tu utilises std::string  (ou std::cout pour l'affichage) en C++, tu manipules des chaines de caractères... ASCII...  Pour manipuler des chaines de caractères "multibytes" (UTF ou autres), tu dois utiliser std::wstring en C++ (et, accessoirement std::wcout pour l'affichage).

Côté C++, j'utilise OutputDebugString :

• OutputDebugStringW (Unicode) and OutputDebugStringA (ANSI).
  
  
• OutputDebugStringW converts the specified string based on the current system locale information and passes it to OutputDebugStringA to be displayed. As a result, some Unicode characters may not be displayed correctly.

Effectivement donc, ça concorde.

Là où je m'interroge, c'est qu'au final, on stocke juste une série de binaires, nan ?

Je le perçois comme ça : de tel à tel endroit dans la mémoire y'a telle série de binaires. Cette série est ensuite récupérée et interprétée en utilisant tel schéma de decoding défini par le type. La question du decoding ne se présente donc que si l'on travaille ou affiche les données. Vrai ?

Sillimon a écrit:

Là où je m'interroge, c'est qu'au final, on stocke juste une série de binaires, nan ?

Au final, oui, tu stockes toujours une succession de bits.

Le gros problème vient de l'interprétation que l'on fait de ces successions de bits:

Si tu utilises std::string, C++ va interpréter cette succession de bits comme "un ensemble de valeurs codées sur 8 bits" et va spécifiquement rechercher le "glyphe" qui correspond à cette valeur (codée sur 8 bits) qu'il doit afficher dans la table ASCII.

De toute évidence, C# interprétera la même succession de bits comme  "un ensemble de valeurs codées sur (8/16/32) bits" et va spécifiquement rechercher le "glyphe" qui correspond à cette valeur (codée sur 8/16/32 bits) dans "une autre table de caractères" (qui dépend entre autre des réglages du système d'exploitation )

Sillimon a écrit:

Je le perçois comme ça : de tel à tel endroit dans la mémoire y'a telle série de binaires. Cette série est ensuite récupérée et interprétée en utilisant tel schéma de decoding défini par le type. La question du decoding ne se présente donc que si l'on travaille ou affiche les données. Vrai ?

 FAUX, du moins, si tu affiche les données sous la forme de caractères.  Parce que cela met en place toute une mécanique d'interprétation.

Il n'y a que si tu affiche ces données sous forme de valeurs numériques que tu te rendra -- effectivement compte que les données sont bel et bien identiques

EDIT:  Et encore: deux systèmes différents pourraient très bien te fournir des valeurs différentes, en fonction du "boutisme" (Big Endian Vs Little Endian) qu'ils utilisent

-
Edité par koala01 21 août 2018 à 18:34:49

Toutes ces manipulations sans jamais prendre le temps de regarder concrètement, en hexadécimale, ce qu'il y a vraiment en mémoire, c'est vraiment vouloir de faire des nœuds au cerveau.

Je passe sur la complète inutilité de faire se passage en C++ "natif" (le C++/CLI c'est pas juste pour faire jolie), et de la chose en générale car une string .NET est en claire dans la mémoire d'un programme .NET et y restera toutes la vie du programme.

Le Framework .NET 2.0 est ton ami :

https://msdn.microsoft.com/fr-fr/library/system.security.securestring(v=vs.110).aspx

Si tu insistes à faire du C++ Natif, faudrait penser à revoir les mécanismes de P/Invoke pour ce qui est du marshalling de chaine de caractère et pas réinventer une roue complètement voilée et totalement carrée.

https://docs.microsoft.com/en-us/dotnet/framework/interop/default-marshaling-for-strings

Vous nous indiquez pas les primitives de récupération de la chaine de caractère. Un très grand nombre de celles-ci ont des options pour le mode d'encodage des chaines de caractères qu'elles reçoivent, quand c'est pas fonction de l'OS ou du thread l'exécutant quand on prend l'encodage "par défaut".

Pour voir le contenu effectif des string :

https://stackoverflow.com/questions/241405/how-do-you-convert-a-string-to-a-byte-array-in-net

>c'est compatible UTF8, UTF16 et gb18030

Ça veut rien dire de bien précis tout ça.

>D'où vient cet espace côté C# ?

GetBytes est ton ami (et l'encodage de la primitive utilisées).

>J'ai lu que le seul intérêt de l'ASCII sur l'UTF8 était la rapidité

Où ça ??? Dans les passerelles mails des années 70 ?

C'est où que ta vu cette ineptie.

>Pourquoi '€' et 'é' passent-ils alors qu'on a refus

Quand on fait un peu n'importe quoi avec l'encodage, le résultat, bin, c'est un peu n'importe quoi.

>Au final, comment je peux supporter ce genre de caractères ?

En utilisant correctement les outils qu'on nous donne : paramétrage des primitives de lecture, utilisation (correcte) des primitives de marshalling, ne pas utiliser des sorties consoles pour déboguer (le débogueur et la visualisation en hexadécimale sont tes amis), etc...

Tu la sort d'où ta documentation d'OutputDebugString ??? De la version Window95 Win32s de MSDN ???

Cela fait plus de 15 ans que toutes les API ASCII des Windows sont un wrapper vers la version UNICODE et pas l'inverse.

>on stocke juste une série de binaires, nan ?

Oui, mais l'objet qui gère ces "binaires" sait comment interpréter cette séries de bits.

>récupérée et interprétée en utilisant tel schéma de decoding défini par le type

C'est pour ça que tu cherches à lire le contenu d'un champs d'un objet de type "référence" (System::string est un type référence) comme un char*. T'as pas l'impression d'avoir changé de type et donc le modèle d'interprétation du contenu de la mémoire entre les 2 étapes ???

Utilises le débogueur et la représentation hexadécimale avant de faire des conclusions bien trop hâtives.

koala01 a écrit:

Le gros problème vient de l'interprétation que l'on fait de ces successions de bits

interprétation potentiellement différente de la façon dont on a interprétée la saisie utilisateur en cette même succession de bits donc.

bacelar a écrit:

Je passe sur la complète inutilité de faire se passage en C++ "natif" (le C++/CLI c'est pas juste pour faire jolie)

C'est du très vieux code que j'ai repris. Il devrait pas tarder à atteindre ses 15 ans et il est loin d'être parfait, c'est vrai. Se retaper toute la logique en C++/CLI était en projet mais ça a été repoussé suite à des priorités autres ! C'est pas plus mal, ça me laisse le temps de me pencher un peu plus dessus.

bacelar a écrit:

 la chose en générale car une string .NET est en claire dans la mémoire d'un programme .NET et y restera toutes la vie du programme.

Le Framework .NET 2.0 est ton ami :

https://msdn.microsoft.com/fr-fr/library/system.security.securestring(v=vs.110).aspx

J'ai pas d'excuses. Je change ça.

bacelar a écrit:

Vous nous indiquez pas les primitives de récupération de la chaine de caractère. Un très grand nombre de celles-ci ont des options pour le mode d'encodage des chaines de caractères qu'elles reçoivent, quand c'est pas fonction de l'OS ou du thread l'exécutant quand on prend l'encodage "par défaut".

Une String récupérée via TextEdit.Text .

bacelar a écrit:

>J'ai lu que le seul intérêt de l'ASCII sur l'UTF8 était la rapidité

Où ça ??? Dans les passerelles mails des années 70 ?

C'est où que ta vu cette ineptie.

Ici : ASCII versus UTF-8
Mais j'avoue avoir lu en diagonale, c'était plus pour "trouver une raison" que pour la raison en elle même au final.

bacelar a écrit:

>Pourquoi '€' et 'é' passent-ils alors qu'on a refus

Quand on fait un peu n'importe quoi avec l'encodage, le résultat, bin, c'est un peu n'importe quoi.

Le raisonnement se tient.

bacelar a écrit:

Tu la sort d'où ta documentation d'OutputDebugString ??? De la version Window95 Win32s de MSDN ???

Pas loin !

bacelar a écrit:

>récupérée et interprétée en utilisant tel schéma de decoding défini par le type

C'est pour ça que tu cherches à lire le contenu d'un champs d'un objet de type "référence" (System::string est un type référence) comme un char*. T'as pas l'impression d'avoir changé de type et donc le modèle d'interprétation du contenu de la mémoire entre les 2 étapes ???

Utilises le débogueur et la représentation hexadécimale avant de faire des conclusions bien trop hâtives.

C'est justement là que je commence à m'embrouiller l'esprit. En revenant au type d'origine avec la même valeur et le même système donc la même mécanique d'interprétation dont parle également koala, ça devrait donner le même rendu.

Autrement dit, si je ne touche pas à ma donnée côté C++, et que je retourne côté C#, j'aurais la même série de bits, et le modèle d'interprétation d'origine.

Le problème viens donc au moment où je crypte une donnée qui es mal interprétée. Enfin encore une conclusion sur le tas, je vais devoir vérifier ça mais si j'ai bien compris, en théorie, c'est le cas.

-
Edité par Sillimon 22 août 2018 à 14:45:43

>Se retaper toute la logique en C++/CLI était en projet mais ça a été repoussé suite à des priorités autres !

Si le code n'est pas trop pourri de base et qu'il compile sous MSVC, le passage en C++/CLI, c'est juste changer quelques paramètres.

C++/CLI n'existait pas il y a 15 ans, mais il est prévus pour avoir une bonne compatibilité avec du code 100% natif.

C'est, je pense, une grosse boulette d'avoir retardé cette migration qui vous fait perdre bien du temps maintenant, dans du code casse-gueule.

>Une String récupérée via TextEdit.Text .

Ok, c'est donc une string .NET (UTF-16), mais attention au fait que le contrôle affiche une interprétation de cette chaine (police utilisée, culture du thread d'affichage (pour les caractères à sémantique comme les chiffer etc..), etc..). La localisation de l'OS joue sur la configuration du clavier, qui va donc jouer sur l'interprétation des touche en caractères, puis le contrôle peut aussi avoir des mécanisme de translation touche clavier -> caractère, etc...

>Ici : ASCII versus UTF-8

La seul vrai raison : "To support legacy stuff..." (et celles qui expliquent les salles bidouilles des temps anciens qui ne fonction qu'avec des ASCII en entré).

Les autres, c'est juste des justifications de cas qui ne devraient jamais arrivés si on utilise correctement les outils (le coup de la recherche dans un base de données sans même prendre en compte la "collation" du server, de la base, de la table, c'est du grand nimpornawak).

Ne cherchez pas à comprendre le layout et le management mémoire d'un objet .NET, vous allez y perdre votre santé mentale, et très rapidement. Il n'y a pas de pointeurs directes sur ces objets, ils sont tous gérés via des handle pour pouvoir les déplacer librement en mémoire lors des garbage-collection. Ils utilisent un layout extrêmement complexe pour implémenté la reflexion, etc... Et cerise sur le gâteau, "string" c'est le type le plus atypique de tous avec les notions "d'internation" pour faire en sorte que le "==" fonction sur la valeur et pas sur l'objet. etc...

C++/CLI est ton ami, ou au moins le "pinnage" d'objet .NET et le marshalling .NET, sinon, t'es mort !!!

>j'aurais la même série de bits, et le modèle d'interprétation d'origine.

Si vous n'utilisez pas les attribut .NET de marshalling, vous avez quasiment systématiquement des mécanismes de clonage des paramètres en entré et des résultats en sortie. Donc, l'objet (donc l'adresse de l'objet) d'un coté n'a pas grand-chose à voir, même rien. Comme ces clonages utilisent les métadonnées pour faire les conversions, si elles sont fausse, le clonage fera n'importe quoi.

>Le problème viens donc au moment où je crypte une donnée qui es mal interprétée.

Non, c'est que vous faite une idée complètement fausse de comment fonctionne .NET et les mécanismes de marshalling.

Si vous ne les utilisez pas correctement, vous n'arriverez à rien.

Montrez le vieux code fonctionnel (C++ et C#) d'il y a 15ans, et le code (C++ et C#) de ce que vous essayez de faire.

bacelar a écrit:

>Se retaper toute la logique en C++/CLI était en projet mais ça a été repoussé suite à des priorités autres !

Si le code n'est pas trop pourri de base et qu'il compile sous MSVC, le passage en C++/CLI, c'est juste changer quelques paramètres.

Ouip. Mais on a eu quelques problèmes d'undefined behavior. L'appel au C++ se faisait bien mais pas moyen qu'il retourne au C#. Comme si il perdait le handle GetProcAdress de la fonction et qu'il se retrouvait coincé en C++. Du moins c'est ce qu'on soupçonne.
je viens de tomber là-dessus, je me suis pas encore penché plus dessus mais si ma première impression est bonne, je me demande si ça résoudrai pas le problème.

bacelar a écrit:

>Une String récupérée via TextEdit.Text.

Ok, c'est donc une string .NET (UTF-16), mais attention au fait que le contrôle affiche une interprétation de cette chaine (police utilisée, culture du thread d'affichage (pour les caractères à sémantique comme les chiffer etc..), etc..). La localisation de l'OS joue sur la configuration du clavier, qui va donc jouer sur l'interprétation des touche en caractères, puis le contrôle peut aussi avoir des mécanisme de translation touche clavier -> caractère, etc...

C'est un peu ce que je suspectais, notamment pour l'espace random que j'avais au début. Mais c'est le genre de choses assez chiantes à tester...

bacelar a écrit:

Ne cherchez pas à comprendre le layout et le management mémoire d'un objet .NET, vous allez y perdre votre santé mentale, et très rapidement. Il n'y a pas de pointeurs directes sur ces objets, ils sont tous gérés via des handle pour pouvoir les déplacer librement en mémoire lors des garbage-collection. Ils utilisent un layout extrêmement complexe pour implémenté la reflexion, etc... Et cerise sur le gâteau, "string" c'est le type le plus atypique de tous avec les notions "d'internation" pour faire en sorte que le "==" fonction sur la valeur et pas sur l'objet. etc...

C++/CLI est ton ami, ou au moins le "pinnage" d'objet .NET et le marshalling .NET, sinon, t'es mort !!!

Si ça peut me permettre de mieux comprendre tout ce qui se passe en coulisse, je veux bien perdre ma santé mentale plus tôt que prévu  !

J'ai changé le paramètre [*in] de ma fonction C++ en wchar_t pour supporter le multibytes (n'ayant, de base, aucun problème avec tout les caractères Latin-1).

Le debugger me retournait une erreur 'Error reading character of String - unable to read memory' sur le paramètre [*in] C++. Erreur qui a disparut après Marshal de ma String C# en LPWStr.

LPWStr : The LPWSTR type is a 32-bit pointer to a string of 16-bit Unicode characters, which MAY be null-terminated.

Ici, plus question de clonage donc. On a un pointer sur la String C#, String qui est donc automatiquement "pinned" comme "non-garbage-collectorable" ?

Tandis que sans le Marshaling, on avait clonage d'une String déjà garbage-collected peut-être ? D'où l'erreur ?

bacelar a écrit:

>Le problème viens donc au moment où je crypte une donnée qui es mal interprétée.

Non, c'est que vous faite une idée complètement fausse de comment fonctionne .NET et les mécanismes de marshalling.

Si vous ne les utilisez pas correctement, vous n'arriverez à rien.

Montrez le vieux code fonctionnel (C++ et C#) d'il y a 15ans, et le code (C++ et C#) de ce que vous essayez de faire.

 Pour le moment, il n'y a pas vraiment de nouveau code. Je bidouille un peu sur l'ancien (que je ne peux hélàs pas montrer) et j'essaye de comprendre pleinement ce qui se passe. Pour savoir (et comprendre) ce que je dois faire.

Après, si je devais faire un petit sum-up de ce que j'ai bidouillé jusqu'ici :

Côté C#

public const string C++_DLL = "C++.dll";
[DllImport(C++_DLL)]
private static extern bool DoSomething([MarshalAs(UnmanagedType.LPWStr)] string inParam, [MarshalAs(UnmanagedType.OnVerraAvecQuoiJeVaisTravaillerEnC++)]StringBuilder outParam);

//Main
string userEntry = weirdChineseCharTextEdit.Text; //Ou pour le test string userEntry = "\u7684  -  \u20000";
StringBuilder sb = new StringBuilder(1024);
if(DoSomething(pwd, sb))
    //OK

Côté C++

BOOL DoSomething(const wchar_t *inParam, char *outParam){}

>Comme si il perdait le handle GetProcAdress

Ouais, les ordinateurs ne sont pas réputés pour être atteint d'Alzheimer précoce. Je dirais plus que cela a révélé des bugs latents. Si vous avez encore des "GetProcAdress" dans votre code, c'est qu'il date de bien plus de 15 ans votre code (ou celui qui l'a écrit n'était pas très à jour techniquement).

>Du moins c'est ce qu'on soupçonne.

Vous disposez du code source C++, vous pouvez disposer du code source du Framework .NET, je comprends pas pourquoi vous "soupçonner" plutôt que vérifier.

>je viens de tomber là-dessus,

Pas de "magic bullet", ça fait ce qui est dit, rien de plus : Passer l'handle d'un objet, pas l'adresse d'un objet, et seul du code managé peut ce servir de ce handle.

>je veux bien perdre ma santé mentale plus tôt que prévu  !

Comme c'est des choses qui ne sont pas documentés et qu'elles sont susceptible de changer entre les implémentations, vous perdrez votre santé mentale pour pas grand-chose d'utile. Lisez et comprenez la documentation.

Je vous conseille très très chaudement, quitte à passer pas mal de temps, d'utiliser C++/CLI.

En utilisant le C (pas vraiment le C++ car on doit avoir le mangling C), vous allez vous prendre la tête.

En nous donnant les signatures C, on n'a aucune idée du type d'utilisation précise des paramètres (ownership, constness, sauvegarde du pointeur dans un coin sombre, etc...)

>une erreur 'Error reading character of String - unable to read memory'

Preuve, s'il en était encore nécessaire que le marshalling fait les copies qui sont nécessaire au passage d'un contexte à l'autre.

>Ici, plus question de clonage donc.

Why, il fait ce qu'il veut le marshalleur, s'il veut cloner ou pinner la mémoire ou unboxer l'objet ou plein d'autres trucs, c'est ses oignons, pas les tient.

>On a un pointer sur la String C#

Non, on a un pointeur (32bit ?, bizarre pas 64 bits sur les machines 64 bits ?) sur une chaine de caractères Unicode (une copie du contenu de l'objet au moment de l'appel ; ou de la mémoire pinnée si l'implémentation de la classe string du Framework courant est le même que celui du C (pas du C++) ; le "reste déshydraté" d'un objet unboxé ; ou etc... )

>String qui est donc automatiquement "pinned" comme "non-garbage-collectorable" ?

Conclusion bien trop hâtive, sans aucune preuve, et qui doit être éminemment variable en fonction de l'implémentation du Framework (différentes versions, différentes plateformes, différents paramétrage du Framework, etc...)

>on avait clonage d'une String déjà garbage-collected peut-être ? D'où l'erreur ?

S'il y avait clonage, il n'y aurait pas d'erreurs d'accès en mémoire. Il faudrait faire SYSTÉMATIQUEMENT un clonage pour éviter les erreurs. (Mais c'est très con, vu que le Marshaling est ton ami)

Il y a de grosse chance que le code existant est dépendant de réglages très spécifiques pour qu'il tombe en marche sur une implémentation particulière du Framework .NET.

Que vous utilisez du C (API), ou du C++/CLI, vous devez correctement configurer le marshaling .NET pour qu'il corresponde à la sémantique de l'API appelée.

Je prend note de tout ça !

bacelar a écrit:

Je vous conseille très très chaudement, quitte à passer pas mal de temps, d'utiliser C++/CLI.

En utilisant le C (pas vraiment le C++ car on doit avoir le mangling C), vous allez vous prendre la tête.

 Effectivement, je perd beaucoup de temps sur des choses qui ne devraient pas poser problème...

Je reviendrai (si problème, toujours il y a) lorsque j'aurais appliqué ton conseil et "dépoussiéré" un peu.
Bien que j'ai pu m'en sortir avec le marshalling, je rencontre des problèmes un peu partout et ça commence à me prendre sérieusement la tête.

Merci beaucoup pour vos explications et votre temps passé à m'éclairer !

-
Edité par Sillimon 27 août 2018 à 15:43:38