त्रुटि सुधार के साथ पेन और पेपर पर फाइल कैसे ट्रांसफर करें

Question

मैं केवल एक पेन और पेपर का उपयोग करके किसी फ़ाइल को स्थानांतरित करने का तरीका ढूंढ रहा हूं।

यह कुछ हद तक पेपरबेक के समान है , जिस घनत्व को मैं देख रहा हूं, वह बहुत कम है, और मैं प्रिंटर या स्कैनर का उपयोग नहीं करना चाहता।

जाहिर है, पहला जवाब Base64 एन्कोडिंग है। लेकिन इस तरह के पात्रों को लिखना और पढ़ना त्रुटियों में परिणत होने के लिए बाध्य है। मेरे उद्देश्यों के लिए, कोई भी त्रुटि अस्वीकार्य है।

दूसरा उत्तर रीड-सोलोमन त्रुटि सुधार कोड (उदाहरण के लिए, rsbep का उपयोग करके ) हो सकता है। हालाँकि, यह भी एक समस्या है, क्योंकि मेरी समझ से, रीड-सोलोमन कोड प्रविष्टि / विलोपन त्रुटियों को ठीक नहीं करते हैं, जो संभवतः इस मामले में प्रतिस्थापन त्रुटियों की तुलना में अधिक संभावना है।

क्या कोई ऐसा कार्यक्रम है जो प्रविष्टि / विलोपन संबंधी त्रुटि सुधार कोड के साथ मनमानी फाइलों को कूटबद्ध / डिकोड करेगा? अधिमानतः यह विंडोज, लिनक्स और मैक ओएस एक्स पर काम करना चाहिए

स्पष्ट रूप से सामान्य समस्या का कोई अन्य समाधान स्वागत योग्य है।

Comments

क्या आप लेखन में त्रुटियों, या सिर्फ पढ़ने की उम्मीद करते हैं?

— ईसाई मान

मैं दोनों में त्रुटियों की उम्मीद करता हूं, लेकिन मैं उनसे समकक्ष होने की उम्मीद भी करूंगा ...

— जेरेमी सलवेन

मुझे माफ करें। मैंने गलत समझा और सोचा कि तुम छाप रहे हो। आप इसे हाथ से लिखना चाहते हैं?

— ईसाई मान

पेन के कितने रंग इस्तेमाल कर सकते हैं? :)

— डेर होकस्टापलर

केवल एक ही रंग की कलम, अन्यथा इसे स्थानांतरित करना बहुत मुश्किल होगा। मैं वास्तव में संपीड़ित, हस्ताक्षरित, एन्क्रिप्ट किए गए पाठ को प्रसारित कर रहा हूं, इसलिए यहां तक ​​कि 50% अतिरेक दर का अनुमान लगाते हुए, लेखन की कुल राशि होगी <1.5 बार जितना मूल पाठ लिखना होगा उतना ही होगा (एक बार जब आप संपीड़न को ध्यान में रखते हैं )। हालाँकि, वहाँ समस्या है कि यादृच्छिक वर्णों की नकल करना अंग्रेजी पाठ की नकल करने की तुलना में कठिन है। तो अपने सवाल का जवाब देने के लिए, निश्चित रूप से केबी रेंज के जोड़े में ही।

— जेरेमी सलवेन

Answer 1

मुझे संदेह है कि otherwise transcribing it will be too difficultक्या समस्या होने वाली है।

मान लीजिए कि आपके पास लाल, हरा, नीला और काला है। आप एक स्क्रिप्ट लिख सकते हैं जो आपके डेटा को अक्षरों के संग्रह में बदल देती है RGBY, जैसे: RGBYGBRYBGBYRYYBYBRYYG(या यहां तक Red Green Blue Black Green Blue Red Black...कि एक एक्सेल शीट में) और फिर से वापस। यह सिर्फ बेस 2 की बात है जो आपके बाइनरी डेटा को बेस 2 (या बेस 16 से हेक्साडेसिमल डेटा) को आपके द्वारा लिए जाने वाले रंगों की मात्रा में आधार पर ले जाता है (इस उदाहरण में 4)।

अब, सबसे तार्किक दृष्टिकोण अपने आप को 16 रंगों को प्राप्त करना होगा। इस तरह, आपको 4 गुना कम डॉट्स का उपयोग करना होगा जो इसके लायक पेन के बीच स्विच करता है। यह आपको कागज पर 4 गुना अधिक डेटा लिखने की अनुमति देता है यदि आपको ज़रूरत है, या शायद अपने डॉट्स डालते समय 4 गुना कम सटीक हो सकता है, तो स्केलिंग आपके ऊपर है। मैं वास्तव में हर एक बिट ड्राइंग के खिलाफ सलाह दूंगा।

उदाहरण के लिए, 5565 bytesहेक्साडेसिमल की मात्रा को प्राप्त करने के लिए दो से गुणा करना होगा 11130 hexadecimals( जो कि विपरीत है 44520 bits) जिसे 106 x 106ग्रिड में डाला जा सकता है ।

डेटा के प्रकार के आधार पर आप शायद कुछ अनुकूलन के साथ आ सकते हैं ...

संकेत: सबसे अलग (सबसे विपरीत) रंग लेने का प्रयास ...

एक पेन का उपयोग कर सकने वाले विकल्प:

• विभिन्न प्रतीकों द्वारा विभिन्न हेक्साडेसिमल का प्रतिनिधित्व करते हैं -, /, |, \, +, ...

• एक छोटे पिक्सेल फ़ॉन्ट द्वारा विभिन्न हेक्साडेसिमल का प्रतिनिधित्व करें, मेरा अवतार देखें।

  

  यह बेस 32 (या बेस 36) जैसी किसी चीज़ का उपयोग करना भी उपयोगी बनाता है। ध्यान दें कि Qऔर 9समान हैं, इसलिए आप Qएक स्पष्ट अंतर के लिए शीर्ष दाएं पिक्सेल को व्हाइट होना चाहेंगे । बेस 32 में केवल 53 x 53आपके उदाहरण के लिए ग्रिड की आवश्यकता होती है , साथ ही अक्षरों के बीच अंतर करने के लिए एक छोटा सा स्पेस।

Comments

खैर, इसके साथ कुछ समस्याएँ हैं। 1. मैं कलरब्लाइंड हूं। 2. यह कलम का एक गुच्छा खरीदने की आवश्यकता है। 3. यह त्रुटि सुधार के साथ बिल्कुल भी मदद नहीं करता है। 4. इसमें टेक्स्ट के बजाय राइटिंग कोड शामिल हैं, जो इंसानों से भी बदतर हैं।

— जेरेमी सलवेन

@JeremySalwen: उह, एक ग्रिड में पात्र लिखना वास्तव में कठिन नहीं है। और आप कुछ अतिरिक्त अनुदैर्ध्य चेक नंबर या सीआरसी लिखकर त्रुटियों को ठीक कर सकते हैं। लेकिन वास्तव में, एक ग्रिड से एक ग्रिड पर पत्र लिखना बहुत आसान है, सबसे खराब स्थिति है कि आप इसे फिर से मान्य करने के लिए फिर से चलते हैं।

— तमारा विज्समैन

@JeremySalwen: और यदि आप कलर ब्लाइंड हैं, तो आप केवल उन रंगों में से कोई भी रंग नहीं लेते हैं, जिसके लिए आप कलर ब्लाइंड हैं।

— तमारा विज्समैन

कलर ब्लाइंडनेस रंग स्थान की एक आयामी कमी से अधिक है, यह कुछ रंगों को देखने के लिए एक चयनात्मक अक्षमता है। मेरा मतलब है, मैं शायद ब्लैक, ब्लू, येलो, रेड, ग्रीन, ग्रे को खींच सकता हूं, लेकिन बहुत अधिक नहीं

— जेरेमी सलवेन

