c# - studio - Cómo convertir un carácter Unicode a su equivalente ASCII
visual studio code acentos (5)
Aquí está el problema:
En C # obtengo información de una base de datos ACCESS heredada. .NET convierte el contenido de la base de datos (en el caso de este problema, una cadena) en Unicode antes de entregarme el contenido.
¿Cómo convierto esta cadena Unicode a su equivalente ASCII?
EditarUnicode char 710 es de hecho MODIFICADOR DE LA LETRA CIRCUMFLEX ACCENT. Aquí está el problema un poco más 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. Esto es lo que he intentado (ahora veo por qué esto no funcionó ...):
string myInput = Convert.ToString(Convert.ToChar(710));
byte[] asBytes = Encoding.ASCII.GetBytes(myInput);
Pero esto no da como resultado 94 sino un byte con valor 63 ...
Aquí hay una nueva prueba, pero todavía no funciona:
byte[] bytes = Encoding.ASCII.GetBytes("ê"); Soltura
Gracias a ambos csgero y bzlm por apuntar en la dirección correcta resolví el problema aquí .
ASCII no define ê; el número 136 proviene del número para el circunflejo en codificaciones de 8 bits como Windows-1252.
¿Puedes verificar que una pequeña e con un circunflejo (ê) es en realidad lo que se supone que debe almacenarse en la base de datos de Access en este caso? Quizás U + 02C6 U + 0065 es el resultado de un error de conversión, donde la entrada es en realidad una e seguida de un circunflejo, o algo completamente diferente. Quizás su base de datos de Access tenga datos corruptos en el sentido de que la codificación designada no coincide con el contenido, en cuyo caso el cliente .NET podría analizar los datos incorrectamente (utilizando el decodificador incorrecto).
Si este error se introduce efectivamente durante la lectura de la base de datos, quizás pegarle a algún código o configuración puede ser útil.
En la página de códigos 437 , el número de carácter 136 es una e con un circunflejo.
El valor 63 es el signo de interrogación, AKA "No puedo mostrar este carácter en ASCII".
Hmm ... No estoy seguro de a qué personaje te refieres. El símbolo de intercalación ("^", CIRCUMFLEX ACCENT) tiene el mismo código en ASCII y Unicode (U + 005E).
/ EDITAR: Maldita sea, mi culpa. 710 (U + 02C6) es en realidad la LETRA MODIFICADORA CIRCUMFLEX ACCENT. Desafortunadamente, este personaje no es parte de ASCII en absoluto. Puede parecer el símbolo normal pero es un personaje diferente. La conversión simple no ayudará aquí. No estoy seguro de si .NET admite el mapeo de caracteres similares al convertir desde Unicode. Vale la pena investigar, sin embargo.
No puede usar la codificación ASCII predeterminada (Encoding.ASCII) aquí, pero debe crear la codificación con la página de códigos apropiada utilizando Encoding.GetEncoding (...). Puede intentar usar la página de códigos 1252, que es un superconjunto de ISO 8859-1.
De acuerdo, vamos a elaborar. Tanto csgero como bzlm apuntaban en la dirección correcta.
Debido a la respuesta de blzm busqué la página de Windows-1252 en la wiki y descubrí que se llama una página de códigos. El artículo de wikipedia para la página de códigos que indica lo siguiente:
No existe un estándar formal para estos '' conjuntos de caracteres extendidos ''; IBM simplemente se refirió a las variantes como páginas de códigos, como siempre lo había hecho para variantes de codificaciones EBCDIC.
Esto me llevó a la página de códigos 437:
n Páginas de códigos compatibles con ASCII, los 128 caracteres inferiores mantuvieron sus valores estándar de US-ASCII, y diferentes páginas (o conjuntos de caracteres) podrían estar disponibles en los 128 caracteres superiores. Las computadoras DOS construidas para el mercado norteamericano, por ejemplo, usaban la página de códigos 437 , que incluía caracteres acentuados necesarios para el francés, el alemán y algunos otros idiomas europeos, así como algunos caracteres gráficos de trazado de líneas.
Entonces, la página de códigos 437 era la página de códigos a la que llamaba ''extendido ASCII'', tenía el carácter ê como 136, así que busqué otros caracteres y parecían correctos.
csgero vino con la sugerencia Encoding.GetEncoding (), lo usé para crear la siguiente declaración que resuelve mi problema:
byte[] bytes = Encoding.GetEncoding(437).GetBytes("ê");