Base64

редактировать

В программировании Base64 - это группа двоичного кода в текст кодирование схем, представляющих двоичные данные (точнее, последовательность из 8-битных байтов) в строковый формат ASCII, переводя их в основание - 64 представления. Термин Base64 происходит от конкретной кодировки передачи содержимого MIME. Каждая незавершенная цифра Base64 представляет ровно 6 бит данных. Таким образом, три 8-битных байта (то есть всего 24 бита) могут быть представлены четырьмя 6-битными цифрами Base64.

Общий для всех схем кодирования двоичного кода в текст, Base64 предназначен для передачи данных, хранящихся в двоичных форматах, по каналам, которые надежно поддерживают только текстовое содержимое. Base64 особенно распространен в World Wide Web, где его использование включает возможность встраивать файлы изображений или другие двоичные ресурсы в текстовые ресурсы, такие как HTML и Файлы CSS.

Base64 также широко используется для отправки вложений электронной почты. Это необходимо, потому что SMTP в своей исходной форме был разработан для передачи только 7-битных символов ASCII. Эта кодировка вызывает накладные расходы в размере 33–36% (33% из-за самой кодировки, до 3% больше из-за вставленных разрывов строки).

Содержание

  • 1 Дизайн
  • 2 Таблица Base64
  • 3 Примеры
    • 3.1 Заполнение вывода
    • 3.2 Декодирование Base64 с заполнением
    • 3.3 Декодирование Base64 без заполнения
  • 4 Реализации и история
    • 4.1 Сводная таблица вариантов
    • 4.2 Почта с улучшенной конфиденциальностью
    • 4.3 MIME
    • 4.4 UTF-7
    • 4.5 OpenPGP
    • 4.6 RFC 3548
    • 4.7 RFC 4648
    • 4.8 Имена файлов
    • 4.9 Приложения URL
    • 4.10 HTML
    • 4.11 Другие приложения
    • 4.12 Приложения Radix-64, несовместимые с Base64
  • 5 См. Также
  • 6 Ссылки

Дизайн

Конкретный набор из 64 символов, выбранных для представления 64 цифровых значений для базы, варьируется в зависимости от реализации. Общая стратегия состоит в том, чтобы выбрать 64 символа, которые являются общими для большинства кодировок и которые также печатаются. Эта комбинация оставляет маловероятным изменение данных при передаче через информационные системы, такие как электронная почта, которые традиционно не были 8-битными чистыми. Например, реализация MIME Base64 использует AZ, azи 09для первых 62 значений. Другие варианты разделяют это свойство, но отличаются символами, выбранными для последних двух значений; пример: UTF-7.

Самые ранние экземпляры этого типа кодирования были созданы для коммутируемого соединения между системами, работающими под одной и той же ОС - например, uuencode для UNIX, BinHex для TRS-80 (позже адаптированный для Macintosh ) - и поэтому мог сделать больше предположений о том, какие символы были безопасными использовать. Например, uuencode использует прописные буквы, цифры и многие символы пунктуации, но не строчные.

Таблица Base64

Таблица индексов Base64:

IndexBinaryCharIndexBinaryCharIndexBinaryCharIndexДвоичныйChar
0000000A16010000Q32100000g48110000w
1000001B17010001R33100001h49110001x
2000010C18010010S34100010i50110010y
3000011D19010011T35100011j51110011z
4000100E20010100U36100100k521101000
5000101F21010101V37100101l531101011
6000110G22010110W38100110m541101102
7000111H23010111X39100111n551101113
8001000I24011000Y40101000o561110004
9001001J25011001Z41101001p571110015
10001010K26011010a42101010q581110106
11001011L27011011b43101011r591110117
12001100M28011100c44101100s601111008
13001101N29011101d45101101t611111019
14001110O30011110e46101110u62111110+
15001111P31011111f47101111v63111111/
Padding=

Примеры

В приведенном ниже примере для простоты используется текст ASCII, но это не типичный вариант использования, поскольку он может уже безопасно переносится во все системы, поддерживающие Base64. Более типичное использование - кодирование двоичных данных (например, изображения); итоговые данные Base64 будут содержать только 64 различных символа ASCII, каждый из которых может надежно передаваться между системами, что может повредить исходные байты.

