Dotaz: ako ukladať digitalizované dokumenty?

[rastos]

Doma sa mi za roky nahromadili najrôznejšie papierové dokumenty. Mám v úmysle zbaviť sa ich a previesť ich do digitálnej podoby - a napísať si na to vlastnú aplikáciu. V jave. S možnosťou dokumenty otagovať, priradiť dátum, poznámku, nanovo vytlačiť, vyhľadávať, ...

Chcel by som od vás počuť názory na to, ako ukladať oskenované dokumenty:

• Q1: je dôvod uprednostniť obrázok pred pdf?
• Q2: kam ukladať oskenované dokumenty? Viem si predstaviť nasledovné možnosti:
  • čo dokument to súbor
  • embeded databáza - derby/h2/...
  • kombinácia predchádzajúcich dvoch. V DB metadáta a odkaz na súbor s blobom.
  • SQL server (postgres/mysql/...)

Ten SQL server mi príde najhorší lebo chcem, aby bolo jednoduché tie dáta zálohovať a presúvať. A to aj pre členov rodiny, ktorí nie sú IT zdatní. Mať niekde SQL server a raz za 5 rokov znova objavovať ako sa to backupuje, upgraduje, ... to ma nenadchýňa. Pri upgrade embeded databázy, ku ktorému rokmi dôjde, by som tiež chcel čo najjednoduchší priebeh.

Máte nejaké rady?

Odpovědi

[O'o'yam]

Dokumenty o ktere nechcete prijit je nejlepsi ukladat ve formatech, na ktere budete mit ctecku i za nekolik desetileti. Predstavte si, ze dnes najdete nejake dokumenty v AmiPro, C602, nebo v T602 (a z te ten text nakonec dostanete) - co s nimi? Leda hledat na netu nejaky konvertor.

Pokud se chcete chranit pouze proti tomu, ze za 10 az 40 let nebude jak dokumenty otevrit, muzete asi pouzit jpg, nebo pdf. V techto formatech je dnes tolik dokumentu, ze by ctecky nemely zmizet velmi dlouho. Databazi nedoporucuji. Pouzijte nejaky obycejny a jednoduchy a velmi rozsireny souborovy system a dejte je do adresaru.

Obrazek zabaleny v pdf a to ulozene v databazi je uzasne reseni az do okamziku, kdy prohlizec pdf prestane podporovat 30 let starou verzi jpg, protoze tu uz preci nikdo nepouziva, nebo ulozena data z databaze nedokaze nacist verze o 15 novejsi.

Disky jsou dneska levne. 4TB poridite za 5000, kdyz koupite nejlevnejsi WD a nejlevnejsi Seagate a date je do mirroru (stejne disky ze stejne serie casto odchazi ve stejnou dobu - na to take nechcete prijit tim tezsim zpusobem).

Takze ja osobne bych scannoval do pnm (nebo do jineho uplne cisteho bitmapoveho formatu, ktery dokazete popsat z hlavy za 2 minuty a naimplementovat ctecku v libovolnem programovacim jazyce za nekolik malo hodin). Vubec bych je nekomprimoval a idealne bych plytval mistem jeste vic tak, ze bych si zvolil beznou sirku obrazku (napriklad na celou sirku scanneru) a v te bych mel co nejvic obrazku a ostatni v jejich celociselnych nasobcich. Strankovani vyreste ve jmene souboru, nebo za pomoci adresaru.

Pokud si navic ulozite ta sama data v jpg, pdf, nebo dokonce v cistem textu (po pruchodu OCR - hodi se pro vyhledavani), rozhodne to neuskodi. Jen nemazte originaly.

Textove dokumenty ukladejte v textu. V cistem textu. Tak, aby sly cist, kdyz je otevre vim, less, nebo cat. I kdyby cele IT preslo z ASCII na EBCDIC, tak nekde najdete, jak vypadalo ASCII, nebo to odhadnete, pokud si to nepamatujete z hlavy. Ale to se nestane - neni duvod to menit. V IT se dnes veci nemeni, ale rozsiruji. Diakritiku si domyslite, at uz bude kodovana jakkoliv, pokud budete mit ve stejnem kodovani dostatek textu. UTF-8 vypada, ze tu s nami vydrzi velmi dlouho, takze ho doporucuji pouzivat na vsechno.

Mozna se ptate proc doporucuji tak primitivni pristup?

Predstavte si, ze najdete 5 1/4" disketu z roku 1990 a na ni je napsano neco jako "dulezite dokumenty". Sezenete nekoho, kdo ma nekde v krabici starou disketovou mechaniku, vysajete z ni vysavacem centimetr prachu, pripojite k prehistorickemu pocitaci (nebo naimplementujete FDC na arduinu), zkusite to precist ... a co dal? Data tecou byte za bytem, ale vy nevite, co s nimi. FAT 32 to neni, FAT 16 to neni, FAT 12 jste v encyklopedii nenasli (nebo to je disketa treba z Commodora, pripadne se prvni stopu nepodarilo precist spravne). Na disku mate binarni obraz cehosi.

Pokud v tom je cisty holy ASCII text, tak ho tam najdete snadno. Mate mozek a ten je na tenhle typ uloh staveny - staci tim proscrollovat v textovem editoru, nebo to vypsat na terminal. I pokud to bude rozhazene po cele diskete po jednotlivych sektorech, tak to pravdeporobne dokazete poskladat dohromady. Tak, aby navazovala slova, vety, vyznam, smysl.

Obrazky v bitmapach budou horsi, ale pokud znate sirku, tak muzete cely dump diskety zarovnat na tu sisrku a zobrazit jako jeden hodne vysoky obrazek. A ten nechat velmi rychle scrollovat. Data budou vypadat jako sum, obrazek bude mozna rozbity, mozna posunuty, mozna se zprehazenymi barvami, ale vsimnete si ho. A pak dokazete najit, kde zacina, kde konci a jak patri barvy. Mate mozek, v nem zrakovovu kuru a ta je v tom fakt dobra. Dalo by se rici, ze je na to stavena.

Cokoliv jineho najdete jen za pouziti nastroju napsanych se znalosti formatu dat, ktera hledate. Tedy - takovou znalost potrebujete i tady - z retezce nul a jednicek byste to asi nevykoukali. Ale jestli je bila 255 a cerna 0, nebo naopak je jedno, protoze obrazek uvidite v obou pripadech stejne, jako s prehazenymi barvami. A to, ze A je v ASCII 65 (41 hexa), a je 97 (61 hexa) 0 je 48 (30 hexa) a znaky jdou pekne za sebou - to si pamatuje dost lidi z hlavy. Kolik lidi zna z hlavy format komprimovaneho PNG?

To, ze je dobre drzet filesystem s obrazky nefragmentovany vam asi doslo, ze? Skladat obrazek z kousku vekych 512B, nebo i 4096B bude na dlouho.

[Heron]

+1 komplet.

Osobně dokumenty scanuju a nechávám v originální podobě (tiff) + export do png. Pokud je to jeden list, tak dobře pojmenovat soubor, pokud je to více souvisejících stránek, tak napsat README, něco jako tagy na začátek, potom klidně obšírnější povídání o tom co to je a proč to je (tohle dělám tak nějak automaticky, i na serverech zanechávám README s vysvětlením, proč to vzniklo, s odkazem na ticket apod., samotnému mě to několikrát pomohlo, byl tam odkaz do dokumentace atd).

K původnímu dotazu jen snad tohle:

Q1: je dôvod uprednostniť obrázok pred pdf?

Ano je, pdf je komplexnější formát. Osobně u důležitých dat vždy uchovávám originál (raw z foťáku, tiff ze scanneru - ano vím, že tiff je jen kontejner pro mnoho formátů) + export v nějaké podobě. U bitmap preferuju png, ale nemám to nějak příliš důkladně obhájené, ve skutečnosti by bylo nejlepší to uchovat jako farbfeld, tedy tak primitivní, jak jen to může být.

kombinácia predchádzajúcich dvoch. V DB metadáta a odkaz na súbor s blobom.

Ne, nikdy!!! Toto je nejhorší řešení. Pokud už chcete použít DB, tak do ní uložte i ta data. Není nic horšího, než najít metadata a nemít k nim data (někdo udělal dbdump, ale už jaksi zapomněl na adresář). Data patří do DB a to kompletně. Pokud se z nějakého důvodu bojíte o původní soubory, nechte je na disku a navíc je uložte do db. A obecně nedoporučuji používat BLOBy, ale třeba něco jako pg BYTEA, kdy je tento byte array hodnotou stejně jako cokoliv jiného. Tj lze nad tím mít transakce apod.

[Jendа]

farbfeld

Do teď mi není jasné, jestli autoři fakt neznali PBM, nebo proč se snažili vytvořit totéž znovu nekompatibilně.

[Heron]

Nemůžu mluvit za autory, ale tak se podívej na délku a komplikovanost té specifikace.

U farbfeldu máš 16B dlouhou hlavičku a potom už jen pole pixelů. Snadno se to iteruje přes 8B pixely.

U toho PPM máš ascii formát nebo binary formát, v ascii je povoleno hodně lidové tvořivosti co se týče whitespace a dokonce dva typy komentářů.

Pro který formát se ti bude lépe psát knihovna?

[Jendа]

Já bych to tak černě neviděl, dnes jsou věci podstatně rozšířenější než v roce 1990, a s tím i tlak na jejich konzervaci. A navíc na ten disk můžeš nahrát i ten software (ve formě image kompletního OS) -- emulátory x86/amd64 prostě nezmizí. Koneckonců to by fungovalo i tehdy, vždyť dneska máme dokonce webové (!) emulátory, kde v JavaScriptu běží Windows 95 a i ten software pro Commodore. A co se FS týče, FAT32 je tak extrémně konzervovaný (doslova všechna embedded zařízení, UEFI…), že to taky prostě nezmizí. Totéž JPG, PNG… U PDF je potřeba dát si pozor, aby ses neodkazoval na externí fonty atd. - viz formát PDF/A.

No a pak tu ještě je ten faktor, že musíš jednou za pár let ta média fyzicky číst a nahrazovat nečitelná - a během toho uvidíš, jestli digitální formáty nezestárly.

[dnes 05:33 Matlák]

No a pak tu ještě je ten faktor, že musíš jednou za pár let ta média fyzicky číst a nahrazovat nečitelná - a během toho uvidíš, jestli digitální formáty nezestárly.

No mně přišlo že O'o'yam vysloveně cílí na situaci kdy to prostě na to médium nahraješ a necháš to 50 let ležet někde v prachu. Je fakt že k důležitým dokumentům by se tak člověk chovat neměl, ale reálně se to (s papírovými dokumenty) stává..

Jinak souhlasím s tou konzervací formátů a systémů. Záleží vlastně už jen na tom jak "důležité" jsou to dokumenty, jestli je třeba nutné aby to vydrželo jaderný útok, pád velkého asteroidu a podobně

[Radovan]

Hledat na netu nějaký konvertor? Ale ne, prostě si ten program spustíš v emulátoru a soubor normálně otevřeš.

U těch starších používajících jednodušší datové formáty bude užitečné hledat dobovou literaturu, protože třeba struktura souboru VisiCalcu je velmi dobře zdokumentovaná a editovatelná ručně v libovolném textovém editoru. Příklad:

>H15:@SUM(H3...H14)
>G15:@SUM(G3...G14)
>F15:@SUM(F3...F14)
>E15:@SUM(E3...E14)
>D15:@SUM(D3...D14)
>C15:@SUM(C3...C14)
>B15:@SUM(B3...B14)
>A15:/FR"soucet
>H14:@SUM(B14...G14)
>G14:704
>F14:80
>D14:4494
>C14:706
>B14:3344
>A14:1+A13
atd. ...

Pokud chceš skladovat grafická data, vyhnul bych se ztrátové kompresi. A co nejjednodušší uložení dat, nejsnáze rekonstruovatelné mi připadají truecolor a monochromatické bitmapy.

[xxxs]

"Kolik lidi zna z hlavy format komprimovaneho PNG?"

ten si moze do textatku ulozit tiez.

[Pavel 'TIGER' Růžička]

Jak bylo napsáno, není nad jednoduchou adresářovou strukturu a známý formát. Kdyby náhodou nestačila délka souboru, vždycky se může do adresáře hodit i jednoduchý texťák. Odpadá tím jakákoliv správa a údržba databáze.

[Peter Golis]

+1

Akurát mi chýba jedna podstatná vec. Ako zaistiť overenie elektronického dokumentu, to sú už podpisy z eletrických občianok s nekonečne dlhou platnosťou? Bez tejto jednej drobnosti sa jedná len o papier, ktorému sa originál "stratil".

[Jendа]

sqlite, ale bloby bych do ní nedával, protože s terabajtovou databází je opruz navíc.

Ale osobně bych preferoval adresářovou strukturu + texťáky.

Zvážil bych par2 pro ochranu před vadnými bloky.