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