Hata düzeltmesiyle bir dosyayı kalem ve kağıda aktarma


22

Sadece bir kalem ve kağıt kullanarak bir dosyayı aktarmak için bir yol arıyorum.

Bu, paperbak’a biraz benziyor , ancak aradığım yoğunluk çok, çok daha düşük ve bir yazıcı veya tarayıcı kullanmak istemiyorum.

Açıkçası, ilk cevap Base64 kodlamasıdır. Ancak bu kadar çok sayıda karakterin yazılması ve okunması, hatalara yol açması şarttır. Benim amaçlarıma göre, herhangi bir hata kabul edilemez.

İkinci cevap Reed-Solomon hatası düzeltme kodları olabilir (örneğin, rsbep kullanarak ). Ancak, bu aynı zamanda bir problemdir, çünkü benim anladığım kadarıyla Reed-Solomon kodları, muhtemelen bu durumda ikame hatalarından daha muhtemel olan ekleme / silme hatalarını düzeltmemektedir.

Ekleme / silme farkında hata düzeltme kodları ile rastgele dosyaları kodlayan / kodunu çözen bir program var mı? Tercihen Windows, Linux ve Mac OS X üzerinde çalışmalıdır.

Açıkçası genel soruna başka bir çözüm açığız.


Yazarken hata mı yoksa sadece okuma mı bekliyorsunuz?
Christian Mann

Her ikisinde de hatalar bekliyorum, ama aynı zamanda eşdeğer olmalarını da beklerdim ...
Jeremy Salwen

Ay pardon. Yanlış okudum ve baskı yaptığını düşündüm. El ile mi yazmak istiyorsun?
Christian Mann

3
Kaç renk kalem kullanabilirim? :)
Der Hochstapler

1
Sadece tek renkli bir kalem, aksi halde yazıya dökülmesi çok zor olacaktır. Aslında sıkıştırılmış, imzalı, şifreli metin gönderiyorum, bu yüzden% 50 fazlalık oranı bile varsayalım, toplam yazı miktarı orijinal metnin gerçekte yazıldığından <1,5 kat daha fazla olacak (sıkıştırma dikkate alındığında) ). Ancak, rasgele karakterleri kopyalamanın İngilizce metinleri kopyalamaktan daha zor olduğu bir mesele var. Bu yüzden sorunuzu yanıtlamak için, kesinlikle sadece kb aralıktaki çiftlerde.
Jeremy Salwen

Yanıtlar:


4

otherwise transcribing it will be too difficultBir sorun mu olacağından şüpheliyim .

Diyelim ki Kırmızı, Yeşil, Mavi ve Siyah. Verilerinizi bir mektup koleksiyonuna dönüştüren bir komut dosyası yazabilirsiniz RGBY, örneğin: RGBYGBRYBGBYRYYBYBRYYG(hatta Red Green Blue Black Green Blue Red Black...bir Excel sayfasında) ve tekrar. Bu sadece ikilik verilerinizi taban 2'den (ya da taban 16'dan onaltılık verileri) tabanınıza aldığınız renk miktarına (bu örnekte 4) dönüştürmektir.

Şimdi, en mantıklı yaklaşım kendinize 16 renk elde etmektir. Bu şekilde, 4 kat daha az nokta kullanmanız gerekir; bu da buna değer olan kalemler arasında geçiş yapmayı sağlar. Bu, kağıda 4 kat daha fazla veri yazmanıza izin verir veya noktalarınızı koyarken 4 kat daha az kesinliğe sahip olabilir, ölçeklendirme size bağlıdır. Her bir parçayı çizmemeye gerçekten öneriyorum.

Örneğin, bir ızgaraya yerleştirilebilecek olan (aksine ) 5565 bytesonaltılık miktarları elde etmek için iki ile çarpılması gerekir .11130 hexadecimals44520 bits106 x 106

Veri türüne bağlı olarak, muhtemelen bazı optimizasyonlarla gelebilirsiniz ...

İpucu: En belirgin (en zıt) renkleri seçmeye çalış ...

