Il formato non ha specifiche esterne all'implementazione; IL Manuale PHP per unserialize() è il riferimento ed è esplicito che il passaggio di input non attendibili non è sicuro.
La prima volta che i dati PHP serializzati mi sono costati un pomeriggio, era un ticket di supporto per amministrare WP. Le impostazioni del widget del dashboard dell'utente erano diventate in tilt e le "impostazioni" che descrivevano vivevano nel wp_options Tabella come una singola stringa serializzata che sembrava rumore di linea: a:4:{s:8:"_builtin";b:1;.... Non riuscivo a leggerlo, non potevo dire a colpo d'occhio cosa c'era che non andava e non volevo far girare un ambiente PHP completo solo per print_r una riga. Quel pomeriggio è il motivo per cui mi interessa avere un decoder che è a una scheda del browser di distanza.
Se lavori in WordPress, WooCommerce, Laravel o qualsiasi base di codice PHP legacy, hai incontrato dati serializzati, che tu lo volessi o meno. Viene visualizzato nelle tabelle delle opzioni, nei file di sessione, negli archivi di cache e nel post meta. E quando qualcosa si rompe, riuscire a leggerlo velocemente fa la differenza tra una soluzione di cinque minuti e un pomeriggio.
Questa guida spiega cosa sia effettivamente il formato serializzato, come decodificarlo con il deselezionare strumento su Toolz.dev e, cosa importante, l'unica vera limitazione di cui devi essere a conoscenza prima di fidarti dell'output su dati non inglesi.
tl; dr: php
serialize()racchiude i valori in una stringa digitata comea:2:{s:4:"name";s:5:"Alice";...}dove ogni pezzo porta il suo tipo e lunghezza. la Strumento di non serializzare lo analizza nel tuo browser e lo mostra come un albero,print_r,var_dump, o JSON - nessun server PHP, nessun caricamento di dati Grande avvertenza Ho verificato me stesso: conta la lunghezza della stringa in unità di codice UTF-16, non byte, quindi i dati serializzati contenenti accenti, emoji o caratteri CJK possono analizzare erroneamente o fallire Per i dati ASCII è affidabile Legge i dati; non risolve i riferimenti agli oggetti o ti consente di modificare sul posto.
Che cos'è davvero la serializzazione PHP?
La serializzazione trasforma un valore PHP - un array, un oggetto, una stringa, un numero intero, qualunque cosa - in una stringa piatta che puoi archiviare in una colonna di database o in un file e successivamente ricostruire con unserialize(). Due funzioni fanno il lavoro: serialize() Converte un valore in stringa e unserialize() lo converte.
Ciò che rende leggibile il formato una volta che si conosce il codice è che ogni valore annuncia il suo tipo e dimensione. Ecco tutto il vocabolario:
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:{...}
Quindi un array associativo serializzato è simile a questo:
a:3:{s:4:"name";s:10:"John Smith";s:5:"email";s:16:"[email protected]";s:4:"role";s:5:"admin";}
Che è solo questo array PHP, imballato stretto:
array(
'name' => 'John Smith',
'email' => '[email protected]',
'role' => 'admin'
)
Compatto per la macchina, quasi illeggibile per un essere umano alle 14:00 su una chiamata di supporto. Questo è l'intero problema che lo strumento risolve.
In che modo lo strumento Toolz.dev non serializza lo decodifica?
Incolla la stringa e analizza il formato direttamente in JavaScript nel tuo browser e visualizza il risultato. Ho testato ciascuno di questi contro il parser dello strumento durante la scrittura, quindi il comportamento qui sotto è ciò che effettivamente fa, non quello che un manuale presume.
Gli array con chiave intera sequenziale tornano come un elenco reale. a:2:{i:0;s:5:"apple";i:1;s:6:"banana";} decodifica a ["apple", "banana"]. Gli array associativi vengono restituiti come oggetti con chiave. Le strutture nidificate si annidano correttamente, gli array all'interno degli array all'interno degli oggetti, fino in fondo.
Gli oggetti mantengono il nome della classe. O:4:"User":2:{s:4:"name";s:3:"Bob";...} decodifica con a __class__ segnalino di "User" inoltre le sue proprietà, in modo da poter vedere sia il tipo che i dati Gestisce persino il caso scomodo di proprietà private e protette, che PHP serializza con prefissi null-byte attorno al nome della classe - lo strumento li spoglia e ti mostra il nome della proprietà pulita.
Ottieni otto formati di output per passare da: vista ad albero, print_r, var_dump, var_export, Krumo, Firephp, DBug e Plain JSON. Vivo a Tree View per esplorare e JSON per aver copiato in qualcos'altro, ma se la tua memoria muscolare se lo aspetta var_dump output, è proprio lì.
L'unica limitazione che devi sapere: stringhe multibyte
Questa è la parte che vorrei che qualcuno mi dicesse prima di fidarmi di un decoder sui dati di produzione, quindi eccolo in anticipo.
Il formato serializzato PHP misura la lunghezza della stringa in byte. Lo strumento lo misura lunghezza della stringa javascript, che conta le unità di codice UTF-16. Per ASCII semplici quelli sono lo stesso numero, quindi i dati inglesi decodificano perfettamente. Nel momento in cui una stringa contiene un carattere UTF-8 multibyte, divergono.
Prendi la parola "café". In UTF-8 il "É" è di due byte, quindi PHP lo serializza come s:5:"café" - lunghezza cinque, conteggio dei byte Lo strumento lo legge 5 e ne prende cinque Codice Unità dalla stringa, che è café" - ingoia la citazione di chiusura e perde il suo posto Ho eseguito esattamente questo: uno standalone s:5:"café"; decodifica al valore sbagliato e all'interno di un array a:2:{s:1:"a";s:5:"café";s:1:"b";i:1;} fallisce apertamente con Unknown type ':' at position 25.
Il punto pratico: se stai eseguendo il debug delle opzioni WordPress che sono ASCII puro - la maggior parte delle impostazioni del plugin, slugs, flag booleani - stai bene Se i dati serializzati contengono nomi accentati, emoji o testo CJK, la decodifica potrebbe corrompersi o commettere errori, e questo è un vero bug nello strumento, non i tuoi dati. (Per la cronaca, la correzione alla nostra fine è analizzare in base alla lunghezza dei byte UTF-8 anziché .length; è nella mia lista.) Quando lo colpisci, i comandi sensibili alla serializzazione di WP-CLI sul server sono l'affidabile fallback.
C'è un avvertimento correlato e più delicato: il var_dump OUTPUT segnala le lunghezze delle stringhe utilizzando lo stesso conteggio delle unità di codice, quindi var_dump("café") mostra string(4) dove direbbe il vero php string(5)e un emoji mostra una lunghezza che non corrisponderà nemmeno al numero di byte di PHP. Leggi quei numeri come "JavaScript Lunghezza,"non "Lunghezza del byte PHP"
Perché dovresti non serializzare i dati al di fuori di PHP?
Un sacco di ragioni, e quasi nessuna è "per divertimento"
Il debug è quello grande. Una segnalazione di bug dice che le impostazioni dell'utente sono errate; le impostazioni sono un BLOB serializzato nel database; non puoi vedere il problema fino a quando non lo decodifichi. Il flusso di lavoro che utilizzo è: SELECT option_value FROM wp_options WHERE option_name = 'widget_text';, copia il risultato, incollalo in Strumento di non serializzare, e leggi l'albero. Dieci secondi contro la scrittura di uno script PHP usa e getta.
Le migrazioni sono quelle subdole Le stringhe serializzate incorporano le proprie lunghezze, quindi un ingenuo "trova e sostituisci" su un dump del database - ad esempio, scambiando un vecchio dominio con uno nuovo - modifica il contenuto della stringa senza aggiornare il prefisso della lunghezza e ogni valore interessato diventa non serializzabile La decodifica prima ti mostra esattamente quali valori trasportano il dominio in modo da sapere cosa romperà una semplice ricerca e sostituzione. (Lo strumento corretto per la sostituzione stessa è WP-CLI's search-replace, che comprende la serializzazione.)
Poi c'è l'ispezione della cache e della sessione - Redis, Memcached e le cache dei file nelle app PHP spesso contengono valori serializzati - e la revisione della sicurezza, dove è necessario vedere cosa è effettivamente memorizzato prima di poter giudicare se è sicuro.
La decodifica dei dati serializzati nel browser è sicura?
Più sicuro che farlo in PHP e vale la pena capire perché.
Nativo di PHP unserialize() ha una lunga cronologia di sicurezza. alimentato una stringa artigianale, può istanziare oggetti arbitrari e attivare i loro metodi magici (__wakeup, __destruct), che nelle giuste condizioni diventa un attacco di iniezione oggetto e, nel peggiore dei casi, l'esecuzione di codice remoto. Ecco perché il consiglio permanente è di non chiamare mai unserialize() su input non attendibili, e passare ['allowed_classes' => false] Quando devi.
Lo strumento browser elude tutto questo perché mai corre PHP. legge il formato stringa e visualizza la struttura - non vengono creati oggetti PHP, nessun fuoco di metodi magici, e non c'è nessun interprete da sfruttare I dati rimangono anche sul tuo dispositivo; vengono analizzati localmente e mai inviati a un server, il che conta quando il blob serializzato è una sessione o qualcos'altro che preferiresti non caricare Quindi per ispezione Dati serializzati non attendibili, il browser è davvero il luogo più sicuro.
Nativo PHP unserialize() |
Toolz.dev Strumento browser | |
|---|---|---|
| istanzia gli oggetti | Sì (rischio di iniezione) | No - legge solo la struttura |
| Esegue su un server | certo | No - locale nel browser |
| Sicuro su input non attendibili | Solo con allowed_classes |
Sì, non viene mai eseguito |
| Gestisce lunghezze multibyte | correttamente (byte) | Non in modo affidabile (unità di codice) |
| Risolve i riferimenti agli oggetti | certo | No - spettacoli [Reference] |
| proposito | ricostruire i valori in tempo reale | Ispeziona e leggi |
Quella tabella è anche un riassunto onesto del compromesso: lo strumento del browser è il lettore sicuro, non un sostituto drop-in per la funzione linguistica.
Quali sono le fonti comuni del mondo reale?
Se sei qui, probabilmente è uno di questi. WordPress si basa fortemente sulla serializzazione wp_options - widget_text, sidebars_widgets, theme_mods_*, l'elenco dei plug-in attivi, Cron Schedules. WooCommerce memorizza variazioni di prodotto, attributi e campi personalizzati come meta serializzato, motivo per cui un prodotto con un prezzo errato così spesso risale a un valore serializzato. Laravel utilizza la serializzazione per la cache dei file e l'archiviazione della sessione. Il sistema di configurazione di Magento ne è pieno. Stesso formato ovunque; stesso approccio di decodifica.
un paio di cose che lo strumento non fa
Due confini onesti Non risolve i riferimenti - PHP può serializzare un puntatore su un valore precedente (r: oppure R:), e lo strumento li mostra come letterale [Reference] marcatore piuttosto che seguirli Ed è un lettore, non un editor: non c'è & quot; cambia questo valore e ri-serializza& quot; modalità Per modificare i dati serializzati, decodificali, fai il tuo cambiamento in PHP o in JSON, e ri-serializza sul lato PHP Se devi modificare a mano la stringa grezza, ricorda che devi correggere anche i prefissi di lunghezza, e - per la sezione sopra - conta i byte, non i caratteri.
Domande frequenti
A cosa serve la serializzazione PHP?
Converte valori complessi come array e oggetti in una singola stringa che può vivere in una colonna di database, in un file o in una cache e essere ricostruita in seguito. WordPress, WooCommerce, Laravel e Magento lo usano tutti pesantemente per impostazioni, dati di sessione e valori memorizzati nella cache.
Posso deserializzare i dati PHP senza un server PHP?
si. la Strumento di non serializzare Analizza PHP serializzato in JavaScript nel tuo browser. Nessuna installazione PHP, nessun server, nessun account.
È sicuro decodificare i dati serializzati nel browser?
Sì, ed è più sicuro di quello di PHP unserialize() Su un input non attendibile, perché lo strumento legge solo la struttura delle stringhe. Non istanzia mai gli oggetti PHP, quindi gli attacchi del metodo magico che rendono nativo unserialize() pericoloso semplicemente non può accadere.
Perché la mia stringa serializzata non riesce a decodificare?
Le cause abituali sono una copia troncata (hai perso le parentesi graffe finali o il primo carattere), un prefisso di lunghezza rotto dopo un ritrovamento e una sostituzione o dati che non sono effettivamente serializzati PHP. Un altro che cattura le persone: se la stringa contiene caratteri accentati, emoji o testo CJK, il conteggio della lunghezza dell'unità di codice dello strumento può analizzarlo erroneamente, perché PHP conta la lunghezza della stringa in byte e lo strumento conta le unità UTF-16.
Posso decodificare i valori di WordPress WP_Options con esso?
Sì - questo è uno degli usi più comuni Interroga il option_value, incollalo e leggi la struttura. Tieni presente che se l'opzione contiene testo multibyte, potresti aver bisogno di wp-cli sul server.
Posso modificare i dati serializzati con questo strumento?
No, è un lettore. Per modificare un valore, decodificarlo, modificare in PHP o JSON e ri-serializzare sul lato PHP. Modificare a mano la stringa RAW significa correggere da soli i prefissi di lunghezza del byte, che è soggetto a errori.
Qual è la differenza tra la serializzazione PHP e JSON?
La serializzazione conserva i tipi specifici di PHP, inclusi i nomi delle classi degli oggetti e le proprietà private. JSON è indipendente dalla lingua e conosce solo stringhe, numeri, booleani, null, array e oggetti. Il nuovo codice generalmente preferisce JSON perché json_decode() Non istanzia gli oggetti, quindi evita il rischio di iniezione e JSON è leggibile ovunque. puoi spostare una struttura decodificata in Formattatore JSON per lavorarci in questo modo.
Lo strumento gestisce oggetti serializzati, non solo array?
si. Gli oggetti decodificano con il loro nome di classe conservato accanto alle proprietà e le proprietà private o protette (che PHP serializza con prefissi null-byte) vengono ripuliti per i nomi leggibili nell'output.
conclusione
I dati PHP serializzati sono inevitabili se tocchi WordPress, WooCommerce o Laravel e la possibilità di leggerli su richiesta trasforma una categoria di bug frustranti in rapidi. la Strumento di non serializzare fa che in una scheda del browser, in modo sicuro, senza un server PHP - fintanto che si conosce il suo unico bordo reale: le stringhe multibyte possono far scattare il conteggio della lunghezza, e i dati ASCII sono dove brilla Incolla, leggi, fissa E quando i dati sono pieni di accenti o emoji, raggiungere invece WP-CLI.
Strumenti correlati:
