База64

В компьютерном программировании Base64 — это группа схем кодирования двоичного текста в текст , которые преобразуют двоичные данные в последовательность печатных символов, ограниченную набором из 64 уникальных символов. Точнее, исходные двоичные данные берутся по 6 бит за раз, затем эта группа из 6 бит сопоставляется с одним из 64 уникальных символов.

Как и все схемы кодирования двоичного текста, Base64 предназначен для передачи данных, хранящихся в двоичных форматах, по каналам, которые надежно поддерживают только текстовый контент. Base64 особенно распространен во Всемирной паутине. ^{[ 1 ]} где одним из его применений является возможность встраивать файлы изображений или другие двоичные ресурсы в текстовые ресурсы, такие как файлы HTML и CSS . ^{[ 2 ]}

Base64 также широко используется для отправки вложений электронной почты , поскольку SMTP в своей первоначальной форме был разработан для передачи только 7-битных символов ASCII . Кодирование вложения в формате Base64 перед отправкой, а затем декодирование при получении гарантирует, что старые SMTP-серверы не будут мешать вложению.

Кодирование Base64 вызывает накладные расходы в размере 33–37 % по отношению к размеру исходных двоичных данных (33 % за счет самого кодирования; до 4 % больше из-за вставленных разрывов строк).

Дизайн

Конкретный набор из 64 символов, выбранный для представления 64-значных значений базы, варьируется в зависимости от реализации. Общая стратегия состоит в том, чтобы выбрать 64 символа, которые являются общими для большинства кодировок и которые также можно распечатать. Эта комбинация исключает возможность изменения данных при передаче через информационные системы, такие как электронная почта, которые традиционно не были 8-битными . ^{[ 3 ]} Например, реализация MIME Base64 использует A– Z, a– z, и 0– 9 для первых 62 значений. Другие варианты разделяют это свойство, но отличаются символами, выбранными для последних двух значений; пример — UTF-7 .

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

Таблица Base64 из RFC 4648

Это алфавит Base64, определенный в RFC 4648 §4 . См. также § Сводную таблицу вариантов .

Алфавит Base64, определенный в RFC 4648.
Индекс	Двоичный	Чар.	Индекс	Двоичный	Чар.	Индекс	Двоичный	Чар.	Индекс	Двоичный	Чар.
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	`/`
									Заполнение		=

Примеры

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

Вот известная идиома из распределенных вычислений :

Множество рук делают легкую работу.

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

TWFueSBoYW5kcyBtYWtlIGxpZ2h0IHdvcmsu

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

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

Кодировка исходной строки ⟨Man⟩ в Base64
Источник ASCII-текст	Характер	М								а								н
Источник ASCII-текст	Октеты	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
База64 закодированный	Секстеты	19						22						5						46
	Характер	Т						В						Ф						в
	Октеты	84 (0x54)						87 (0x57)						70 (0x46)						117 (0x75)

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

Преобразование шестнадцатеричного числа в восьмеричное полезно для преобразования между двоичным кодом и Base64. Такое преобразование доступно как для продвинутых калькуляторов, так и для языков программирования. Например, шестнадцатеричное представление 24 приведенных выше битов — 4D616E. Восьмеричное представление — 23260556. Эти 8 восьмеричных цифр можно разделить на пары ( 23 26 05 56 ), и каждая пара преобразуется в десятичное число, чтобы получить 19 22 05 46 . Если использовать эти четыре десятичных числа в качестве индексов алфавита Base64, соответствующие символы ASCII будут TWFu .

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

Источник ASCII-текст	Характер	М								а
Источник ASCII-текст	Октеты	77 (0x4d)								97 (0x61)
Биты		0	1	0	0	1	1	0	1	0	1	1	0	0	0	0	1	0	0
База64 закодированный	Секстеты	19						22						4						Заполнение
	Характер	Т						В						И						=
	Октеты	84 (0x54)						87 (0x57)						69 (0x45)						61 (0x3D)

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

Источник ASCII-текст	Характер	М
Источник ASCII-текст	Октеты	77 (0x4d)
Биты		0	1	0	0	1	1	0	1	0	0	0	0
База64 закодированный	Секстеты	19						16						Заполнение	Заполнение
	Характер	Т						вопрос						=	=
	Октеты	84 (0x54)						81 (0x51)						61 (0x3D)	61 (0x3D)

Существуют также интерактивные инструменты для пошаговой визуализации кодировки от обычного текста до base64. ^{[ 7 ]}

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

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

