Szerializálás - Serialization

Ez a cikk az adatszerkezet kódolásáról szól. A többi felhasználást lásd: Sorosítás (egyértelműsítés) .

A számítástechnikában a szerializálás (amerikai helyesírás) vagy a szerializálás (az Egyesült Királyság helyesírása) az adatszerkezet vagy objektumállapot olyan formátumba való lefordítása, amely tárolható (például fájlban vagy memóriaadat -pufferben ) vagy továbbítható (például egy számítógépes hálózat ) és a rekonstruált később (esetleg egy másik számítógépes környezetben). Amikor a kapott bit sorozatot a szerializációs formátumnak megfelelően újraolvassuk, felhasználható az eredeti objektum szemantikailag azonos klónjának létrehozásához. Sok összetett objektum esetében, például azoknál, amelyek széles körben használják a hivatkozásokat , ez a folyamat nem egyszerű. Sorszámozás az objektum-orientált tárgyakat nem tartalmaz a hozzájuk tartozó módszerek , amelyekkel korábban kapcsolódnak.

Az objektum sorosításának ezt a folyamatát bizonyos helyzetekben objektum rendezésének is nevezik . Az ellentétes műveletet, extrahálására adatstruktúra egy sor bájt, jelentése deserialization , (más néven deszerializációs vagy unmarshalling ).

Használ

Módszerek:

Ezen funkciók némelyikének használatához meg kell őrizni az architektúra függetlenségét. Például a disztribúció maximális kihasználása érdekében egy másik hardver architektúrán futó számítógépnek képesnek kell lennie arra, hogy megbízhatóan rekonstruálja a sorosított adatfolyamot, a végtelenségtől függetlenül . Ez azt jelenti, hogy az adatszerkezet memóriaelrendezésének közvetlen másolásának egyszerűbb és gyorsabb eljárása nem működik megbízhatóan minden architektúra esetén. Az adatstruktúra architektúrától független formalizálása azt jelenti, hogy megelőzzük a bájtsorrendet , a memória elrendezését vagy az adatstruktúrák különböző programozási nyelveken való ábrázolásának különböző módjait .

Minden szerializációs séma velejárója, hogy mivel az adatok kódolása definíció szerint soros, a sorosított adatszerkezet egy részének kinyerése megköveteli, hogy a teljes objektumot az elejétől a végéig olvassák és rekonstruálják. Ez a linearitás sok alkalmazásban előny, mert lehetővé teszi az egyszerű, közös I/O interfészek használatát az objektum állapotának megőrzésére és továbbítására. Azokban az alkalmazásokban, ahol a nagyobb teljesítmény jelent problémát, ésszerűbb lehet erőfeszítéseket fordítani egy bonyolultabb, nemlineáris tárolási szervezet kezelésére.

A primitív mutatóobjektumok még egyetlen gépen is túl törékenyek a mentéshez, mert az objektumok, amelyekre mutatnak, újra betölthetők a memória egy másik helyére. Ennek kezelésére a szerializálási folyamat magában foglal egy unswizzling vagy pointer unswizzling nevű lépést , ahol a közvetlen mutató hivatkozásokat név vagy pozíció alapján referenciákká alakítják át. A deszerializációs folyamat magában foglal egy fordított lépést, amelyet pointer swizzlingnek neveznek .

Mivel mind a szerializálás, mind a deserializálás a közös kódból hajtható végre (például a Microsoft Foundation osztályok Serialize funkciója ), lehetséges, hogy a közös kód egyszerre teszi mindkettőt, és így 1) észleli a különbségeket az objektumok között. és 2) a bemenetet szolgáltatják a következő ilyen észleléshez. Nem szükséges ténylegesen felépíteni az előző példányt, mert menet közben észlelhetők a különbségek, ezt a technikát differenciális végrehajtásnak nevezik. Ez hasznos azoknak a felhasználói felületeknek a programozásában, amelyek tartalma időben változik-grafikus objektumok hozhatók létre, távolíthatók el, módosíthatók, vagy kezelhetők a beviteli események kezelésére anélkül, hogy szükségszerűen külön kódot kellene írni ezekhez.

Hátrányok

A szerializálás megtöri az absztrakt adattípus átlátszatlanságát azáltal, hogy potenciálisan felfedi a privát megvalósítási részleteket. Az összes adattagot sorosító triviális megvalósítások sérthetik a beágyazást .