Tek bir kalem kullanabilecek alternatifler:

  • Farklı sembollerle farklı Heksadesimalleri Temsil -, /, |, \, +, ...

  • Farklı onaltılık görüntüleri küçük bir piksel fontuyla temsil edin, avatarıma bakın.

    Bu, Base 32 (veya Base 36) gibi bir şey kullanmayı bile faydalı kılar. QVe 9aynı olduğuna dikkat edin , böylece Qnet bir ayrım için üst sağ pikselinin Beyaz olmasını isteyeceksiniz . Taban 32 sadece 53 x 53örneğin bir ızgara gerektiriyor , ayrıca harfler arasında ayrım yapmak için küçük bir boşluk bırakıyor.


Bununla ilgili birkaç sorun var. 1. Renk körü duyuyorum. 2. Bir sürü kalem almayı gerektirir. 3. Hata düzeltmede hiç yardımcı olmuyor. 4. İnsanların daha kötüsü olduğu metin yerine yazı kodlarını içerir.
Jeremy Salwen

@JeremySalwen: Uhm, bir tablodaki karakterleri yazmak gerçekten zor değil. Ve bazı ekstra uzunlamasına kontrol numaraları veya bir CRC yazarak hataları düzeltebilirsiniz. Ama gerçekten, bir ızgaradan ızgaraya mektuplar yazmak çok kolaydır, sadece onaylamak için tekrar gözden geçirmeniz en kötü durumdur.
Tamara Wijsman

1
@JeremySalwen: Ve eğer renk körüyseniz, sadece renk körü olduğunuz renklerin hiçbirini almazsınız.
Tamara Wijsman

1
Renk körlüğü, renk uzayını, belirli renkleri görememenin seçici bir yetersizliğinden daha fazla boyutsal bir azalmadır. Demek istediğim, muhtemelen Siyah, Mavi, Sarı, Kırmızı, Yeşil, Gri gibi
renkleri çıkartabilirim

@ Tom muhtemelen karışıklığı önlemek için eski avatarınızı yerleştirmelisiniz :)
Nate Koppenhaver 16:12

2

İnsanların verileri okuyup yazabilmesini istiyorsanız, Base64 ve birçok metin kodlamasındaki sorun, insanların kafasını karıştırmak için I, l, 1, |, /, 0, O, o gibi karakterleri kullanmasıdır. birbirleriyle.

Douglas Crockford'un Base32 kodlamasını araştır . Alfabesi, benzer karakterlerden kaçınmak için özel olarak seçildi ve hata tespitini içeriyor.


Teşekkürler, muhtemelen bunu kullanacağım, ancak hala hata düzeltme sorununu çözmüyor.
Jeremy Salwen,

@ Jeremy, Crockford'un uygulaması hata tespitini de içeriyor . Hataları düzeltmeniz gerekiyorsa, İleri Hata Düzeltmeyi araştırın ( en.wikipedia.org/wiki/Forward_error_correction ).
Dour High Arch,

1

Yorumlarınızı okuduktan sonra, bu daha mantıklı geliyor. Bunun gibi megabayt veriyi kodlamak isteyip istemediğinizden emin değildim.

Oliver'ın önerisi doğrultusunda, hapishane çetelerinin genellikle iki ya da daha fazla senaryoda yazılmış olan iki farklı senaryoda saklanan mesajları kodlamak için sıkça kullandıkları Bacon'un şifresinden bir sayfa ödünç alarak veri yoğunluğunuzu arttırmanızı tavsiye ederim. küçük harfli karakterler veya yazdırmaya karşı el yazısı karakterleri;

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

Ancak, amacınız stegnografi olmadığından, bunu glif kümenizi genişletmek için kullanırsınız. Bunu yaparak, yalnızca baskı ve el yazısı alfanümerik karakterleri kullanarak 114 glif veya çift karakterli kodlamayı kullanarak 12996 kod noktasına sahip olabilirsiniz.

Bununla birlikte, tüm glif sayıları 15'ten büyük ve 256'dan küçük sayılar temelde bir ikili veri şifresi için aynıdır (yani, karakter başına 4 bitlik bir veri yoğunluğu veren, her baytı temsil etmek için 2 karaktere ihtiyacınız olacak) tüm durumlarda), fazladan 98 glif / 12740 kod noktasını hata algılama / düzeltme için kullanabilirsiniz.