Вход		Выход		Заполнение
Текст	Длина	Текст	Длина	Заполнение
легкая работа К.	11	bGlnaHQg d29y ay4=	16	1
легкая работа к	10	bGlnaHQg d29y aw==	16	2
легкая работа	9	bGlnaHQg d29y	12	0
свет горе	8	bGlnaHQg d28=	12	1
свет ш	7	bGlnaHQg dw==	12	2

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

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

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

Закодированный	Заполнение	Длина	Декодированный
bGlnaHQg dw==	`==`	1	свет ш
bGlnaHQg d28=	`=`	2	свет горе
bGlnaHQg d29y	Никто	3	легкая работа

Другой способ интерпретации символа заполнения — рассматривать его как инструкцию по удалению двух конечных битов из битовой строки каждый раз, когда = встречается. Например, когда ` bGlnaHQg dw== ` декодируется, мы преобразуем каждый символ (кроме конечных вхождений =) в соответствующее 6-битное представление, а затем отбросить 2 завершающих бита для первого = и еще 2 завершающих бита для другого =. В этом случае мы получим 6 бит из d, и еще 6 бит из w для битовой строки длиной 12, но поскольку мы удаляем по 2 бита для каждого = (всего 4 бита), dw== в конечном итоге при декодировании получается 8 бит (1 байт).

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

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

Длина	Закодированный	Длина	Декодированный
2	bGlnaHQg dw	1	свет ш
3	bGlnaHQg d28	2	свет горе
4	bGlnaHQg d29y	3	легкая работа

Декодирование без заполнения не выполняется согласованно среди декодеров. Кроме того, разрешение бесконтактного декодирования по определению позволяет декодировать несколько строк в один и тот же набор байтов, что может представлять угрозу безопасности. ^{[ 8 ]}

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

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

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

Кодирование	Кодирование символов			Раздельное кодирование строк			Декодирование некодирующих символов
Кодирование	62-й	63-й	подушечка	Сепараторы	Длина	Контрольная сумма	Декодирование некодирующих символов
RFC 1421 : Base64 для почты с повышенной конфиденциальностью (устарело)	`+`	`/`	`=` обязательный	CR+LF	64 или ниже для последней строки	Нет	Нет
RFC 2045 : кодировка передачи Base64 для MIME.	`+`	`/`	`=` обязательный	CR+LF	Максимум 76	Нет	Выброшено
RFC 2152 : Base64 для UTF-7.	`+`	`/`	Нет	Нет			Нет
RFC 3501 : кодировка Base64 для имен почтовых ящиков IMAP.	`+`	`,`	Нет	Нет			Нет
RFC 4648 §4 : base64 (стандарт) ^{[ а ]}	`+`	`/`	`=` необязательный	Нет			Нет
RFC 4648 §5 : base64url (стандарт, безопасный для URL-адресов и имен файлов) ^{[ а ]}	`-`	`_`	`=` необязательный	Нет			Нет
RFC 4880 : Radix-64 для OpenPGP	`+`	`/`	`=` обязательный	CR+LF	Максимум 76	в кодировке Radix-64 24-битный CRC	Нет
Другие варианты	См. § Приложения, несовместимые с RFC 4648 Base64.

^ Перейти обратно: ^а ^б Этот вариант предназначен для предоставления общих функций там, где их специализация не требуется, обеспечивая надежное проектирование. Это особенно важно в свете кодировок и ограничений отдельных строк, которые не учитывались, когда предыдущие стандарты были адаптированы для использования в других местах. Таким образом, указанные здесь функции могут быть переопределены.

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

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

Текущая версия PEM (указанная в RFC 1421 ) использует 64-символьный алфавит, состоящий из латинских букв верхнего и нижнего регистра ( A– Z, a– z), цифры ( 0– 9), и + и / символы. = Символ также используется в качестве суффикса заполнения. ^{[ 4 ]} Оригинальная спецификация, RFC 989 дополнительно использовал * символ для разделения закодированных, но незашифрованных данных в выходном потоке.

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

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

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

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

МИМ

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

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

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

bytes = (string_length(encoded_string) − 814) / 1.37

UTF-7

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

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

OpenPGP

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

RFC 3548

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

Если реализации не написаны в соответствии со спецификацией, которая ссылается на RFC 3548 и, в частности, требует иного, RFC 3548 запрещает реализациям генерировать сообщения, содержащие символы вне алфавита кодирования или без заполнения, а также заявляет, что реализации декодера должны отклонять данные, содержащие символы вне алфавита кодирования. ^{[ 6 ]}

