Расшифровать текст в кодировке: Универсальный декодер текста — Хитрые инструменты

, также известное как «процентное кодирование», представляет собой механизм кодирования информации в унифицированном идентификаторе ресурса (URI).Хотя это называется кодированием URL-адресов, на самом деле оно используется более широко в основном наборе универсальных идентификаторов ресурсов (URI), который включает как универсальный указатель ресурсов (URL), так и универсальное имя ресурса (URN). Как таковой, он также используется при подготовке данных типа носителя «application / x-www-form-urlencoded», как это часто бывает при отправке данных HTML-формы в HTTP-запросах.

Дополнительные параметры

• Набор символов: В случае текстовых данных схема кодирования не содержит набора символов, поэтому вы должны указать, какой набор символов использовался в процессе кодирования.Обычно это UTF-8, но может быть и множество других; если вы не уверены, поиграйте с доступными опциями или попробуйте опцию автоопределения. Эта информация используется для преобразования декодированных данных в набор символов нашего веб-сайта, чтобы все буквы и символы могли отображаться правильно. Обратите внимание, что это не имеет отношения к файлам, поскольку к ним не нужно применять безопасные веб-преобразования.
• Декодировать каждую строку отдельно: Закодированные данные обычно состоят из непрерывного текста, поэтому даже символы новой строки преобразуются в их формы с процентной кодировкой.Перед декодированием все незакодированные пробелы удаляются из ввода для защиты целостности ввода. Эта опция полезна, если вы собираетесь декодировать несколько независимых записей данных, разделенных переносом строки.
• Режим реального времени: Когда вы включаете эту опцию, введенные данные немедленно декодируются с помощью встроенных функций JavaScript вашего браузера, без отправки какой-либо информации на наши серверы. В настоящее время этот режим поддерживает только набор символов UTF-8.

Все коммуникации с нашими серверами осуществляются через безопасные зашифрованные соединения SSL (https).Мы удаляем загруженные файлы с наших серверов сразу после обработки, а полученный загружаемый файл удаляется сразу после первой попытки загрузки или 15 минут бездействия (в зависимости от того, что короче). Мы никоим образом не храним и не проверяем содержимое отправленных данных или загруженных файлов. Ознакомьтесь с нашей политикой конфиденциальности ниже для получения более подробной информации.

Совершенно бесплатно

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

Подробная информация о кодировке URL-адресов

Типы символов URI

Допустимые символы в URI либо зарезервированы, либо не зарезервированы (или символ процента как часть процентного кодирования). Зарезервированные символы — это символы, которые иногда имеют особое значение. Например, символы прямой косой черты используются для разделения различных частей URL-адреса (или, в более общем смысле, URI). Незарезервированные символы не имеют такого особого значения. При использовании процентного кодирования зарезервированные символы представляются с помощью специальных последовательностей символов.Наборы зарезервированных и незарезервированных символов, а также обстоятельства, при которых определенные зарезервированные символы имеют особое значение, немного меняются с каждой новой редакцией спецификаций, управляющих URI и схемами URI.

Зарезервированные символы с процентным кодированием

Когда символ из зарезервированного набора («зарезервированный символ») имеет особое значение («зарезервированное назначение») в конкретном контексте, а схема URI говорит, что необходимо использовать это символ для какой-либо другой цели, тогда этот символ должен быть закодирован в процентах.Процентное кодирование зарезервированного символа означает преобразование символа в соответствующее ему байтовое значение в ASCII и последующее представление этого значения в виде пары шестнадцатеричных цифр. Цифры, которым предшествует знак процента («%»), затем используются в URI вместо зарезервированного символа. (Для символа, отличного от ASCII, он обычно преобразуется в свою последовательность байтов в UTF-8, а затем каждое значение байта представляется, как указано выше.)

Зарезервированный символ «/», например, если он используется в пути « «компонент URI, имеет особое значение как разделитель между сегментами пути.Если в соответствии с заданной схемой URI «/» должен находиться в сегменте пути, тогда в этом сегменте должны использоваться три символа «% 2F» (или «% 2f») вместо «/».

В компоненте «запрос» URI (часть после символа «?»), Например, «/» по-прежнему считается зарезервированным символом, но обычно не имеет зарезервированного назначения (если в конкретной схеме URI не указано иное).Символ не нужно кодировать в процентах, если он не имеет зарезервированной цели.

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

Процентное кодирование незарезервированных символов

Символы из незарезервированного набора никогда не нуждаются в процентном кодировании.

URI, которые различаются только тем, является ли незарезервированный символ закодированным в процентах или нет, эквивалентны по определению, но процессоры URI на практике не всегда могут обрабатывать их одинаково. Например, потребители URI не должны обрабатывать «% 41» иначе, чем «A» («% 41» — это процентное кодирование «A») или «% 7E» иначе, чем «~», но некоторые это делают. Поэтому для максимальной совместимости производителям URI не рекомендуется использовать процентное кодирование незарезервированных символов.

Процентное кодирование символа процента

Поскольку символ процента («%») служит индикатором для октетов, закодированных в процентах, он должен быть закодирован в процентах как «% 25», чтобы этот октет использовался в качестве данных в URI.

Процентное кодирование произвольных данных

Большинство схем URI включают представление произвольных данных, таких как IP-адрес или путь файловой системы, как компоненты URI. Спецификации схемы URI должны, но часто этого не делать, предоставлять явное сопоставление между символами URI и всеми возможными значениями данных, представленными этими символами.

Двоичные данные

С момента публикации RFC 1738 в 1994 году было указано, что схемы, которые обеспечивают представление двоичных данных в URI, должны разделять данные на 8-битные байты и кодировать каждый байт в процентах в таким же образом, как указано выше.Например, байтовое значение 0F (шестнадцатеричное) должно быть представлено как «% 0F», а байтовое значение 41 (шестнадцатеричное) может быть представлено как «A» или «% 41». Использование незакодированных символов для буквенно-цифровых и других незарезервированных символов обычно предпочтительнее, поскольку это приводит к более коротким URL-адресам.

Символьные данные

Процедура процентного кодирования двоичных данных часто экстраполировалась, иногда неправильно или не полностью, для применения к символьным данным.В годы становления Всемирной паутины при работе с символами данных в репертуаре ASCII и использовании соответствующих им байтов в ASCII в качестве основы для определения последовательностей, закодированных в процентах, эта практика была относительно безвредной; многие считали, что символы и байты взаимно однозначно сопоставлены и взаимозаменяемы. Однако потребность в представлении символов вне диапазона ASCII быстро росла, и схемы и протоколы URI часто не обеспечивали стандартных правил подготовки символьных данных для включения в URI.Следовательно, веб-приложения начали использовать различные многобайтовые кодировки, кодировки с отслеживанием состояния и другие несовместимые с ASCII кодировки в качестве основы для процентного кодирования, что привело к неоднозначности, а также затруднило надежную интерпретацию URI.

Например, многие схемы и протоколы URI, основанные на RFC 1738 и 2396, предполагают, что символы данных будут преобразованы в байты в соответствии с некоторой неопределенной кодировкой символов, прежде чем будут представлены в URI незарезервированными символами или байтами, закодированными в процентах.Если схема не позволяет URI предоставлять подсказку о том, какая кодировка использовалась, или если кодировка конфликтует с использованием ASCII для процентного кодирования зарезервированных и незарезервированных символов, то URI не может быть надежно интерпретирован. Некоторые схемы вообще не учитывают кодирование и вместо этого просто предлагают, чтобы символы данных отображались непосредственно на символы URI, что оставляет на усмотрение отдельных пользователей решать, следует ли и как процентно кодировать символы данных, которые не входят ни в зарезервированные, ни в незарезервированные наборы.

Base64 — Глоссарий веб-документации MDN: Определения терминов, связанных с Интернетом

Base64 — это группа аналогичных схем кодирования двоичного кода в текст, которые представляют двоичные данные в строковом формате ASCII путем их перевода в представление radix-64. Термин Base64 происходит от конкретной кодировки передачи содержимого MIME.

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

Одним из распространенных приложений кодирования Base64 в Интернете является кодирование двоичных данных, чтобы их можно было включить в URL-адрес data :.

В JavaScript есть две функции соответственно для декодирования и кодирования строк Base64:

• btoa () : создает строку ASCII в кодировке Base64 из «строки» двоичных данных («btoa» следует читать как «двоичный в ASCII»).
• atob () : декодирует строку в кодировке Base64 («atob» следует читать как «ASCII в двоичную форму»).

Алгоритм, используемый atob () и btoa () , указан в RFC 4648, раздел 4.

Обратите внимание, что btoa () ожидает передачи двоичных данных и вызовет исключение, если данная строка содержит какие-либо символы, представление UTF-16 которых занимает более одного байта. Дополнительные сведения см. В документации для btoa () .

Каждая цифра Base64 представляет ровно 6 бит данных. Таким образом, три 8-битных байта входной строки / двоичного файла (3 × 8 бит = 24 бита) могут быть представлены четырьмя 6-битными цифрами Base64 (4 × 6 = 24 бита).

Это означает, что версия строки или файла в формате Base64 будет иметь размер не менее 133% от размера исходного кода (увеличение на ~ 33%).Увеличение может быть больше, если закодированные данные малы. Например, строка "a" с длиной === 1 кодируется в "YQ ==" с длиной === 4 — увеличение на 300%.

Поскольку DOMString s являются строками с 16-битной кодировкой, в большинстве браузеров вызов window.btoa в строке Unicode вызовет исключение Character Out Of Range , если символ превышает диапазон 8-битного ASCII -кодированный символ. Есть два возможных метода решения этой проблемы:

• первый — экранировать всю строку и затем кодировать ее;
• второй — преобразовать UTF-16 DOMString в массив символов UTF-8, а затем закодировать его.

Вот два возможных метода.

Решение №1 — экранирование строки перед ее кодированием

  function utf8_to_b64 (str) {
  вернуть window.btoa (unescape (encodeURIComponent (str)));
}

function b64_to_utf8 (str) {
  вернуть decodeURIComponent (escape (window.atob (str)));
}


utf8_to_b64 ('✓ в режиме');
b64_to_utf8 ('4pyTIMOgIGxhIG1vZGU =');  

Это решение было предложено Йоханом Сундстремом.

Другое возможное решение без использования устаревших функций unescape и escape.

  function b64EncodeUnicode (str) {
    return btoa (encodeURIComponent (str) .replace (/% ([0-9A-F] {2}) / g, function (match, p1) {
        вернуть String.fromCharCode ('0x' + p1);
    }));
}
 b64EncodeUnicode ('✓ в режиме');
  

Решение № 2 — переписывание

Примечание: Следующий код также полезен для получения ArrayBuffer из строки Base64 и / или наоборот (см. ниже).A-Za-z0-9 \ + \ /] / g, «»), nInLen = sB64Enc.length, nOutLen = nBlocksSize? Math.ceil ((nInLen * 3 + 1 >> 2) / nBlocksSize) * nBlocksSize: nInLen * 3 + 1 >> 2, taBytes = new Uint8Array (nOutLen); for (var nMod3, nMod4, nUint24 = 0, nOutIdx = 0, nInIdx = 0; nInIdx >> (16 >>> nMod3 & 24) & 255; } nUint24 = 0; } } вернуть taBytes; } function uint6ToB64 (nUint6) { вернуть nUint6 <26? nUint6 + 65 : nUint6 <52? nUint6 + 71 : nUint6 <62? nUint6 - 4 : nUint6 === 62? 43 год : nUint6 === 63? 47 : 65; } function base64EncArr (aBytes) { var nMod3 = 2, sB64Enc = ""; для (var nLen = aBytes.длина, nUint24 = 0, nIdx = 0; nIdx 0 && (nIdx * 4/3)% 76 === 0) {sB64Enc + = «\ r \ n»; } nUint24 | = aBytes [nIdx] << (16 >>> nMod3 & 24); if (nMod3 === 2 || aBytes.length — nIdx === 1) { sB64Enc + = String.fromCharCode (uint6ToB64 (nUint24 >>> 18 & 63), uint6ToB64 (nUint24 >>> 12 & 63), uint6ToB64 (nUint24 >>> 6 & 63), uint6ToB64 (nUint24 & 63)); nUint24 = 0; } } вернуть sB64Enc.substr (0, sB64Enc.length — 2 + nMod3) + (nMod3 === 2? »: nMod3 === 1? ‘=’: ‘==’); } function UTF8ArrToStr (aBytes) { var sView = «»; for (var nPart, nLen = aBytes.length, nIdx = 0; nIdx 251 && nPart <254 && nIdx + 5 247 && nPart <252 && nIdx + 4 239 && nPart <248 && nIdx + 3 223 && nPart <240 && nIdx + 2 191 && nPart <224 && nIdx + 1 >> 6); aBytes [nIdx ++] = 128 + (nChr & 63); } else if (nChr <0x10000) { aBytes [nIdx ++] = 224 + (nChr >>> 12); aBytes [nIdx ++] = 128 + (nChr >>> 6 и 63); aBytes [nIdx ++] = 128 + (nChr & 63); } else if (nChr <0x200000) { aBytes [nIdx ++] = 240 + (nChr >>> 18); aBytes [nIdx ++] = 128 + (nChr >>> 12 и 63); aBytes [nIdx ++] = 128 + (nChr >>> 6 и 63); aBytes [nIdx ++] = 128 + (nChr & 63); } else if (nChr <0x4000000) { aBytes [nIdx ++] = 248 + (nChr >>> 24); aBytes [nIdx ++] = 128 + (nChr >>> 18 и 63); aBytes [nIdx ++] = 128 + (nChr >>> 12 и 63); aBytes [nIdx ++] = 128 + (nChr >>> 6 и 63); aBytes [nIdx ++] = 128 + (nChr & 63); } еще { aBytes [nIdx ++] = 252 + (nChr >>> 30); aBytes [nIdx ++] = 128 + (nChr >>> 24 и 63); aBytes [nIdx ++] = 128 + (nChr >>> 18 и 63); aBytes [nIdx ++] = 128 + (nChr >>> 12 и 63); aBytes [nIdx ++] = 128 + (nChr >>> 6 и 63); aBytes [nIdx ++] = 128 + (nChr & 63); } } return aBytes; }

Тесты

 

var sMyInput = "Base 64 \ u2014 Mozilla Developer Network";

var aMyUTF8Input = strToUTF8Arr (sMyInput);

var sMyBase64 = base64EncArr (aMyUTF8Input);

оповещение (sMyBase64);

var aMyUTF8Output = base64DecToArr (sMyBase64);

var sMyOutput = UTF8ArrToStr (aMyUTF8Output);

оповещение (sMyOutput);  

Приложение: декодирование строки Base64 в Uint8Array или ArrayBuffer

Эти функции позволяют нам создавать также uint8Arrays или arrayBuffers из строк в кодировке Base64:

 
var myArray = base64DecToArr ("QmFzZSA2NCDigJQgTW96aWxsYSBEZXZlbG9wZXIgTmV0d29yaw ==");


var myBuffer = base64DecToArr ("QmFzZSA2NCDigJQgTW96aWxsYSBEZXZlbG9wZXIgTmV0d29yaw ==").буфер;

оповещение (myBuffer.byteLength);  

Примечание: Функция base64DecToArr (sBase64 [, nBlocksSize ]) возвращает uint8Array байтов. Если ваша цель — создать буфер из 16-битных / 32-битных / 64-битных необработанных данных, используйте аргумент nBlocksSize , который представляет собой количество байтов, из которых свойство uint8Array.buffer.bytesLength должно привести к несколько ( 1 или опущено для ASCII, двоичных строк или строк в кодировке UTF-8, 2 для строк UTF-16, 4 для строк UTF-32).

base64 — Кодировки данных Base16, Base32, Base64, Base85 — Документация Python 3.9.6

Исходный код: Lib / base64.py

Этот модуль предоставляет функции для кодирования двоичных данных для печати Символы ASCII и декодирование таких кодировок обратно в двоичные данные. Он предоставляет функции кодирования и декодирования для кодировок, указанных в RFC 3548 , который определяет алгоритмы Base16, Base32 и Base64, и для де-факто стандартных кодировок Ascii85 и Base85.

Кодировки RFC 3548 подходят для кодирования двоичных данных, так что они могут безопасно отправлено по электронной почте, использовано как часть URL-адресов или включено как часть HTTP POST запрос. Алгоритм кодирования отличается от uuencode программа.

Этот модуль предоставляет два интерфейса. Современный интерфейс поддерживает кодирование байтовых объектов в ASCII байтов , и декодирование байтовых объектов или строки, содержащие ASCII до байт .Оба алфавита base-64 определены в RFC 3548 (нормальный и безопасный для URL-адресов и файловой системы).

Устаревший интерфейс не поддерживает декодирование из строк, но поддерживает предоставляют функции для кодирования и декодирования файловых объектов и обратно. Он поддерживает только стандартный алфавит Base64 и добавляет новые строки каждые 76 символов согласно RFC 2045 . Обратите внимание, что если вы ищете для поддержки RFC 2045 вы, вероятно, захотите посмотреть электронное письмо пакет вместо этого.

Изменено в версии 3.3: строки Unicode, содержащие только ASCII, теперь принимаются функциями декодирования современный интерфейс.

Изменено в версии 3.4: Любые байтовые объекты теперь принимаются всеми функции кодирования и декодирования в этом модуле. Добавлена ​​поддержка Ascii85 / Base85.

Современный интерфейс обеспечивает:

base64. b64 кодировать ( s , altchars = None )

Закодировать байтовый объект s с использованием Base64 и вернуть закодированный байт .

Необязательно altchars должен быть байтовым объектом не менее длина 2 (дополнительные символы игнорируются), что указывает на альтернативный алфавит для символов + и /. Это позволяет приложению, например, генерировать строки Base64, безопасные для URL или файловой системы. По умолчанию — Нет , для который используется стандартный алфавит Base64.

base64. b64decode ( s , altchars = None , validate = False )

Декодировать байтовый объект в кодировке Base64 или строку ASCII s и вернуть декодированные байтов .

Необязательно altchars должен быть байтовым объектом или строкой ASCII не менее длины 2 (дополнительные символы игнорируются), что указывает альтернативный алфавит, используемый вместо символов + и /.

Возникает исключение binascii.Error если s неправильно заполнен.

Если подтвердит, что — это Ложь (по умолчанию), символы, которые ни в нормальном алфавите base-64 и альтернативном алфавите отбрасывается до проверки заполнения.Если подтверждает, что — это Истина , эти неалфавитные символы во вводе приводят к binascii. Ошибка .

base64. standard_b64 код ( s )

Кодировать байтовый объект s с использованием стандартного алфавита Base64 и вернуть закодированные байтов .

base64. standard_b64decode ( s )

Декодировать байтовый объект или строку ASCII s с использованием стандартного Base64 алфавит и вернуть декодированные байтов .

base64. urlsafe_b64encode ( s )

Кодировать байтовый объект s с помощью Алфавит, безопасный для URL и файловой системы, который заменяет - вместо + и _ вместо / в стандартный алфавит Base64, и верните закодированные байтов . Результат все еще может содержать = .

base64. urlsafe_b64decode ( s )

Декодировать байтовый объект или строку ASCII с с использованием безопасного URL-адреса и файловой системы алфавит, который заменяет - вместо + и _ вместо / в стандартном алфавите Base64 и вернуть декодированный байт .

base64. b32 код ( s )

Закодировать байтовый объект s с использованием Base32 и вернуть закодировано байтов .

base64. b32decode ( s , casefold = False , map01 = None )

Декодировать байтовый объект в кодировке Base32 или строку ASCII s и вернуть декодированные байтов .

Необязательно casefold — это флаг, указывающий допустимы ли строчные буквы в качестве входных данных. В целях безопасности по умолчанию Ложь .

RFC 3548 позволяет по желанию сопоставить цифру 0 (ноль) с буквой O (о), и для необязательного сопоставления цифры 1 (один) либо букве I (глаз) или буква L (эл). Необязательный аргумент map01 , если не Нет , указывает с какой буквой должна быть сопоставлена ​​цифра 1 (когда map01 не Нет , цифра 0 всегда сопоставляется с буквой O).В целях безопасности по умолчанию Нет , поэтому 0 и 1 не допускаются на входе.

binascii. Ошибка возникает, если s неправильно заполнены или если в Вход.

base64. b16 кодировать ( s )

Закодировать байтовый объект s с использованием Base16 и вернуть закодировано байтов .

base64. b16decode ( s , casefold = False )

Декодировать байтовый объект в кодировке Base16 или строку ASCII s и вернуть декодированные байтов .

Необязательно casefold — это флаг, определяющий, В качестве входных данных можно использовать строчные буквы. В целях безопасности по умолчанию это Ложь .

binascii. Ошибка возникает, если s неправильно заполнены или если в Вход.

base64. a85encode ( b , * , foldspaces = False , wrapcol = 0 , pad = False , adobe = False )

Закодируйте байтовый объект b с помощью Ascii85 и верните закодировано байтов .

кратных пространств — это необязательный флаг, который использует специальную короткую последовательность «y» вместо 4 последовательных пробелов (ASCII 0x20), как поддерживается «btoa».Этот эта функция не поддерживается «стандартной» кодировкой Ascii85.

wrapcol определяет, должен ли вывод иметь новую строку ( b '\ n' ) добавлены персонажи. Если это не ноль, каждая строка вывода будет самое большее это количество символов.

pad контролирует, дополняется ли ввод до кратного 4 перед кодированием. Обратите внимание, что реализация btoa всегда дополняет.

adobe контролирует, будет ли закодированная последовательность байтов обрамлена <~ и ~> , который используется реализацией Adobe.

base64. a85decode ( b , * , foldspaces = False , adobe = False , ignorechars = b '\ t \ n \ r \ v' )

Декодировать байтовый объект в кодировке Ascii85 или строку ASCII b и вернуть декодированные байтов .

кратных пространств - это флаг, который указывает, должна ли короткая последовательность «y» следует принимать как сокращение для 4 последовательных пробелов (ASCII 0x20).Эта функция не поддерживается «стандартной» кодировкой Ascii85.

Adobe определяет, находится ли входная последовательность в формате Adobe Ascii85. (т.е. обрамлен символами <~ и ~>).

ignorechars должен быть байтовым объектом или строкой ASCII содержащие символы для игнорирования со входа. Он должен содержать только символы пробела, и default содержит все пробельные символы в ASCII.

base64. b85 код ( b , pad = False )

Кодируйте байтовый объект b с использованием base85 (как используется в e.грамм. git-style binary diffs) и вернуть закодированные байтов .

Если pad истинно, ввод дополняется b '\ 0' , поэтому его длина равна кратное 4 байтам до кодирования.

base64. b85decode ( b )

Декодировать байтовый объект в кодировке base85 или строку ASCII b и вернуть декодированные байтов . Заполнение неявно удаляется, если необходимо.

Устаревший интерфейс:

base64. декодировать ( вход , выход )

Расшифруйте содержимое двоичного файла input и запишите полученный двоичный файл данные в выходной файл . вход и выход должны быть файловыми объектами. input будет считываться до тех пор, пока input.readline () не вернет пустой объект байтов.

base64. декодбайт ( с )

Декодировать байтовый объект s , который должен содержать один или несколько строки данных в кодировке base64 и возвращают декодированные байтов .

base64. кодировать ( вход , выход )

Кодировать содержимое двоичного файла input и записывать полученный base64 закодированные данные в выходной файл . вход и выход должен быть файлом объекты. input будет считываться до тех пор, пока input.read () не вернется. пустой объект байтов. encode () вставляет символ новой строки ( b '\ n' ) после каждых 76 байтов вывода, а также гарантируя, что вывод всегда заканчивается новой строкой в ​​соответствии с RFC 2045 (MIME).

base64. байтов кодирования ( с )

Кодировать байтовый объект s , который может содержать произвольный двоичный data и вернуть байтов , содержащих данные в кодировке base64, с символами новой строки ( b '\ n' ) вставляется после каждых 76 байтов вывода и гарантирует, что есть завершающий символ новой строки, согласно RFC 2045 (MIME).

Пример использования модуля:

 >>> импорт base64
>>> encoded = base64.b64encode (b'data для кодирования ')
>>> закодировано
b'ZGF0YSB0byBiZSBlbmNvZGVk '
>>> data = base64.b64decode (в кодировке)
>>> данные
b'data для кодирования '
 

См. Также

Модуль binascii

Модуль поддержки, содержащий преобразования из ASCII в двоичный и двоичный в ASCII.

RFC 1521 - MIME (многоцелевые расширения электронной почты), часть первая: механизмы определения и описания формата тел сообщений в Интернете

Раздел 5.2, «Кодирование передачи содержимого Base64», дает определение кодировка base64.

- Как определить, какой алгоритм кодирования используется?

Есть два распространенных заблуждения / заблуждения относительно строк в кодировке base64:

1. Ожидание получения читаемого текста после декодирования строки в кодировке base64, наряду с предположением, что либо кодировка отличается, либо декодер base64 не работает, если результат не соответствует ожиданиям

   Данная строка кажется быть в кодировке base64, он содержит только символы из набора символов base64 и правильно дополнен, поэтому, скорее всего, это строка в кодировке base64.Кодирование Base64 используется для кодирования всех видов данных, но очень распространенный вариант использования - это кодирование двоичных данных (которые не могут быть распечатаны или отображаются только как строка «странных» символов) в более простую для обработки форму. Один из типичных вариантов использования - кодирование base64 результата шифрования или хеширования, которые создают двоичные результаты.

2. Ожидание, что декодирование base64 является единственным шагом, необходимым для возврата оригинала (например, обычного текста, пароля и т. Д.)

   Как упоминалось выше, base64 часто используется для кодирования двоичного результата шифрования или хеширования.Сам по себе Base64 не является шифрованием и (надеюсь) никогда не используется для защиты паролей или другой конфиденциальной информации.
   «привет, мир» в кодировке base64 - это «aGVsbG8gd29ybGQ =», и каждый может декодировать его с помощью любого декодера base64.
   Процесс паролей обычно состоит в том, чтобы сначала хешировать пароль, а затем base64 кодирует двоичное хеш-значение. Для другой конфиденциальной информации выполняется шифрование, а затем кодирование base64.
   

Сказав это, можно сделать вывод, что данная строка, скорее всего, является хешем в кодировке base64 или зашифрованным текстом.

Типичный последующий вопрос:
Если эта двоичная чушь, которую я получаю при декодировании, является результатом шифрования или хеширования, как мне получить простой текст?

Ответ на это: вероятно, совсем не так, по крайней мере, не на основании данной информации.

Если это хэш, расшифровывать нечего, так как хеширование - это односторонний процесс. Если он зашифрован, нет информации, как его расшифровать. Для дешифрования вам необходимо знать алгоритм шифрования и ключ.

И в случае хеширования или шифрования двоичная информация обычно не содержит никаких маркеров, которые помечают данные как результат какого-либо определенного алгоритма хеширования или шифрования.
Единственная информация, которую я могу получить из строки в кодировке base64 (помимо двоичного результата), - это длина. Данная строка имеет длину 44 символа, включая один символ заполнения, то есть 43 * 6 (каждый символ base64 кодирует 6 бит) = 258 бит, поэтому, вероятно, 256 бит. Это может быть, например, хеш sha-256, но на самом деле это всего лишь возможность.

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