Есть ли хороший двухсторонний хэш для преобразования адреса электронной почты в предсказуемое, читаемое имя пользователя Unix?

Question

Мы работаем с несколькими файловыми системами на основе Unix, которые имеют одинаковый набор ограничений на то, что определенные символы не могут использоваться в полях имени пользователя. Одно из таких ограничений - «@», «_» или «.» в именах. Для Unix существует ряд других ограничений.

Итак, вопрос в том, существует ли хорошо известный алгоритм, который может взять адрес электронной почты и превратить его в предсказуемое имя файла Unix. Нам нужно будет отменить это в какой-то момент, чтобы получить письмо

Я подумал о том, чтобы сделать что-то вроде "." -> "DOT", "@" -> "AT" и т. Д. Но есть ограничения по размеру и другие проблемы, которые обычно проблематичны. Я также мог бы оптимизировать, сопоставив часть электронной почты @ xyz.com со специальным символом или чем-то еще. Каждая реализация будет иметь не более 3 доменов, которые она должна будет поддерживать. Я надеюсь, что кто-то нашел решение без огромного количества компромиссов.

UPDATE: - Две целевые файловые системы - AFS и NFS.

-Base64 не работает, так как содержит несовместимые символы. "/"

-Чтение предпочтительнее.

Похоже, что лучшим ответом было бы заменить домен @ xyz.com одним нестандартным символом, а затем иметь функцию, которая могла бы сжимать первую часть имени до чего-то, что соответствует ограничениям длины имени пользователя: различные файловые системы. Но что для этого подходит?

Answer 1

Вы можете попробовать модифицированную версию схемы кодирования процентов (%) URL, используемой для URI.

Если символ процента не разрешен в вашей конкретной файловой системе (ах), просто замените его другим разрешенным символом (и не забывайте правильно кодировать любые вхождения этого символа).

Используя этот метод: mail.address@server.com

станет: mail%2Eaddress%40server%2Ecom

Или, если вам пришлось заменить (например) букву a вместо символа %: ma61ila2Ea61ddressa40servera2Ecom

Возможно, не совсем читабельно, но достаточно легко обрабатывается с помощью алгоритма кодирования. Для максимальной эффективности использования пробела символ перехода должен быть разрешен файловой системой, но вряд ли он часто встречается в адресе.

Преимущество этой схемы кодирования заключается в том, что для большинства обычных символов увеличение размера отсутствует. Длина строки будет увеличиваться ТОЛЬКО для символов, не поддерживаемых файловой системой.

Answer 2

Проверьте base64. Кодирование и декодирование четко определены. Я предпочел бы это вместо того, чтобы свернуть мой собственный формат в любой день.

Answer 3

Дано ...
- ограниченный набор символов, допустимый в различных файловых системах
- желание сохранить закодированный адрес электронной почты коротким (как для удобства чтения, так и для возможных проблем с ограничениями файловой системы)
... возможный подход может быть логика двухэтапного кодирования , при которой адрес электронной почты

• сначала сжимается с использованием алгоритма сжатия без потерь, такого как Lempel-Ziv, эффективно превращая его в «двоичную» форму, хранящуюся в более коротком массиве байтов
  
• затем этот массив байтов кодируется с использованием Base64-подобного алгоритма

Идея состоит в том, чтобы минимизировать размер двоичного представления, чтобы расширение, связанное с неэффективностью хранения кодирования, которое может хранить только приблизительно 6 бит (и, возможно, немного меньше) на символ, не вызывает закодированная строка слишком длинная.
Без излишней сложности со сжатием и кодированием такая система, скорее всего, будет производить закодированные строки, которые, возможно, составляют 4/5 от размера входной строки (адрес электронной почты): сжатие должно легко вдвое меньше, чем кодирование, скажем, Base32 , увеличит размер двоичной формы на 8 / 5.

Усилия по улучшению степени сжатия могут позволить выбрать более «расточительные» схемы кодирования (с меньшими наборами символов), и это может помочь сделать вывод более понятным для человека, а также более безопасным в различных вариантах файловых систем. Например, когда Base64 кажется оптимальным. В отношении пробелов использование только заглавной буквы (основание 26) может обеспечить переносимость базовой схемы на файловые системы, в которых имена файлов не чувствительны к регистру.
Другое преимущество начального универсального сжатия заключается в том, что необходимо сделать несколько предположений относительно синтаксиса действительного ключа ввода (адреса электронной почты здесь).

Идеи для сжатия :
LZ кажется хорошим выбором, хотя можно считать primin его начальным буфером с общими шаблонами, найденными в адресах электронной почты (например, «.com» или даже «a.com», «b.com» и т. Д.).
Это Первоначальный буфер обеспечивал бы несколько экземпляров «ссылок» на сжатый адрес электронной почты, следовательно, в целом лучший коэффициент сжатия). Для дальнейшего сжатия нескольких байтов может быть использован LZH или другие варианты LZ.
Помимо заполнения буфера, упомянутого выше, другой настройкой может быть использование более короткого буфера, чем типичные алгоритмы LZ, так как строка, которую мы должны сжимать (экземпляры адресов электронной почты), сами по себе очень короткие и не выиграют, скажем, от буфера в 512 байт , (Более короткие размеры буфера позволяют более короткие коды для ссылок)

