В программировании 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% больше из-за вставленных разрывов строки).
Конкретный набор из 64 символов, выбранных для представления 64 цифровых значений для базы, варьируется в зависимости от реализации. Общая стратегия состоит в том, чтобы выбрать 64 символа, которые являются общими для большинства кодировок и которые также печатаются. Эта комбинация оставляет маловероятным изменение данных при передаче через информационные системы, такие как электронная почта, которые традиционно не были 8-битными чистыми. Например, реализация MIME Base64 использует A
–Z
, a
–z
и 0
–9
для первых 62 значений. Другие варианты разделяют это свойство, но отличаются символами, выбранными для последних двух значений; пример: UTF-7.
Самые ранние экземпляры этого типа кодирования были созданы для коммутируемого соединения между системами, работающими под одной и той же ОС - например, uuencode для UNIX, BinHex для TRS-80 (позже адаптированный для Macintosh ) - и поэтому мог сделать больше предположений о том, какие символы были безопасными использовать. Например, uuencode использует прописные буквы, цифры и многие символы пунктуации, но не строчные.
Таблица индексов Base64:
Index | Binary | Char | Index | Binary | Char | Index | Binary | Char | Index | Двоичный | Char | |||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0 | 000000 | A | 16 | 010000 | Q | 32 | 100000 | g | 48 | 110000 | w | |||
1 | 000001 | B | 17 | 010001 | R | 33 | 100001 | h | 49 | 110001 | x | |||
2 | 000010 | C | 18 | 010010 | S | 34 | 100010 | i | 50 | 110010 | y | |||
3 | 000011 | D | 19 | 010011 | T | 35 | 100011 | j | 51 | 110011 | z | |||
4 | 000100 | E | 20 | 010100 | U | 36 | 100100 | k | 52 | 110100 | 0 | |||
5 | 000101 | F | 21 | 010101 | V | 37 | 100101 | l | 53 | 110101 | 1 | |||
6 | 000110 | G | 22 | 010110 | W | 38 | 100110 | m | 54 | 110110 | 2 | |||
7 | 000111 | H | 23 | 010111 | X | 39 | 100111 | n | 55 | 110111 | 3 | |||
8 | 001000 | I | 24 | 011000 | Y | 40 | 101000 | o | 56 | 111000 | 4 | |||
9 | 001001 | J | 25 | 011001 | Z | 41 | 101001 | p | 57 | 111001 | 5 | |||
10 | 001010 | K | 26 | 011010 | a | 42 | 101010 | q | 58 | 111010 | 6 | |||
11 | 001011 | L | 27 | 011011 | b | 43 | 101011 | r | 59 | 111011 | 7 | |||
12 | 001100 | M | 28 | 011100 | c | 44 | 101100 | s | 60 | 111100 | 8 | |||
13 | 001101 | N | 29 | 011101 | d | 45 | 101101 | t | 61 | 111101 | 9 | |||
14 | 001110 | O | 30 | 011110 | e | 46 | 101110 | u | 62 | 111110 | + | |||
15 | 001111 | P | 31 | 011111 | f | 47 | 101111 | v | 63 | 111111 | / | |||
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) | M | a | n | |||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Октеты | 77 (0x4d) | 97 (0x61) | 110 (0x6e) | ||||||||||||||||||||||
Биты | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | |
Base64. закодированы | Секстеты | 19 | 22 | 5 | 46 | ||||||||||||||||||||
Символ | T | W | F | u | |||||||||||||||||||||
Октеты | 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) | M | a | ||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Октеты | 77 (0x4d) | 97 (0x61) | |||||||||||||||||||||||
Биты | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | |||||||
Base64. в кодировке | Секстеты | 19 | 22 | 4 | Заполнение | ||||||||||||||||||||
Символ | T | W | E | = | |||||||||||||||||||||
Октеты | 84 (0x54) | 87 (0x57) | 69 (0x45) | 61 (0x3D) |
Если имеется только один значимый входной октет (например, 'M'), или когда последняя группа входных данных содержит только один октет, все 8 бит будут захвачены в первых двух цифрах Base64 (12 бит); четыре младших бита последнего 6-битового блока, несущего контент, окажутся равными нулю и будут отброшены при декодировании (вместе со следующими символами заполнения =
):
Источник | Текст (ASCII) | M | |||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Октеты | 77 (0x4d) | ||||||||||||||||||||||||
Биты | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | |||||||||||||
в кодировке Base64. | Секстеты | 19 | 16 | Заполнение | Заполнение | ||||||||||||||||||||
Символ | T | Q | = | = | |||||||||||||||||||||
Октеты | 84 (0x54) | 81 (0x51) | 61 (0x3D) | 61 (0x3D) |
Поскольку Base64 является шестибитной кодировкой и потому что декодированные значения делятся на 8 -битовые октеты на современном компьютере, каждые четыре символа текста в кодировке Base64 (4 секстета = 4 * 6 = 24 бита) представляют три октета незашифрованного текста или данных (3 октета = 3 * 8 = 24 бита). Это означает, что, когда длина некодированного ввода не кратна трем, к закодированному выводу необходимо добавить заполнение, чтобы его длина была кратна четырем. Дополняющий символ - =
, что указывает на то, что для полного кодирования ввода не требуется дополнительных битов. (Это отличается от A
, что означает, что все оставшиеся биты - нули.) В приведенном ниже примере показано, как усечение ввода приведенной выше цитаты изменяет отступы вывода:
Вход | Вывод | Отступ | ||
---|---|---|---|---|
Длина | Текст | Длина | Текст | |
20 | любое плотское удовольствие. | 28 | YW55IGNhcm5hbCBwbGVhc3VyZS4 = | 1 |
19 | любое плотское удовольствие | 28 | YW55IGNhcm5hbCBwbGVhc3VyZQ == | 2 |
18 | любой плотский pleasur | 24 | YW55IGNhcm5hbCBwbGVhc3Vy | 0 |
17 | любой плотский pleasu | 24 | YW55IGNhcm5hbCBwbGVhc3U = | 1 |
16 | любой плотский мольбы | 24 | YW55IGNhcm5hbCBwbGVhcw == | 2 |
Знак заполнения не важен для декодирования, поскольку количество пропущенных байтов может быть выведено из длины закодированного текста. В некоторых реализациях символ заполнения является обязательным, в то время как в других он не используется. Исключением, когда требуются символы заполнения, является объединение нескольких файлов в кодировке Base64.
Другим следствием секстетного кодирования октетов является то, что один и тот же октет будет кодироваться по-разному в зависимости от его положения в трехоктетной группе ввода и в зависимости от того, какой конкретный октет предшествует ему в группе. Например:
Введите | Выведите |
---|---|
удовольствие. | cGxlYXN1cmUu |
отдых. | bGVhc3VyZS4 = |
easure. | ZWFzdXJlLg == |
asure. | YXN1cmUu |
конечно. | c3VyZS4 = |
Поскольку восемь битов октета распределены по нескольким секстетам в пределах вывода, это очевидное последствие, поскольку ни один октет не может быть помещен в один секстет; вместо этого они должны делиться.
Однако, поскольку секстеты или символы вывода должны быть сохранены и обработаны в той же компьютерной системе, которая понимает только октеты, они должны быть представлены как октеты, с двумя старшими битами, установленными в ноль. (Другими словами, закодированный вывод YW55
занимает 4 * 8 = 32 бита, хотя только 24 бита значимо выводятся из ввода, любые.) Действительно, эти якобы потраченные впустую биты в точности соответствуют причина кодировки Base64. Отношение выходных байтов к входным байтам составляет 4: 3 (33% накладных расходов). В частности, при вводе n байтов на выходе будет байтов, включая символы заполнения.
При декодировании текста Base64 четыре символа обычно преобразуются обратно в три байта. Единственное исключение - когда существуют символы заполнения. Одиночный =
указывает, что четыре символа будут декодироваться только до двух байтов, а ==
указывает, что четыре символа будут декодироваться только до одного байта. Например:
Закодировано | Пэддинг | Длина | Декодировано |
---|---|---|---|
YW55IGNhcm5hbCBwbGVhcw == | == | 1 | любые плотские мольбы |
YW55IGNhcm5hbCBwbGVh Pleasu | |||
YW55IGNhcm5hbCBwbGVhc3Vy | None | 3 | любое плотское удовольствие |
Без заполнения, после обычного декодирования четырех символов в три байта снова и снова, меньше чем могут остаться четыре закодированных символа. В этой ситуации останутся только два или три символа. Единственный оставшийся закодированный символ невозможен (потому что один символ Base64 содержит только 6 бит, а для создания байта требуется 8 бит, поэтому требуется минимум 2 символа Base64: первый символ вносит 6 бит, а второй символ вносит свои первые 2 бита.) Например:
Length | Encoded | Length | Decoded |
---|---|---|---|
2 | YW55IGNhcm5hbCBwbGVhcw | 1 | любые плотские мольбы |
3 | YW55IGNhbcm5hbC 367>любое плотское удовольствие | ||
4 | YW55IGNhcm5hbCBwbGVhc3Vy | 3 | любое плотское удовольствие |
Реализации могут иметь некоторые ограничения на алфавит, используемый для представления некоторых битовых шаблонов. Это особенно касается последних двух символов, используемых в индексной таблице для индексов 62 и 63, и символа, используемого для заполнения (который может быть обязательным в некоторых протоколах или удален в других). В таблице ниже перечислены эти известные варианты и даны ссылки на нижеприведенные подразделы.
Кодирование | Кодирование символов | Раздельное кодирование строк | Декодирование некодирующих символов | ||||
---|---|---|---|---|---|---|---|
62-й | 63-й | pad | Разделители | Длина | Контрольная сумма | ||
RFC 1421: Base64 для Privacy-Enhanced Mail (устарело) | + | / | = обязательно | CR+LF | 64 или ниже для последней строки | No | Нет |
RFC 2045: кодировка передачи Base64 для MIME | + | / | = обязательная | CR + LF | Не более 76 | No | Отброшено |
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 | Не более 76 | 24-битная кодировка Radix-64 CRC | Нет |
первое известное стандартизованное использование кодировки, которая теперь называется MI ME Base64 использовался в протоколе электронной почты с улучшенной конфиденциальностью (PEM), предложенном RFC 989 в 1987 году. PEM определяет схему «печатного кодирования», которая использует кодировку Base64 для преобразования произвольного последовательность октетов в формате, который может быть выражен короткими строками из 6-битных символов, как того требуют протоколы передачи, такие как SMTP.
Текущая версия PEM (указанная в RFC 1421 ) использует 64-символьный алфавит, состоящий из прописных и строчных латинских букв (A
–Z
, a
–z
), цифр (0
–9
) и +
и <136.>/символы. Символ =
также используется в качестве суффикса заполнения. Исходная спецификация, RFC 989, дополнительно использовала символ *
для ограничения закодированных, но незашифрованных данных в выходном потоке.
Для преобразования данных в печатаемую кодировку PEM первый байт помещается в старшие восемь битов 24-битного буфера, следующий в средних восьми и третий в наименее значимых восьми битах. Если для кодирования осталось менее трех байтов (или всего), оставшиеся биты буфера будут нулевыми. Затем используется буфер по шесть битов, сначала наиболее значимый, в качестве индексов в строке: «ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 + /
», и выводится указанный символ.
Процесс повторяется для оставшихся данных, пока не останется менее четырех октетов. Если осталось три октета, они обрабатываются нормально. Если для кодирования остается менее трех октетов (24 бита), входные данные дополняются справа нулевыми битами для формирования целого числа, кратного шести битам.
После кодирования незаполненных данных, если два октета 24-битного буфера заполнены нулями, к выходным данным добавляются два символа =
; если один октет 24-битного буфера заполнен заполненными нулями, добавляется один символ =
. Это сигнализирует декодеру, что нулевые биты, добавленные из-за заполнения, должны быть исключены из восстановленных данных. Это также гарантирует, что длина закодированного вывода кратна 4 байтам.
PEM требует, чтобы все закодированные строки состояли ровно из 64 печатных символов, за исключением последней строки, которая может содержать меньше печатаемых символов. Строки разделяются пробелами в соответствии с местными (зависящими от платформы) соглашениями.
В спецификации 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, описанный сначала в 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, описанный в RFC 4880, описывает кодировку Radix-64, также известную как «броня ASCII ". Radix-64 идентичен кодировке "Base64", описанной в MIME, с добавлением необязательного 24-битного CRC. Контрольная сумма вычисляется для входных данных перед кодированием; контрольная сумма затем кодируется тем же алгоритмом Base64 и с префиксом «=
» в качестве разделителя добавляется к закодированным выходным данным.
RFC 3548, озаглавленный Кодировки данных Base16, Base32 и Base64 - это информационная (ненормативная) памятка, в которой делается попытка унифицировать спецификации RFC 1421 и RFC 2045 кодировок Base64, кодировок с альтернативным алфавитом, и кодировки Base32 (которая используется редко) и Base16.
Если реализации не написаны в спецификации, которая ссылается на RFC 3548 и специально не требует иного, RFC 3548 запрещает реализациям генерировать сообщения, содержащие символы вне алфавита кодирования или без padding, а также объявляет, что реализации декодера должны отклонять данные, содержащие символы вне алфавита кодирования.
Этот RFC отменяет RFC 3548 и фокусируется на Base64 / 32/16:
Другой вариант под названием модифицированный Base64 для имени файла использует '-
' вместо '/
', потому что имена файлов Unix и Windows не могут содержать '/
'.
Вместо этого можно было бы порекомендовать использовать измененный Base64 для 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 больше не требуется и не влияет на длину закодированного значения, оставляя ту же закодированную форму нетронутой для использования в реляционных базах данных, веб-формах и идентификаторах объектов в целом. Некоторые варианты позволяют или требуют опускать знаки заполнения '=
', чтобы их не путали с разделителями полей, или требуют, чтобы любое такое заполнение было закодировано в процентах. Некоторые библиотеки будут кодировать от '=
' до '.
', потенциально подвергая приложения атакам относительного пути, когда имя папки кодируется из пользовательских данных.
Методы JavaScript atob ()и btoa (), определенные в черновике спецификации HTML5, предоставляют функциональные возможности кодирования и декодирования Base64 для интернет страницы. Метод btoa ()выводит символы заполнения, но они не являются обязательными при вводе метода atob ().
Base64 может использоваться в различных контекстах:
…
, например значки в экспортируемом Firefox bookmarks.html.data:
URI вместо того, чтобы поставляться в отдельных файлах.От
"(пробел)) до 95 (" _
"), последовательно, делая его набор из 64 символов" ! "# $% '() * +, -. / 0123456789 :; <=>? @ABCDEFGHIJKLMNOPQRSTUVWXYZ [\] ^ _
". Избегание всех строчных букв было полезным, потому что многие старые принтеры печатали только прописные. Использование последовательных символов ASCII сэкономило вычислительную мощность, поскольку нужно было только добавить 32, не выполняйте поиск. Он использует большинство слов Символы обозначения и пробел ограничивают его полезность.7
', 'O
', 'g
'и' o
'. Его набор из 64 символов: "!" # $% '() * +, - 012345689 @ ABCDEFGHIJKLMNPQRSTUVXYZ [ʻabcdefhijklmpqr
"..
и /
. Его набор из 64 символов: «./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
». Заполнение не используется../0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
"../ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789
".и и + + чем .
и /
. Его 64-символьный набор: "+ -0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
".
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ @ _
.