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

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

12 голосов
/ 26 сентября 2008

Вот проблема:

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

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

Редактировать
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 за указание в правильном направлении я решил проблему здесь .

Ответы [ 5 ]

9 голосов
/ 27 сентября 2008

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

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

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

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

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

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

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

byte[] bytes = Encoding.GetEncoding(437).GetBytes("ê");
3 голосов
/ 26 сентября 2008

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

2 голосов
/ 26 сентября 2008

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

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

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

В Кодовая страница 437 , символ с номером 136 является символом с обведением.

0 голосов
/ 26 сентября 2008

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

0 голосов
/ 26 сентября 2008

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

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

...