Bunu yapmanın yolları şunlardır:

  • Karakter kombinasyonlarını okumak / yazmak için en kolay 256 kümesi seçin. Başka bir karakter kombinasyonu olursa, bunun bir kopyalama hatası olduğunu biliyorsunuzdur.
  • Bitiş karakterinin iki sürümünü parite biti olarak kullanın.
  • 50 farklı 16 karakterlik glif kümeleri oluşturun. Hata düzeltme verilerini kodlamak için bunları kullanabilirsiniz.

    Örneğin {set 1}{set 1}, bir sonraki 3 nibble eşit 0x000, {set 1}{set 2}eşittir 0x001, vb. Anlamına gelir .

    Bunu, 4096 olası 1,5 bayt değerinin 2500+ değerini temsil etmek için kullanabilirsiniz. Benzer şekilde, aşağıdaki baytın tüm değerlerini temsil etmek için yalnızca 16 takım kullanabilirsiniz, kodlanmış veri uzunluğunuzu arttırmadan size% 100 fazlalık verir.

Alternatif olarak, ilave sıkıştırma için fazladan glifleri kullanabilirsiniz:

  • 98 tek karakterli kod noktası seçerek değişken genişlikli kodlama uygulayın. Bu, ortalama kodlanmış içerik boyutunu yaklaşık% 20 oranında azaltır.
  • Tekrarlayan nibble / baytları temsil etmek için farklı glif kümeleri veya glif kümesi kombinasyonları kullanarak çalışma uzunluğu kodlamasına benzer bir şey uygulayın. Örneğin, Ab= aba; aB= abab; AB= ababab...
  • Verilerinizde tekrarlanan "kelimeleri" ve "ifadeleri" temsil etmek için fazladan glifleri veya kod noktalarını kullanın. Önceden sıkıştırılmış veriler muhtemelen yüksek bir entropiye sahip olacak olsa da, bunun ne kadar etkili olacağını bilmiyorum.


Kopyalama hatalarını daha da azaltmak için, kodlanmış içeriği kılavuz çizgilerinde görüntüler ve grafik kağıdına kopyalardım. Değişken sütun / satır renkleri olan özel sabitleri veya hızlı görünümler için harfli sütunlar ve numaralı satırları olan satranç tahtası stilinde kareli bir ızgara kullanabilirsiniz, bu, kopyalama doğruluğunu artıracaktır.

Alternatif bir ızgara düzenini, kolay bir hata saptama şekli olarak alternatif karakter stilleriyle birleştirebilirsiniz. Yani, eğer tek sütunlar her zaman büyük harfle yazılırsa, eğer transkript kendi küçük harflerle küçük harflerle yazılırsa, bir hata yaptıklarını bilirler ve nerede olduğunu görmek için geri izlemeye başlayabilirler.


Ana önceliğiniz doğruluk olsa bile, bir ikili kodlama + Hamming kodu kullanırdım . Standart grafik kağıdına (12, 8) kısaltılmış bir Hamming kodu kullanarak, yalnızca 124 bayt veri kodlayan yalnızca 187 bayta sığabilir. Ancak çok hızlı bir şekilde kopyalanabilir (1 için bir eğik çizgi, 0 için hiçbir şey değil) ve tek bir hata düzeltmesi sağlayabilir. Ek bir eşlik biti (13, 8) üzerine yapıştırma işlemi SECDED sağlar (tek hata düzeltmesi, çift hata tespiti). (15, 11) veya (31, 26) gibi standart bir hamming kodu kullanarak, sayfa başına sırasıyla 137 ve 156 bayt veriyle daha iyi verim elde edersiniz. Transkriptinizin ne kadar doğru olduğunu düşündüğünüze bağlı olarak daha yüksek kod oranları elde edilebilir.

Bir ikili kodlamanın okunması (sesli) ve OCR / OMR da daha kolay olacaktır.


Açıkçası ben de büyük harf karakterleri kullanmayı planlıyorum. Önerdiğiniz tüm hata düzeltme şemaları dışında, özel bir dosya formatı vb. Tasarlamadan bunları uygulamanın bir yolunu görmüyorum. Dosyalara hata düzeltme korumasını koymak için bir emsal yok mu? Belki de özel programlar oluşturmanın da çok istenmeyen olduğunu söylemeliydim? Hata düzeltme kodlarıyla dosyalarınızı koruyacak herhangi bir program bulamıyorum.
Jeremy Salwen

