Комментарии 26
Не так давно у меня возникла необходимость использовать кодированные данные в адресе http-ссылки. Как известно, стандарт http подразумевает регистронезависимые url-адреса и любой прокси-сервер или браузер мог испортить данные в случае использования регистрочувствительного кодирования.
Это что-то новенькое. И в теории и на практике. Только домен — case insensetive.
Буду иметь ввиду, спасибо!
Схема тоже case insensitive, хотя и рекомендуется использовать только lower case.
tools.ietf.org/html/rfc3986#section-3.1
tools.ietf.org/html/rfc3986#section-3.1
А можно наверное улучшить алгоритм, чтобы использовать символы, количество которых не кратно степени двойки? Тогда можно будет достичь еще большей степени сжатия, по сравнению с base64.
Можно дополнить реализацию в статье методом для кодирования любым набором символов для универсальности.
К слову, такой алгоритм я реализовал в итоге в свое время: Кодирование бинарных данных в строку с алфавитом произвольной длины (BaseN).
Позволяет кодировать информацию, представленную набором байт, используя всего 62 символа: A-Z, a-z, 0-9. В конце кодированной последовательности может содержаться несколько спецсимволов (обычно “=”).
65 символов (включая равно, /, +).
Исправьте плиз.
вообще-то, не 65, а 64
= используется чтобы выровнять последовательность.
Ладно, тут есть о чём поспорить, но алфавит выходной всё равно 64 символа
Еще можно вспомнить сопутствующие RFC для MIME кодировок, по которым Base64 последовательность разбивается на куски по 76 символов с помощью перевода строки CRLF, например в email для ограничения длины строки в 80 байт для совместимости со старыми нюансами стандартов.
Хотя по сути вы правы: = относится непосредственно к самой Base64 кодировке, не смотря на то, что в ее «алфавит» не входит.
Хотя по сути вы правы: = относится непосредственно к самой Base64 кодировке, не смотря на то, что в ее «алфавит» не входит.
65, всё верно. 64 для кодирования данных и символ равно как выравнивание хвостовых битов.
Есть модифицированный вариант для УРЛов, вот из вики: «Стандартом Base64-кодирования URL адресов, признается вариант, когда символы '+' и '/' заменяются, соответственно, на '-' и '_' (RFC3548, раздел 4).»
Благодарю за RFC3548. Я использовал другие символы по собственной глупости.
Да, спасибо за уточнение.
А как правильно — последовательность байт или байтов?
Наиболее проработанная таблица символов для облегчения запоминания кодированной информации.
в заключение 4nq7bcgosuemmwcq4gy7ddbcrdeadwcn4napdysttuea6egosmembwfhrdemdwcm4n77bcby4n97bxsozzea9wcn4n67bcby4nhnbwf94n9pbq6oszemxwf74nanh
Запомнил сразу!
Еще есть Base58. Тоже используется для разного рода URL-ов. Там не используются похожие символы типа 0 O I l (латинское i большое и латинское л малое) чтобы было меньше визуальной путаницы и нету символов + и / т.к. они влияют на интерпретацию URL.
Когда-то для внутренностей одного проекта я реализовывал даже Base128. Суть была ровно той же, что и Base64, только оверхед меньше(114% против 133%). Даже не знаю, существует ли такой стандарт кодировки. По идее должен, т.к. очевиден.
P.S. паддинг для Base128, конечно же, будет длиннее, потому она не выгодна для слишком коротких кусков данных.
P.S. паддинг для Base128, конечно же, будет длиннее, потому она не выгодна для слишком коротких кусков данных.
Исходниками не поделитесь? Хотя конечно понимаю, что это не сложно реализовать.
Это было наверное лет 15 назад, если не больше, где-то 94-97 годы или около того. Мы организовывали почтовый обмен данными для своей складской системы и предприятия по доставке медикаментов. Тогда онлайн-интернета толком еще не было, все работало на модемах и весь обмен происходил посредством UUCP в почтовых сообщениях.
Черт, я даже не помню, зачем нам понадобилось изобретать этот велосипед поверх base64 )))
Помню, реализовывали стандартные base64 и uuencode, а вот base128… наверное для самых хреновых каналов опцию эту делали — данных было много, и разница в оверхеде была существенной в итоге.
Так что вряд ли я найду вам исходники, уж простите. Но если вам так нужно, могу набросать заново. Это действительно не сложно: берем каждые 7 символов(56 бит), и преобразуем в восемь семибитных, далее табличная подстановка алфавита и паддинг до кратности(при чем не обязательно паддить именно до кратности).
Только алфавит свой придумаете, я уже не помню, какие именно диапазоны символов мы выбирали, кроме очевидных. Помню, что для совместимости с 7-битной кодировкой(уже в каком-то другом проекте) отдельно что-то мудрили, чтобы избавиться от паддинга — этот 129-й символ был явно лишним в кодировке, предполагающей всего 128 значений для байта.
Черт, я даже не помню, зачем нам понадобилось изобретать этот велосипед поверх base64 )))
Помню, реализовывали стандартные base64 и uuencode, а вот base128… наверное для самых хреновых каналов опцию эту делали — данных было много, и разница в оверхеде была существенной в итоге.
Так что вряд ли я найду вам исходники, уж простите. Но если вам так нужно, могу набросать заново. Это действительно не сложно: берем каждые 7 символов(56 бит), и преобразуем в восемь семибитных, далее табличная подстановка алфавита и паддинг до кратности(при чем не обязательно паддить именно до кратности).
Только алфавит свой придумаете, я уже не помню, какие именно диапазоны символов мы выбирали, кроме очевидных. Помню, что для совместимости с 7-битной кодировкой(уже в каком-то другом проекте) отдельно что-то мудрили, чтобы избавиться от паддинга — этот 129-й символ был явно лишним в кодировке, предполагающей всего 128 значений для байта.
>> Base64… дает результат, который составляет только 130% от длины исходных данных.
Немного занудно, но поправьте: не 130, а 133.(3)% плюс оверхед от паддинга.
Наиболее точно: каждые три байта(8-битных) превращает в четыре байта(6-битных по словарю) и выравнивает в конце дополняющим символом (=) до количества байт, кратного четырем.
Как-то так.
Немного занудно, но поправьте: не 130, а 133.(3)% плюс оверхед от паддинга.
Наиболее точно: каждые три байта(8-битных) превращает в четыре байта(6-битных по словарю) и выравнивает в конце дополняющим символом (=) до количества байт, кратного четырем.
Как-то так.
Всем спасибо за дельные комментарии!
Думаю, это редкий случай, когда статья в совокупности с обсуждением стала не плохим учебным материалом.
Думаю, это редкий случай, когда статья в совокупности с обсуждением стала не плохим учебным материалом.
Тут ещё basE91 не поминали, тоже оригинальная схема кодирования, один раз баловался с ней:
base91.sourceforge.net
base91.sourceforge.net
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ZBase32, Base32 и Base64 алгоритмы кодирования