@Tom आपको भ्रम को रोकने के लिए संभवतः अपना पुराना अवतार रखना चाहिए :)

— नैट कोपेनहेवर

Answer 2

यदि आप चाहते हैं कि लोग डेटा को पढ़ने और लिखने में सक्षम हों, तो Base64 और कई टेक्स्ट एनकोडिंग के साथ समस्या यह है कि वे I, l, 1, |, /, 0, O, o, और जैसे वर्णों का उपयोग करते हैं, ताकि लोग भ्रमित हों। एक दूसरे के साथ।

डगलस क्रॉकफोर्ड के बेस 32 एनकोडिंग की जांच करें । इसकी वर्णमाला को विशेष रूप से समान वर्णों से बचने के लिए चुना गया था, और इसमें त्रुटि का पता लगाना भी शामिल है।

Comments

धन्यवाद, मैं शायद इसका उपयोग करूंगा, लेकिन यह अभी भी त्रुटि सुधार समस्या को हल नहीं करता है।

— जेरेमी सलवेन

@ जेरेमी, क्रॉकफोर्ड के कार्यान्वयन में त्रुटि का पता लगाना शामिल है । यदि आपको त्रुटियों को ठीक करने की आवश्यकता है, तो अग्रेषित-त्रुटि सुधार ( en.wikipedia.org/wiki/Forward_error_correction ) की जांच करें ।

— डोर हाई आर्क

Answer 3

आपकी टिप्पणियों को पढ़ने के बाद, यह अधिक उचित लगता है। मुझे यकीन नहीं था कि आप इस तरह के डेटा के मेगाबाइट एन्कोडिंग पर इरादा कर रहे थे।

मैं ओलिवर के सुझाव की तर्ज पर सुझाव देता हूं, कि आप बेकन के सिफर से एक पृष्ठ उधार लेकर अपना डेटा घनत्व बढ़ाते हैं , जिसे जेल गिरोह अक्सर 2 अलग-अलग स्क्रिप्ट शैलियों में लिखी गई मिसाइलों में छिपे संदेशों को एनकोड करने के लिए उपयोग करते हैं - आमतौर पर ऊपरी बनाम लोअरकेस वर्ण या प्रिंट बनाम घसीट वर्ण, जैसे

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

हालाँकि, चूंकि आपका लक्ष्य स्टेग्नोग्राफ़ी नहीं है, आप अपने ग्लिफ़ सेट का विस्तार करने के लिए इसका उपयोग करेंगे। ऐसा करने से, आप 114 ग्लिफ़ तक प्रिंट और सरसरी अल्फ़ान्यूमेरिक वर्ण या 12996 कोड बिंदुओं का उपयोग करके दोहरे वर्ण एन्कोडिंग का उपयोग कर सकते हैं।

हालाँकि, चूंकि सभी ग्लिफ़ 15 से अधिक और 256 से कम की गणना बाइनरी डेटा के एक सीधे सिफर के लिए अनिवार्य रूप से समान हैं (मतलब, आपको प्रत्येक बाइट का प्रतिनिधित्व करने के लिए 2 वर्णों की आवश्यकता होगी, जिससे आपको प्रति वर्ण 4 बिट का डेटा घनत्व मिलेगा सभी मामलों), आप त्रुटि का पता लगाने / सुधार के लिए अतिरिक्त 98 ग्लिफ़ / 12740 कोड पॉइंट का उपयोग कर सकते हैं।

ऐसा करने के तरीकों में शामिल हैं:

• वर्ण कंघी पढ़ने / लिखने के लिए सबसे आसान 256 का एक सेट चुनें। यदि कोई अन्य वर्ण कॉम्बो होता है, तो आप जानते हैं कि यह एक प्रतिलिपि त्रुटि है।
• समता वर्ण के रूप में अंत वर्ण के दो संस्करणों का उपयोग करें।