Annak érdekében, hogy a versenytársakat eltántorítsák a kompatibilis termékek gyártásától, a szabadalmazott szoftverek kiadói gyakran üzleti titokban tartják programjaik sorozatszerkesztési formátumainak részleteit . Néhányan szándékosan elhomályosítják vagy akár titkosítják a sorosított adatokat. Az interoperabilitás azonban megköveteli, hogy az alkalmazások képesek legyenek megérteni egymás szerializációs formátumait. Ezért a távoli metódushívási architektúrák, például a CORBA , részletesen meghatározzák a sorosítási formátumukat.

Sok intézmény, például archívumok és könyvtárak, kísérlet arra, hogy időtálló a mentési archívum-különösen tárol guba -by tárolja őket néhány viszonylag ember által olvasható szerializált formátumban.

Szerializációs formátumok

Fő cikk: Az adatok sorosítási formátumainak összehasonlítása

A Xerox Network Systems Courier technológia az 1980-as évek elején befolyásolta az első széles körben elfogadott szabványt. A Sun Microsystems 1987 -ben tette közzé a külső adatábrázolást (XDR). Az XDR nyílt formátumú , és szabványosított STD 67 (RFC 4506).

Az 1990-es évek végén elindult a standard sorosítási protokollok alternatívájának biztosítása: az XML-t , egy SGML- részhalmazot használták az ember számára olvasható szöveges kódolás előállítására . Egy ilyen kódolás hasznos lehet tartós objektumok esetén, amelyeket az emberek elolvashatnak és megértenek, vagy a programozási nyelvtől függetlenül más rendszerekkel kommunikálhatnak. Hátránya, hogy elveszíti a kompaktabb, bájtfolyam-alapú kódolást, de ekkor a nagyobb tárolási és átviteli kapacitás miatt a fájlméret kevésbé volt aggodalomra okot adó, mint a számítástechnika kezdeti napjaiban. A 2000 -es években az XML -t gyakran használták a strukturált adatok aszinkron átviteléhez kliens és szerver között Ajax webes alkalmazásokban. Az XML nyílt formátum, és W3C ajánlásként van szabványosítva .

A JSON az XML egyszerűbb szöveges alternatívája, amelyet gyakran használnak kliens-szerver kommunikációra a webes alkalmazásokban. A JSON a JavaScript szintaxisán alapul , de független a JavaScript-től és más programozási nyelveken is támogatott. A JSON nyílt formátum, szabványosítva STD 90 ( RFC  8259 ), ECMA-404 és ISO/IEC 21778: 2017 .

A YAML szigorú JSON-szuperset, és további funkciókat tartalmaz, mint például az adattípusok címkézésének fogalma, a nem hierarchikus adatstruktúrák támogatása, az adatok behúzással való strukturálásának lehetősége és a skaláris adatok idézésének több formája. A YAML egy nyílt formátum.

A tulajdonságlistákat a NeXTSTEP , a GNUstep , a macOS és az iOS keretrendszerek használják sorosításhoz . A tulajdonságlista , vagy röviden a p-lista nem egyetlen sorosítási formátumra vonatkozik, hanem több különböző változatra, néhány ember által olvashatóra és egy binárisra.

Nagy volumenű tudományos adatkészletekhez, például műholdas adatokhoz és numerikus éghajlati, időjárási vagy óceáni modellek kimenetéhez speciális bináris sorosítási szabványokat dolgoztak ki, pl. HDF , netCDF és a régebbi GRIB .

Programozási nyelv támogatása

Számos objektumorientált programozási nyelv közvetlenül támogatja az objektumok szerializálását (vagy objektum archiválását ), akár szintaktikai cukorelemekkel , akár szabványos interfészt biztosítva ehhez. Az ilyen nyelvek közé tartozik a Ruby , a Smalltalk , a Python , a PHP , az Objective-C , a Delphi , a Java és a .NET nyelvcsalád. Vannak olyan könyvtárak is, amelyek sorosítási támogatást adnak azokhoz a nyelvekhez, amelyekben nincs natív támogatás.

