Come convertire un carattere Unicode nel suo equivalente ASCII

Ecco il problema:

In C # sto ricevendo informazioni da un database ACCESS legacy. .NET converte il contenuto del database (nel caso di questo problema una stringa) in Unicode prima di consegnarmi il contenuto.

Come posso convertire questa stringa Unicode al suo equivalente ASCII?


modificare
Unicode char 710 è infatti MODIFIER LETTER CIRCUMFLEX ACCENT. Ecco il problema un po ‘più preciso:

  -> (Esteso) Il carattere ASCII ê (ASCII esteso 136) è stato inserito nel database.
  -> Accesso o il componente di lettura in. NET convertito in U + 02C6 U + 0065
     (MODIFICA LETTERA CIRCUMFLEX ACCENT + LATINA PICCOLA LETTERA E)
  -> Ho bisogno del carattere ASCII (Esteso) 136 indietro.

Ecco cosa ho provato (vedo ora perché questo non ha funzionato …):

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

Ma questo non risulta in 94 ma un byte con valore 63 …
Ecco una nuova prova ma ancora non funziona:

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

Soltution
Grazie a csgero e bzlm per aver indicato nella giusta direzione ho risolto il problema qui .

Ok, procediamo. Sia csgero che bzlm puntavano nella giusta direzione.

A causa della risposta di blzm, ho cercato la pagina Windows-1252 su wiki e ho scoperto che si chiama codepage. L’articolo di Wikipedia per la pagina Codice che ha dichiarato quanto segue:

Non esistevano standard formali per questi ” set di caratteri estesi “; IBM si riferiva semplicemente alle varianti come pagine di codice, come aveva sempre fatto per le varianti delle codifiche EBCDIC.

Questo mi ha portato a codepage 437:

n Code di codici compatibili con ASCII, i 128 caratteri inferiori mantenevano i loro valori US-ASCII standard e pagine superiori (o gruppi di caratteri) potevano essere rese disponibili nei 128 caratteri superiori. I computer DOS costruiti per il mercato nordamericano, ad esempio, utilizzavano la code page 437 , che includeva caratteri accentati necessari per il francese, il tedesco e alcune altre lingue europee, nonché alcuni caratteri grafici di disegno a linee.

Quindi, la codepage 437 era la codepage che stavo definendo “ASCII esteso”, aveva la ê come carattere 136, quindi ho cercato anche altri caratteri e sembrano giusti.

csgero è venuto con il suggerimento Encoding.GetEncoding (), l’ho usato per creare la seguente dichiarazione che risolve il mio problema:

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

Non è ansible utilizzare la codifica ASCII predefinita (Encoding.ASCII) qui, ma è necessario creare la codifica con la code page appropriata utilizzando Encoding.GetEncoding (…). Potresti provare a utilizzare la code page 1252, che è un superset di ISO 8859-1.

ASCII non definisce ê; il numero 136 viene dal numero per il circonflesso nelle codifiche a 8 bit come Windows-1252.

Puoi verificare che una piccola e con un circonflesso (ê) sia effettivamente ciò che si suppone debba essere archiviato nel database di Access in questo caso? Forse U + 02C6 U + 0065 è il risultato di un errore di conversione, in cui l’input è in realtà una e seguita da un circonflesso, o qualcos’altro interamente. Forse il tuo database Access ha dati corrotti, nel senso che la codifica designata non corrisponde al contenuto, nel qual caso il client .NET potrebbe analizzare in modo errato i dati (usando il decodificatore sbagliato).

Se questo errore viene effettivamente introdotto durante la lettura dal database, potrebbe essere utile incollare un po ‘di codice o le impostazioni di configurazione.

Nella pagina di codice 437 , il carattere numero 136 è una e con un accento circonflesso.

Hmm … Non sono sicuro di quale personaggio intendi. Il segno di omissione (“^”, CIRCUMFLEX ACCENT) ha lo stesso codice in ASCII e Unicode (U + 005E).

/ EDIT: Accidenti, colpa mia. 710 (U + 02C6) è in realtà il MODIFIER LETTER CIRCUMFLEX ACCENT. Sfortunatamente, questo personaggio non fa parte di ASCII. Potrebbe sembrare il normale segno di omissione, ma è un personaggio diverso. La conversione semplice non aiuterà qui. Non sono sicuro che .NET supporti la mapping di caratteri simili durante la conversione da Unicode. Vale la pena indagare, comunque.

Il valore 63 è il punto interrogativo, AKA “Non sono in grado di visualizzare questo carattere in ASCII”.