кодировка — строка сеанса PHP содержит странные пустые / нулевые символы
История вопроса: я пытался реализовать дескриптор сеанса DynamoDB в моем приложении Symfony2.
Я столкнулся с камнем преткновения, когда сессия была сохранена в DynamoDB. Похоже, что строка из PHP находится в какой-то странной кодировке, которая содержит пустые символы, которые не являются пробелами, что препятствует правильному сохранению строки в DynamoDB. Строка также не играет хорошо, когда я вставляю ее в PhpStorm.
Вот пример этого:
$illegalString = 's:8:"userData";O:27:"\SomeClass":49:{s:8:"�*�email";s:27:"me@domain.com";s:13:"�*�first_name";s:4:"Greg";';
И для справки, вот скриншот из PhpStorm, показывающий, что это не пробел.
Кроме того, если я пытаюсь переместить курсор на эти символы, другие символы начинают появляться, на изображении ниже моего курсора есть пара пробелов слева от последней точки с запятой в строке 1, кавычка не существует в строка, но по какой-то причине она появляется, когда на нее наведен курсор.
Если вы скопируете / вставите строку выше на сайт ниже, это сломает страницу: http://www.asciivalue.com/index.php
Три вопроса:
- Что не так с этой строкой? Что это за прикольная кодировка?
- Почему PHP обрабатывает строки сессий таким образом?
- Как я могу сказать PHP использовать UTF-8 только при создании строк сеанса?
Примечание. Это возможно только в AWS ec2 с использованием новейшей версии Linux AMI.
Решение
Эти символы говорят о том, что у вас есть проблемы с кодировкой где-либо (либо при преобразовании из одного в другое (возможно, без вывода сообщений), либо при указании неправильной кодировки).
Последовательность у вас там, кажется, EF BF BD (как я вижу после того, как я скопировал его в документ UTF-8), и это означает REPLACEMENT CHARACTER — используется в качестве замены недопустимых символов при преобразовании из одной кодировки в другую (или проверке / очистке с использованием неправильной кодировки).
Например: A0 символ действителен в ISO 8599-1, но если вы ошибочно воспринимаете такую строку как кодировку UTF-8, этот символ там недопустим и будет заменен вышеупомянутой последовательностью.
Я предлагаю проверить данные вашего сеанса до того, как они будут сохранены обработчиком сеанса (особенно если вы используете пользовательский) — возможно, так оно и есть перед записью в сеанс.
Также проверьте, какой файл session.serialize_handler вы используете, особенно если используется пользовательский.
Вы также можете попробовать написать свой собственный обработчик сеанса (часть, которая будет записывать закодированные данные в файл или что-то еще — это легко) — посмотреть, какие данные поступают в обработчик: это хорошо или уже «повреждено».
Я не пользовался услугами AWS самостоятельно, поэтому не могу дать совет по этой части.
Другие решения
Других решений пока нет …
detector