Como converter um caractere Unicode em seu equivalente ASCII

Aqui está o problema:

Em c # eu estou recebendo informações de um database ACCESS herdado. O .NET converte o conteúdo do database (no caso deste problema, uma string) para Unicode antes de entregar o conteúdo para mim.

Como faço para converter essa string Unicode de volta para seu equivalente em ASCII?


Editar
Unicode char 710 é de fato MODIFIER LETTER CIRCUMFLEX ACCENT. Aqui está o problema um pouco mais preciso:

  -> Caractere ASCII (estendido) ê (Extended ASCII 136) foi inserido no database.
  -> O Access ou o componente de leitura no .NET converteu isso para U + 02C6 U + 0065
     (LETRA DE MODIFICADOR CIRCUMFLEX ACCENT + LETRA PEQUENA E)
  -> Eu preciso do caractere ASCII (estendido) 136 de volta.


Aqui está o que eu tentei (vejo agora porque isso não funcionou …):

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

Mas isso não resulta em 94, mas um byte com valor 63 …
Aqui está uma nova tentativa, mas ainda não funciona:

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


Solução
Graças ao csgero e bzlm por apontar na direção certa, resolvi o problema aqui .

Ok, vamos elaborar. Ambos csgero e bzlm apontaram na direção certa.

Por causa da resposta do blzm, procurei a página do Windows-1252 no wiki e descobri que ela é chamada de página de códigos. O artigo da wikipedia para a página de códigos, que afirmava o seguinte:

Nenhum padrão formal existia para esses ‘ conjuntos de caracteres estendidos ‘; A IBM limitou-se a referir-se às variantes como páginas de código, como sempre fizera para variantes de codificações EBCDIC.

Isso me levou à página de códigos 437:

n páginas de código compatíveis com ASCII, os 128 caracteres inferiores mantiveram seus valores US-ASCII padrão e páginas diferentes (ou conjuntos de caracteres) poderiam ser disponibilizadas nos 128 caracteres superiores. Os computadores DOS criados para o mercado norte-americano, por exemplo, usavam a página de código 437 , que incluía caracteres acentuados necessários para francês, alemão e alguns outros idiomas europeus, bem como alguns caracteres charts de desenho de linhas.

Então, a página de códigos 437 era a página de códigos que eu estava chamando de ‘extended ASCII’, tinha o ê como caracter 136, então eu procurei alguns outros caracteres também e eles parecem corretos.

csgero veio com a dica Encoding.GetEncoding (), eu usei para criar a seguinte declaração que resolve o meu problema:

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

Você não pode usar a codificação ASCII padrão (Encoding.ASCII) aqui, mas deve criar a codificação com a página de código apropriada usando Encoding.GetEncoding (…). Você pode tentar usar a página de código 1252, que é um superconjunto da ISO 8859-1.

ASCII não define ê; o número 136 vem do número do circunflexo em codificações de 8 bits, como o Windows-1252.

Você pode verificar que um pequeno e com um circunflexo ()) é, na verdade, o que deve ser armazenado no database do Access, neste caso? Talvez U + 02C6 U + 0065 seja o resultado de um erro de conversão, em que a input é na verdade uma e seguida por um circunflexo, ou algo totalmente diferente. Talvez o database do Access tenha dados corrompidos no sentido de que a codificação designada não corresponde ao conteúdo; nesse caso, o cliente .NET pode analisar incorretamente os dados (usando o decodificador incorreto).

Se esse erro for realmente introduzido durante a leitura do database, talvez a colagem de algumas configurações de código ou configuração possa ajudar.

Na página de código 437 , o número de caractere 136 é um e com um circunflexo.

Hmm… não tenho certeza de qual personagem você quer dizer. O cursor (“^”, CIRCUMFLEX ACCENT) possui o mesmo código em ASCII e Unicode (U + 005E).

/ EDIT: Porra, minha culpa. 710 (U + 02C6) é, na verdade, o ACENTUADOR DE CARTA MODIFICADA CIRCUMFLEX. Infelizmente, esse personagem não faz parte do ASCII. Pode parecer o cursor normal, mas é um personagem diferente. Conversão simples não ajudará aqui. Não tenho certeza se o .NET suporta o mapeamento de caracteres semelhantes ao converter do Unicode. Vale a pena investigar, no entanto.

O valor 63 é o ponto de interrogação, AKA “Não consigo exibir este caractere em ASCII”.