вручную преобразовывая между ASCII и символами.NET
Я работаю над написанием некоторого кода для вычищения ввода данных пользователем на мой сайт ASP.NET. Я должен вычистить вход для удаления всех ссылок на символы ASCII 145, 146, 147, 148, которые иногда становятся введенными от моих пользователей Mac, которые копируют и вставляют содержание, которое они пишут, одним словом, процессору на своих макинтошах.
Моей проблемой являются следующие три строки, которым я ведусь верить, должен произвести тот же текст.
string test1 = Convert.ToChar(147).ToString();
string test2 = String.Format("'{0}'", Convert.ToChar(147));
char[] characters = System.Text.Encoding.ASCII.GetChars(new byte[] { 147 });
string test3 = new string(characters);
Все же, когда я установил ASP TextBox для равенства следующему
txtShowValues.Text = test1 + "*" + test2 + "*" + test3;
Я получаю пустое значение для test1, test2 работы правильно и test3 выводы как a'?'.
Может кто-то объяснять, что происходит по-другому. Я надеюсь, что это поможет мне понять, как.NET использует значения ASCII для символов более чем 128 так, чтобы я мог записать хороший сценарий вычищения.
Править
Значения, которые я упомянул (145 - 148), являются изогнутыми кавычками. Так единственное левое, единственное право, дважды оставленное, удваивают право.
"Работами правильно" я подразумеваю, что это производит изогнутую кавычку к моему браузеру.
ВТОРОЕ РЕДАКТИРОВАНИЕ
Следующий код (упомянутый в ответе) производит изогнутые кавычки также. Таким образом, возможно, проблема использовала ASCII в тесте 3.
char[] characters2 = System.Text.Encoding.Default.GetChars(new byte[] { 147 });
string test4 = new string(characters2);
ТРЕТЬЕ РЕДАКТИРОВАНИЕ
Я нашел Mac, который я мог одолжить и смог копировать проблему. Когда я копирую и вставляю текст, который имеет символы кавычки в них из Word в мое веб-приложение на Mac, это вставляет изогнутые кавычки (147 и 148). Когда я совершил нападки, сохраняют изогнутые кавычки, сохраняются к базе данных, таким образом, я буду использовать код, Вы все помогли мне с вычистить то содержание.
РЕДАКТИРОВАНИЕ FOUTH
Потраченный на некоторое время, пишущий более код кода на основе ответов здесь и замеченный это имеет некоторое отношение к MultiLine TextBoxes в ASP.NET. Здесь была хорошая информация, таким образом, я решил только запустить новый вопрос: разрешение текстового поля ASP.NET Multiline вводится выше UTF-8
3 ответа
Символ 147 - это U + 0093 УСТАНОВИТЬ СОСТОЯНИЕ ПЕРЕДАЧИ. Как и все символы Unicode в диапазоне 0–255, он совпадает с символом ISO-8859-1 с тем же номером. ISO-8859-1 присваивает 147 этому невидимому управляющему коду.
То, о чем вы думаете, это не «ASCII» или даже «ISO-8859-1», а кодовая страница Windows 1252. Это нестандартная кодировка, которая похожа на 8859-1, но назначает символы 128–159 различным типографским расширениям, таким как умные кавычки, вместо в значительной степени бесполезных управляющих кодов. На кодовой странице 1252 символ 147 - это «, также известный как U + 201C ЛЕВЫЙ ДВОЙНОЙ МАРКЕТ.
Если вы хотите преобразовать кодовые страницы Windows (часто ошибочно известные как «ANSI») в символы Unicode, вам необходимо указать нужную кодовую страницу, например:
System.Text.Encoding.getEncoding(1252).GetChars(new byte[] { 147 })
System.Text.Encoding.Default предоставит вам кодировку по умолчанию на вашем сервере. Для сервера в западноевропейском регионе это будет 1252. В других местах этого не будет. Обычно не рекомендуется иметь зависимость от кодовой страницы локали по умолчанию в серверном приложении.
В любом случае, вы не должны получать байты вроде 147, представляющие « во входных данных веб-приложения. Это произойдет только в том случае, если сама ваша страница находится в кодировке кодовой страницы 1252 (и чтобы запутать и ввести в заблуждение еще больше, когда вы говорите, что ваша страница находится в формате ISO-8859-1, браузеры вместо этого будут молча использовать кодовую страницу 1252). Ваша страница также может быть в 1252, если вы не указали для нее какую-либо кодировку (браузер догадывается; другие языковые стандарты будут угадывать другие кодовые страницы, поэтому все будет большим беспорядком).
Убедитесь, что вы используете UTF-8 для всех кодировок в своем веб-приложении, и отметьте свои страницы как таковые . Сегодня все веб-приложения должны использовать UTF-8.
Я получаю вопросительные знаки для всех 3-х из них в консольном приложении (.NET 3.5SP1). Насколько я знаю, все они должны быть эквивалентны. Джон Кноллер прав в отношении ASCII против ANSI.
Пытались ли вы использовать один из классов Encoding' GetBytes() на оригинальной строке и выполнить итерацию, удаляя (копируя "хорошие" байты в другой буфер) значения, которые вам не нужны?
например (используя Linq):
byte[] original = System.Text.Encoding.ASCII.GetBytes(badString);
byte[] clean = (from b in original where b < 145 || b > 148 select b).ToArray<byte>();
string cleanString = System.Text.Encoding.ASCII.GetString(clean);
ASCII, вероятно, неправильно использовать здесь, если честно; если оригинальный текст - это Unicode, то это может сделать плохие вещи (если вам передадут UTF-16, например).
.NET использует Unicode (UCS-2), который совпадает с ASCII только для значений ниже 128.
ASCII не определяет значения выше 127 .
Думаю, вы думаете об ANSI, который определяет значения выше 127 как (в основном) языковые символы, необходимые для большинства европейских языков. или OEM (исходный набор символов IBM pc), который определяет символы> 127 как (в основном) символы.
Разница в том, как интерпретируются символы выше 127, называется кодовой страницей или кодировкой. (отсюда System.Text.Encoding). Таким образом, вы, вероятно, смогли бы запустить тест 3, если бы использовали другую кодировку, например System.Text.Encoding.Default .
Edit: Хорошо, теперь, когда мы знаем, что вам нужна кодировка ANSI, стало яснее, что происходит.
Правило преобразования символов заключается в замене символов, которые не могут быть представлены в кодировке как какой-либо другой символ - обычно это поле. Но для ASCII нет символа рамки, поэтому он использует? вместо. Это объясняет тест 3.
test1 и 2 оба используют Convert.ToChar с целочисленной константой. Что будет интерпретировать ввод как символ UNICODE, а не как символ ANSI, поэтому преобразование не применяется. 147-й символ Юникода - это непечатаемый символ.