Cách chuyển tập tin qua bút và giấy, với sửa lỗi

Tôi đang tìm cách chuyển tập tin chỉ bằng bút và giấy.

Điều này hơi giống với paperbak , ngoại trừ mật độ tôi đang tìm kiếm thấp hơn nhiều, và tôi không muốn sử dụng máy in hoặc máy quét.

Rõ ràng, câu trả lời đầu tiên là mã hóa Base64 . Nhưng viết và đọc một số lượng lớn các ký tự như vậy chắc chắn sẽ dẫn đến lỗi. Đối với mục đích của tôi, bất kỳ lỗi là không thể chấp nhận.

Câu trả lời thứ hai có thể là mã sửa lỗi của Reed-Solomon (ví dụ: sử dụng rsbep ). Tuy nhiên, đây cũng là một vấn đề, bởi vì theo hiểu biết của tôi, mã Reed-Solomon không sửa lỗi chèn / xóa, có lẽ nhiều khả năng hơn lỗi thay thế trong trường hợp này.

Có chương trình nào sẽ mã hóa / giải mã các tệp tùy ý với các mã sửa lỗi nhận biết chèn / xóa không? Tốt nhất là nó nên hoạt động trên Windows, Linux và Mac OS X

Rõ ràng bất kỳ giải pháp khác cho vấn đề chung đều được hoan nghênh.

Tôi nghi ngờ nếu otherwise transcribing it will be too difficultsẽ là một vấn đề.

Giả sử bạn có Đỏ, Xanh lục, Xanh lam và Đen. Bạn có thể viết một tập lệnh biến dữ liệu của bạn thành một tập hợp các chữ cái từ RGBY, ví dụ: RGBYGBRYBGBYRYYBYBRYYG(hoặc thậm chí Red Green Blue Black Green Blue Red Black...trong một bảng Excel) và quay lại. Đây chỉ là vấn đề cơ sở chuyển đổi dữ liệu nhị phân của bạn từ cơ sở 2 (hoặc dữ liệu thập lục phân từ cơ sở 16) sang cơ sở theo số lượng màu bạn lấy (4 trong ví dụ này).

Bây giờ, cách tiếp cận hợp lý nhất sẽ là lấy cho mình 16 màu. Bằng cách này, bạn phải sử dụng số chấm ít hơn 4 lần , điều này làm cho việc chuyển đổi giữa các cây bút trở nên đáng giá. Điều này cho phép bạn viết gấp 4 lần dữ liệu trên giấy nếu bạn cần, hoặc có lẽ có thể chính xác hơn 4 lần khi đặt dấu chấm của bạn, tỷ lệ tùy thuộc vào bạn. Tôi thực sự sẽ khuyên không nên vẽ từng bit một.

Chẳng hạn, 5565 bytessẽ phải được nhân với hai để có được số lượng hexadecimals 11130 hexadecimals(trái ngược với 44520 bits) có thể được đưa vào 106 x 106lưới.

Tùy thuộc vào loại dữ liệu bạn có thể có thể đi kèm với một số tối ưu hóa ...

Gợi ý: Cố gắng chọn các màu khác biệt (tương phản nhất) ...

Các lựa chọn thay thế có thể sử dụng một cây bút duy nhất:

• Đại diện cho hexadecimals khác nhau bằng các ký hiệu khác nhau -, /, |, \, +, ...

• Đại diện cho các hexadecimals khác nhau bằng một phông chữ pixel nhỏ, xem hình đại diện của tôi.

  

  Điều này làm cho nó thậm chí hữu ích để sử dụng một cái gì đó như Base 32 (hoặc Base 36). Lưu ý rằng Qvà 9giống nhau, vì vậy bạn sẽ muốn pixel trên cùng bên phải Qlà Trắng để phân biệt rõ ràng. Cơ sở 32 chỉ yêu cầu một 53 x 53lưới cho ví dụ của bạn, cộng với một chút khoảng cách để phân biệt giữa các chữ cái.

Nếu bạn muốn mọi người có thể đọc và ghi dữ liệu, vấn đề với Base64 và nhiều mã hóa văn bản là họ sử dụng các ký tự như I, l, 1, |, /, 0, O, o, v.v. với nhau

Điều tra mã hóa Base32 của Douglas Crockford . Bảng chữ cái của nó được chọn đặc biệt để tránh các ký tự tương tự, và nó bao gồm phát hiện lỗi.

Sau khi đọc bình luận của bạn, điều đó nghe có vẻ hợp lý hơn. Tôi chỉ không chắc chắn nếu bạn có ý định mã hóa megabyte dữ liệu như thế này.

Tôi khuyên bạn, dọc theo dòng gợi ý của Oliver, bạn nên tăng mật độ dữ liệu bằng cách mượn một trang từ mật mã của Bacon , mà các băng đảng nhà tù thường sử dụng để mã hóa các tin nhắn ẩn trong các tên lửa được viết theo 2 kiểu chữ viết khác nhau - thường là trên ký tự chữ thường hoặc in so với ký tự chữ thảo, vd

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

Tuy nhiên, vì mục tiêu của bạn không phải là bản sao, bạn chỉ cần sử dụng mục tiêu này để mở rộng bộ glyph của mình. Làm điều này, bạn có thể có tới 114 glyphs chỉ bằng cách sử dụng các ký tự chữ và số in chữ thảo hoặc 12996 điểm mã bằng cách sử dụng mã hóa ký tự kép.

Tuy nhiên, vì tất cả số lượng glyph lớn hơn 15 và nhỏ hơn 256 về cơ bản là giống nhau cho một mật mã thẳng của dữ liệu nhị phân (nghĩa là, bạn vẫn sẽ cần 2 ký tự để biểu thị mỗi byte, cung cấp cho bạn mật độ dữ liệu 4 bit cho mỗi ký tự tất cả các trường hợp), bạn có thể sử dụng thêm 98 điểm glyphs / 12740 điểm để phát hiện / sửa lỗi.

