Что может помешать правильной сериализации?

[asdfix]

Что может помешать правильной сериализации?

Есть стандартные функции для работы с базой:

function to_base ($text) {
    return addslashes(serialize($text));
}
function from_base ($text) {
    return unserialize(stripslashes($text));
}

С помощью них обрабатывается переменная $text и пишется в базу.
$text получена скриптом из файла, загружаемого юзером из мультипарт-формы.
Далее, на одном сервере все работает штатно. На другом - загруженная в базу сериализованная переменная имеет "большую" длину, при том что само значение сериализованных данных совпадает.

s:140:"****тут тектс/данные, короче содежимое полученного файла*****";
s:152:"****тут тот же тектс/данные, короче то же самое содежимое полученного файла*****";

В итоге в первом случай ансериализация проходит штатно и даныые извлеченные из базы не теряются...
Во втором случае - ансериализация не проходит - и данные потеряны.

Кто знает, где искать ошибку?

 

[Sirius]

может тип поля таблицы не позволяет всё записать? Смотрел в базу?

 

[SiMM]

PHP FAQ: Ничего не работает! Что делать???

> s:140:"****тут тектс/данные, короче содежимое полученного файла*****";
> s:152:"****тут тот же тектс/данные, короче то же самое содежимое полученного файла*****";
Что-то мне подсказывает, что утверждение "то же самое" ложно.

 

[Фанат]

фигассе - "стандартные"

 

[tony2001]

Фанат
хинт:
function from_base ($text) {
return unserialize(stripslashes($text));
}

 

[SiMM]

tony2001, ЗачОт
Видимо кто-то обчитался ламерских утверждений.

 

[Фанат]

tony2001, спасибо, дошло. я на сам код не обратил внимания

asdfix, речь идёт о файлах, или это просто слово красивое ты употребил?

 

[asdfix]

Автор оригинала: Фанат
фигассе - "стандартные"

Сарказьм...? Не ясно...

речь идёт о файлах, или это просто слово красивое ты употребил?

Речь идет о том, что $text - содержимое файла, полученного скриптом из мультипарт формы.

может тип поля таблицы не позволяет всё записать? Смотрел в базу?

примеры сериализованных данных именно из баз.
1. штатно
2. s:152... а не s:140...

Ключевым является то, что неясно, почему разная длина сериализованных данных при их фактическом "равентстве".
И как это счастье может зависить от настроек сервера, например?

 

[SiMM]

asdfix, один вопрос (возможно, не являющийся причиной) - ты уверен, что знаешь, для чего используешь stripslashes? Мне кажется, что нет...

> И как это счастье может зависить от настроек сервера, например?
Как угодно. Пока ты не локализуешь проблему, говорить что-то конкретное бессмысленно.
Думаю, какое-то отношение может иметь PHP FAQ: \"Кавычки \". Cоставление запросов mysql, слеши, экранирование кавычек.

 

[Фанат]

А можно спросить, зачем нужна сериализация?

 

[asdfix]

Автор оригинала: SiMM
asdfix, один вопрос (возможно, не являющийся причиной) - ты уверен, что знаешь, для чего используешь stripslashes? Мне кажется, что нет...

>Думаю, какое-то отношение может иметь PHP FAQ: \"Кавычки \". Cоставление запросов mysql, слеши, экранирование кавычек.

stripslashes - досталось "в наследство" и убито за ненадобностью после очередного детального анализа материлов фака. SiMM, спасибо. Не в том месте искал неприятности от включеной magic_quotes_gpc.

А можно спросить, зачем нужна сериализация?

Иной раз приходится грузить в базу массивы

 

[Фанат]

Иной раз приходится грузить в базу массивы

в которых лежит содержимое файла, полученного скриптом из мультипарт формы.

Давно ли у нас мультипарт формы научились передавать массивы в файлах?

 

[asdfix]

Та не. То уже совсем другая история...
Кавычковый фак позволил таки понять, как локализовать проблему. И как водится, "не работала" как раз не сериализация. Проблема решилась добавлением htmlspecialchars при выводе текущего содержимого полей мультипарт формы. Массивы тут не причем... Хотя намек понят...