Het formaat heeft geen specificatie buiten de implementatie; de PHP handleiding voor unserialize() is de referentie, en het is expliciet dat het doorgeven van niet-vertrouwde invoer onveilig is.
De eerste keer dat PHP-gegevens in series werden geserialiseerd, kostte me een middag, het was een WP Adminify Support Ticket. De instellingen van een gebruikersdashboardwidget waren in de war geraakt en de "settings" ze beschreven leefden in de wp_options Tabel als een enkele serienummer dat eruitzag als lijnruis: a:4:{s:8:"_builtin";b:1;.... Ik kon het niet lezen, ik kon niet in één oogopslag zien wat er aan de hand was, en ik wilde geen volledige PHP-omgeving draaien om gewoon te print_r een rij. Die middag is waarom ik het belangrijk vind om een decoder te hebben die één browsertab verwijderd is.
Als je in WordPress, WooCommerce, Laravel of een oude PHP-codebase werkt, heb je aan seriegegevens voldaan, of je dat nu wilde of niet. Het wordt weergegeven in optiestabellen, sessiebestanden, cacheopslag en postmeta. En als er iets kapot gaat, is het snel kunnen lezen het verschil tussen een fix van vijf minuten en een middag.
Deze gids behandelt wat het geserialiseerde formaat eigenlijk is, hoe het te decoderen met de niet aantoonen tool op Toolz.dev, en - belangrijk - de enige echte beperking die u moet weten voordat u de uitvoer vertrouwt op niet-Engelse gegevens.
tl;dr: PHP
serialize()packs waarden in een getypte tekenreeks zoalsa:2:{s:4:"name";s:5:"Alice";...}waar elk stuk zijn type en lengte draagt. de niet-Seriliseren-tool ontleedt dat in uw browser en laat het zien als een boom,print_r,var_dump, of JSON - geen PHP-server, geen data-upload Grote kanttekening Ik heb mezelf geverifieerd: het telt de tekenreekslengte in UTF-16 code-eenheden, niet bytes, dus geserialiseerde gegevens met accenten, emoji of CJK-tekens kunnen verkeerd parseren of mislukken Voor ASCII-gegevens is het betrouwbaar Het leest gegevens; het lost geen objectreferenties op en laat u niet op hun plaats bewerken.
Wat is PHP-serialisatie eigenlijk?
Serialisatie verandert een PHP-waarde - een array, object, string, geheel getal, wat dan ook - in een platte string die je kunt opslaan in een databasekolom of een bestand en later opnieuw kunt opbouwen met unserialize(). Twee functies doen het werk: serialize() Converteert een waarde naar de tekenreeks, en unserialize() zet het terug.
Wat het formaat leesbaar maakt als je de code eenmaal kent, is dat elke waarde zijn type en grootte aankondigt. Hier is de hele woordenschat:
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:{...}
Dus een geserialiseerde associatieve array ziet er als volgt uit:
a:3:{s:4:"name";s:10:"John Smith";s:5:"email";s:16:"[email protected]";s:4:"role";s:5:"admin";}
Dat is alleen deze PHP-array, strak verpakt:
array(
'name' => 'John Smith',
'email' => '[email protected]',
'role' => 'admin'
)
Compact voor de machine, dicht bij onleesbaar voor een mens om 14.00 uur tijdens een ondersteuningsgesprek. Dat is het hele probleem dat het gereedschap oplost.
Hoe decodeert de Toolz.dev unserialize tool het?
U plakt de tekenreeks en het parseert het formaat rechtstreeks in JavaScript in uw browser en geeft het resultaat weer. Ik heb elk van deze getest met de eigen parser van de tool tijdens het schrijven, dus het onderstaande gedrag is wat het eigenlijk doet, niet wat een handleiding aanneemt.
Sequentiële arrays met integer-keyed komen terug als een echte lijst. a:2:{i:0;s:5:"apple";i:1;s:6:"banana";} decodeert naar ["apple", "banana"]. Associatieve arrays komen terug als sleutelobjecten. Geneste structuren nestelen correct, arrays in arrays in objecten, helemaal naar beneden.
Objecten behouden hun klassenaam. O:4:"User":2:{s:4:"name";s:3:"Bob";...} decodeert met een __class__ affiche van "User" plus de eigenschappen ervan, zodat u zowel het type als de gegevens kunt zien. Het behandelt zelfs het lastige geval van privé- en beschermde eigendommen, die PHP serialiseert met null-byte voorvoegsels rond de klassenaam - het gereedschap verwijdert deze en toont u de schone eigendomsnaam.
U krijgt acht uitvoerformaten om te schakelen tussen: boomweergave, print_r, var_dump, var_export, Krumo, FirePHP, DBUG en gewone JSON. Ik leef in Tree View voor het verkennen en JSON voor het kopiëren naar iets anders, maar als je spiergeheugen verwacht var_dump output, het is daar.
De enige beperking die u moet weten: Multibyte Strings
Dit is het deel dat ik zou willen dat iemand me vertelt voordat ik een decoder op productiegegevens vertrouwde, dus hier is het vooraf.
PHP's serieel formaat meet de lengte van de tekenreeks in bytes. Het gereedschap meet het in JavaScript-tekenreekslengte, die UTF-16 code-eenheden telt. Voor gewone ASCII zijn dat hetzelfde nummer, dus Engelse gegevens decoderen perfect. Op het moment dat een string een multibyte UTF-8-teken bevat, divergeren ze.
Neem het woord "café" in UTF-8, de "é" is twee bytes, dus PHP serialiseert het als s:5:"café" - lengte vijf, bytes tellen Het gereedschap leest dat 5 en pakt vijf Code-eenheden van de string, die is café" - het slikt het slotcitaat in en verliest zijn plaats. Ik heb precies dit uitgevoerd: een op zichzelf staande s:5:"café"; decodeert naar de verkeerde waarde, en binnen een array zoals a:2:{s:1:"a";s:5:"café";s:1:"b";i:1;} Het mislukt ronduit met Unknown type ':' at position 25.
De praktische afhaalmaaltijd: als u WordPress-opties debugt die puur ASCII zijn - de meeste plug-ininstellingen, slugs, Booleaanse vlaggen - gaat het goed. Als de geserialiseerde gegevens namen, emoji of CJK-tekst met accenten bevatten, kan de decode corrupt zijn of een fout maken, en dat is een echte bug in de tool, niet uw gegevens. (Voor de goede orde: de oplossing aan onze kant is om te parseren op UTF-8 byte-lengte in plaats van .length; het staat op mijn lijst.) Wanneer je erop drukt, zijn WP-CLI's serialisatie-bewuste commando's op de server de betrouwbare uitval.
Er is een gerelateerde, zachtere waarschuwing: de var_dump uitvoerrapporten tekenreekslengtes met dezelfde code-eenheidtelling, dus var_dump("café") voorstellingen string(4) Waar echte PHP zou zeggen string(5), en een emoji toont een lengte die ook niet overeenkomt met de byte-telling van PHP. Lees die getallen als "javascript-lengte" niet "PHP-bytelengte".
Waarom zou u gegevens buiten PHP moeten one-serialiseren?
genoeg redenen, en bijna geen van hen is "voor de lol."
Debuggen is de grote. Een bugrapport zegt dat de instellingen van de gebruiker verkeerd zijn; de instellingen zijn een seriemix in de database; je kunt het probleem pas zien als je het decodeert. De workflow die ik gebruik is: SELECT option_value FROM wp_options WHERE option_name = 'widget_text';, kopieer het resultaat, plak het in de niet-Seriliseren-toolen lees de boom. Tien seconden versus het schrijven van een wegwerp PHP-script.
Migraties zijn de stiekeme. Geserialiseerde tekenreeksen verankeren hun eigen lengte, dus een naïeve find-and-replace op een databasedump - bijvoorbeeld het ruilen van een oud domein voor een nieuw domein - verandert de tekenreeksinhoud zonder het lengtevoorvoegsel bij te werken, en elke betrokken waarde wordt niet-onserialiseerbaar. Decodering laat je eerst precies zien welke waarden het domein dragen, zodat je weet wat een gewone zoek- en vervangingsfunctie zal verbreken. (Het juiste hulpmiddel voor het vervangen zelf is WP-CLI's search-replace, die serialisatie begrijpt.)
Dan is er cache - en sessie-inspectie - Redis, Memcached, en bestandscaches in PHP-apps bevatten vaak geserialiseerde waarden - en beveiligingsbeoordeling, waarbij je moet zien wat er daadwerkelijk is opgeslagen voordat je kunt beoordelen of het veilig is.
Is het decoderen van geserialiseerde gegevens in de browser veilig?
veiliger dan het in PHP doen, en het waard zijn om te begrijpen waarom.
php's native unserialize() Heeft een lange beveiligingsgeschiedenis. een vervaardigde string, het kan willekeurige objecten instantiëren en hun magische methoden activeren (__wakeup, __destruct), die onder de juiste omstandigheden een aanval van objectinjecties wordt en in het slechtste geval de uitvoering van de remote code. Daarom is het staande advies om nooit te bellen unserialize() op niet-vertrouwde inbreng, en om te slagen ['allowed_classes' => false] Wanneer moet u.
de browsertool omzeilt dat allemaal omdat het nooit lymfe PHP. Het leest het stringformaat en geeft de structuur weer - er worden geen PHP-objecten gemaakt, er worden geen magische methoden afgevuurd en er is geen interpreter om te exploiteren. De gegevens blijven ook op uw apparaat; het wordt lokaal geparseerd en nooit naar een server verzonden, wat belangrijk is wanneer de geserialiseerde blob een sessie is of iets anders dat u liever niet uploadt. Dus voor nakijkend Niet-vertrouwde seriegegevens, de browser is echt de veiligere plek.
inheemse php unserialize() |
Toolz.dev-browsertool | |
|---|---|---|
| Instantiatieert objecten | Ja (injectierisico) | Nee - leest alleen structuur |
| draait op een server | ja | Nee - lokaal in browser |
| Veilig op niet-vertrouwde input | ALLEEN MET allowed_classes |
Ja, het wordt nooit uitgevoerd |
| Handgrepen met meerdere byte lengtes | correct (bytes) | niet betrouwbaar (code-eenheden) |
| Hiermee lost objectreferenties op | ja | Nee - shows [Reference] |
| voornemen | Live-waarden reconstrueren | Inspecteren en lezen |
Die tabel is ook een eerlijke samenvatting van de afweging: de browsertool is de veilige lezer, geen drop-in vervanging voor de taalfunctie.
Wat zijn de gemeenschappelijke real-world bronnen?
Als je hier bent, is het waarschijnlijk een van deze. WordPress leunt zwaar op serialisatie in wp_options teneinde widget_text, sidebars_widgets, theme_mods_*, de lijst met actieve plug-ins, cron-schema's. WooCommerce slaat productvariaties, attributen en aangepaste velden op als seriegestuurde post-meta, daarom gaat een product met verkeerde prijzen zo vaak terug naar een geserialiseerde waarde. Laravel gebruikt serialisatie voor bestandscache en sessieopslag. Het configuratiesysteem van Magento staat er vol mee. Overal hetzelfde formaat; dezelfde decoderingsbenadering.
Een paar dingen die de tool niet doet
Twee eerlijke grenzen Het lost geen referenties op - PHP kan een verwijzing naar een eerdere waarde serialiseren (r: of R:), en de tool toont die als een letterlijke [Reference] markeer in plaats van ze te volgen En het is een lezer, geen editor: er is geen & quot; wijzig deze waarde en opnieuw serialiseren" modus Om geserialiseerde gegevens te wijzigen, decodeer deze, voer uw wijziging in PHP of in JSON uit en serialiseer opnieuw aan de PHP-kant. Als u de onbewerkte tekenreeks met de hand moet bewerken, onthoud dan dat u ook de lengtevoorvoegsels moet repareren, en - volgens de sectie hierboven - bytes tellen, geen tekens.
Veelgestelde vragen
Waar wordt PHP-serialisatie gebruikt voor?
Het converteert complexe waarden zoals arrays en objecten naar een enkele tekenreeks die kan leven in een databasekolom, een bestand of een cache, en later opnieuw kan worden opgebouwd. WordPress, WooCommerce, Laravel en Magento gebruiken het allemaal zwaar voor instellingen, sessiegegevens en gecachte waarden.
Kan ik PHP-gegevens ongedaan maken zonder een PHP-server?
Ja. de niet-Seriliseren-tool Parses geserialiseerde PHP in JavaScript in uw browser. Geen PHP-installatie, geen server, geen account.
Is het veilig om geserialiseerde gegevens in de browser te decoderen?
Ja, en het is veiliger dan PHP's eigen unserialize() op niet-vertrouwde invoer, omdat de tool alleen de tekenreeksstructuur leest. Het instantiëren nooit PHP-objecten, dus de magische methode-aanvallen die native maken unserialize() Gevaarlijk kan gewoon niet gebeuren.
Waarom decodeert mijn serienummer niet?
De gebruikelijke oorzaken zijn een afgeknotte kopie (je hebt de sleepbeugel of het eerste teken gemist), een voorvoegsel voor gebroken lengte na een zoek-en-vervanging, of gegevens die niet echt PHP zijn geserialiseerd. Nog een die mensen vangt: als de tekenreeks geaccentueerde tekens, emoji of CJK-tekst bevat, kan de code-eenheid tellen van de tool het verkeerd scheiden, omdat PHP de tekenreekslengte in bytes telt en de tool UTF-16-eenheden telt.
Kan ik de WordPress WP_Options-waarden ermee decoderen?
Ja - dat is een van de meest voorkomende toepassingen Query de option_value, plak het in en lees de structuur. Houd er rekening mee dat als de optie Multibyte-tekst bevat, u mogelijk WP-CLI op de server nodig heeft.
Kan ik geserialiseerde gegevens bewerken met deze tool?
Nee, het is een lezer. Om een waarde te wijzigen, decodeer deze, bewerk in PHP of JSON en serialiseer opnieuw aan de PHP-kant. De onbewerkte tekenreeks met de hand bewerken betekent dat u de voorvoegsels van de bytelengte zelf moet repareren, wat foutgevoelig is.
Wat is het verschil tussen PHP-serialisatie en JSON?
Serialisatie behoudt PHP-specifieke typen, waaronder namen van objectklassen en privé-eigenschappen. JSON is taal-agnostisch en kent alleen strings, getallen, booleans, null, arrays en objecten. Nieuwe code geeft over het algemeen de voorkeur aan JSON omdat json_decode() Instantiëren geen objecten, dus het vermijdt het injectierisico en JSON is overal leesbaar. U kunt een gedecodeerde structuur naar de JSON-formatter om er zo mee te werken.
Behandelt het gereedschap geserialiseerde objecten, niet alleen arrays?
Ja. Objecten decoderen met hun klassenaam bewaard naast de eigenschappen, en privé of beschermde eigenschappen (die PHP serialiseert met null-byte voorvoegsels) worden opgeschoond tot leesbare namen in de uitvoer.
conclusie
Geserialiseerde PHP-gegevens zijn onvermijdelijk als je WordPress, WooCommerce of Laravel aanraakt, en het on-demand kunnen lezen verandert een categorie van frustrerende bugs in snelle. de niet-Seriliseren-tool doet dat in een browsertabblad, veilig, zonder PHP-server - zolang je maar weet dat het één echte rand is: multibyte-strings kunnen het tellen van de lengte uitschakelen, en ASCII-gegevens zijn waar het schijnt Plakken, lezen, repareren En wanneer de gegevens vol accenten of emoji zitten, grijp dan naar WP-CLI.
Verwante hulpmiddelen:
