Строка сеанса PHP содержит странные пустые/нулевые символы

Предыстория: я пытался реализовать дескриптор сеанса DynamoDB в своем приложении Symfony2.

Я столкнулся с камнем преткновения, когда сеанс сохраняется в DynamoDB. Похоже, что строка, исходящая из PHP, имеет какую-то странную кодировку, содержащую пустые символы, которые не являются пробелами, что затем препятствует правильному сохранению строки в DynamoDB. Строка также не работает, когда я вставляю ее в PhpStorm.

Вот пример этого: $illegalString = 's:8:"userData";O:27:"\SomeClass":49:{s:8:"�*�email";s:27:"[email protected]";s:13:"�*�first_name";s:4:"Greg";';

И для справки, вот снимок экрана из PhpStorm, показывающий, что это не пробел. PhpStorm Снимок экранаКроме того, если я попытаюсь переместить курсор на эти символы, другие символы начнут появляться в изображение под моим курсором - это пара пробелов слева от последней точки с запятой в строке 1, кавычка не существует в строке, но по какой-то причине она появляется, когда на ней находится мой курсор. введите здесь описание изображения

Если вы скопируете/вставите указанную выше строку на указанный ниже сайт, она разорвет страницу: http://www.asciivalue.com/index.php

Три вопроса:

  1. Что не так с этой строкой? Что за странная кодировка?
  2. Почему PHP обрабатывает строки сеанса таким образом?
  3. Как я могу указать PHP использовать только UTF-8 при создании строк сеанса?

Примечание. Похоже, это происходит только на AWS ec2 с последней версией Linux AMI.


php amazon-dynamodb encoding aws-php-sdk
person greg    schedule 16.10.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Эти символы говорят о том, что у вас где-то есть проблема с кодировками (либо при преобразовании из одной в другую (возможно, молча), либо при указании неправильной кодировки).

Последовательность, которую вы там имеете, кажется EF BF BD (как я вижу ее после того, как скопировала ее в документ UTF-8), и она означает REPLACEMENT CHARACTER - используется в качестве замены недопустимых символов при преобразовании из одной кодировки в другую (или проверка/очистка с использованием неправильной кодировки).

Например: символ A0 допустим в ISO 8599-1, но если вы ошибочно трактуете такую ​​строку как закодированную в UTF-8, этот символ там недействителен и будет заменен вышеупомянутой последовательностью.

Я предлагаю проверить данные вашего сеанса, прежде чем они будут сохранены обработчиком сеанса (особенно если вы используете пользовательский) - возможно, это так, прежде чем записывать в сеанс.

Также проверьте, какой session.serialize_handler вы используете, особенно если используется пользовательский.

Вы также можете попробовать написать свой собственный обработчик сеанса (часть, которая будет записывать закодированные данные в файл или что-то еще — это легко) — посмотрите, какие данные поступают в обработчик: хорошие или уже «испорченные».

Я сам не использовал ни один из сервисов AWS, поэтому не могу дать совет по этой части.

person LazyOne    schedule 17.10.2014