• 50 अलग-अलग 16-वर्ण ग्लिफ़ सेट बनाएं। फिर आप उन्हें त्रुटि सुधार डेटा सांकेतिक शब्दों में बदलना करने के लिए उपयोग कर सकते हैं।

  उदा का {set 1}{set 1}अर्थ है अगले 3 निबल समान 0x000, {set 1}{set 2}बराबर 0x001आदि।

  आप 4096 संभावित 1.5 बाइट मानों के 2500+ का प्रतिनिधित्व करने के लिए इसका उपयोग कर सकते हैं। इसी तरह, आप निम्नलिखित बाइट के सभी मूल्यों का प्रतिनिधित्व करने के लिए सिर्फ 16 सेट का उपयोग कर सकते हैं, जिससे आपको अपने एन्कोडेड डेटा की लंबाई में वृद्धि के बिना 100% अतिरेक मिलता है।

वैकल्पिक रूप से, आप अतिरिक्त संपीड़न के लिए अतिरिक्त ग्लिफ़ का उपयोग कर सकते हैं:

• 98 एकल-वर्ण कोड बिंदुओं को चुनकर चर-चौड़ाई एन्कोडिंग को लागू करें। इससे औसत एन्कोडेड सामग्री का आकार लगभग 20% कम हो जाएगा।
• रनिंग-लेंडिंग एन्कोडिंग के समान कुछ को अलग-अलग ग्लिफ़ सेट या ग्लिफ़ सेट संयोजन का उपयोग करके दोहराते हुए निबल्स / बाइट्स का प्रतिनिधित्व करने के लिए लागू करें। जैसे Ab= aba; aB= abab; AB= ababab...
• "शब्दों" और "वाक्यांशों" का प्रतिनिधित्व करने के लिए अतिरिक्त ग्लिफ़ या कोड बिंदुओं का उपयोग करें जो आपके डेटा में दोहराए जाते हैं। हालांकि पूर्व-संपीड़ित डेटा में उच्च स्तर की एंट्रोपी होगी, इसलिए मुझे नहीं पता कि यह कितना प्रभावी होगा।

---

कॉपी करने की त्रुटियों को और कम करने के लिए, मैं ग्रिडलाइन में एन्कोडेड सामग्री को प्रदर्शित करूंगा और ग्राफिंग पेपर पर कॉपी करूंगा। यदि आप कस्टम स्टेशनरी का उपयोग कर सकते हैं जिसमें बारी-बारी से कॉलम / पंक्ति के रंग या त्वरित लुक-अप के लिए लेटरेड कॉलम और गिने पंक्तियों के साथ एक शतरंजबोर्ड-स्टाइल चेकर ग्रिड है, जो प्रतिलिपि सटीकता को बढ़ाएगा।

आप वैकल्पिक वर्ण शैलियों के साथ एक वैकल्पिक ग्रिड लेआउट को त्रुटि का पता लगाने के एक आसान रूप के रूप में भी जोड़ सकते हैं। यानी अगर अजीब कॉलम को हमेशा कैपिटल में रखा जाता है, अगर ट्रांसक्रिप्शनर खुद को अजीब कॉलम में लोअरकेस अक्षर लिखते हुए पाता है, तो उन्हें पता है कि उन्होंने एक त्रुटि की है और यह देखने के लिए वापस ट्रैकिंग शुरू कर सकते हैं कि यह कहां हुआ।

---

यद्यपि यदि आपकी मुख्य प्राथमिकता सटीकता है, तो मैं एक बाइनरी एन्कोडिंग + हैमिंग कोड का उपयोग करूंगा । मानक रेखांकन कागज पर एक (12, 8) छोटा हैमिंग कोड का उपयोग करते हुए, आप केवल 187 बाइट्स फिट कर सकते हैं, केवल 124 बाइट्स डेटा एन्कोडिंग। लेकिन इसे बहुत जल्दी (1 के लिए स्लैश, 0 के लिए कुछ भी नहीं) और एकल त्रुटि सुधार प्रदान किया जा सकता है। एक अतिरिक्त समता बिट (13, 8) पर टैप करने से SECDED (एकल त्रुटि सुधार, दोहरी त्रुटि का पता लगाने) की सुविधा मिलेगी। मानक हैमिंग कोड जैसे (15, 11) या (31, 26) का उपयोग करके, आपको क्रमशः प्रति शीट डेटा 137 और 156 बाइट्स के साथ और भी बेहतर दक्षता मिलती है। यहां तक ​​कि उच्च कोड दरें भी प्राप्त की जा सकती हैं, यह इस बात पर निर्भर करता है कि आप कितना सटीक मानते हैं कि आपका प्रतिलेखक हो सकता है।