Demek istediğim sadece büyük harfler kullanmak değil, aynı zamanda farklı scriptler / fontlar kullanmaktı. Yalnızca büyük ve küçük harf alfasayısal karakterler kullanıyorsanız, yalnızca 62 glif veya 3844 kod noktanız vardır. Cevabımın amacı olan transfer için kullanılan depolama ortamından yararlanarak, 2 komut dosyası kullanarak bu miktardaki kod puanlarının üç katından fazlasını alabilirsiniz. Bunun yazılı bir ortam olduğu gerçeğinden yararlanmak istemiyorsanız, hata kodlaması uygulayan birçok dosya biçimi vardır. Çoğu arşiv / sıkıştırma formatı yerleşik olarak hata düzeltme özelliğine sahiptir.
Lèse majesté

Yine de yeni dosya biçimleri oluşturarak ne demek istediğinizi bilmiyorum. Bahsettiğim tekniklerin tümü, el yazısı metin / işaretlerdeki rastgele ikili verileri görsel olarak kodlamak içindir. Onları bilgisayarda böyle saklayamazsınız (taranmış bir resmi kaydetmenin ötesine geçemezsiniz). Temel olarak, kullanıcının kodlaması için ekranda bir görüntü çıktısını alan, verileri kodlayacak bir programınız olurdu. Sonra bir bilgisayara geri aktarmak için, OCR / OMR'nin taranan görüntü olduğu ya da girişi klavye yoluyla kabul eden bir kod çözme programı kullanacaksınız (örneğin, "a" için el yazısı için alt+ a).
Lèse majesté

Gördüğüm gibi sorun şu ki: "verileri kodlamak için bir programın olurdu" ... hayır, bilmiyorum. Bunu yapacak bir programım yok ve yapacak bir programım yok. Ayrıca , diğer hataların üstünde dosyanın başlangıcından itibaren silinen (silinmeyen) kaldırılan bir baytı incelikle ele alabilecek herhangi bir dosya biçiminin de farkında değilim . Bunların veri yoğunluğunu arttırma yöntemleri olduğuna kesinlikle katılıyorum, ancak bu şimdi ana sorunum değil, okuma / yazma ve hata korumanın kolaylığı.
Jeremy Salwen

@ Jeremy: Dediğim gibi, çoğu arşiv formatı, çoğu insan için yeterince iyi çalıştığı anlaşılan hata düzeltmesine sahiptir. Ancak, el yazısı için özel olarak tasarlanmış bir şey istiyorsanız, o zaman yazmanız veya sizin için bir şeyler yazmanız gerekir. Aksi halde, en iyi bahis, yüksek gürültülü kanallar üzerinden yayın yapmak için tasarlanmış mevcut uygulamalara bakmaktır. Her ne kadar veri yoğunluğu için endişesiz en kolay seçenek sadece yüksek seviyede hata düzeltmeli bir RAR dosyası kullanmak ve daha sonra üçlü modüler yedeklilik için başlık bölümünü 3 kez tekrarlamak.
Majesteleri

1

Bu amaçla S-Records kullanıyorduk . Hata tespiti için satır başına basit bir sağlama toplamı vardı. Normalde son satır dışındakilerin tümü sabit uzunluktaydı, bu nedenle satır sonu işaretçisinin ekleme ve silme kontrolü olarak görev yaptı. Yine de eksik hatların kontrolü yoktu. Bunun için satır sayısını saydık. Çoğunlukla dosyalar 100 satırdan az, kısa, ancak 300 satır veya daha fazla olan en az birini hatırlıyorum. O was çok sisteme sıkıcı yazarak dosyaları. Tabii ki, bu şekilde aktarılan ilk programlar arasında bir indirici oldu;)


0

Optik Mark Tanıma , on yıllardır makinede okunabilen el yazısı formları oluşturmak için kullanılmıştır. Wikipedia sayfasının birçok Açık Kaynak versiyonuna bağlantıları vardır.

Okullar uzun süredir test için OMR'yi kullandılar; formların kullanımı ve okunması kolaydır ve doğruluk genellikle klavye girişinden daha iyidir. Daha yüksek doğruluk için, Scantron ve ReMark gibi ticari üreticiler özel formlar oluşturabilir.


Bu ilginç, maalesef, çalışması için bilgisayara bağlı bir tarayıcı veya başka bir görüntüleme sistemi gerekiyor.
Jeremy Salwen
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.