Идеи для кодирования :
Base64 не подходит как есть из-за косой черты (/), плюс (+) и равных (=) символов. Альтернативные символы могут быть использованы для их замены; На ум приходит тире (-), но поиск трех символов, разрешенных всеми «разновидностями» целевых файловых систем, может быть трудным.
Тем не менее Base64 и его 4 выходных символа на 3 байта полезной нагрузки обеспечивают, вероятно, едва достижимый верхний предел эффективности хранения [для приемлемого набора символов].
В нижней части этой эффективности может быть ASCII-представление шестнадцатеричных значений байтов в массиве . Этот формат с удвоением байтов полезной нагрузки может быть приемлемым по длине и интересен своей простотой (существует прямая и простая связь между каждым полубайтом (4 бита) на входе и символами в кодированной строке.
Base32 , в результате чего от A до Z кодируют от 0 до 25 и от 0 до 5 кодируют от 26 до 31 соответственно, поэтому вариация Base64 с соотношением 8 выходных символов на 5 байтов полезной нагрузки может быть очень приемлемым компромиссом.

Answer 4

Хм, из твоего вопроса, я не совсем ясен в этом вопросе, но, так как ты хотел какого-то преобразования, я предполагаю, что ты хочешь что-то, что, по крайней мере, читается человеком?

Каждая ОС может иметь свои ограничения, но достаточно ли вы близки к платформам, чтобы вы могли узнать / проверить, что приемлемо для имени пользователя? Если бы вы могли найти три «специальных» символа, которые вы могли бы использовать только для замены на '@', '.', '_', вам было бы хорошо пойти. (Это всеобъемлющее? Если нет, то вам нужно убедиться, что вы знаете все из них, иначе вы можете столкнуться.) Я немного искал, пытаясь выяснить, существует ли стандарт POSIX, но не смог ничего найти, вот почему Я думаю, что если вы можете просто проверить, что действительно, это будет самый прямой путь.

Даже с одним специальным символом вы можете выполнить кодировку URL-адреса, либо с помощью «%», если он доступен, либо с любым другим, если вы не выберите, скажем «!», Затем { '@'->'!40", '_'->'!5F', '.'-> '!2E' }. (Спецификация [RFC1738] http://www.rfc -editor.org / rfc / rfc1738.txt ) определяет символы как US-ASCII, поэтому вы можете просто найти таблицу, например, в статье ASCII Википедии и найти правильные шестнадцатеричные цифры там.) Или, вы можете просто сделать свое собственное простое отображение, так как вам не нужен весь набор ASCII, вы можете просто сделать карту с двумя символами для каждого экранированного символа и иметь, скажем, '!a','!u','!p' для at, подчеркивания, точки .

Если у вас есть два специальных символа, скажем, «%» и «!», Вы можете разделить текст, который представляет символ, скажем, %at!, &us! и '&pd!'. (Это в значительной степени кодировка в стиле html, но вместо '&' и ';' вы используете доступные и создаете свою собственную мнемонику.) Другая идея заключается в том, что вы можете использовать серии символов для определить переведенный символ, где каждый новый символ меняется, какой символ используется. (Это удобно останавливает выполнение, если нам нужно поместить два запрещенных символа рядом друг с другом.) Итак, предположим, что «%» и «!», С периодом 1, подчеркиванием 2 и знаком-знаком, равным трем, 'mickey._sample_@fake.out' станет 'mickey%!!sample%%!!!fake%out'. Существуют и другие варианты, но этот код легко кодировать.

Если ни одна из этих опций не является опцией (например, вообще нет символов, просто [a-zA-Z0-9]), то на самом деле я думаю, что ответ Base64 звучит правильно. На самом деле, когда мы добираемся до чего-то другого, кроме простой замены (и даже этого), уже становится трудно печатать, если это цель. Но если вам действительно нужно, чтобы электронная почта была в основном читабельной, то вы делаете что-то вроде экранирования. Я думаю, использовать «0» в качестве escape-символа, поэтому теперь «0» становится «00», «@» становится «01», «.» становится «02», а «_» становится «03». Так что теперь 'mickey01._sample_@fake.out' станет 'mickey0010203sample0301fake02out'. Не красиво, но это должно работать; так как мы избежали любых необработанных нулей, просто убедитесь, что вы определили отображение для того, что вы выбрали в качестве escape-символа, и у вас все будет хорошо ..

Это все, что я могу придумать. :) Определенно, если нет необходимости, чтобы эти имена пользователей были доступны для чтения в сыром виде, кажется, что, очевидно, Base64 не будет работать, так как он может создавать косые черты. Черт, ладно, просто двухзначное шестнадцатеричное значение US-ASCII для каждого символа, и все готово ...] - хороший путь; для этого есть множество хороших отлаженных, тщательно протестированных в полевых условиях кодов, и он довольно легко решает вашу проблему. :)