Le format n'a aucune spécification en dehors de l'implémentation ; le Manuel PHP pour unserialize() est la référence, et il est explicite que la transmission d'entrées non fiables n'est pas sûre.
La première fois que les données PHP sérialisées m'ont coûté un après-midi, c'était un ticket d'assistance WP Adminify. Les paramètres du widget de tableau de bord d'un utilisateur étaient devenus détraqués, et les "paramètres" qu'ils décrivaient dans le wp_options Tableau sous forme de chaîne sérialisée unique qui ressemblait à un bruit de ligne : a:4:{s:8:"_builtin";b:1;.... Je ne pouvais pas le lire, je ne pouvais pas dire d'un seul coup d'œil ce qui n'allait pas, et je ne voulais pas créer un environnement PHP complet juste pour print_r une rangée. Cet après-midi-là, c'est pourquoi je me soucie d'avoir un décodeur à un onglet de navigateur.
Si vous travaillez dans WordPress, WooCommerce, Laravel ou toute autre base de code PHP, vous avez rencontré des données sérialisées, que vous le souhaitiez ou non. Il apparaît dans les tables d'options, les fichiers de session, les magasins de cache et la publication de méta. Et quand quelque chose se brise, pouvoir lire rapidement est la différence entre un correctif de cinq minutes et un après-midi.
Ce guide couvre ce qu'est réellement le format sérialisé, comment le décoder avec le annuler la série outil sur Toolz.dev et - surtout - la seule véritable limitation que vous devez connaître avant de faire confiance à la sortie sur des données non anglaises.
tl;dr : PHP
serialize()Pack des valeurs dans une chaîne typée commea:2:{s:4:"name";s:5:"Alice";...}où chaque pièce porte son type et sa longueur. le Outil de déssérialisation analyse cela dans votre navigateur et l'affiche sous forme d'arbre,print_r,var_dump(traduction), ou JSON - pas de serveur PHP, pas de téléchargement de données Gros avertissement Je me suis vérifié : il compte la longueur de chaîne dans les unités de code UTF-16, pas les octets, donc les données sérialisées contenant des accents, des emoji ou des caractères CJK peuvent mal analyser ou échouer Pour les données ASCII, il est fiable Il lit les données ; il ne résout pas les références d'objet ou vous laisse modifier en place.
Qu'est-ce que la sérialisation PHP, vraiment ?
La sérialisation transforme une valeur PHP - un tableau, un objet, une chaîne, un entier, peu importe - en une chaîne plate que vous pouvez stocker dans une colonne de base de données ou un fichier, puis reconstruire avec unserialize(). Deux fonctions font le travail : serialize() convertit une valeur en chaîne, et unserialize() le reconvertit.
Ce qui rend le format lisible une fois que vous savez que le code est que chaque valeur annonce son type et sa taille. Voici le vocabulaire entier :
s:5:"hello" // string: s:length:"value"
i:42 // integer: i:value
d:3.14 // double: d:value
b:1 // boolean true (b:0 is false)
N; // null
a:2:{...} // array: a:count:{key;value;...}
O:8:"ClassName":1:{...} // object: O:namelen:"Class":propcount:{...}
Un tableau associatif sérialisé ressemble donc à ceci :
a:3:{s:4:"name";s:10:"John Smith";s:5:"email";s:16:"[email protected]";s:4:"role";s:5:"admin";}
qui est juste ce tableau PHP, emballé serré :
array(
'name' => 'John Smith',
'email' => '[email protected]',
'role' => 'admin'
)
Compact pour la machine, presque illisible pour un humain à 14h lors d'un appel d'assistance. C'est tout le problème que l'outil résout.
Comment l'outil Toolz.dev décompresse-t-il le décoder ?
Vous collez la chaîne et analyse le format directement en JavaScript dans votre navigateur et rend le résultat. J'ai testé chacun de ces éléments par rapport au propre analyseur de l'outil lors de l'écriture de ceci, donc le comportement ci-dessous est ce qu'il fait réellement, pas ce qu'un manuel suppose.
Les tableaux séquentielles d'entiers reviennent comme une véritable liste. a:2:{i:0;s:5:"apple";i:1;s:6:"banana";} Décodes ["apple", "banana"]. Les tableaux associatifs reviennent en tant qu'objets clés. Les structures imbriquées s'imbriquent correctement, les tableaux à l'intérieur des tableaux à l'intérieur des objets, jusqu'au bout.
Les objets conservent leur nom de classe. O:4:"User":2:{s:4:"name";s:3:"Bob";...} Décode avec un __class__ marque de "User" plus ses propriétés, pour que vous puissiez voir à la fois le type et les données Il gère même le cas gênant des propriétés privées et protégées, que PHP sérialise avec des préfixes d'octets nuls autour du nom de la classe - l'outil les supprime et vous montre le nom de la propriété propre.
Vous obtenez huit formats de sortie pour basculer entre : Arborescence, print_r, var_dump, var_export, Krumo, FirePHP, DBUG et Plain JSON. Je vis dans Tree View pour explorer et JSON pour avoir copié quelque chose d'autre, mais si votre mémoire musculaire s'attend à var_dump Sortie, c'est juste là.
La seule limitation que vous devez connaître : chaînes multi-octets
C'est la partie que je voudrais que quelqu'un me dise avant de faire confiance à un décodeur sur les données de production, alors la voici à l'avance.
Le format sérialisé de PHP mesure la longueur de la chaîne dans octets. L'outil le mesure dans Longueur de chaîne de javascript, qui compte les unités de code UTF-16. Pour les ASCII simples, ce sont les mêmes nombres, donc les données en anglais décodent parfaitement. Au moment où une chaîne contient un caractère UTF-8 multi-octets, ils divergent.
Prendre le mot "Café." En UTF-8, le "é" est de deux octets, donc PHP le sérialise comme s:5:"café" - longueur cinq, comptage des octets L'outil lit ça 5 et attrape cinq Codes unités de la chaîne, qui est café" - il avale la citation finale et perd sa place J'ai couru exactement ceci : un autonome s:5:"café"; Décode la valeur incorrecte et dans un tableau comme a:2:{s:1:"a";s:5:"café";s:1:"b";i:1;} Il échoue carrément avec Unknown type ':' at position 25.
Le point à retenir pratique : si vous déboguez des options WordPress qui sont purement ASCII - la plupart des paramètres du plugin, slugs, drapeaux booléens - vous allez bien Si les données sérialisées contiennent des noms accentués, des emoji ou du texte CJK, le décodage peut corrompre ou s'erreurs, et c'est un vrai bug dans l'outil, pas vos données. (Pour mémoire, le correctif à notre fin est d'analyser par longueur d'octet UTF-8 plutôt que par .length; c'est sur ma liste.) Lorsque vous le frappez, les commandes de sérialisation WP-CLI sur le serveur sont le repli fiable.
Il existe une mise en garde connexe et plus douce : var_dump La sortie signale la longueur des chaînes en utilisant le même nombre de codes-unités, donc var_dump("café") spectacles string(4) Où le vrai php dirait string(5), et un emoji affiche une longueur qui ne correspondra pas non plus au nombre d'octets de PHP. Lisez ces nombres comme "Longueur JavaScript", pas "Longueur d'octets PHP".
Pourquoi auriez-vous besoin de décomposer les données en dehors de PHP ?
Beaucoup de raisons, et presque aucune d'entre elles n'est "pour le plaisir".
Le débogage est le plus important. Un rapport de bogue indique que les paramètres de l'utilisateur sont erronés ; les paramètres sont un blob sérialisé dans la base de données ; vous ne pouvez pas voir le problème tant que vous ne l'avez pas décodé. Le flux de travail que j'utilise est : SELECT option_value FROM wp_options WHERE option_name = 'widget_text';, copiez le résultat, collez-le dans le Outil de déssérialisation, et lisez l'arbre. Dix secondes par rapport à l'écriture d'un script PHP jetable.
Les migrations sont sournoises Les chaînes sérialisées intègrent leurs propres longueurs, donc une recherche et un remplacement naïfs sur un vidage de base de données - par exemple, échanger un ancien domaine contre un nouveau - modifie le contenu de la chaîne sans mettre à jour le préfixe de longueur, et chaque valeur affectée devient non sérialisable Le décodage vous montre d'abord exactement quelles valeurs portent le domaine afin que vous sachiez ce qu'une recherche et un remplacement simples vont casser. (L'outil correct pour le remplacement lui-même est WP-CLI' ; s search-replace, qui comprend la sérialisation.)
Ensuite, il y a l'inspection du cache et des sessions - Redis, Memcached et les caches de fichiers dans les applications PHP contiennent souvent des valeurs sérialisées - et l'examen de sécurité, où vous devez voir ce qui est réellement stocké avant de pouvoir juger s'il est sûr.
Le décodage des données sérialisées dans le navigateur est-il sécurisé ?
Plus sûr que de le faire en PHP, et cela vaut la peine de comprendre pourquoi.
Natif de PHP unserialize() a un long historique de sécurité. Alimenté une chaîne artisanale, il peut instituer des objets arbitraires et déclencher leurs méthodes magiques (__wakeup, __destruct), qui, dans les bonnes conditions, devient une attaque par injection d'objet et, au pire, une exécution de code à distance. C'est pourquoi le conseil permanent est de ne jamais appeler unserialize() sur une entrée non fiable, et pour passer ['allowed_classes' => false] Quand tu dois.
L'outil de navigation évite tout cela car il n'est jamais piste PHP. Il lit le format de chaîne et affiche la structure - aucun objet PHP n'est créé, aucune méthode magique ne se déclenche et il n'y a pas d'interpréteur à exploiter Les données restent également sur votre appareil ; elles sont analysées localement et ne sont jamais envoyées à un serveur, ce qui importe lorsque le blob sérialisé est une session ou quelque chose d'autre que vous préféreriez ne pas télécharger Donc pour inspecteur Données sérialisées non fiables, le navigateur est vraiment l'endroit le plus sûr.
PHP natif unserialize() |
Outil de navigation Toolz.dev | |
|---|---|---|
| Instancie des objets | Oui (risque d'injection) | Non - lit uniquement la structure |
| Fonctionne sur un serveur | oui | Non - local dans le navigateur |
| Sécurisé sur les entrées non fiables | seulement avec allowed_classes |
Oui, il n'exécute jamais |
| Gère les longueurs multi-octets | correctement (octets) | Pas fiable (unités de code) |
| Résout les références d'objets | oui | Non - spectacles [Reference] |
| intention | Reconstituer les valeurs en direct | Inspecter et lire |
Ce tableau est également un résumé honnête du compromis : l'outil de navigation est le lecteur sûr, et non un remplacement de la fonction de langage.
Quelles sont les sources communes du monde réel ?
Si vous êtes ici, c'est probablement l'un d'entre eux. WordPress s'appuie fortement sur la sérialisation dans wp_options - widget_text, sidebars_widgets, theme_mods_*, la liste des plugins actifs, les horaires cron. WooCommerce stocke les variations de produits, les attributs et les champs personnalisés en tant que post méta sérialisé, c'est pourquoi un produit avec une tarification erronée remonte si souvent à une valeur sérialisée. Laravel utilise la sérialisation pour le cache de fichiers et le stockage de session. Le système de configuration de Magento en est plein. Partout le même format, même approche de décodage.
Quelques choses que l'outil ne fait pas
Deux limites honnêtes Il ne résout pas les références - PHP peut sérialiser un pointeur vers une valeur antérieure (en anglais)r: ou R:), et l'outil montre ceux-ci comme un littéral [Reference] marqueur plutôt que de les suivre Et c'est un lecteur, pas un éditeur : il n'y a pas de " ; changez cette valeur et re-sérialisez" ; mode Pour modifier les données sérialisées, décodez-les, effectuez votre changement en PHP ou en JSON, et re-sérialisez côté PHP. Si vous devez éditer manuellement la chaîne brute, rappelez-vous que vous devez également fixer les préfixes de longueur, et - selon la section ci-dessus - compter les octets, pas les caractères.
Questions fréquentes
A quoi sert la sérialisation PHP ?
Il convertit des valeurs complexes comme des tableaux et des objets en une seule chaîne qui peut vivre dans une colonne de base de données, un fichier ou un cache, et être reconstruite ultérieurement. WordPress, WooCommerce, Laravel et Magento l'utilisent tous fortement pour les paramètres, les données de session et les valeurs mises en cache.
Puis-je décomposer les données PHP sans serveur PHP ?
Oui. le Outil de déssérialisation Analyse le PHP sérialisé en Javascript dans votre navigateur. Pas d'installation PHP, pas de serveur, pas de compte.
Est-il sécuritaire de décoder des données sérialisées dans le navigateur ?
Oui, et c'est plus sûr que celui de PHP unserialize() En entrée non approuvée, car l'outil lit uniquement la structure de chaîne. Il n'instancier jamais les objets PHP, de sorte que les attaques de la méthode magique qui rendent natifs unserialize() Dangereux ne peut tout simplement pas arriver.
Pourquoi ma chaîne sérialisée ne décode-t-elle pas ?
Les causes habituelles sont une copie tronquée (vous avez manqué les accolades ou le premier caractère), un préfixe de longueur cassé après une recherche et un remplacement, ou des données qui ne sont pas réellement sérialisées. Un autre qui capte les gens : si la chaîne contient des caractères accentués, des emoji ou du texte CJK, le comptage de la longueur de l'unité de code de l'outil peut l'analyser mal, car la longueur de chaînes de PHP compte en octets et l'outil compte les unités UTF-16.
Puis-je décoder les valeurs WordPress WP_Options avec elle ?
Oui - c'est l'une des utilisations les plus courantes Interrogez le option_value, collez-le et lisez la structure. Sachez simplement que si l'option contient du texte multi-octets, vous pourriez avoir besoin de WP-CLI sur le serveur à la place.
Puis-je modifier des données sérialisées avec cet outil ?
Non, c'est un lecteur. Pour modifier une valeur, décoder, modifier en PHP ou JSON et re-sérialiser du côté PHP. L'édition manuelle de la chaîne brute signifie vous-même fixer vous-même les préfixes de longueur d'octets, ce qui est sujet aux erreurs.
Quelle est la différence entre la sérialisation PHP et JSON ?
La sérialisation conserve les types spécifiques à PHP, y compris les noms de classes d'objets et les propriétés privées. JSON est indépendant du langage et ne connaît que les chaînes, les nombres, les booléens, les nulls, les tableaux et les objets. Le nouveau code préfère généralement JSON car json_decode() N'institue pas les objets, il évite donc le risque d'injection, et JSON est lisible partout. Vous pouvez déplacer une structure décodée dans le Formateur JSON travailler avec cela de cette façon.
L'outil gère-t-il les objets sérialisés, pas seulement les tableaux ?
Oui. Les objets décodent avec leur nom de classe conservés à côté des propriétés, et les propriétés privées ou protégées (que PHP sérialise avec les préfixes null-byte) sont nettoyées pour obtenir des noms lisibles dans la sortie.
conclusion
Les données PHP sérialisées sont inévitables si vous touchez WordPress, WooCommerce ou Laravel, et la possibilité de les lire à la demande transforme une catégorie de bogues frustrants en bugs rapides. le Outil de déssérialisation fait cela dans un onglet de navigateur, en toute sécurité, sans serveur PHP - tant que vous connaissez son seul bord réel : les chaînes multioctets peuvent déclencher le comptage de longueur, et les données ASCII sont là où elles brillent Coller, lire, corriger Et lorsque les données sont pleines d'accents ou d'emoji, atteignez WP-CLI à la place.
Outils associés :
