Список символов Юникода, которые должны быть отфильтрованы на выходе?

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

Последовательность байтов UTF-8 "E2-80-A8" (U + 2028, LINE SEPARATOR), вполне допустимый символ в базе данных Unicode. Однако эта последовательность представляет собой разделитель строк (Да, другой - "0A" ).

И плохо, многие браузеры (включая Chrome, Firefox и Safari, я не тестировал других), не смогли обработать обратный вызов JSONP, который имеет строку, содержащую этот символ Unicode. JSONP был включен HTML-кодом, отличным от Юникода, который я не имел никакого контроля.

Браузеры просто сообщили об ошибке INVALID CODE/синтаксиса на таком JavaScript, который выглядит корректно из инструментов отладки и всех текстовых редакторов. Я думаю, что он может попытаться преобразовать "E2-80-A8" в BIG-5 и сломал синтаксис JS.

Вышеприведенный пример является лишь примером того, как Unicode может неожиданно нарушить вашу систему. Насколько я знаю, некоторые хакеры могут использовать RTL и другие контрольные символы для своего блага. И в спецификации Юникода есть много "кавычек", "пробелов", "символов" и "элементов управления".

Вопрос:

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

EDIT:

Я не прошу JSON и JavaScript. Я прошу об общей передовой практике использования Unicode во всех программах.

Ответ 1

Здесь есть база данных свойств символов и отчет, описывающий ее, UNICODE CHARACTER DATABASE, что дает хорошее представление о том, как браузеры должны "обрабатывать кодовую точку. Мне нравится это слово," должно". Safest станет белым, вы, вероятно, могли бы пойти с L | M | N | S, буквой или маркой или номером или символом.

Посмотрите проект ICU для библиотеки

Ответ 2

Он разбивает javascript, потому что строки не могут иметь в них символы новой строки:

var myString = "

";

//SyntaxError: Unexpected token ILLEGAL

Теперь последовательность UTF-8 "E2-80-A8" декодирует кодовую точку юникода U+2028, которая обрабатывается аналогично новой строке в javascript:

 var myString = " ";

//Syntax Error

Однако безопасно писать

var myString = "\u2028";
//you can now log myString in console and get real representation of this character

который будет правильно закодирован JSON. Я бы посмотрел на правильную кодировку JSON вместо сохранения черного списка небезопасных символов. (U + 2028 и U + 2029 AFAIK).

В PHP:

echo json_encode( chr(0xe2). chr(0x80).chr(0xA8 ) );
//"\u2028"

Ответ 3

Посмотрите на диаграммы Unicode. Там список непечатаемых символов. Это те, которые были бы потенциальными нарушителями спокойствия. У вашего друга U + 2028 есть куча друзей: http://www.unicode.org/charts/PDF/U2000.pdf И это не только в диапазоне 2000.

Вы можете либо уничтожить их всех, либо разделить на разные категории (символы SEP, такие как U + 2028, становятся \n или экранированы должным образом) и т.д.

НТН

Ответ 4

A-Z, a-z и 0-9, как правило, безопасны. За пределами этих 62 символов вы столкнетесь с проблемами в какой-то системе. Нет другого ответа, который любой может вам дать.

Например, вы указываете имена доменов. Единственный способ обработки имен доменов Unicode - следовать RFC 3454 и RFC 5890-5893 и обрабатывать данные таким образом и только таким образом. Имена файлов в большинстве файловых систем Unix представляют собой произвольные строки байтов, которые не включают/или\0. Функциональная обработка имени файла в Unix как строка Unicode без нарушения чего-либо является вопросом сама по себе. Обратите внимание, что имена файлов Windows не являются безопасными A-Z; такие как NUL и PRN являются зарезервированными именами. Каждый домен имеет свои собственные небольшие проблемы и причуды, и простого описания не хватит везде.