Pull to refresh

Comments 26

Не так давно у меня возникла необходимость использовать кодированные данные в адресе http-ссылки. Как известно, стандарт http подразумевает регистронезависимые url-адреса и любой прокси-сервер или браузер мог испортить данные в случае использования регистрочувствительного кодирования.

Это что-то новенькое. И в теории и на практике. Только домен — case insensetive.
Буду иметь ввиду, спасибо!
А можно наверное улучшить алгоритм, чтобы использовать символы, количество которых не кратно степени двойки? Тогда можно будет достичь еще большей степени сжатия, по сравнению с base64.
Можно дополнить реализацию в статье методом для кодирования любым набором символов для универсальности.
Позволяет кодировать информацию, представленную набором байт, используя всего 62 символа: A-Z, a-z, 0-9. В конце кодированной последовательности может содержаться несколько спецсимволов (обычно “=”).

65 символов (включая равно, /, +).
Исправьте плиз.
= используется чтобы выровнять последовательность.
Ладно, тут есть о чём поспорить, но алфавит выходной всё равно 64 символа
Еще можно вспомнить сопутствующие RFC для MIME кодировок, по которым Base64 последовательность разбивается на куски по 76 символов с помощью перевода строки CRLF, например в email для ограничения длины строки в 80 байт для совместимости со старыми нюансами стандартов.
Хотя по сути вы правы: = относится непосредственно к самой Base64 кодировке, не смотря на то, что в ее «алфавит» не входит.
65, всё верно. 64 для кодирования данных и символ равно как выравнивание хвостовых битов.
Есть модифицированный вариант для УРЛов, вот из вики: «Стандартом Base64-кодирования URL адресов, признается вариант, когда символы '+' и '/' заменяются, соответственно, на '-' и '_' (RFC3548, раздел 4).»
Благодарю за RFC3548. Я использовал другие символы по собственной глупости.
Да, спасибо за уточнение.
А как правильно — последовательность байт или байтов?
Байтов.
Так же как и «пара носков», а не «пара носок»…
Наиболее проработанная таблица символов для облегчения запоминания кодированной информации.
в заключение 4nq7bcgosuemmwcq4gy7ddbcrdeadwcn4napdysttuea6egosmembwfhrdemdwcm4n77bcby4n97bxsozzea9wcn4n67bcby4nhnbwf94n9pbq6oszemxwf74nanh

Запомнил сразу!
Еще есть Base58. Тоже используется для разного рода URL-ов. Там не используются похожие символы типа 0 O I l (латинское i большое и латинское л малое) чтобы было меньше визуальной путаницы и нету символов + и / т.к. они влияют на интерпретацию URL.
Когда-то для внутренностей одного проекта я реализовывал даже Base128. Суть была ровно той же, что и Base64, только оверхед меньше(114% против 133%). Даже не знаю, существует ли такой стандарт кодировки. По идее должен, т.к. очевиден.
P.S. паддинг для Base128, конечно же, будет длиннее, потому она не выгодна для слишком коротких кусков данных.
Исходниками не поделитесь? Хотя конечно понимаю, что это не сложно реализовать.
Это было наверное лет 15 назад, если не больше, где-то 94-97 годы или около того. Мы организовывали почтовый обмен данными для своей складской системы и предприятия по доставке медикаментов. Тогда онлайн-интернета толком еще не было, все работало на модемах и весь обмен происходил посредством UUCP в почтовых сообщениях.
Черт, я даже не помню, зачем нам понадобилось изобретать этот велосипед поверх base64 )))
Помню, реализовывали стандартные base64 и uuencode, а вот base128… наверное для самых хреновых каналов опцию эту делали — данных было много, и разница в оверхеде была существенной в итоге.
Так что вряд ли я найду вам исходники, уж простите. Но если вам так нужно, могу набросать заново. Это действительно не сложно: берем каждые 7 символов(56 бит), и преобразуем в восемь семибитных, далее табличная подстановка алфавита и паддинг до кратности(при чем не обязательно паддить именно до кратности).
Только алфавит свой придумаете, я уже не помню, какие именно диапазоны символов мы выбирали, кроме очевидных. Помню, что для совместимости с 7-битной кодировкой(уже в каком-то другом проекте) отдельно что-то мудрили, чтобы избавиться от паддинга — этот 129-й символ был явно лишним в кодировке, предполагающей всего 128 значений для байта.
>> Base64… дает результат, который составляет только 130% от длины исходных данных.
Немного занудно, но поправьте: не 130, а 133.(3)% плюс оверхед от паддинга.
Наиболее точно: каждые три байта(8-битных) превращает в четыре байта(6-битных по словарю) и выравнивает в конце дополняющим символом (=) до количества байт, кратного четырем.
Как-то так.
Всем спасибо за дельные комментарии!
Думаю, это редкий случай, когда статья в совокупности с обсуждением стала не плохим учебным материалом.
Sign up to leave a comment.

Articles