Вот цитата из Томаса Гоббса «Левиафан :

. Человека отличает не только его разум, но и особая страсть других животных, которая является вожделение ума, которое благодаря настойчивости восторга в непрерывном и неутомимом накоплении знания превосходит кратковременную страстность любого плотского удовольствия.

(Обратите внимание, что во всех приведенных ниже примерах кодирования используются только байты, показанные здесь; это не строка с завершающим нулем.)

Когда эта цитата закодирована в Base64 он представлен как последовательность байтов из 8-битных дополненных символов ASCII, закодированных в схеме Base64 MIME следующим образом (новые строки и пробелы могут присутствовать где угодно, но игнорируются при декодировании):

TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlz IHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2Yg dGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGlu dWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRo ZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4 =

в приведенных выше цитатах, закодированное значение Человеческого TWFu. Закодированные в ASCII символы M, a и n сохраняются как байтовые значения 77, 97и 110, которые представляют собой 8-битные двоичные значения 01001101, 01100001и 01101110. Эти три значения объединяются в 24-битную строку, в результате чего получается 010011010110000101101110. Группы из 6 бит (6 битов имеют максимум 2 = 64 различных двоичных значения) преобразуются в отдельные числа слева направо (в данном случае четыре числа в 24-битной строке), которые затем преобразуются в соответствующие им значения символов Base64.

Как показано в этом примере, кодировка Base64 преобразует три октета в четыре закодированных символа.

ИсточникТекст (ASCII)Man
Октеты77 (0x4d)97 (0x61)110 (0x6e)
Биты010011010110000101101110
Base64. закодированыСекстеты1922546
СимволTWFu
Октеты84 (0x54)87 (0x57)70 (0x46)117 (0x75)

=могут быть добавлены символы заполнения, чтобы последний закодированный блок содержал четыре Base64 символы.

Шестнадцатеричное преобразование в восьмеричное полезно для преобразования между двоичным и Base64. Такая конвертация доступна как для продвинутых калькуляторов, так и для языков программирования. Например, 24 бита выше - это 4D616E (шестнадцатеричный) и преобразованы в восьмеричное 23260556, которое разделено на четыре группы 23 26 05 56, что в десятичном виде составляет 19 22 05 46, которое преобразуется таблицей в Base64, в данном случае TWFu.

Если имеется только два значимых входных октета (например, «Ma») или когда последняя группа входных данных содержит только два октета, все 16 битов будут захвачены в первых трех цифрах Base64 (18 бит); два младших бита последнего 6-битового блока, несущего контент, окажутся равными нулю и будут отброшены при декодировании (вместе со следующими символами заполнения =):

ИсточникТекст (ASCII)Ma
Октеты77 (0x4d)97 (0x61)
Биты010011010110000100
Base64. в кодировкеСекстеты19224Заполнение
СимволTWE=
Октеты84 (0x54)87 (0x57)69 (0x45)61 (0x3D)

Если имеется только один значимый входной октет (например, 'M'), или когда последняя группа входных данных содержит только один октет, все 8 бит будут захвачены в первых двух цифрах Base64 (12 бит); четыре младших бита последнего 6-битового блока, несущего контент, окажутся равными нулю и будут отброшены при декодировании (вместе со следующими символами заполнения =):

ИсточникТекст (ASCII)M
Октеты77 (0x4d)
Биты010011010000
в кодировке Base64.Секстеты1916ЗаполнениеЗаполнение
СимволTQ==
Октеты84 (0x54)81 (0x51)61 (0x3D)61 (0x3D)

Заполнение вывода

Поскольку Base64 является шестибитной кодировкой и потому что декодированные значения делятся на 8 -битовые октеты на современном компьютере, каждые четыре символа текста в кодировке Base64 (4 секстета = 4 * 6 = 24 бита) представляют три октета незашифрованного текста или данных (3 октета = 3 * 8 = 24 бита). Это означает, что, когда длина некодированного ввода не кратна трем, к закодированному выводу необходимо добавить заполнение, чтобы его длина была кратна четырем. Дополняющий символ - =, что указывает на то, что для полного кодирования ввода не требуется дополнительных битов. (Это отличается от A, что означает, что все оставшиеся биты - нули.) В приведенном ниже примере показано, как усечение ввода приведенной выше цитаты изменяет отступы вывода:

ВходВыводОтступ
ДлинаТекстДлинаТекст
20любое плотское удовольствие.28YW55IGNhcm5hbCBwbGVhc3VyZS4 =1
19любое плотское удовольствие28YW55IGNhcm5hbCBwbGVhc3VyZQ ==2
18любой плотский pleasur24YW55IGNhcm5hbCBwbGVhc3Vy0
17любой плотский pleasu24YW55IGNhcm5hbCBwbGVhc3U =1
16любой плотский мольбы24YW55IGNhcm5hbCBwbGVhcw ==2

Знак заполнения не важен для декодирования, поскольку количество пропущенных байтов может быть выведено из длины закодированного текста. В некоторых реализациях символ заполнения является обязательным, в то время как в других он не используется. Исключением, когда требуются символы заполнения, является объединение нескольких файлов в кодировке Base64.

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

ВведитеВыведите
удовольствие.cGxlYXN1cmUu
отдых.bGVhc3VyZS4 =
easure.ZWFzdXJlLg ==
asure.YXN1cmUu
конечно.c3VyZS4 =

Поскольку восемь битов октета распределены по нескольким секстетам в пределах вывода, это очевидное последствие, поскольку ни один октет не может быть помещен в один секстет; вместо этого они должны делиться.

Однако, поскольку секстеты или символы вывода должны быть сохранены и обработаны в той же компьютерной системе, которая понимает только октеты, они должны быть представлены как октеты, с двумя старшими битами, установленными в ноль. (Другими словами, закодированный вывод YW55занимает 4 * 8 = 32 бита, хотя только 24 бита значимо выводятся из ввода, любые.) Действительно, эти якобы потраченные впустую биты в точности соответствуют причина кодировки Base64. Отношение выходных байтов к входным байтам составляет 4: 3 (33% накладных расходов). В частности, при вводе n байтов на выходе будет 4 ⌈ 1 3 n ⌉ {\ textstyle 4 \ left \ lceil {\ frac {1} {3}} n \ right \ rceil}{\ textstyle 4 \ left \ lceil {\ frac {1} {3}} n \ right \ rceil} байтов, включая символы заполнения.

Декодирование Base64 с заполнением

При декодировании текста Base64 четыре символа обычно преобразуются обратно в три байта. Единственное исключение - когда существуют символы заполнения. Одиночный =указывает, что четыре символа будут декодироваться только до двух байтов, а ==указывает, что четыре символа будут декодироваться только до одного байта. Например:

ЗакодированоПэддингДлинаДекодировано
YW55IGNhcm5hbCBwbGVhcw ====1любые плотские мольбы
YW55IGNhcm5hbCBwbGVh Pleasu
YW55IGNhcm5hbCBwbGVhc3VyNone3любое плотское удовольствие

Декодирование Base64 без заполнения

Без заполнения, после обычного декодирования четырех символов в три байта снова и снова, меньше чем могут остаться четыре закодированных символа. В этой ситуации останутся только два или три символа. Единственный оставшийся закодированный символ невозможен (потому что один символ Base64 содержит только 6 бит, а для создания байта требуется 8 бит, поэтому требуется минимум 2 символа Base64: первый символ вносит 6 бит, а второй символ вносит свои первые 2 бита.) Например:

LengthEncodedLengthDecoded
2YW55IGNhcm5hbCBwbGVhcw1любые плотские мольбы
3YW55IGNhbcm5hbC 367>любое плотское удовольствие
4YW55IGNhcm5hbCBwbGVhc3Vy3любое плотское удовольствие

Реализации и история

Сводная таблица вариантов

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

