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 limitation réelle 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, ou JSON — Pas de serveur PHP, pas de téléchargement de données. Grosse caveat que j'ai vérifié : il compte la longueur de la chaîne en unités de code UTF-16, et non en octets, de sorte que les données sérialisées contenant des accents, des emoji ou des CJK peuvent mal analyser ou échouer. Pour les données ASCII, elles sont fiables. Il lit les données, il ne résout pas les références d'objets ou ne vous permet pas de 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 nombre entier, peu importe - en une chaîne plate que vous pouvez stocker dans une colonne de base de données ou un fichier et reconstruire ultérieurement 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, vous pouvez donc voir à la fois le type et les données. Il gère même le cas embarrassant des propriétés privées et protégées, que PHP sérialise avec des préfixes null-byte autour du nom de la classe. L'outil les stripe et vous montre le nom de la propriété Clean.
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, comptant les octets. L'outil lit que 5 et attrape cinq Codes unités de la chaîne, qui est café" — Il avale le devis de clôture et perd sa place. J'ai exécuté 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 de pur ASCII - la plupart des paramètres de plugin, des limaces, des drapeaux booléens - tout va bien. Si les données sérialisées contiennent des noms accentués, des emoji ou du texte CJK, le décodage peut être corrompu ou erreur, et c'est un vrai bogue dans l'outil, pas vos données. (Pour la notation, le correctif de notre part est d'analyser par la longueur d'octet de 8 octets plutôt que .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 les plus sournois. Les chaînes sérialisées intègrent leurs propres longueurs, de sorte qu'un recherche-et-remplacement naïf dans un vidage de base de données - disons, échangeant 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 indique d'abord quelles valeurs portent le domaine afin que vous sachiez ce qu'une simple recherche et remplacement va casser. (L'outil correct pour le remplacement lui-même est WP-CLI search-replace, qui comprend la sérialisation.)
Ensuite, il y a l'inspection du cache et de la session - Redis, Memcached et des caches de fichiers dans les applications PHP contiennent souvent des valeurs sérialisées - et une révision 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 sur un serveur, ce qui importe lorsque le blob sérialisé est une session ou autre chose que vous préférez ne pas télécharger. tant 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 la structure uniquement |
| 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 — Afficher [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 (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 "changement de valeur et de re-sérialisation". Pour modifier des données sérialisées, décoder, effectuer votre modification en PHP ou en JSON et re-sérialiser du côté PHP. Si vous devez modifier manuellement la chaîne brute, n'oubliez pas que vous devez également corriger 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 Cela fait-il dans un onglet de navigateur, en toute sécurité, sans serveur PHP - tant que vous savez que c'est un véritable bord : les chaînes multi-octets peuvent déclencher la longueur en comptant 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, optez plutôt pour WP-CLI.
Outils associés :
