Sous le capot de GetEncodingData() ?

Bonjour à tous.

J'ai remarqué que Encoding.GetEncoding(string) ne fonctionne pas si on l'appelle avec "cp1252".
Je ne suis pas du tout expert en la matière mais il semble que "cp1252" soit un alias pas mal répandu pour "windows-1252".

En essayant de comprendre le fonctionnement de cette méthode (Reflector mon ami...), je suis tombé sur la fonction :

Code:

---

1 2	[MethodImpl(MethodImplOptions.InternalCall)] private static extern unsafe InternalEncodingDataItem* GetEncodingData();

---

J'avais espoir que celle-ci utilise la base de registre mais l'ajout de la clé :

Code:

---

1 2	[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MIME\Database\Charset\cp1252] "AliasForCharset"="windows-1252"

---

ne change rien...

Savez vous s'il est possible de savoir comment fonctionne GetEncodingData ? Ou mieux, savez-vous comment fonction GetEncodingData ? :P

Merci,

bon ben je crois qu'il va falloir que je me débrouille autrement...

Pour GetEncodingData, aucune idée... Visiblement c'est une méthode interne du framework implémentée en code natif, donc pas moyen de voir ce qu'elle fait.

A priori "cp1252" signifie "CodePage 1252"... et justement, une des surcharges de GetEncoding prend en paramètre un numéro de codepage, donc il suffit de faire ça :

Code:

---

Encoding.GetEncoding(1252);

---

Sinon, j'ai pas l'impression que l'info vienne de la base de registre... en surveillant les accès avec Process Monitor, j'ai rien vu passer qui semble concerner l'encodage

En fait, je ne suis pas maître du code.

Nous utilisons pour recevoir/traiter des e-mails "Power TCP Mail" de Dart. Nous sommes tombé sur le cas d'un mail qui fait exploser le composant. Cet email utilise le charset cp1252.

C'est en décompilant leur source que j'ai compris que l'erreur remonte en fait de la méthode GetEncoding.

Dart sort une release de ce composant environ une fois l'an et je ne pense pas avoir un fix rapide de la part de Microsoft.... Je m'étais donc dit qu'en comprenant le fonction de GetEncodingData je pourrais peut être m'en sortir car j'ai du mal à croire qu'ils aient "hardcodé" la liste des charsets. Cela dit, pour des pbs de perfs c'est pas impossible...

Citation:

---

Envoyé par Tetranos

j'ai du mal à croire qu'ils aient "hardcodé" la liste des charsets

---

Effectivement ce serait étonnant... et si c'était le cas, je vois pas pourquoi ils auraient besoin de le faire en code non managé.

Essaie de poster sur les forums MSDN, y a souvent des gens de MS qui répondent, donc tu auras sans doute plus de chances de trouver une solution

Si j'ai bien compris le sens de l'attribut "MethodImplOptions.InternalCall", ce n'est pas du code non managé, mais du code IL...enfin pas sûr.

En tout cas merci pour les conseils, je vais tenter ma chance sur les forums MSDN.

Citation:

---

Envoyé par Tetranos

Si j'ai bien compris le sens de l'attribut "MethodImplOptions.InternalCall", ce n'est pas du code non managé, mais du code IL...enfin pas sûr.

---

Voilà ce que dit la doc sur InternalCall :

Citation:

---

Specifies an internal call. An internal call is a call to a method that is implemented within the common language runtime itself.

---

Donc en fait on sait pas trop si c'est du code managé ou non, on sait juste que c'est implémenté dans le CLR... j'ai supposé que c'était non managé parce que la méthode renvoie un pointeur sur une structure

Voilà, le sujet est lancé sur MSDN :

http://social.msdn.microsoft.com/For...9-cd71d3945961

Je vous tiens au courant...

En fait je parlais des forums MSDN en anglais... je suis pas sûr que tu obtiennes une réponse sur les forums francophones

flut :? ...bon ben je vais voir ce que ça donne sur le FR, sinon je prendrai mon harrap's et j'irai poster sur le forum EN...