КодированиеКодирование символовРаздельное кодирование строкДекодирование некодирующих символов
62-й63-йpadРазделителиДлинаКонтрольная сумма
RFC 1421: Base64 для Privacy-Enhanced Mail (устарело)+/=обязательноCR+LF64 или ниже для последней строкиNoНет
RFC 2045: кодировка передачи Base64 для MIME+/=обязательнаяCR + LFНе более 76NoОтброшено
RFC 2152: Base64 для UTF-7+/НетNoНет
RFC 3501 : Кодировка Base64 для IMAP имена почтовых ящиков+,НетNoНет
RFC 4648 §4 : base64 (стандартный)+/=необязательноNoНет
RFC 4648 §5 : base64url (URL- и безопасный для файлов стандартный)-_=необязательноNoНет
RFC 4880: Radix-64 для OpenPGP+/=обязательноCR+LFНе более 7624-битная кодировка Radix-64 CRC Нет

Почта с улучшенной конфиденциальностью

первое известное стандартизованное использование кодировки, которая теперь называется MI ME Base64 использовался в протоколе электронной почты с улучшенной конфиденциальностью (PEM), предложенном RFC 989 в 1987 году. PEM определяет схему «печатного кодирования», которая использует кодировку Base64 для преобразования произвольного последовательность октетов в формате, который может быть выражен короткими строками из 6-битных символов, как того требуют протоколы передачи, такие как SMTP.

Текущая версия PEM (указанная в RFC 1421 ) использует 64-символьный алфавит, состоящий из прописных и строчных латинских букв (AZ, az), цифр (09) и +и <136.>/символы. Символ =также используется в качестве суффикса заполнения. Исходная спецификация, RFC 989, дополнительно использовала символ *для ограничения закодированных, но незашифрованных данных в выходном потоке.

Для преобразования данных в печатаемую кодировку PEM первый байт помещается в старшие восемь битов 24-битного буфера, следующий в средних восьми и третий в наименее значимых восьми битах. Если для кодирования осталось менее трех байтов (или всего), оставшиеся биты буфера будут нулевыми. Затем используется буфер по шесть битов, сначала наиболее значимый, в качестве индексов в строке: «ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 + /», и выводится указанный символ.

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

После кодирования незаполненных данных, если два октета 24-битного буфера заполнены нулями, к выходным данным добавляются два символа =; если один октет 24-битного буфера заполнен заполненными нулями, добавляется один символ =. Это сигнализирует декодеру, что нулевые биты, добавленные из-за заполнения, должны быть исключены из восстановленных данных. Это также гарантирует, что длина закодированного вывода кратна 4 байтам.

PEM требует, чтобы все закодированные строки состояли ровно из 64 печатных символов, за исключением последней строки, которая может содержать меньше печатаемых символов. Строки разделяются пробелами в соответствии с местными (зависящими от платформы) соглашениями.

MIME

В спецификации MIME (многоцелевые расширения почты Интернета) Base64 указан как одна из двух схем кодирования двоичного текста (другая быть цитируемым-печатным ). Кодировка MIME Base64 основана на кодировке RFC 1421 версии PEM: она использует тот же 64-символьный алфавит и механизм кодирования, что и PEM, и использует символ =для заполнения вывода в таким же образом, как описано в RFC 2045.

MIME не определяет фиксированную длину для строк в кодировке Base64, но определяет максимальную длину строки 76 символов. Кроме того, он указывает, что любые экстра-алфавитные символы должны игнорироваться совместимым декодером, хотя в большинстве реализаций для разграничения закодированных строк используется пара CR / LF новая строка.

Таким образом, фактическая длина MIME-совместимых двоичных данных в кодировке Base64 обычно составляет около 137% от исходной длины данных, хотя для очень коротких сообщений накладные расходы могут быть намного выше из-за накладных расходов на заголовки. Грубо говоря, окончательный размер двоичных данных в кодировке Base64 в 1,37 раза больше исходного размера данных + 814 байтов (для заголовков). Размер декодированных данных можно приблизительно определить по следующей формуле:

байтов = (длина_строки (кодированная_строка) - 814) / 1,37

UTF-7

