Question

Voici le problème:

En C #, je récupère les informations d’une base de données ACCESS héritée. .NET convertit le contenu de la base de données (dans le cas de ce problème une chaîne) en Unicode avant de me le remettre.

Comment reconvertir cette chaîne Unicode en son équivalent ASCII?


Modifier
Unicode char 710 est en effet MODIFIER LETTER CIRCUMFLEX ACCENT. Voici le problème un peu plus précis:

 -> (Extended) ASCII character ê (Extended ASCII 136) was inserted in the database.
 -> Either Access or the reading component in .NET converted this to U+02C6 U+0065
    (MODIFIER LETTER CIRCUMFLEX ACCENT + LATIN SMALL LETTER E)
 -> I need the (Extended) ASCII character 136 back.


Voici ce que j'ai essayé (je vois maintenant pourquoi cela n'a pas fonctionné ...):

string myInput = Convert.ToString(Convert.ToChar(710));
byte[] asBytes = Encoding.ASCII.GetBytes(myInput);

Mais cela ne donne pas 94 mais un octet de valeur 63 ...
Voici un nouvel essai mais cela ne fonctionne toujours pas:

byte[] bytes = Encoding.ASCII.GetBytes("ê");


Solution
Merci à la fois csgero et bzlm pour le pointage dans la bonne direction, j'ai résolu le problème ici .

Était-ce utile?

La solution

D'accord, élaborons. Les deux csgero et < a href = "https://stackoverflow.com/questions/138449/how-to-convert-a-unicode-character-to-its-extended-ascii-equivalent#138583"> bzlm pointé dans la droite direction.

À cause de la réponse de blzm, j'ai consulté la page Windows-1252 sur le wiki et découvert qu'il s'agissait d'une page de codes. L'article de Wikipédia pour la page de code qui indiquait ce qui suit:

  

Il n’existait aucune norme officielle pour ces jeux de caractères étendus '; IBM a simplement qualifié les variantes de "pages de code", comme il l'avait toujours fait pour les variantes de codages EBCDIC.

Cela m'a conduit à la page de code 437:

  

n Les pages de codes compatibles ASCII, les 128 caractères inférieurs conservent leurs valeurs standard US-ASCII et différentes pages (ou ensembles de caractères) peuvent être rendus disponibles pour les 128 caractères supérieurs. Les ordinateurs DOS conçus pour le marché nord-américain, par exemple, utilisaient la page de code 437 , qui incluait caractères requis pour le français, l'allemand et quelques autres langues européennes, ainsi que des caractères graphiques de dessin au trait.

Ainsi, la page de code 437 était la page de code que j’appelais «ASCII étendu», elle avait le caractère ê comme caractère 136;

csgero est venu avec l'indicateur Encoding.GetEncoding (), je l'ai utilisé pour créer l'instruction suivante qui résout mon problème:

byte[] bytes = Encoding.GetEncoding(437).GetBytes("ê");

Autres conseils

Vous ne pouvez pas utiliser le codage ASCII par défaut (Encoding.ASCII) ici, mais vous devez créer le codage avec la page de code appropriée à l'aide de Encoding.GetEncoding (...). Vous pouvez essayer d’utiliser la page de codes 1252, qui est un sur-ensemble de la norme ISO 8859-1.

ASCII ne définit pas & # 234 ;; le nombre 136 provient du numéro de la circonflexe codé en 8 bits, tel que Windows-1252.

Pouvez-vous vérifier qu'un petit e avec un circonflexe (& # 234;) est bien ce qui est censé être stocké dans la base de données Access dans ce cas? Peut-être que U + 02C6 U + 0065 est le résultat d’une erreur de conversion, où l’entrée est en fait un e suivi de un circumflexe ou autre chose. Peut-être que votre base de données Access contient des données corrompues en ce sens que le codage désigné ne correspond pas au contenu. Dans ce cas, le client .NET pourrait analyser de manière incorrecte les données (en utilisant le mauvais décodeur).

Si cette erreur est effectivement introduite lors de la lecture de la base de données, peut-être que coller du code ou des paramètres de configuration pourrait vous aider.

Dans la page de code 437 , le caractère numéro 136 est un e avec un circumflexe.

Hmm & nbsp;… Je ne suis pas sûr du personnage que vous voulez dire. Le caret (“^”, ACCENT CIRCUMFLEX) a le même code en ASCII et Unicode (U + 005E).

/ EDIT: Merde, de ma faute. 710 (U + 02C6) est en réalité la lettre d’accent circulaire du modificateur. Malheureusement, ce personnage ne fait pas du tout partie de l'ASCII. Cela peut ressembler au signe normal, mais c'est un personnage différent. La conversion simple ne va pas aider ici. Je ne sais pas si .NET prend en charge le mappage de caractères similaires lors de la conversion à partir d'Unicode. Cela vaut la peine d’enquêter, cependant.

La valeur 63 est le point d'interrogation, AKA "Je ne peux pas afficher ce caractère en ASCII".

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top