Я использую Hotaru CMS с плагином загрузки изображений, я получаю эту ошибку, если пытаюсь прикрепить изображение к сообщению, в противном случае ошибки нет:
unserialize () [function.unserialize]: ошибка смещения
Код нарушения (ошибка указывает на строку с **):
/**
* Retrieve submission step data
*
* @param $key - empty when setting
* @return bool
*/
public function loadSubmitData($h, $key = '')
{
// delete everything in this table older than 30 minutes:
$this->deleteTempData($h->db);
if (!$key) { return false; }
$cleanKey = preg_replace('/[^a-z0-9]+/','',$key);
if (strcmp($key,$cleanKey) != 0) {
return false;
} else {
$sql = "SELECT tempdata_value FROM " . TABLE_TEMPDATA . " WHERE tempdata_key = %s ORDER BY tempdata_updatedts DESC LIMIT 1";
$submitted_data = $h->db->get_var($h->db->prepare($sql, $key));
**if ($submitted_data) { return unserialize($submitted_data); } else { return false; }**
}
}
Данные из таблицы, обратите внимание, что конечный бит содержит информацию об изображении, я не эксперт в PHP, поэтому мне было интересно, что вы, ребята, можете подумать?
tempdata_value:
a:10:{s:16:"submit_editorial";b:0;s:15:"submit_orig_url";s:13:"www.bbc.co.uk";s:12:"submit_title";s:14:"No title found";s:14:"submit_content";s:12:"dnfsdkfjdfdf";s:15:"submit_category";i:2;s:11:"submit_tags";s:3:"bbc";s:9:"submit_id";b:0;s:16:"submit_subscribe";i:0;s:15:"submit_comments";s:4:"open";s:5:"image";s:19:"C:fakepath100.jpg";}
Изменить: я думаю, что нашел бит сериализации ...
/**
* Save submission step data
*
* @return bool
*/
public function saveSubmitData($h)
{
// delete everything in this table older than 30 minutes:
$this->deleteTempData($h->db);
$sid = preg_replace('/[^a-z0-9]+/i', '', session_id());
$key = md5(microtime() . $sid . rand());
$sql = "INSERT INTO " . TABLE_TEMPDATA . " (tempdata_key, tempdata_value, tempdata_updateby) VALUES (%s,%s, %d)";
$h->db->query($h->db->prepare($sql, $key, serialize($h->vars['submitted_data']), $h->currentUser->id));
return $key;
}
php
mysql
serialization
content-management-system
пользователь576820
источник
источник
@unserialize($product->des_txtmopscol);
@
- это не устранение ошибок, а их подавление - ничто не "исправляется" с помощью этой техники.Ответы:
unserialize() [function.unserialize]: Error at offset
был оброкinvalid serialization data
из - за некорректную длинуБыстрая починка
Что вы можете сделать, это
recalculating the length
элементы в сериализованном массивеВы текущие сериализованные данные
Пример без пересчета
Вывод
Пересчет
Вывод
Рекомендация .. I
Вместо того, чтобы использовать такое быстрое исправление ... я советую вам обновить вопрос с помощью
Как вы сериализуете свои данные
Как вы это сохраняете ..
================================ РЕДАКТИРОВАТЬ 1 ================ ===============
Ошибка
Ошибка возникла из-за использования двойной кавычки
"
вместо одинарной'
, поэтомуC:\fakepath\100.png
была преобразована вC:fakepath100.jpg
Чтобы исправить ошибку
Вам нужно изменить
$h->vars['submitted_data']
From (обратите внимание на один'
)Заменить
С участием
Дополнительный фильтр
Вы также можете добавить этот простой фильтр перед вызовом сериализации
Если у вас есть символы UTF, вы также можете запустить
Как обнаружить проблему в будущих сериализованных данных
Вывод
findSerializeError
ФункцияЛучший способ сохранить в базе данных
источник
findSerializeError
функцией и нашел много ошибок. Пожалуйста, посмотрите мою темуbase64
в статье перед добавлением его в базу данных ... он сохранит нулевой символУ меня недостаточно репутации, чтобы комментировать, поэтому я надеюсь, что это увидят люди, использующие приведенный выше «правильный» ответ:
Начиная с php 5.5, модификатор / e в preg_replace () полностью устарел, и предыдущий preg_match выдает ошибку. Документация php рекомендует использовать вместо него preg_match_callback.
Найдите следующее решение в качестве альтернативы предложенному выше preg_match.
источник
strlen()
и, следовательно, делает избыточные вызовы функций. Лично я считаю добавление встроенного условия слишком подробным, но этот фрагмент дает хорошие результаты по уважительным причинам.'!s:(\d+):"(.*?)";!s'
(с окончанием s, чтобы также вводить новые строки). Спасибо за комментарий Адильбо ниже.Есть еще одна причина
unserialize()
неудачной, потому что вы неправильно поместили сериализованные данные в базу данных, см. Официальное объяснение здесь. Посколькуserialize()
возвращаемые двоичные данные и переменные php не заботятся о методах кодирования, поэтому, помещая их в TEXT, VARCHAR () вызовет эту ошибку.Решение: сохраните сериализованные данные в BLOB в вашей таблице.
источник
image
значения. Ваш ответ не имеет отношения к конкретному вопросу ОП. Вы можете переместить свой совет поБыстрая починка
Пересчет длины элементов в сериализованном массиве - но не используйте (preg_replace), он устарел - лучше используйте preg_replace_callback:
Изменить: новая версия теперь не только неправильной длины, но также исправляет разрывы строк и подсчитывает правильные символы с акцентом (благодаря mickmackusa )
источник
Эта ошибка вызвана неправильной кодировкой.
Установить кодировку после открытого тега:
И установите кодировку utf8 в своей базе данных:
источник
image
значение и не смог обновить счетчик байтов. Если не указано иное, я должен предположить, что этот ответ неверен для вопроса OP.Вы можете исправить сломанную строку сериализации, используя следующую функцию с обработкой многобайтовых символов .
источник
mb_strlen()
это неуместно, потому чтоserialize()
хранит количество байтов, а не количество символов. Если вы исправите свой ответ, это приведет к появлению на странице лишних советов.публичная функция unserializeKeySkills ($ string) {
источник
trim()
каждую совпавшую подстроку. Одно только это делает невозможным рекомендовать это решение. Кроме того, он задыхается от символов новой строки и излишне захватывает уже существующее количество байтов, которое в любом случае будет перезаписано. Наконец, это «ответ, состоящий только из кода», и эти типы ответов не имеют большого значения, поскольку они мало что делают для обучения / расширения возможностей будущих исследователей.Вы не можете исправить сломанную строку сериализации с помощью предлагаемых регулярных выражений:
Вы можете исправить сломанную строку сериализации, используя следующее регулярное выражение:
Вывод
или
источник
что официальные документы говорят , что должно возвращать ложное и множество E_NOTICE
но поскольку вы получили ошибку, отчет об ошибке должен запускаться E_NOTICE
вот исправление, позволяющее обнаруживать false, возвращаемое
unserialize
вы можете захотеть использовать кодирование / декодирование base64
источник
base64_encode
сделал трюк для меня. В моем случае мы передаемserialize
данные d через командную строку, и похоже, что какие-то странные символы мешают ей работать правильно.base64_encode()
не является решением вопроса, заданного ОП. Вопрос / проблема OP конкретно касается того факта, что (вероятно, связано с несоответствующей заменой подстроки в «последнем элементе массива» сериализованной строки) в сериализованной строке есть неправильное количество байтов. Пожалуйста, публикуйте только ответы, которые напрямую связаны с заданным вопросом.Повреждение в этом вопросе изолировано от единственной подстроки в конце сериализованной строки, которая, вероятно, была вручную заменена кем-то, кто лениво хотел обновить
image
имя файла. Этот факт будет очевиден в моей демонстрационной ссылке ниже с использованием опубликованных данных OP - короче говоря,C:fakepath100.jpg
не имеет длины19
, она должна быть17
.Поскольку повреждение сериализованной строки ограничено неправильным числом счетчика байтов / символов, следующее будет выполнять прекрасную работу по обновлению поврежденной строки с правильным значением счетчика байтов.
Следующая замена на основе регулярных выражений будет эффективна только для исправления количества байтов, не более того.
Похоже, что многие из предыдущих сообщений просто копируют шаблон регулярного выражения от кого-то другого. Нет причин фиксировать потенциально поврежденный счетчик байтов, если он не будет использоваться при замене. Кроме того, добавление
s
модификатора шаблона является разумным включением в случае, если строковое значение содержит символы новой строки / возврат строки.* Для тех, кто не осведомлен об обработке многобайтовых символов с помощью сериализации, вы не должны использовать
mb_strlen()
в настраиваемом обратном вызове, потому что это счетчик байтов, который сохраняется, а не количество символов , см. Мой вывод ...Код: ( Демо с данными OP ) ( Демо с произвольными выборочными данными ) ( Демо с заменой условий )
Вывод:
Одна нога в кроличьей норе ... Вышеупомянутое отлично работает, даже если в строковом значении встречаются двойные кавычки, но если строковое значение содержит
";
или какой-то другой sbustring, вам нужно пойти немного дальше и реализовать «поисковые обходы». Моя новая выкройкапроверяет, что ведущий
s
:;
и проверяет, что
";
:}
илиs:
илиi:
Я не проверял каждую возможность; Фактически, я относительно незнаком со всеми возможностями сериализованной строки, потому что я никогда не выбираю работу с сериализованными данными - всегда json в современных приложениях. Если есть дополнительные возможные начальные или конечные символы, оставьте комментарий, и я расширю поиск.
Расширенный фрагмент: ( Демо )
Вывод:
источник
Вам нужно будет изменить тип сопоставления на,
utf8_unicode_ci
и проблема будет устранена.источник
utf8_unicode_ci
? У меня есть сомнения по этому поводу.В моем случае я хранил сериализованные данные в
BLOB
поле базы данных MySQL, которое, по-видимому, не было достаточно большим, чтобы содержать все значение, и урезал его. Очевидно, что такую строку нельзя десериализовать.Однажды преобразовав это поле,
MEDIUMBLOB
проблема рассеялась. Также может потребоваться переключить параметры таблицыROW_FORMAT
наDYNAMIC
илиCOMPRESSED
.источник
TEXT
поле и поэтому было обрезано до 65kb.Попробовав некоторые вещи на этой странице без успеха, я заглянул в источник страницы и заметил, что все кавычки в сериализованной строке были заменены на html-объекты. Расшифровка этих сущностей помогает избежать большой головной боли:
источник
Вот онлайн-инструмент для исправления поврежденной сериализованной строки.
Я хотел бы добавить , что это в основном происходит из - за поиск и замены делается на БД и данных сериализации ( специально
key length
) не обновляются в соответствии с ЗАМЕНИТЬ и что вызывает «коррупцию».Тем не менее, вышеуказанный инструмент использует следующую логику для исправления данных сериализации ( скопировано отсюда ).
источник
Другой причиной этой проблемы может быть тип столбца таблицы сеансов полезной нагрузки. Если у вас есть огромные данные о сеансе, текстового столбца будет недостаточно. Вам понадобится MEDIUMTEXT или даже LONGTEXT.
источник