RFC 4648

RFC 4648 устарел RFC 3548 и ориентирован на Base64/32/16:

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

URL-приложения

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

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

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

Javascript (веб-API DOM)

The atob() и btoa() Методы JavaScript, определенные в черновой версии спецификации HTML5, ^{[ 14 ]} обеспечить функциональность кодирования и декодирования Base64 для веб-страниц. btoa() метод выводит символы заполнения, но они не являются обязательными при вводе atob() метод.

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

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

Base64 можно использовать для передачи и хранения текста, который в противном случае мог бы вызвать конфликт разделителей.
Base64 используется для кодирования строк символов в формата обмена данными LDAP. файлах
Base64 часто используется для встраивания двоичных данных в XML- файл, используя синтаксис, аналогичный <data encoding="base64">…</data> например значки в Firefox экспортированных bookmarks.html.
Base64 используется для кодирования двоичных файлов, таких как изображения, в сценариях, чтобы избежать зависимости от внешних файлов.
Base64 можно использовать для встраивания PDF- файлов в HTML-страницы. ^{[ 16 ]}
Схема URI данных может использовать Base64 для представления содержимого файла. Например, фоновые изображения и шрифты можно указать в файле таблицы стилей CSS как data: URI вместо предоставления в отдельных файлах.
Хотя это не является частью официальной спецификации формата SVG , некоторые средства просмотра могут интерпретировать Base64 при использовании для встроенных элементов, таких как растровые изображения внутри файлов SVG. ^{[ 17 ]}
компьютера Base64 можно использовать для хранения/передачи относительно небольших объемов двоичных данных с помощью функции текстового буфера обмена , особенно в тех случаях, когда информация не требует постоянного сохранения или когда информацию необходимо быстро пересылать между широким спектром различных, потенциально несовместимых программы. Примером может служить представление открытых ключей получателей криптовалюты в виде текстовых строк в кодировке Base64, которые можно легко скопировать и вставить в программное обеспечение кошелька пользователя .
Двоичные данные, которые должны быть быстро проверены людьми в качестве механизма безопасности, такие как контрольные суммы файлов или отпечатки ключей , часто представляются в Base64 для легкой проверки, иногда с дополнительным форматированием, например, с разделением каждой группы из четырех символов в представлении PGP. отпечаток ключа через пробел.
QR-коды, содержащие двоичные данные, иногда сохраняют их в кодировке Base64, а не просто сохраняют необработанные двоичные данные, поскольку существует более надежная гарантия того, что все считыватели QR-кода точно декодируют текст, а также тот факт, что некоторые устройства легче сохраняют текст. текст из QR-кода, чем потенциально вредоносные двоичные данные.

Приложения, несовместимые с RFC 4648 Base64.

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

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

Одна из проблем с алфавитом RFC 4648 заключается в том, что когда отсортированный список строк в кодировке ASCII преобразуется с помощью Base64 и снова сортируется, порядок элементов меняется. Это связано с тем, что символ заполнения и символы в алфавите замены не упорядочены по значению символа ASCII (что можно увидеть, используя кнопки сортировки в следующей примерной таблице). Для решения этой проблемы используются такие алфавиты, как (без дополнений) B64 .

ASCII-код	База64	Base64, без отступов	Б64
свет ш	`bGlnaHQgdw==`	`bGlnaHQgdw`	`P4ZbO5EURk`
свет горе	`bGlnaHQgd28=`	`bGlnaHQgd28`	`P4ZbO5EURqw`
легкая работа	`bGlnaHQgd29y`	`bGlnaHQgd29y`	`P4ZbO5EURqxm`

См. также

8БИТМИМ
Ascii85 (также называемый Base85)
База16
База32
База36
База62
Кодирование двоичного текста в текст для сравнения различных алгоритмов кодирования.
Двоичное число
URL-адрес

Ссылки

^ «Кодирование и декодирование Base64 – веб-API» . Веб-документы MDN. Архивировано из оригинала 11 ноября 2014 г.
^ «Когда кодировать изображения в base64 (а когда нет)» . 28 августа 2011 г. Архивировано из оригинала 29 августа 2023 г.
^ Перейти обратно: ^а ^б Кодировки данных Base16, Base32 и Base64 . IETF . Октябрь 2006 г. doi : 10.17487/RFC4648 . РФК 4648 . Проверено 18 марта 2010 г.
^ Перейти обратно: ^а ^б Повышение конфиденциальности для электронной почты в Интернете: Часть I: Процедуры шифрования и аутентификации сообщений . IETF . Февраль 1993 г. doi : 10.17487/RFC1421 . РФК 1421 . Проверено 18 марта 2010 г.
^ Перейти обратно: ^а ^б Многоцелевые расширения почты Интернета: (MIME). Часть первая. Формат тел сообщений Интернета . IETF . Ноябрь 1996 г. doi : 10.17487/RFC2045 . РФК 2045 . Проверено 18 марта 2010 г.
^ Перейти обратно: ^а ^б Кодировки данных Base16, Base32 и Base64 . IETF . Июль 2003 г. doi : 10.17487/RFC3548 . РФК 3548 . Проверено 18 марта 2010 г.
^ «Интерактивный инструмент для визуализации кодировки» . base64decode.tech .
^ Халкия, Константинос; Хацигианнис, Панайотис (30 мая 2022 г.). Податливость Base64 на практике (PDF) . ASIA CCS '22: ACM 2022 на Азиатской конференции по компьютерной и коммуникационной безопасности. стр. 1219–1221. дои : 10.1145/3488932.3527284 .
^ Улучшение конфиденциальности для электронной почты Интернета . IETF . Февраль 1987 г. doi : 10.17487/RFC0989 . РФК 989 . Проверено 18 марта 2010 г.
^ UTF-7 Формат преобразования Unicode, безопасный для почты . IETF . Июль 1994 г. doi : 10.17487/RFC1642 . РФК 1642 . Проверено 18 марта 2010 г.
^ UTF-7 Формат преобразования Unicode, безопасный для почты . IETF . Май 1997 г. doi : 10.17487/RFC2152 . РФК 2152 . Проверено 18 марта 2010 г.
^ Формат сообщения OpenPGP . IETF . Ноябрь 2007 г. doi : 10.17487/RFC4880 . РФК 4880 . Проверено 18 марта 2010 г.
^ «Вот почему на YouTube практически никогда не закончатся уникальные идентификаторы видео» . www.mentalfloss.com . 23 марта 2016 года . Проверено 27 декабря 2021 г.
^ «7.3. Утилитные методы Base64» . Редакторский черновик HTML 5.2 . Консорциум Всемирной паутины . Проверено 2 января 2018 г. Введено набором изменений 5814 , 1 февраля 2021 г.
^ <image xlink:href="data:image/jpeg;base64, JPEG contents encoded in Base64" ... />
^ «Кодирование файла PDF (формат переносимого документа) (.pdf) в данные Base64» . base64.онлайн . Проверено 21 марта 2024 г.
^ «Редактировать скрипку» . jsfiddle.net .
^ «Стандарт GEDCOM, версия 5.5» . Homepages.rootsweb.ancestry.com . Проверено 21 июня 2012 г.
^ Провос, Нильс (13 февраля 1997 г.). "src/lib/libc/crypt/bcrypt.c r1.1" . Проверено 18 мая 2018 г.
^ «6PACK — протокол ПК «реального времени» для TNC» . Архивировано из оригинала 24 февраля 2012 г. Проверено 19 мая 2013 г.
^ «Оболочечная арифметика» . Справочное руководство по Bash . Проверено 8 апреля 2020 г. В противном случае числа принимают форму [base#]n, где необязательная база — это десятичное число от 2 до 64, представляющее арифметическую базу, а n — число в этой базе.

[common-9] Перейти обратно: ^а ^б Этот вариант предназначен для предоставления общих функций там, где их специализация не требуется, обеспечивая надежное проектирование. Это особенно важно в свете кодировок и ограничений отдельных строк, которые не учитывались, когда предыдущие стандарты были адаптированы для использования в других местах. Таким образом, указанные здесь функции могут быть переопределены.

[1] «Кодирование и декодирование Base64 – веб-API» . Веб-документы MDN. Архивировано из оригинала 11 ноября 2014 г.

[2] «Когда кодировать изображения в base64 (а когда нет)» . 28 августа 2011 г. Архивировано из оригинала 29 августа 2023 г.

[autogenerated2006-3] Перейти обратно: ^а ^б Кодировки данных Base16, Base32 и Base64 . IETF . Октябрь 2006 г. doi : 10.17487/RFC4648 . РФК 4648 . Проверено 18 марта 2010 г.

[rfc_1421-4] Перейти обратно: ^а ^б Повышение конфиденциальности для электронной почты в Интернете: Часть I: Процедуры шифрования и аутентификации сообщений . IETF . Февраль 1993 г. doi : 10.17487/RFC1421 . РФК 1421 . Проверено 18 марта 2010 г.

[rfc_2045-5] Перейти обратно: ^а ^б Многоцелевые расширения почты Интернета: (MIME). Часть первая. Формат тел сообщений Интернета . IETF . Ноябрь 1996 г. doi : 10.17487/RFC2045 . РФК 2045 . Проверено 18 марта 2010 г.

[rfc_3548-6] Перейти обратно: ^а ^б Кодировки данных Base16, Base32 и Base64 . IETF . Июль 2003 г. doi : 10.17487/RFC3548 . РФК 3548 . Проверено 18 марта 2010 г.

[7] «Интерактивный инструмент для визуализации кодировки» . base64decode.tech .

[8] Халкия, Константинос; Хацигианнис, Панайотис (30 мая 2022 г.). Податливость Base64 на практике (PDF) . ASIA CCS '22: ACM 2022 на Азиатской конференции по компьютерной и коммуникационной безопасности. стр. 1219–1221. дои : 10.1145/3488932.3527284 .

[10] Улучшение конфиденциальности для электронной почты Интернета . IETF . Февраль 1987 г. doi : 10.17487/RFC0989 . РФК 989 . Проверено 18 марта 2010 г.

[11] UTF-7 Формат преобразования Unicode, безопасный для почты . IETF . Июль 1994 г. doi : 10.17487/RFC1642 . РФК 1642 . Проверено 18 марта 2010 г.

[12] UTF-7 Формат преобразования Unicode, безопасный для почты . IETF . Май 1997 г. doi : 10.17487/RFC2152 . РФК 2152 . Проверено 18 марта 2010 г.

[13] Формат сообщения OpenPGP . IETF . Ноябрь 2007 г. doi : 10.17487/RFC4880 . РФК 4880 . Проверено 18 марта 2010 г.

[14] «Вот почему на YouTube практически никогда не закончатся уникальные идентификаторы видео» . www.mentalfloss.com . 23 марта 2016 года . Проверено 27 декабря 2021 г.

[15] «7.3. Утилитные методы Base64» . Редакторский черновик HTML 5.2 . Консорциум Всемирной паутины . Проверено 2 января 2018 г. Введено набором изменений 5814 , 1 февраля 2021 г.

[16] <image xlink:href="data:image/jpeg;base64, JPEG contents encoded in Base64" ... />

[17] «Кодирование файла PDF (формат переносимого документа) (.pdf) в данные Base64» . base64.онлайн . Проверено 21 марта 2024 г.

[18] «Редактировать скрипку» . jsfiddle.net .

[19] «Стандарт GEDCOM, версия 5.5» . Homepages.rootsweb.ancestry.com . Проверено 21 июня 2012 г.

[20] Провос, Нильс (13 февраля 1997 г.). "src/lib/libc/crypt/bcrypt.c r1.1" . Проверено 18 мая 2018 г.

[21] «6PACK — протокол ПК «реального времени» для TNC» . Архивировано из оригинала 24 февраля 2012 г. Проверено 19 мая 2013 г.

[22] «Оболочечная арифметика» . Справочное руководство по Bash . Проверено 8 апреля 2020 г. В противном случае числа принимают форму [base#]n, где необязательная база — это десятичное число от 2 до 64, представляющее арифметическую базу, а n — число в этой базе.

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ а ]

[ 9 ]

[ 10 ]

[ 11 ]

[ 12 ]

[ 13 ]

[ 14 ]

[ 15 ]

[ 16 ]

[ 17 ]

[ 18 ]

[ 19 ]

[ 20 ]

[ 21 ]

v т и обмена данными Форматы
Читабельный для человека	Атом CSV-файл ЭДИФАКТ JSON Веб-шифрование Веб-токен Веб-подпись Список недвижимости РДФ Ребол ТОМЛ XML ЯМЛ
Двоичный	АМФ АСН.1 SMI Евро База32 База64 БСОН УБЖСОН Капитан Прото КБОР Плоские буферы Пакет сообщений Список недвижимости Буферы протоколов Бережливость Цифал DSDL ШДР uuencode yEnc
Сравнение форматов сериализации данных