Các cách để làm điều này bao gồm:

• Chọn một bộ gồm 256 bộ ký tự dễ đọc / ghi nhất. Nếu bất kỳ kết hợp ký tự nào khác xảy ra, bạn biết đó là lỗi sao chép.
• Sử dụng hai phiên bản của ký tự kết thúc dưới dạng một bit chẵn lẻ.

• Tạo 50 bộ glyph 16 ký tự khác nhau. Sau đó, bạn có thể sử dụng chúng để mã hóa dữ liệu sửa lỗi.

  Ví dụ: {set 1}{set 1}3 nibble tiếp theo bằng nhau 0x000, {set 1}{set 2}bằng nhau 0x001, v.v.

  Bạn có thể sử dụng điều này để biểu thị 2500+ trong số 4096 giá trị 1,5 byte có thể. Tương tự, bạn có thể sử dụng chỉ 16 bộ để biểu diễn tất cả các giá trị của byte sau, mang lại cho bạn 100% dự phòng mà không làm tăng độ dài dữ liệu được mã hóa của bạn.

Ngoài ra, bạn có thể sử dụng glyphs bổ sung để nén bổ sung:

• Thực hiện mã hóa độ rộng thay đổi bằng cách chọn 98 điểm mã ký tự đơn. Điều này sẽ làm giảm kích thước nội dung được mã hóa trung bình khoảng 20%.
• Thực hiện một cái gì đó tương tự như mã hóa độ dài chạy bằng cách sử dụng các tập hợp glyph hoặc tập hợp glyph khác nhau để biểu diễn các nibble / byte lặp lại. Ví dụ Ab= aba; aB= abab; AB= ababab...
• Sử dụng các glyphs hoặc điểm mã bổ sung để thể hiện "từ" và "cụm từ" được lặp lại trong dữ liệu của bạn. Mặc dù dữ liệu được nén trước có thể sẽ có mức độ entropy cao, vì vậy tôi không biết hiệu quả của việc này sẽ như thế nào.

---

Để tiếp tục giảm lỗi sao chép, tôi sẽ hiển thị nội dung được mã hóa theo đường lưới và sao chép vào giấy vẽ biểu đồ. Nếu bạn có thể sử dụng văn phòng phẩm tùy chỉnh có màu sắc cột / hàng xen kẽ hoặc lưới rô theo kiểu bàn cờ với các cột chữ và hàng được đánh số để tra cứu nhanh, điều đó sẽ tăng thêm độ chính xác sao chép.

Bạn cũng có thể kết hợp bố cục lưới xen kẽ với các kiểu ký tự xen kẽ như một hình thức phát hiện lỗi dễ dàng. Tức là nếu các cột lẻ luôn được viết hoa, nếu người chuyển đổi thấy mình viết các chữ cái viết thường trong các cột lẻ, thì họ biết rằng họ đã mắc lỗi và có thể bắt đầu theo dõi lại để xem nó xảy ra ở đâu.

---

Mặc dù nếu ưu tiên chính của bạn là độ chính xác, tôi sẽ sử dụng mã hóa nhị phân + mã Hamming . Sử dụng mã Hamming rút gọn (12, 8) trên giấy vẽ đồ thị tiêu chuẩn, bạn có thể chỉ phù hợp với 187 byte, chỉ mã hóa 124 byte dữ liệu. Nhưng nó có thể được sao chép rất nhanh (dấu gạch chéo cho 1, không có gì cho 0) và cung cấp sửa lỗi đơn. Việc xử lý một bit chẵn lẻ bổ sung (13, 8) sẽ cung cấp SECDED (sửa lỗi đơn, phát hiện lỗi kép). Sử dụng mã hamming tiêu chuẩn như (15, 11) hoặc (31, 26), bạn sẽ có được hiệu quả thậm chí tốt hơn với lần lượt là 137 và 156 byte dữ liệu trên mỗi tờ. Thậm chí tỷ lệ mã cao hơn có thể đạt được, tùy thuộc vào mức độ chính xác mà bạn nghĩ rằng người chuyển đổi của bạn có thể.

Mã hóa nhị phân cũng sẽ dễ đọc hơn (to) và OCR / OMR.

Chúng tôi thường sử dụng S-Records cho mục đích này. Có một tổng kiểm tra đơn giản, trên mỗi dòng, để phát hiện lỗi. Thông thường tất cả ngoại trừ dòng cuối cùng là độ dài cố định, do đó, điểm đánh dấu cuối dòng được dùng làm kiểm tra để chèn và xóa. Không có kiểm tra cho các dòng bị thiếu mặc dù. Đối với điều này, chúng tôi chỉ đơn giản là đếm số lượng dòng. Hầu hết các tệp đều ngắn, dưới 100 dòng, nhưng tôi nhớ ít nhất một dòng có 300 dòng trở lên. Nó rất tẻ nhạt gõ các tập tin vào hệ thống. Tất nhiên, trong số các chương trình đầu tiên được chuyển theo cách này là một trình tải xuống;)

Nhận dạng nhãn hiệu quang học đã được sử dụng trong nhiều thập kỷ để tạo ra các hình thức viết tay có thể đọc được bằng máy. Trang Wikipedia có các liên kết đến một số phiên bản Nguồn mở.

Các trường từ lâu đã sử dụng OMR để thử nghiệm; các hình thức đơn giản để sử dụng và đọc, và độ chính xác thường tốt hơn so với nhập bằng bàn phím. Để có độ chính xác cao hơn, các nhà sản xuất thương mại như Scantron và ReMark có thể tạo các biểu mẫu tùy chỉnh.