Domanda

Ecco il problema:

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

Come riconvertire questa stringa Unicode al suo equivalente ASCII?


Modifica
Unicode char 710 è infatti MODIFICATORE LETTERA CIRCUMFLEX ACCENT. Ecco il problema un po 'più preciso:

 -> (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.


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 in un byte con valore 63 ...
Ecco un nuovo tentativo ma non funziona ancora:

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


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

È stato utile?

Soluzione

Va ??bene, elaboriamo. Entrambi csgero e < a href = "https://stackoverflow.com/questions/138449/how-to-convert-a-unicode-character-to-its-extended-ascii-equivalent#138583"> bzlm puntato a destra direzione.

A causa della risposta di Blzm ho cercato la pagina di Windows 1252 su wiki e ho scoperto che si chiama codepage. L'articolo di Wikipedia per pagina di codice che riportava 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 alla tabella codici 437:

  

n Pagine di codice compatibili con ASCII, i 128 caratteri inferiori hanno mantenuto i loro valori US-ASCII standard e diverse pagine (o serie di caratteri) potrebbero essere rese disponibili nei 128 caratteri superiori. I computer DOS creati per il mercato nordamericano, ad esempio, utilizzavano code page 437 , che includeva l'accento caratteri necessari per il francese, il tedesco e alcune altre lingue europee, nonché alcuni caratteri grafici per disegnare le linee.

Quindi, la codepage 437 era la codepage che stavo chiamando "ASCII estesa", aveva il 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("ê");

Altri suggerimenti

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

ASCII non definisce ê; il numero 136 deriva dal numero per il circumflex in codifiche a 8 bit come Windows-1252.

Puoi verificare che una piccola e con un circumflex (ê) sia effettivamente ciò che dovrebbe 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à un seguito da un circumflex, o qualcos'altro del tutto. Forse il tuo database di Access ha dati corrotti nel senso che la codifica designata non corrisponde ai contenuti, nel qual caso il client .NET potrebbe analizzare erroneamente i dati (usando il decodificatore sbagliato).

Se questo errore viene effettivamente introdotto durante la lettura dal database, forse potrebbe essere utile incollare alcune impostazioni di codice o di configurazione.

In pagina di codice 437 , il numero di carattere 136 è una e con una circonferenza.

Hmm & nbsp; ... Non sono sicuro di quale personaggio intendi. Il punto di inserimento ("^", CIRCUMFLEX ACCENT) ha lo stesso codice in ASCII e Unicode (U + 005E).

/ EDIT: Accidenti, colpa mia. 710 (U + 02C6) è in realtà il MODIFICATORE LETTERA CIRCUMFLEX ACCENT. Sfortunatamente, questo personaggio non fa affatto parte di ASCII. Potrebbe sembrare il normale cursore ma è un personaggio diverso. La conversione semplice non aiuta qui. Non sono sicuro che .NET supporti la mappatura di caratteri simili durante la conversione da Unicode. Vale la pena indagare, tuttavia.

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

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top