UTF-7, описанный сначала в RFC 1642, который позже был заменен RFC 2152, представил систему под названием модифицированный Base64. Эта схема кодирования данных используется для кодирования UTF-16 как символов ASCII для использования в 7-битных транспортных средствах, таких как SMTP. Это вариант кодировки Base64, используемой в MIME.

Алфавит «Modified Base64» состоит из алфавита MIME Base64, но не использует символ заполнения «=». UTF-7 предназначен для использования в заголовках сообщений (определенных в RFC 2047 ), а символ «=» зарезервирован в этом контексте как escape-символ для «quoted-printable» кодирование. Модифицированный Base64 просто опускает заполнение и заканчивается сразу после последней цифры Base64, содержащей полезные биты, оставляя до трех неиспользуемых битов в последней цифре Base64.

OpenPGP

OpenPGP, описанный в RFC 4880, описывает кодировку Radix-64, также известную как «броня ASCII ". Radix-64 идентичен кодировке "Base64", описанной в MIME, с добавлением необязательного 24-битного CRC. Контрольная сумма вычисляется для входных данных перед кодированием; контрольная сумма затем кодируется тем же алгоритмом Base64 и с префиксом «=» в качестве разделителя добавляется к закодированным выходным данным.

RFC 3548

RFC 3548, озаглавленный Кодировки данных Base16, Base32 и Base64 - это информационная (ненормативная) памятка, в которой делается попытка унифицировать спецификации RFC 1421 и RFC 2045 кодировок Base64, кодировок с альтернативным алфавитом, и кодировки Base32 (которая используется редко) и Base16.

Если реализации не написаны в спецификации, которая ссылается на RFC 3548 и специально не требует иного, RFC 3548 запрещает реализациям генерировать сообщения, содержащие символы вне алфавита кодирования или без padding, а также объявляет, что реализации декодера должны отклонять данные, содержащие символы вне алфавита кодирования.

RFC 4648

Этот RFC отменяет RFC 3548 и фокусируется на Base64 / 32/16:

Этот документ описывает обычно используемые схемы кодирования Base64, Base32 и Base16. В нем также обсуждается использование перевода строки в кодированных данных, использование заполнения в кодированных данных, использование неалфавитных символов в кодированных данных, использование различных алфавитов кодирования и канонические кодировки.

Имена файлов

Другой вариант под названием модифицированный Base64 для имени файла использует '-' вместо '/', потому что имена файлов Unix и Windows не могут содержать '/'.

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

Приложения URL

Кодировка Base64 может быть полезной, когда в среде HTTP используется довольно длинная идентифицирующая информация. Например, структура сохраняемости базы данных для объектов Java может использовать кодировку Base64 для кодирования относительно большого уникального идентификатора (обычно 128-битного UUID ) в строку для использования в качестве параметра HTTP в Формы HTTP или HTTP GET URL. Кроме того, многим приложениям необходимо кодировать двоичные данные таким образом, чтобы их было удобно включать в URL-адреса, в том числе в скрытые поля веб-форм, а Base64 - это удобная кодировка для их компактной визуализации.

