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

Существует база данных свойств символов и отчет с ее описанием, БАЗА ДАННЫХ СИМВОЛОВ UNICODE, которая дает хорошая идея о том, как браузеры «должны» обрабатывать кодовую точку. Я люблю это слово «должен». Самым безопасным будет белый список, вы, вероятно, можете использовать L|M|N|S, Letter или Mark, Number или Symbol.

Взгляните на проект ICU для библиотеки.

Это ломает 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"

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

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

ХТН

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

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