Vhodny oddelovac pre binarne zaznamy

Ak si vezmem nejaky jednoduchy binarny log, kde nechcem pouzivat vobec alebo vyhradne type-length-value/length-value(TLV/LV) format, ale chcem aj/len jednoducho oddelit zaznamy, aky znak alebo retazec by na to mohol byt najvhodnejsi?

Napriklad ak mam json, tak ten osetri, mimo ineho, aj \n(novy riadok LF) takze \n sa moze pouzit ako oddelovac zaznamov, naprikald ako v jsonl. Ale to je textovy format a mna zaujima binarny.

TLV respektive skor LV je fajn, lenze clovek musi zacat od 0 aby mohol potom skakat na dalsie zaznamy, kdezto s oddelovacom staci skocit hocikam a len citat dopredu kym sa nenajde oddelovac.

Uz som to riesil viac krat no nastastie nikdy neislo o nieco kde islo o rychle citanie a teda som mohol vzdy zacat od 0. Ale do buducna by som chcel vediet ako na to. Co fici, co sa pouziva, ako to riesia iny.

Používám řídící ascii znaky, které nejsou vykreslitelné. V enterprise databázích můžeš často najít BELL alias \a, protože má svoji escape sekvenci. Když můžeš zapsat cokoliv tak stačí jít od začátku a používat znaky \01 \02 \03 atd.

Zároveň tyhle znaky můžeš bezpečně odstranit z ascii/utf textu, protože tam nemají nikdy co dělat. Ideální na ukládání formátů jako xml,json, na binární data musíš vždy používat offset a velikost případně je nejprve převést do ascii (base64).

Asi to není co hledáš, ale existuje MessagePack.

Původně odeslal TomášX ↪

Zároveň tyhle znaky můžeš bezpečně odstranit z ascii/utf textu, protože tam nemají nikdy co dělat. Ideální na ukládání formátů jako xml,json, na binární data musíš vždy používat offset a velikost případně je nejprve převést do ascii (base64).

no hej, ale co ked uz mam hotovy zaznam v bytovej forme kedy nemam pristup k povodnym datam pred serializovanim alebo kompresiou. tzn. nemozem si diktovat ktore znaky sa escapuju a ktore nie. proste mam uz zaznam ako []byte pole a nic viac neviem.

asi jsem dotaz pochopil jinak, ale pokud jde o hotové formáty, je jich opravdu dost. MessagePack je už poměrně přežitý, Z těch dnes nepoužívanějších kolem mě:

1) avro
binární plně strukturovaný formát, možnost mít schéma (používá json schema) uvnitř s daty, podpora napříč jazyky, docela parsování

2) protobuf
binární strukturovaný formát s podporou rpc, schéma je mimo data a je nutné sdílet dopředu

3) cap n proto
binární formát s nulovou režií pro enkodování/dekódování, nutnost k datům přistupovat přes getter/settery

4) arrow
právě se dostává do stabilní verze, nová hvězda, shodný paměťový layout pro data v paměti, na disku, na gpu, levné enkodóvání a parsování

5) thrift
primárně pro komunikaci mezi službami jako náhrada xmlrpc

6) messagePack (jak jsi zmiňoval)
pěkný formát s in-place editací bez enkodování, je ale těžké s ním pracovat mimo striktně typové jazyky (java, c++, D), má horší validace


Pak existují pěkné věci jako pandas, dataframe, ale to je jen pro python.

Původně odeslal node ↪

no hej, ale co ked uz mam hotovy zaznam v bytovej forme kedy nemam pristup k povodnym datam pred serializovanim alebo kompresiou. tzn. nemozem si diktovat ktore znaky sa escapuju a ktore nie. proste mam uz zaznam ako []byte pole a nic viac neviem.

tak to je boj s pravděpodobností, můžeš hledat tak dlouhou posloupnost, která tam “určitě” nebude.

Za dob kamených jsme používali trik s kompresí, komprese totiž nikdy nenechá třeba čtyři bajty po sobě nulové, takže gzip binárních hodnot a pak \00\00\00\00.

Lze také nejprve projít určitý blok k uložení, zjistit co tam není a vybrat si oddělovač, který nemá konflikt, takovýhle oddělovač pak můžeš uvést v třeba v prvních dvou bajtech každého bloku dat, který bude obsahovat N zpráv.