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