J'ai cette fonction dans mon application: Il ne doit jamais ne jamais renvoyer false mais dans le journal des erreurs, la conduite d'erreur indique qu'il est renvoyé faux. Cependant , Je ne peux pas reproduire l'erreur dans mon application. J'essaie de toutes les réponses possibles, mais cela fonctionne toujours. Y a-t-il quelque chose qui ne va pas avec la fonction? Le edit: la regex est là car: $ thetree provient de la session. < / p> Non Serialize - Recherchez ma Regex dans les commentaires. C'est censé résoudre un problème.
6 Réponses :
est la valeur de magic_quotes_gpc identique à la fois sur la production et à votre machine locale?
Oui, les citations magiques sont éteintes sur les deux serveurs, la locale et la production.
J'ai fait face au même type de problème plus tôt. Je vous montre comment je l'ai résolu.
Après avoir sérialisé les données, appliquez la base64_encode ()
E.g et lorsque vous le désérioriez E.g. Essayez ceci. J'espère travailler pour vous aussi. Bonne chance
J'ai eu ce problème et cela a corrigé cela. Merci!
À quoi ressemble cette sorcellerie? Cela fonctionne réellement ... mais serait bien de comprendre!
C'est pourquoi je ne devrais jamais utiliser "Serialize" "désériorize". Si cela ne fait pas ce que vous vous attendez, alors pourquoi l'utiliser. JSON Encode Decoder fonctionne bien.
@Preexo base64 code les données en tant que chaîne ASCII, contourner des problèmes de caractères de votre DB à votre script de serveur, et si vous supprimez les données du Net, puis: à partir de la source, à la DB, à votre script. Les choses peuvent aller mal dans la traduction. Évidemment Serialize Underialize n'encore pas toujours pour vous décoder pour que les gens ont des problèmes. Si vous base64, vous perdez la recherche des données directement lors de la visualisation des entrées brutes de la DB.
J'ai eu un comportement aléatoire sur mon code, mais je pense que j'ai découvert pourquoi. J'utilisais UTF-8 Charset et dans mon serveur de production, il semble produire ces problèmes. Essayez ceci:
$txt = unserialize(utf8_encode($aTreeRoot));
Je crois à échapper aux données que vous avez sérialisé fonctionnerait également comme alternative à la base64.
$data = serialize($results); $encoded = htmlentities($data); echo '<input type="hidden" name="data" value="'.$encoded.'">';
J'ai eu des problèmes similaires. Etepte la colonne de la DB qui stockait la matrice sérialisée avait une assemblée de: J'ai changé la collation de la colonne de données sérialisée vers: latin1_swedish_ci
utf8_bin et re-svaed the Data and Voila - Problème résolu.
Pour moi, le problème était que la chaîne de non-sérifioir doit être coupée! Le message d'erreur n'était pas utile dans ce cas et je suis tombé sur la solution en consultant un autre code.
$unserialized = unserialize(trim($serialized));
Est-ce que ce
Preg_ReplaCing vraiment nécessaire? L'exemple que ce caractère Igor donne qui a invité cette solution de contournement est une chaîne sérialisée complètement invalide pour commencer. Je ne suis au courant de bugs qui nécessiteraient cela. Si votre chaîne a été sérialisée avecSerialize et n'a pas été modifiée, il devraitnon désériorialiser juste bien. Avez-vous rencontré ce problème vous-même, ou vous venez-vous de le dire parce que «c'est censé résoudre un problème»?@Deceze: Oui, sans que cette regex, le désériorize ne fonctionne pas. Je mettant un objet compliqué dans la session sérialisé et sans la regex, il y a des problèmes qui y sont insérentiels. La regex résout ce problème mais il semble toujours que la désérioriation revient parfois de faux.
Triple Vérifiez que votre chaîne Serialized ne récupère pas de caractères supplémentaires sur le chemin, change de codage, etc. Pouvez-vous donner un exemple qui échoue?
Je convoque la chaîne de Windows-1250 en UTF-8 après la sérialisation. Je ne sais pas si cela est signifiant.
@Deceze je n'ai aucun exemple en ce moment. Je vais mettre à jour mon erreur Hadler pour enregistrer la chaîne en cas d'erreurs futures comme celle-ci.
Je ne suis pas sûr, mais la modification du codage peut avoir un impact, car la longueur des chaînes change (si elle est mesurée en octets, pas sûr à 100% de la chaîne sérialisée stocke la longueur de).
@Deceze Oui. C'est ce qui est mentionné dans les commentaires dont beaucoup de gens semblent avoir des problèmes avec les chaînes UTF-8. La solution d'Igor est censée résoudre ce problème.
@Deceze Je vais essayer de l'enregistreratimement, comme Windows-1250 et d'utiliser iconv uniquement lors de l'impression de son contenu avec ECHO. J'espère que cela résout le problème.
et Window-1250 n'est pas un sous-ensemble direct de UTF-8. Certains caractères risquent de manquer de codage. Alors, essayez d'abord avec des caractères simples.