C és C ++
A C és a C ++ nem biztosítja a sorosítást, mint bármilyen magas szintű konstrukciót, de mindkét nyelv támogatja a beépített adattípusok bármelyikét , valamint a sima régi adatstruktúrákat bináris adatként. Mint ilyen, általában triviális az egyedi szerializációs függvények írása. Ezenkívül a fordítóalapú megoldások, mint például az ODB ORM rendszer a C ++ és a gSOAP eszköztár C és C ++ számára, képesek automatikusan generálni a sorosítási kódot az osztály deklarációinak kevés vagy semmilyen módosítása nélkül. Más népszerű szerializációs keretrendszerek a Boost.Serialization a Boost Framework , az S11n keretrendszer és a Cereal. Az MFC-keretrendszer (Microsoft) a Document-View architektúra részeként sorosítási módszertant is kínál.
CFML
A CFML lehetővé teszi az adatstruktúrák sorosítását WDDX -be a <cfwddx>címkével és JSON -ba a SerializeJSON () függvénnyel.
Delphi
A Delphi beépített mechanizmust biztosít a komponensek (más néven perzisztens objektumok) sorosítására, amely teljesen integrálva van az IDE-vel . A komponens tartalmát egy DFM fájlba menti, és menet közben újratölti.
Megy
A Go natívan támogatja a JSON és XML adatok unmarshalling/sorrendbe állítását . Vannak olyan harmadik féltől származó modulok is, amelyek támogatják a YAML és a protokollpuffereket .
Haskell
A Haskell -ben a sorosítást azok a típusok támogatják, amelyek a Read and Show típusú osztályok tagjai . Minden típus, amely a típusosztály tagja, Readdefiniál egy funkciót, amely kivonja az adatokat a kiíratott adatok karakterlánc -ábrázolásából. A Showtípusosztály pedig azt a showfüggvényt tartalmazza , amelyből az objektum karakterlánc -ábrázolása előállítható. A programozónak nem kell kifejezetten definiálnia a függvényeket - pusztán az, hogy egy típust leolvasó vagy származtató show -nak, vagy mindkettőnek származtatja, sok esetben előállíthatja a fordítót a megfelelő függvények előállítására (de nem mindenre: a függvénytípusok például nem tudják automatikusan levezetni a Show -t vagy Olvasás). A Show automatikusan előállított példánya érvényes forráskódot is előállít, így ugyanez a Haskell-érték generálható a show által előállított kód futtatásával, például egy Haskell-tolmácsban. A hatékonyabb sorszámozás, vannak haskell könyvtárak, amelyek lehetővé teszik a nagy sebességű sorszámozás bináris formában, például bináris .
Jáva
A Java automatikus szerializációt biztosít, amely megköveteli, hogy az objektumot az interfész megvalósításával meg kell jelölni . Az interfész megvalósítása az osztályt "rendben van sorosítani" jelzi, és a Java ezután belsőleg kezeli a szerializációt. A kezelőfelületen nincsenek meghatározva szerializálási módszerek , de a sorozható osztályok opcionálisan definiálhatnak bizonyos speciális nevekkel és aláírásokkal rendelkező metódusokat, amelyeket ha definiálnak, a szerializálási/desializálási folyamat részeként hívják meg őket. A nyelv emellett lehetővé teszi a fejlesztő számára, hogy alaposabban felülbírálja a szerializációs folyamatot egy másik interfész, az interfész megvalósításával, amely két speciális módszert tartalmaz az objektum állapotának mentésére és visszaállítására. Három elsődleges oka van annak, hogy az objektumok alapértelmezés szerint nem sorosíthatók, és a Java sorosítási mechanizmusához való hozzáféréshez az interfészt kell megvalósítani . Először is, nem minden objektum rögzít hasznos szemantikát sorosított állapotban. Például egy objektum az aktuális JVM állapotához van kötve . Nincs olyan kontextus, amelyben egy deserializált objektum hasznos szemantikát tartana fenn. Másodszor, az objektumok sorosított állapota része az osztályok kompatibilitási szerződésének. A kompatibilitás fenntartása a sorozatozható osztályok verziói között további erőfeszítéseket és mérlegelést igényel. Ezért az osztály sorosíthatóvá tételének szándékos tervezési döntésnek kell lennie, és nem alapértelmezett feltételnek. Végül a sorozatosítás lehetővé teszi az osztály nem átmeneti magántagjaihoz való hozzáférést , amelyek egyébként nem érhetők el. Az érzékeny információkat (például jelszót) tartalmazó osztályok nem lehetnek sorosíthatók és külső megjeleníthetők. A szabványos kódolási módszer az objektum osztályleírójának és sorosítható mezőinek rekurzív gráf-alapú fordítását használja bájtfolyammá. A primitívek, valamint a nem tranziens, nem statikus hivatkozású objektumok kódolva vannak a folyamban. Minden olyan objektumot, amelyre a sorosított objektum hivatkozik egy mezőn keresztül, amelyet nem jelöltek meg, szintén sorosítani kell; és ha a nem átmeneti objektumhivatkozások teljes gráfjában szereplő bármely objektum nem sorosítható, akkor a szerializálás meghiúsul. A fejlesztő befolyásolhatja ezt a viselkedést, ha átmeneti objektumokat jelöl meg, vagy újradefiniálja az objektumok sorosítását, hogy a referenciagráf bizonyos része csonka legyen, és ne legyen sorosítva. A Java nem használ konstruktőrt az objektumok sorosítására. Lehetőség van a Java objektumok sorozatozására a JDBC -n keresztül, és adatbázisban való tárolásra. Bár a Swing összetevők megvalósítják a sorosítható interfészt, nem garantált, hogy hordozhatóak lesznek a Java virtuális gép különböző verziói között. Mint ilyen, a Swing komponens, vagy bármely alkatrész, amely örökli, sorosítható egy bájtfolyammá, de nem garantált, hogy ez egy másik gépen újra összeállítható.java.io.Serializable SerializableExternalizableSerializableThreadThreadtransient
JavaScript
Az ECMAScript 5.1 óta a JavaScript tartalmazza a beépített JSONobjektumot és annak módszereit JSON.parse()és JSON.stringify(). Bár a JSON eredetileg a JavaScript egy részhalmazán alapul, vannak olyan határidős esetek, amikor a JSON nem érvényes JavaScript. Pontosabban, a JSON lehetővé teszi, hogy az U+2028 LINE SEPARATOR és az U+2029 PARAGRAPH SEPARATOR Unicode vonalvégződések szabadon jelenjenek meg idézett karakterláncokban, míg az ECMAScript 2018 és régebbi nem. Lásd a JSON fő cikkét .
Julia
A Julia a sorosítást a serialize()/ deserialize()modulokon keresztül hajtja végre , amelyek a Julia ugyanazon verzióján és / vagy ugyanazon rendszerkép példányán működnek. A HDF5.jlcsomag stabilabb alternatívát kínál, dokumentált formátumot és közös könyvtárat használva, különböző nyelvű csomagolóanyagokkal, míg az alapértelmezett sorosítási formátumot javasoljuk, hogy inkább a hálózati kommunikáció maximális teljesítményét szem előtt tartva tervezték.
Selypít
Általában egy Lisp adatstruktúra sorosítható a " read" és " print" függvényekkel . Egy változó foo, amely például tömblistát tartalmaz, kinyomtatja (print foo). Hasonló módon egy objektum leolvasható egy s nevű adatfolyamból (read s). A Lisp megvalósításnak ezt a két részét nyomtatónak és olvasónak hívják. A " print" kimenete ember által olvasható; használ listákat demarked zárójel, például: (4 2.9 "x" y). A Lisp számos típusában, beleértve a Common Lisp -t is, a nyomtató nem tud minden típusú adatot ábrázolni, mert nem világos, hogyan kell ezt megtenni. A Common Lisp -ben például a nyomtató nem tud CLOS objektumokat nyomtatni. Ehelyett a programozó írhat egy metódust az általános függvényre print-object, ez az objektum nyomtatásakor lesz meghívva. Ez némileg hasonlít a Ruby -ban használt módszerhez. Maga a Lisp -kód az olvasó szintaxisába van írva, amelyet olvasási szintaxisnak neveznek. A legtöbb nyelv külön és különböző elemzőket használ a kódok és adatok kezelésére, Lisp csak egyet. A lisp kódot tartalmazó fájl adatstruktúraként olvasható be a memóriába, amelyet egy másik program átalakíthat, majd esetleg végrehajthat vagy kiírhat, például egy olvasási -értékelési ciklusban . Nem minden olvasó/író támogatja a ciklikus, rekurzív vagy megosztott struktúrákat.
.NET Framework
A .NET Framework számos, a Microsoft által tervezett sorosítót tartalmaz . Sok harmadik fél által gyártott sorozatkészítő is létezik. Több mint egy tucat sorosító tárgyalja és tesztelt itt . és itt A lista folyamatosan bővül.
OCaml
Az OCaml szabványos könyvtára a Marshalmodul és a Pervasives függvények output_valueés a input_value. Míg az OCaml programozás statikailag típusellenőrzés alatt áll, a Marshalmodul használata megszakíthatja a típusgaranciákat, mivel nincs mód annak ellenőrzésére, hogy a nem hamisított adatfolyam a várt típusú objektumokat reprezentálja-e. Az OCaml -ban nehéz olyan függvényt vagy adatstruktúrát elosztani, amely tartalmaz egy funkciót (pl. Egy objektumot, amely metódust tartalmaz), mert a funkciókban lévő végrehajtható kód nem továbbítható különböző programok között. (Van egy zászló a függvény kódpozíciójának rendezésére, de csak pontosan ugyanabban a programban lehet bontani). A szabványos rendezési funkciók megőrizhetik a megosztást és kezelhetik a ciklikus adatokat, amelyeket egy zászlóval lehet konfigurálni.
Perl
Számos Perl modulok-ről CPAN nyújt sorszámozás mechanizmusok, beleértve Storable, JSON::XSés FreezeThaw. A Tárolható funkciókat tartalmazza a Perl adatstruktúrák fájlokba vagy Perl -skalárokba és azokból történő sorba állítása és deserializálása. A közvetlenül fájlokba való sorosításon kívül Storablemagában foglalja azt a freezefunkciót is, hogy a skalárba csomagolt adatok sorosított példányát visszaküldi, és thawegy ilyen skalárt deserializál. Ez akkor hasznos, ha egy bonyolult adatstruktúrát hálózati aljzaton keresztül küldenek, vagy adatbázisban tárolják. A struktúrák szerializálása során Storablevannak hálózatbiztonságos funkciók, amelyek adataikat mindig olyan formátumban tárolják, amely bármely számítógépen olvasható, kis sebességgel. Ezek a funkciók elnevezése nstore, nfreezestb Nincsenek „n” funkciókat deserializing ezek a szerkezetek - a rendszeres thawés retrievedeserialize struktúrák sorozatban a „ n” funkciók és gép-specifikus megfelelői.
PHP
A PHP eredetileg a sorosítást a beépített serialize()és a unserialize()funkciókon keresztül valósította meg . A PHP az adattípusok bármelyikét sorosítani tudja az erőforrások kivételével (fájlmutatók, foglalatok stb.). A beépített unserialize()funkció gyakran veszélyes, ha teljesen megbízhatatlan adatokon használják. Az objektumok esetében két " mágikus módszer" valósítható meg egy osztályon belül - __sleep()és __wakeup() -, amelyeket belülről hívnak meg, serialize()és unserialize()amelyek tisztíthatják és visszaállíthatják az objektumokat. Például kívánatos lehet az adatbázis -kapcsolat bezárása a szerializálás során, és a kapcsolat helyreállítása deserializáláskor; ezt a funkciót ebben a két varázslatos módszerben kezelik. Azt is lehetővé teszik az objektum számára, hogy kiválassza, mely tulajdonságok vannak sorosítva. A PHP 5.1 óta létezik objektum-orientált szerializációs mechanizmus az objektumokhoz, az Serializableinterfész.
Bevezető
Prolog „s távú struktúra, amely az egyetlen adatstruktúra a nyelv, lehet sorba keresztül a beépített predikátum write_term/3és sorozatban-in keresztül a beépített predikátumok read/1és read_term/2. A kapott adatfolyam tömörítetlen szöveg (bizonyos kódolásban, amelyet a célfolyam konfigurációja határoz meg), és a kifejezés szabad változóit a helyőrző változók nevei képviselik. A predikátum write_term/3szabványosítva van a Prolog ISO-specifikációjában (ISO/IEC 13211-1), az 59. oldalon. ("Kifejezés írása, 7.10.5. §"). Ezért várható, hogy az egyik megvalósítás által sorosított kifejezéseket egy másik is sorosíthatja, egyértelműség és meglepetés nélkül. A gyakorlatban a megvalósítás-specifikus bővítmények (pl. Az SWI-Prolog szótárai) nem szabványos kifejezésszerkezeteket is használhatnak, így az interoperabilitás meghibásodhat szélső esetekben. Példaként lásd az SWI-Prolog, SICStus Prolog, GNU Prolog megfelelő kézikönyv oldalait. Azt, hogy a hálózaton keresztül fogadott sorosított kifejezéseket és hogyan ellenőrzik a specifikációnak megfelelően (miután a karakterfolyamból való deserializálás megtörtént), a végrehajtóra bízzák. A Prolog beépített határozott záradék nyelvtanai alkalmazhatók ebben a szakaszban.
Piton
Az alapvető általános szerializációs mechanizmus a pickle szabványos könyvtári modul, utalva az adatbázis -rendszerek kifejezésének pácolására, hogy leírja az adatok sorosítását ( leválasztás a deserializáláshoz ). A Pickle egy egyszerű verem alapú virtuális gépet használ, amely rögzíti az objektum rekonstruálásához használt utasításokat. Ez egy több verzió közötti testreszabható, de nem biztonságos (nem biztonságos a hibás vagy rosszindulatú adatokkal szemben) szerializációs formátum. A rosszul formázott vagy rosszindulatúan létrehozott adatok miatt a deserializátor tetszőleges modulokat importálhat, és bármilyen objektumot példányosíthat. A szabványos könyvtár tartalmazza a szabványos adatformátumokba sorosító modulokat is: json(beépített támogatással az alapvető skaláris és gyűjteménytípusokhoz, és képes tetszőleges típusok támogatására kódolási és dekódolási horgokon keresztül ). plistlib(bináris és XML tulajdonságlista formátumok támogatásával). xdrlib(az RDR 1014-ben leírt külső adatábrázolási (XDR) szabvány támogatásával). Végül azt javasoljuk, hogy az objektumot __repr__a megfelelő környezetben értékeljék, ami durván illeszkedik a Common Lisp -hez print-object. Nem minden objektumtípus választható automatikusan, különösen azok, amelyek operációs rendszer -erőforrásokat, például fájlkezelőket tartalmaznak , de a felhasználók regisztrálhatnak egyéni "kicsinyítési" és szerkesztési funkciókat, hogy támogassák az önkényes típusok pácolását és eltávolítását. A Pickle-t eredetileg tiszta Python picklemodulként valósították meg , de a Python 3.0 előtti verzióiban a cPicklemodul (szintén beépített) jobb teljesítményt nyújt (akár 1000-szer gyorsabb). Ezt cPicklea terhelés nélküli fecske projektből alakították ki . A Python 3 rendszerben a felhasználóknak mindig a szabványos verziót kell importálniuk, amely megpróbálja importálni a gyorsított verziót, és visszaáll a tiszta Python verzióra.
R
Az R funkciója dputaz, hogy egy R objektum ASCII szöveges ábrázolását fájlba vagy kapcsolatba írja. Egy ábrázolás fájlból olvasható a használatával dget. Pontosabban, a függvény serializesorosítja az R objektumot a kapcsolathoz, a kimenet hexadecimális formátumban kódolt nyers vektor. A unserializefunkció lehetővé teszi egy objektum olvasását kapcsolatból vagy nyers vektorból.
REBOL
A REBOL sorba állítja a ( save/all) vagy a string!( mold/all) fájlt . A karakterláncokat és fájlokat a polimorf load függvénnyel deserializálhatjuk . RProtoBuftöbbnyelvű adatok sorosítását biztosítja R-ben, protokollpufferek használatával .
Rubin
A Ruby tartalmazza a standard modult Marshal2 módszerrel, dumpés loadhasonlóan a szokásos Unix segédprogramokhoz dumpés restore. Ezek a módszerek a szabványos osztályba sorozhatók String, azaz gyakorlatilag bájtsorozatokká válnak. Egyes objektumok nem sorosíthatók (ez TypeErrorkivételt jelentene): kötések, eljárásobjektumok, IO osztályú példányok, egyes objektumok és interfészek. Ha egy osztály egyéni szerializálást igényel (például bizonyos tisztítási műveleteket igényel a dömpingel / visszaállítással kapcsolatban), akkor ezt két módszer végrehajtásával teheti meg: _dumpés _load. A példány metódusnak _dumpvissza kell adnia egy Stringobjektumot, amely tartalmazza az ezen osztály és az összes hivatkozott objektum helyreállításához szükséges összes információt, az egész paraméterként megadott maximális mélységig (-1 érték azt jelenti, hogy a mélységellenőrzést ki kell kapcsolni). Az osztálymetódusnak fel _loadkell vennie a Stringés vissza kell adnia az osztály egy objektumát.
Csevej
Általánosságban elmondható, hogy a nem rekurzív és nem megosztott objektumok a storeOn:/ readFrom:protokoll használatával ember által olvasható formában tárolhatók és visszakereshetők . A storeOn:módszer létrehozza a Smalltalk kifejezés szövegét, amely - használatával értékelve readFrom:- újrateremti az eredeti objektumot. Ez a séma különleges, mivel az objektum eljárási leírását használja, nem magát az adatot. Ezért nagyon rugalmas, lehetővé téve az osztályoknak, hogy kompaktabb ábrázolásokat definiáljanak. Eredeti formájában azonban nem kezel ciklikus adatstruktúrákat, és nem őrzi meg a megosztott hivatkozások azonosságát (azaz egyetlen objektum két hivatkozását visszaállítják hivatkozásként két egyenlő, de nem azonos másolatra). Erre különféle hordozható és nem hordozható alternatívák léteznek. Néhány közülük egy adott Smalltalk megvalósításra vagy osztálykönyvtárra jellemző. A Squeak Smalltalkban többféle módon is sorba rendezhetők és tárolhatók az objektumok. A legegyszerűbb és leggyakrabban használt storeOn:/readFrom:bináris tárolási formátumok a SmartRefStreamsorosítókon alapulnak . Ezenkívül a kötegelt objektumok tárolhatók és visszakereshetők a használatával ImageSegments. Mindkettő úgynevezett "bináris objektum-tárolási keretrendszert" biztosít, amely támogatja a sorosítást és a lekérést egy kompakt bináris formátumból. Mindkettő ciklikus, rekurzív és megosztott struktúrákat, osztály- és metaclass -információk tárolását/visszakeresését kezeli, és mechanizmusokat tartalmaz a "menet közbeni" objektum -áttelepítéshez (azaz olyan példányok konvertálásához, amelyeket egy osztály régebbi változata írt, más objektumelrendezéssel). Az API -k hasonlóak (storeBinary/readBinary), de a kódolás részletei eltérőek, ezért ez a két formátum összeegyeztethetetlen. A Smalltalk/X kód azonban nyílt forráskódú és ingyenes, és más Smalltalks-be is betölthető, hogy lehetővé tegye a dialektuson keresztüli objektumcserét. Az objektumok szerializálása nem része az ANSI Smalltalk specifikációnak. Ennek eredményeképpen az objektum sorosítására szolgáló kód Smalltalk -implementációnként változik. A kapott bináris adatok is változnak. Például a Squeak Smalltalk -ban létrehozott sorosított objektum nem állítható vissza az Ambrai Smalltalk alkalmazásban . Következésképpen a különböző alkalmazások, amelyek több Smalltalk -implementáción is működnek, és objektum -sorosításra támaszkodnak, nem tudnak adatokat megosztani a különböző megvalósítások között. Ezek az alkalmazások magukban foglalják a MinneStore objektumadatbázist és néhány RPC csomagot. A probléma megoldása a SIXX "Újdonságok" . SIXX - Smalltalk példány eXchange XML -ben . 2010. január 23 . Letöltve: 2021. július 25 .</ref>, amely több Smalltalks csomagja, amely XML -alapú formátumot használ a sorozatosításhoz.
Gyors
A Swift szabványos könyvtár két protokollt tartalmaz, Encodableés Decodable(együttesen összeállítva Codable), amelyek lehetővé teszik a megfelelő típusok példányainak sorba rendezését vagy deserializálását a JSON , a tulajdonlista vagy más formátumokból. Ezeknek a protokolloknak az alapértelmezett megvalósításait a fordító generálhatja olyan típusokhoz, amelyek tárolt tulajdonságai szintén Decodablevagy Encodable.
Windows PowerShell
A Windows PowerShell a sorosítást a beépített parancsmag segítségével valósítja megExport-CliXML . Export-CliXMLsorosítja a .NET objektumokat, és a kapott XML -t egy fájlban tárolja. Az objektumok helyreállításához használja a Import-CliXMLparancsmagot, amely deserializált objektumot hoz létre az exportált fájl XML -fájljából. A deszerializált tárgyak, amelyeket gyakran "vagyontárgyaknak" neveznek, nem élő tárgyak; Ezek pillanatképek, amelyek rendelkeznek tulajdonságokkal, de nincsenek módszerek. Kétdimenziós adatstruktúrák is (de) sorosíthatók CSV formátumban a beépített parancsmagok Import-CSVés segítségével Export-CSV.

Lásd még

Hivatkozások

Külső linkek