Come trasferire un file su carta e penna, con correzione degli errori

Sto cercando un modo per trasferire un file usando solo carta e penna.

Questo è in qualche modo simile al paperbak , tranne per il fatto che la densità che sto cercando è molto, molto più bassa, e non voglio usare una stampante o uno scanner.

Ovviamente, la prima risposta è la codifica Base64 . Ma scrivere e leggere un numero così elevato di caratteri è destinato a provocare errori. Per i miei scopi, qualsiasi errore è inaccettabile.

La seconda risposta potrebbe essere la correzione degli errori Reed-Solomon (ad esempio, usando rsbep ). Tuttavia, questo è anche un problema, perché dalla mia comprensione, i codici Reed-Solomon non correggono gli errori di inserimento / cancellazione, che sono probabilmente più probabili degli errori di sostituzione in questo caso.

Esiste un programma che codificherà / decodificherà i file arbitrari con codici di correzione errori di inserimento / cancellazione consapevoli? Preferibilmente dovrebbe funzionare su Windows, Linux e Mac OS X.

Ovviamente qualsiasi altra soluzione al problema generale è benvenuta.

Dubito otherwise transcribing it will be too difficultche sarà un problema.

Diciamo che hai rosso, verde, blu e nero. Puoi scrivere uno script che trasforma i tuoi dati in una raccolta di lettere da RGBY, ad esempio: RGBYGBRYBGBYRYYBYBRYYG(o anche Red Green Blue Black Green Blue Red Black...in un foglio Excel) e viceversa. È solo una questione di base per convertire i dati binari dalla base 2 (o dati esadecimali dalla base 16) alla base nella quantità di colori che prendi (4 in questo esempio).

Ora, l'approccio più logico sarebbe quello di procurarti 16 colori. In questo modo, devi usare 4 volte meno punti per cui vale la pena passare da una penna all'altra. Ciò ti consente di scrivere 4 volte più dati sul foglio, se necessario, o forse può essere 4 volte meno accurato quando si posizionano i punti, il ridimensionamento dipende da te. Vorrei davvero sconsigliare di disegnare ogni singolo bit.

Ad esempio, 5565 bytesdovrebbe essere moltiplicato per due per ottenere la quantità di esadecimali che è 11130 hexadecimals(al contrario di 44520 bits) che può essere inserita in una 106 x 106griglia.

A seconda del tipo di dati, probabilmente puoi ottenere alcune ottimizzazioni ...

Suggerimento: prova a scegliere i colori più distinti (più contrastanti) ...

Alternative che possono usare una sola penna:

• Rappresentare i diversi esadecimali da diversi simboli -, /, |, \, +, ...

• Rappresenta i diversi esadecimali con un font pixel piccolo, vedi il mio avatar.

  

  Questo rende anche utile usare qualcosa come Base 32 (o Base 36). Si noti che Qe 9sono uguali, quindi si desidera che il pixel in alto a destra di Qsia bianco per una chiara distinzione. Base 32 richiede solo una 53 x 53griglia per il tuo esempio, oltre a una piccola spaziatura per distinguere tra le lettere.

Se vuoi che le persone siano in grado di leggere e scrivere i dati, il problema con Base64 e molte codifiche di testo è che usano caratteri come I, l, 1, |, /, 0, O, o e così via che le persone confondono insieme.

Analizza la codifica Base32 di Douglas Crockford . Il suo alfabeto è stato appositamente scelto per evitare caratteri simili e include il rilevamento degli errori.

Dopo aver letto i tuoi commenti, sembra più ragionevole. Non ero sicuro che tu fossi intenzionato a codificare megabyte di dati come questo.

Raccomanderei, sulla falsariga del suggerimento di Oliver, di aumentare la densità dei dati prendendo in prestito una pagina dal codice di Bacon , che le bande carcerarie usano spesso per codificare i messaggi nascosti nelle missive scritte in 2 diversi stili di script - di solito o caratteri minuscoli o caratteri di stampa rispetto a quelli corsivi, ad es

Hey mOM, WHAT's FOR diNNeR TODAY? = ABBBA AAAAA BAAAB BAABA AAAAA
                                  =   P     A     S     T     A

Tuttavia, poiché il tuo obiettivo non è la stegnografia, lo useresti semplicemente per espandere il tuo set di glifi. In questo modo, potresti avere fino a 114 glifi utilizzando solo caratteri alfanumerici di stampa e corsivo o 12996 punti di codice utilizzando la codifica a due caratteri.

Tuttavia, poiché tutti i conteggi di glifi maggiori di 15 e inferiori a 256 sono essenzialmente gli stessi per una cifra semplice di dati binari (il che significa che avrai comunque bisogno di 2 caratteri per rappresentare ogni byte, dandoti una densità di dati di 4 bit per carattere in tutti i casi), è possibile utilizzare i 98 glifi / 12740 punti di codice aggiuntivi per il rilevamento / correzione degli errori.

I modi per farlo includono:

• Scegli un set di 256 combinazioni di caratteri più facili da leggere / scrivere. Se si verifica un'altra combinazione di caratteri, sai che si tratta di un errore di copia.
• Utilizzare due versioni del carattere finale come bit di parità.

• Crea 50 diversi set di glifi di 16 caratteri. È quindi possibile utilizzarli per codificare i dati di correzione degli errori.

  Ad esempio {set 1}{set 1}significa che i prossimi 3 stuzzichini sono uguali 0x000, {set 1}{set 2}uguali 0x001, ecc.

  Puoi usarlo per rappresentare 2500+ dei 4096 possibili valori di 1,5 byte. Allo stesso modo, è possibile utilizzare solo 16 set per rappresentare tutti i valori del byte seguente, offrendo una ridondanza del 100% senza aumentare la lunghezza dei dati codificati.

In alternativa, è possibile utilizzare i glifi extra per una compressione aggiuntiva:

• Implementa la codifica a larghezza variabile scegliendo 98 punti di codice a carattere singolo. Ciò ridurrebbe la dimensione media del contenuto codificato di circa il 20%.
• Implementa qualcosa di simile alla codifica run-length utilizzando diversi set di glifi o combinazioni di set di glifi per rappresentare nibble / byte ripetuti. Ad esempio Ab= aba; aB= abab; AB= ababab...
• Usa i glifi o i punti di codice extra per rappresentare "parole" e "frasi" che si ripetono nei tuoi dati. Sebbene i dati precompressi probabilmente avranno un alto livello di entropia, quindi non so quanto sarebbe efficace.

---

Per ridurre ulteriormente gli errori di copia, visualizzerei il contenuto codificato in griglia e lo copierei su carta millimetrata. Se è possibile utilizzare elementi fissi personalizzati con colori alternati di colonne / righe o una griglia a scacchi stile scacchiera con colonne e righe numerate per ricerche rapide, ciò aumenterebbe ulteriormente l'accuratezza della copia.

Puoi anche combinare un layout a griglia alternata con stili di carattere alternati come una semplice forma di rilevamento degli errori. Vale a dire se le colonne dispari sono sempre in maiuscolo, se il trascrittore si trova a scrivere lettere minuscole in colonne dispari, allora sanno di aver fatto un errore e possono iniziare a rintracciare per vedere dove è successo.

---

Tuttavia, se la tua priorità principale è l'accuratezza, utilizzerei una codifica binaria + un codice Hamming . Usando un codice Hamming (12, 8) abbreviato su carta millimetrata standard, potresti contenere solo 187 byte, codificando solo 124 byte di dati. Ma potrebbe essere trascritto molto rapidamente (una barra per 1, niente per 0) e fornire una singola correzione dell'errore. L'impostazione di un bit di parità aggiuntivo (13, 8) fornirebbe SECDED (correzione dell'errore singolo, rilevamento dell'errore doppio). Utilizzando un codice di hamming standard come (15, 11) o (31, 26), si ottiene un'efficienza ancora migliore con 137 e 156 byte di dati per foglio, rispettivamente. Possono essere raggiunti tassi di codice ancora più alti, a seconda di quanto pensi possa essere accurato il tuo trascrittore.

Una codifica binaria sarebbe anche più facile da leggere (ad alta voce) e OCR / OMR.

A questo scopo usavamo S-Records . C'era un semplice checksum, per riga, per il rilevamento degli errori. Normalmente tutti tranne l'ultima riga erano a lunghezza fissa, quindi il marker di fine riga serviva da controllo per inserimenti ed eliminazioni. Non c'era nessun controllo per le linee mancanti però. Per questo abbiamo semplicemente contato il numero di righe. Per lo più i file erano brevi, meno di 100 righe, ma me ne ricordo almeno uno che aveva 300 righe o più. Era molto noioso digitare file nel sistema. Naturalmente, tra i primi programmi trasferiti in questo modo c'era un downloader;)

Il riconoscimento ottico dei marchi è stato usato per decenni per creare moduli scritti a mano leggibili a macchina. La pagina di Wikipedia contiene collegamenti a diverse versioni Open Source.

Le scuole hanno usato a lungo OMR per i test; i moduli sono semplici da usare e da leggere e la precisione è generalmente migliore dell'input da tastiera. Per una maggiore precisione, produttori commerciali come Scantron e ReMark possono creare moduli personalizzati.