Как преобразовать символ Unicode в его эквивалент ASCII

Здесь проблема:

В С# я получаю информацию из старой базы данных ACCESS..NET преобразует содержимое базы данных (в случае этой проблемы в строку) в Юникод перед передачей содержимого мне.

Как мне преобразовать эту строку Unicode обратно в эквивалент ASCII?

Edit
Unicode char 710 - это действительно ДОПОЛНИТЕЛЬНОЕ ПИСЬМО CIRCUMFLEX ACCENT. Здесь проблема немного точнее:

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

Вот что я пробовал (теперь я вижу, почему это не сработало...):

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

Но это не приводит к 94, а к байту со значением 63...
Здесь новая попытка, но она по-прежнему не работает:

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

Soltution
Благодаря csgero и bzlm для указания в правильном направлении я решил проблему .

Ответ 1

Хорошо, дайте понять. Оба csgero и bzlm указали в правильном направлении.

Из-за ответа blzm я просмотрел страницу Windows-1252 на wiki и обнаружил, что она называется кодовой страницей. Статья в wikipedia для Страница кода, в которой указано следующее:

Никаких формальных стандартов для этих расширенных наборов символов; IBM просто ссылалась на варианты в виде кодовых страниц, как это всегда делалось для вариантов кодировок EBCDIC.

Это привело меня кодовую страницу 437:

n кодовых страниц, совместимых с ASCII, нижние 128 символов сохраняли свои стандартные значения US-ASCII, а различные страницы (или наборы символов) могли быть доступны в верхних 128 символах. Например, компьютеры DOS, построенные для североамериканского рынка, использовали кодовую страницу 437, которая включала акцентированные символы, необходимые для французского, немецкого и нескольких другие европейские языки, а также некоторые графические символы рисования линий.

Итак, кодовая страница 437 была кодовой страницей, которую я называл "расширенным ASCII", у нее был символ ê как символ 136, поэтому я тоже искал некоторые другие символы, и они кажутся правильными.

csgero пришел с подсказкой Encoding.GetEncoding(), я использовал его для создания следующего утверждения, которое решает мою проблему:

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

Ответ 2

Здесь вы не можете использовать кодировку ASCII по умолчанию (Encoding.ASCII), но должны создать кодировку с соответствующей кодовой страницей с помощью Encoding.GetEncoding(...). Вы можете попытаться использовать кодовую страницу 1252, которая является надмножеством стандарта ISO 8859-1.

Ответ 3

ASCII не определяет ê; число 136 исходит от числа для обводки в 8-битных кодировках, таких как Windows-1252.

Можете ли вы проверить, что маленький e с circumflex (ê) на самом деле является тем, что предполагается хранить в базе данных Access в этом случае? Возможно, U + 02C6 U + 0065 является результатом ошибки преобразования, где входной сигнал фактически является e, за которым следует округло, или что-то еще. Возможно, ваша база данных Access имеет поврежденные данные в том смысле, что назначенная кодировка не соответствует содержимому, и в этом случае клиент .NET может неправильно анализировать данные (используя неправильный декодер).

Если эта ошибка действительно введена во время чтения из базы данных, возможно, это поможет скопировать некоторые параметры кода или конфигурации.

В Страница кодовой страницы 437 номер символа 136 является e с огибающей.

Ответ 4

Хм... Я не уверен, какого персонажа ты имеешь в виду. Карет ( "^", CIRCUMFLEX ACCENT) имеет тот же код в ASCII и Unicode (U + 005E).

/EDIT: Черт, моя вина. 710 (U + 02C6) на самом деле является МОДИФИЦИРОВАННЫМ ПИСЬЕМ CIRCUMFLEX ACCENT. К сожалению, этот персонаж вообще не является частью ASCII. Это может выглядеть как обычный карет, но это другой персонаж. Простое преобразование здесь не поможет. Я не уверен, поддерживает ли .NET отображение похожих символов при конвертации из Unicode. Однако стоит исследовать.

Ответ 5

Значение 63 - знак вопроса, AKA "Я не могу отобразить этот символ в ASCII".