एक द्विआधारी एन्कोडिंग को पढ़ना (जोर से) और ओसीआर / ओएमआर को पढ़ना भी आसान होगा।

Comments

जाहिर है मैं ऊपरी मामले के पात्रों का भी उपयोग करने की योजना बना रहा हूं। आपके द्वारा सुझाई गई सभी त्रुटि सुधार योजनाओं में से, मुझे कस्टम फ़ाइल प्रारूप को डिज़ाइन किए बिना उन्हें कार्यान्वित करने का कोई तरीका नहीं दिखता है, क्या वास्तव में फ़ाइलों पर त्रुटि सुधार सुरक्षा लगाने के लिए कोई मिसाल नहीं है? शायद मुझे यह भी उल्लेख करना चाहिए कि कस्टम प्रोग्राम बनाना भी बहुत अवांछित है? मैं किसी भी प्रोग्राम को खोजने के लिए प्रतीत नहीं कर सकता हूं, जो आपकी फाइलों को त्रुटि सुधार कोड के साथ सुरक्षित रखेगा।

— जेरेमी सलवेन

मेरा कहना सिर्फ ऊपरी मामले के पात्रों का उपयोग करना नहीं था, बल्कि विभिन्न लिपियों / फोंट का उपयोग करना भी था। यदि आप केवल ऊपरी और निचले अक्षर अल्फ़ान्यूमेरिक वर्णों का उपयोग करते हैं, तो आपके पास केवल 62 ग्लिफ़ या 3844 कोड बिंदु हैं। आप 2 स्क्रिप्ट्स का उपयोग करके, ट्रांसफर के लिए उपयोग किए जा रहे स्टोरेज माध्यम का लाभ उठाकर कोड पॉइंट्स की तिगुनी से अधिक प्राप्त कर सकते हैं, जो मेरे उत्तर का उद्देश्य था। यदि आप इस तथ्य का लाभ नहीं उठाना चाहते हैं कि यह एक लिखित माध्यम है, तो बहुत सारे फ़ाइल प्रारूप हैं जो त्रुटि एन्कोडिंग को लागू करते हैं। अधिकांश आर्काइव / कम्प्रेशन फॉर्मेट में एरर करेक्शन होता है।

— Lèse majesté

मुझे यकीन नहीं है कि आप नए फ़ाइल स्वरूपों को बनाने से क्या मतलब है। मैंने जिन तकनीकों का उल्लेख किया है, वे सभी हस्तलिखित पाठ / अंकों में मनमाने ढंग से द्विआधारी डेटा एन्कोडिंग के लिए हैं। आप उन्हें इस तरह कंप्यूटर पर संग्रहीत नहीं करेंगे (आप स्कैन की गई छवि को संग्रहीत करने से परे नहीं कर सकते)। मूल रूप से, आपके पास उपयोगकर्ता को कॉपी करने के लिए स्क्रीन पर एक छवि को आउटपुट करने, डेटा को एन्कोड करने का एक कार्यक्रम होगा। फिर इसे कंप्यूटर पर वापस स्थानांतरित करने के लिए, आप एक डिकोडिंग प्रोग्राम का उपयोग करेंगे जो या तो ओसीआर / ओएमआर की स्कैन की गई छवि है या कीबोर्ड के माध्यम से इनपुट को स्वीकार करता है (जैसे alt+ aकर्सिव के लिए "ए")।

— लेजे मेजेस्टे

