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

Question

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

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

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

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

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

ВОПРОС:

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

РЕДАКТИРОВАТЬ:

Я не прошу ни JSON, ни JavaScript. Я прошу об общем передовом опыте передачи Unicode во всех программах.

Answer 1

Существует база данных символьных свойств и отчет, описывающий ее, БАЗА ДАННЫХ UNICODE CHARACTER, которая дает хорошее представление о том, как браузеры "должны" обрабатывать кодовую точку. Я люблю это слово "должен". Самым безопасным будет белый список, вы, вероятно, можете использовать L|M|N|S, Букву или Метку, Цифру или Символ.

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

Answer 2

Это нарушает JavaScript, потому что строки не могут содержать новые строки:

var myString = "

";

//SyntaxError: Unexpected token ILLEGAL

Теперь последовательность UTF-8 "E2-80-A8" декодирует в кодировку Unicode 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"

Answer 3

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

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

НТН

Answer 4

AZ, az и 0-9 обычно безопасны. Помимо этих 62 символов, вы столкнетесь с проблемами в какой-то системе. Там нет другого ответа, который кто-нибудь может дать вам.

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