Как перенести файл поверх ручки и бумаги, с исправлением ошибок

Я сомневаюсь, otherwise transcribing it will be too difficultбудет ли проблема.

Допустим, у вас есть красный, зеленый, синий и черный. Вы можете написать скрипт, который превращает ваши данные в набор писем RGBY, например: RGBYGBRYBGBYRYYBYBRYYG(или даже Red Green Blue Black Green Blue Red Black...в лист Excel) и обратно. Это просто вопрос базового преобразования ваших двоичных данных из базы 2 (или шестнадцатеричных данных из базы 16) в базу в количестве цветов, которые вы берете (4 в этом примере).

Теперь самым логичным подходом было бы получить себе 16 цветов. Таким образом, вы должны использовать в 4 раза меньше точек, что делает переключение между ручками того стоит. Это позволяет вам записывать в 4 раза больше данных на бумаге, если вам нужно или, возможно, иметь, может быть в 4 раза менее точно при нанесении точек, масштабирование зависит от вас. Я бы действительно советовал не рисовать каждый бит.

Например, 5565 bytesпришлось бы умножить на два, чтобы получить количество шестнадцатеричных чисел, которое 11130 hexadecimals(в отличие от 44520 bits) может быть помещено в 106 x 106сетку.

В зависимости от типа данных вы можете прийти с некоторыми оптимизациями ...

Подсказка: попытайтесь выбрать наиболее четкие (наиболее контрастные) цвета ...

Альтернативы, которые могут использовать одну ручку:

• Представляют различный шестнадцатеричном от различных символов -, /, |, \, +, ...

• Представьте различные шестнадцатеричные числа маленьким пиксельным шрифтом, см. Мой аватар.

  

  Это делает даже полезным использовать что-то вроде Base 32 (или Base 36). Обратите внимание, что Qи 9совпадают, поэтому вам нужно, чтобы верхний правый пиксель Qбыл белым для четкого различия. Base 32 требует только 53 x 53сетку для вашего примера, плюс небольшой интервал между буквами.

Если вы хотите, чтобы люди могли читать и записывать данные, проблема с Base64 и многими кодировками текста заключается в том, что они используют такие символы, как I, l, 1, |, /, 0, O, o и т. Д., Что люди путают друг с другом.

Исследуйте кодировку Base32 Дугласа Крокфорда . Его алфавит был специально выбран, чтобы избежать подобных символов, и он включает в себя обнаружение ошибок.

После прочтения ваших комментариев это звучит более разумно. Я просто не был уверен, что вы собираетесь кодировать мегабайты таких данных.

Я бы порекомендовал, в соответствии с предложением Оливера, увеличить плотность данных, заимствуя страницу из шифра Бэкона, которую часто используют тюремные банды для кодирования скрытых сообщений в сообщениях, написанных в 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-символьных наборов глифов. Затем вы можете использовать их для шифрования данных для исправления ошибок.

  Например, следующие 3 полубайта равны 0x000, равны 0x001и т. Д.

  Вы можете использовать это для представления 2500+ из 4096 возможных 1,5-байтовых значений. Точно так же вы можете использовать только 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 байтами данных на лист соответственно. Еще более высокая скорость кодирования может быть достигнута, в зависимости от того, насколько точным, по вашему мнению, может быть ваш транскрибер.

Бинарное кодирование также будет легче читать (вслух) и OCR / OMR.

We used to use S-Records for this purpose. There was a simple checksum, per line, for error detection. Normally all but the last line was fixed length, so the end-of-line marker served as a check for insertions and deletions. There was no check for missing lines though. For this we simply counted the number of lines. Mostly files were short, less than 100 lines, but I do remember at least one which had 300 lines or more. It was very tedious typing files into the system. Of course, among the first programs transferred this way was a downloader ;)

Оптическое распознавание меток использовалось десятилетиями для создания машиночитаемых рукописных форм. На странице Википедии есть ссылки на несколько версий с открытым исходным кодом.

Школы давно используют OMR для тестирования; формы просты в использовании и чтении, а точность обычно лучше, чем ввод с клавиатуры. Для более высокой точности коммерческие производители, такие как Scantron и ReMark, могут создавать собственные формы.