देखें, कि मुझे क्या समस्या है: "आपके पास डेटा को एन्कोड करने का एक कार्यक्रम होगा" ... नहीं, मैं नहीं। मेरे पास ऐसा करने के लिए कोई कार्यक्रम नहीं है, और मुझे ऐसा करने के लिए किसी भी कार्यक्रम की जानकारी नहीं है। मुझे किसी भी फ़ाइल प्रारूप के बारे में पता नहीं है जो अन्य त्रुटियों के शीर्ष पर फ़ाइल की शुरुआत के पास से हटाए गए बाइट को हटा सकते हैं (मिटाया नहीं)। मैं निश्चित रूप से सहमत हूं कि ये डेटा घनत्व बढ़ाने के तरीके हैं, लेकिन अब यह मेरी प्राथमिक चिंता नहीं है, यह पढ़ने / लिखने और त्रुटि सुरक्षा में आसानी है।

— जेरेमी सालवेन

@ जेरेमी: जैसा कि मैंने कहा, ज्यादातर आर्काइव फॉर्मेट में एरर-करेक्शन होता है, जो ज्यादातर लोगों के लिए काफी अच्छा काम करता है। लेकिन यदि आप कुछ विशेष रूप से हाथ से ट्रांसक्रिप्शनिंग के लिए डिज़ाइन करना चाहते हैं, तो आपको लिखने की ज़रूरत है या किसी ने आपके लिए कुछ लिखा है। अन्यथा, आपका सर्वोत्तम दांव उच्च शोर चैनलों पर संचारित करने के लिए डिज़ाइन किए गए मौजूदा अनुप्रयोगों को देखना है। यद्यपि डेटा घनत्व के लिए कोई चिंता नहीं के साथ सबसे आसान विकल्प केवल उच्च स्तर की त्रुटि सुधार के साथ एक RAR फ़ाइल का उपयोग करना है, और फिर ट्रिपल मॉड्यूलर अतिरेक के लिए हेडर अनुभाग को 3 बार दोहराएं।

— लेज़ मेज़े

Answer 4

हम इस उद्देश्य के लिए एस-रिकॉर्ड का उपयोग करते थे । त्रुटि का पता लगाने के लिए प्रति लाइन एक साधारण चेकसम था। आम तौर पर सभी लेकिन अंतिम पंक्ति की लंबाई तय की गई थी, इसलिए अंत-लाइन मार्कर को सम्मिलन और विलोपन के लिए एक चेक के रूप में कार्य किया गया था। हालांकि लापता लाइनों के लिए कोई जांच नहीं की गई थी। इसके लिए हमने बस लाइनों की संख्या गिना। ज्यादातर फाइलें छोटी थीं, 100 से कम लाइनें थीं, लेकिन मुझे कम से कम एक याद है, जिसमें 300 लाइनें या अधिक थीं। यह सिस्टम में बहुत थकाऊ टाइपिंग फाइलें थीं । बेशक, इस तरह स्थानांतरित किए गए पहले कार्यक्रमों में से एक डाउनलोडर था;)

Answer 5

मशीन से पढ़ने योग्य हस्तलिखित रूपों को बनाने के लिए दशकों से ऑप्टिकल मार्क रिकॉग्निशन का उपयोग किया जाता रहा है। विकिपीडिया पृष्ठ में कई ओपन सोर्स संस्करणों के लिंक हैं।

स्कूलों ने लंबे समय तक परीक्षण के लिए ओएमआर का उपयोग किया है; फ़ॉर्म का उपयोग करना और पढ़ना सरल है, और सटीकता आमतौर पर कीबोर्ड इनपुट से बेहतर है। उच्च सटीकता के लिए, स्कंट्रोन और रेमार्क जैसे वाणिज्यिक निर्माता कस्टम रूप बना सकते हैं।

Comments

यह दिलचस्प है, दुर्भाग्य से, यह काम करने के लिए कंप्यूटर से जुड़ी एक स्कैनर या कुछ अन्य इमेजिंग प्रणाली की आवश्यकता है।

— जेरेमी सलवेन