Недавно я столкнулся с ошибкой из-за качества данных при поддержке браузера, и я ищу безопасное правило для применения экранирования строки без двойного размера, если это не требуется.
Последовательность байтов UTF-8 "E2-80-A8" (U+2028, РАЗДЕЛИТЕЛЬ СТРОК), вполне допустимый символ в базе данных Unicode. Однако эта последовательность представляет собой разделитель строк (да, кроме "0A").
И что плохо, многие браузеры (включая Chrome, Firefox и Safari; другие я не тестировал) не смогли обработать обратный вызов JSONP, содержащий строку, содержащую этот символ Unicode. JSONP был включен в не-Unicode HTML, который я не контролировал.
Браузеры просто сообщали об ошибке INVALID CODE/syntax в таком JavaScript, который выглядит допустимым в инструментах отладки и во всех текстовых редакторах. Я предполагаю, что он может попытаться преобразовать "E2-80-A8" в BIG-5 и нарушить синтаксис JS.
Вышеприведенное является лишь примером того, как Unicode может неожиданно сломать вашу систему. Насколько мне известно, некоторые хакеры могут использовать RTL и другие управляющие символы себе во благо. И в спецификации Unicode много "кавычек", "пробелов", "символов" и "элементов управления".
ВОПРОС:
Существует ли список символов Unicode, которые каждый программист должен знать о скрытых функциях (и ошибках), которые мы могли бы не хотеть, чтобы они были эффективными в нашем приложении. (например, Windows отключает RTL в имени файла).
РЕДАКТИРОВАТЬ:
Я не прошу ни JSON, ни JavaScript. Я прошу общую передовую практику передачи Unicode во всех программах.
Ответ 1 · рейтинг 4 · jthill
Существует база данных свойств символов и отчет с ее описанием, БАЗА ДАННЫХ СИМВОЛОВ UNICODE, которая дает хорошая идея о том, как браузеры "должны" обрабатывать кодовую точку. Я люблю это слово "должен". Самым безопасным будет белый список, вы, вероятно, можете использовать L|M|N|S, Letter или Mark, Number или Symbol.
Взгляните на проект ICU для библиотеки.
Ответ 2 · рейтинг 9 · Esailija
Это ломает 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"
Ответ 4 · рейтинг 3 · prosfilaes
AZ, az и 0-9 обычно безопасны. За пределами этих 62 символов вы столкнетесь с проблемами в какой-то системе. Другого ответа вам никто не может дать.
Например, вы упоминаете доменные имена. Единственный способ обработки доменных имен Unicode - следовать RFC 3454 и RFC 5890-5893 и обрабатывать данные таким и только таким образом. Имена файлов в большинстве файловых систем Unix представляют собой произвольные строки байтов, которые не включают / или \0. Функциональная обработка имени файла в Unix как строки Unicode без нарушения чего-либо сама по себе является вопросом. Обратите внимание, что имена файлов Windows не являются безопасными от A до Z; такие вещи, как NUL и PRN, являются зарезервированными именами. У каждого домена есть свои маленькие проблемы и причуды, и простого резюме не будет достаточно для всех.