Использование стандартного Base64 в URL требует кодирования символов '+', '/' и '=' в специальные закодированные в процентах шестнадцатеричные последовательности (+'становится' % 2B',' /'становится' % 2F'и' ='становится' % 3D'), что делает строку излишне длиннее.

По этой причине существует модифицированный Base64 для вариантов URL (например, base64url в RFC 4648 ), где '+'и' /'символы стандартного Base64 заменяются соответственно на' -'и' _', чтобы использовать кодировщики URL / decoders больше не требуется и не влияет на длину закодированного значения, оставляя ту же закодированную форму нетронутой для использования в реляционных базах данных, веб-формах и идентификаторах объектов в целом. Некоторые варианты позволяют или требуют опускать знаки заполнения '=', чтобы их не путали с разделителями полей, или требуют, чтобы любое такое заполнение было закодировано в процентах. Некоторые библиотеки будут кодировать от '=' до '.', потенциально подвергая приложения атакам относительного пути, когда имя папки кодируется из пользовательских данных.

HTML

Методы JavaScript atob ()и btoa (), определенные в черновике спецификации HTML5, предоставляют функциональные возможности кодирования и декодирования Base64 для интернет страницы. Метод btoa ()выводит символы заполнения, но они не являются обязательными при вводе метода atob ().

Другие приложения

Пример SVG, содержащего встроенные изображения JPEG, закодированные в Base64

Base64 может использоваться в различных контекстах:

  • Base64 может использоваться для передачи и хранения текста, который в противном случае мог бы вызвать конфликт разделителей
  • Спамеры используют Base64 для обхода основных средств защиты от спама, которые часто не декодируют Base64 и, следовательно, не могут обнаруживать ключевые слова в закодированных сообщениях.
  • Base64 используется для кодирования символьных строк в файлах LDIF
  • Base64 часто используется для встраивания двоичных данных в файл XML с использованием синтаксиса, аналогичного , например значки в экспортируемом Firefox bookmarks.html.
  • Base64 используется для кодирования двоичных файлов, таких как изображения, в сценариях, чтобы избежать зависимости от внешних файлов.
  • Схема URI данных может использовать Base64 для представления содержимого файла. Например, фоновые изображения и шрифты могут быть указаны в файле таблицы стилей CSS как data:URI вместо того, чтобы поставляться в отдельных файлах.
  • Реализация FreeSWAN IPSec предшествует строкам Base64 с помощью 0s, поэтому их можно отличить от текстовых или шестнадцатеричных строк.
  • Хотя это не является частью официальной спецификации для SVG, некоторые зрители могут интерпретировать Base64 при использовании для встроенных элементов, таких как изображения внутри SVG.

Приложения Radix-64, несовместимые с Base64

  • Uuencoding, традиционно используемый в UNIX, использует ASCII 32 ("От"(пробел)) до 95 (" _"), последовательно, делая его набор из 64 символов" ! "# $% '() * +, -. / 0123456789 :; <=>? @ABCDEFGHIJKLMNOPQRSTUVWXYZ [\] ^ _". Избегание всех строчных букв было полезным, потому что многие старые принтеры печатали только прописные. Использование последовательных символов ASCII сэкономило вычислительную мощность, поскольку нужно было только добавить 32, не выполняйте поиск. Он использует большинство слов Символы обозначения и пробел ограничивают его полезность.
  • BinHex 4 (HQX), который использовался в классической Mac OS, использует другой набор из 64 символов. Он использует прописные и строчные буквы, цифры и знаки препинания, но не использует некоторые визуально запутанные символы, такие как '7', 'O', 'g'и' o'. Его набор из 64 символов: "!" # $% '() * +, - 012345689 @ ABCDEFGHIJKLMNPQRSTUVXYZ [ʻabcdefhijklmpqr".
  • Некоторые другие приложения используют наборы radix-64, более похожие на, но в другом порядке по сравнению с Формат Base64, начиная с двух символов, затем с цифр, затем в верхнем регистре, затем в нижнем регистре:
    • Unix хранит хэши паролей, вычисленные с помощью crypt в / etc / passwdфайл в кодировке radix-64 под названием B64. Он использует преимущественно буквенно-цифровой набор символов, а также .и /. Его набор из 64 символов: «./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz». Заполнение не используется.
    • Стандарт GEDCOM 5.5 для обмена генеалогическими данными кодирует мультимедийные файлы в текстовом иерархическом формате файлов с использованием radix-64. Его 64-символьный набор также имеет вид "./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz".
    • bcrypt хеши предназначены для использования так же, как и традиционные хеши crypt (3), и алгоритм использует тот же алфавит, что и он. 64-символьный набор: "./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789".
    • Xxencoding использует в основном буквенно-цифровой набор символов, аналогичный crypt и GEDCOM, но с использованием и и + + чем .и /. Его 64-символьный набор: "+ -0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz".
    • 6PACK, используемый с некоторыми контроллерами терминальных узлов, использует другой набор из 64 символов от до 0x3f. Bash. поддерживает числовые литералы с основанием 2-64, растягиваясь до набора символов 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ @ _.

См. также

Ссылки

Последняя правка сделана 2021-05-11 13:43:43
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте