typo de compilation

Question

Bonjour,

j'ai tappé un texte en arial.

Je demande le code ascii de chaque caractère avec:

asc(texte(index)) où index vaut une position dans ma chaine de caractère.

Mais cela me renvoie le mauvais code car il (le compilateur) utilise cette chaine ascii:

9 2 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~€‚ƒ„…†‡ˆ‰Š‹ŒŽ‘’“”•–—˜™š›œžŸ ¡¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ

où le premier 9 est 'tab' et le premier 2 est 'enter'.(que j'ai remplacer ci-joint pour ne pas afficher 2 retour à la ligne)

Hors moi je veux utiliser celle ci:

☺☻♥♦♣♠•◘○◙♂♀♪♫☼►◄↕‼¶§▬↨↑↓→←∟↔▲▼!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~⌂ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜø£Ø׃áíóúñѪº¿®¬½¼¡«»░▒▓│┤ÁÂÀ©╣║╗╝¢¥┐└┴┬├─┼ãÃ╚╔╩╦╠═╬¤ðÐÊËÈıÍÎÏ┘┌█▄¦Ì▀ÓßÔÒõÕµþÞÚÛÙýݯ´­±‗¾¶§÷¸°¨·¹³²■

car concrétement quand je lui demande le code ascii de 'ë' il me renvoie : 234

alors que dans ma chaine 'ë' vaut : 135

Comment faire pour changer la typo de compilation?

Merci

Answer 1

Bonjour dialAsp,

J'ai eu exactement le même souci ! Et la solution que j'ai trouvée est de "réécrire" la fonction Asc(). Plus précisément, j'ai crée une variable globale qui est un tableau de correspondance entre les nombres et les caractères.

Je ne l'ai malheurseusement pas sous la main mais essayez quelque chose comme : Dim Ascii(,) As String = {{0, ☺}, {1,☻}, etc...}

Bon c'est relativement long à écrire...et pas très propre.

Il existe sûrement une autre solution comme l'api ToAscii() (http://msdn.microsoft.com/en-us/library/ms646316%28v=vs.85%29.aspx) dont voici la signature VB :

<DllImport("user32")> _
Public Function ToAscii( _
   ByVal uVirtKey As Integer, _
   ByVal uScanCode As Integer, _
   ByVal lpKeyState() As Byte, _
   ByVal lpChar As StringBuilder, _
   ByVal uFlags As Integer)
End Function

En important System.Runtime.InteropServices.

Par contre elle demande beaucoup de paramètres et ce n'est pas très pratique pour récupérer les valeurs sans faire un hook clavier (par exemple).

Enfin, il est sûrement possible de changer cette fonction afin qu'elle soit adaptée, mais dans ce cas si quelqu'un à une solution je suis preneur également.

Peut être en changeant la culture du programme ?

Bonne soirée.

---

N'hésitez pas à poser des questions si un problème subsiste ou quelque chose n'est pas clair. Dans l'autre cas, veuillez indiquer que le problème est résolu. Cordialement - Best Regards. Contact

Answer 2

Merci pour ce début de piste michel.

J'ai bien pensé à une fonction de remplacement mais cela implique qu'à chaque recherche de code il y aura prêt de 200 test pour trouver le bon.

A sacré paquet de cycle machine perdus et un délai inacceptable si la demande comprends de nombreux code à récupérer.

Cela aurait été si simple si la function asc() comportait un argument de + comme:

asc(caratère as char, typo as string) as integer

Answer 3

Le jeu de caractères que vous voulez utiliser ressemble à de l'ibm850

(Page de code 850, Western European DOS)

Bien que le ë y soit en position 137 et non 135 (faute de frappe ?)

Vous pouvez essayer ceci :

System.Text.Encoding.GetEncoding(850).GetBytes(chaine)

Cela retourne un tableau d'octets (un par caractère pour cet encodage).

 

---

Fred

Answer 4

Cette solution me semble très interressante :) Merci foleide.

(effectivement, faute de frappe, c'est bien 137 )

Je vais y regarder de plus prêt pour voir si je trouve les codepages correspondant aux typos que j'utilise ( http://msdn.microsoft.com/fr-fr/library/system.text.encodinginfo.codepage.aspx )

Et aussi jeter un oeil sur les temps de réponse.

il faut aussi que je teste différentes fonctions équivalentes pour trouver celle qui offre les meilleures performances.

Des trucs moches me viennent en tête comme un gros select case ou une recherche par ordre préférentiel des caractères les plus vers les moins utilisés...

En travaux...

Si d'autres solutions possibles vous viennent, n'hésitez pas à continuer de poster. Merci

Answer 5

Quel est le problème que vous cherchez à résoudre ?

 

 

---

Fred

Answer 6

c'est pour une fonction de codage/décodage.

je cherchais si il y avait moyen de créer une fonction qui optimise la recherche du code ascii.

il me faut un truc rapide.

Pour un caractère recherché:

la méthode a base de string comparatif met 37µs

La méthode a base de select case met 51 µs

et la méthode à base de codepage met 42µs

Pour une petite chaine de caractère:

la méthode a base de string comparatif met 120µs

et la méthode à base de codepage met 86µs

La codepage repasse largement devant en temps d'éxécution.

Mais plus difficile à paramétrer pour trouver la page de code à charger.

Elle a cependant l'avantage de présenter les réponse sous forme de tableau ce qui présente un avantage pour mon utilisation.

Il me reste plus qu'à trouver l'opération inverse: ascii vers caratère.

Answer 7

Vous voulez-dire que vous effectuez des opérations mathématiques sur les

codes de caractères ?

L'important dans ce cas n'est pas d'avoir un certain jeu de caractères

mais de garder le même au codage et décodage.

Les chaînes .NET sont encodées en mémoire selon le jeu de caractères

Unicode UTF-16 (deux octets).

Les encodages sont surtout utiles pour transmettre les chaînes à un flux

(fichier, réseau ...)

Dans votre cas, autant utiliser l'encodage natif tel qu'il est en

mémoire. Ce sera encore plus rapide car il n'y aura aucune opération

effectuée sur les octets.

 

Je proposerais d'utiliser :

 

tabInt16 = Encoding.Unicode.GetBytes("texte à coder")

 

Puis après manipulation des entiers 16 bits, faire l'opération inverse avec

 

texte_codé = Encoding.Unicode.GetString(tabInt16)

 

Il faut cependant faire attention que les manipulations ne génèrent pas

des codes de caractère invalides.

 

Est-ce cela dont-il s'agit ?

 

 

---

Fred

Answer 8

 

> tabInt16 = Encoding.Unicode.GetBytes("texte à coder")

 

GetBytes retourne un tableau d'octets, il vaut mieux le réceptionner

dans un tableau d'octets (et non d'int16)

 

 

---

Fred

Answer 9

c'est pour de la transmition d'information et pour éviter que des p'tits malin ne piratent les données, avant d'être trasmises les données passent dans un encodeur fait maison (je suis un peu parano et n'ai pas trop confiance dans les trucs tous faits quelque peu "connus de tous".

Ces données peuvent se présenter avec différentes polices, d'où l'importance que le code ascii soit bien reconnu.

Je n'ai plus aucun bug avec cette méthode.

Si je ne trouve pas la police dans les pages codes, je trouverais un moyen de forcer en amont la police en arial par exemple. La mise en forme importe peu, seules les données textuelles comptent. Cela dit, si il y a moyen de garder la mise en forme c'est t'autant mieux.

je receptionne la réponse comme ceci:

dim reponse() as byte=System.Text.Encoding.GetEncoding(850).GetBytes(chaine)

Ca fonctionne parfaitement. Merci encore. :)

----------------------

re-édit: oui j'effectue un brassage des données au niveau du code asciii

'bonjour' donnera par exemple : K5}:£¦p°