Может ли строка Base64 содержать вкладки?

Question

Простой вопрос да или нет, и я на 90% уверен, что это не так ... но я не уверен.

Может ли строка Base64 содержать вкладки?

Answer 1

Это зависит от того, что вы спрашиваете. Если вы спрашиваете, могут ли вкладки быть закодированы в base-64, тогда ответ «да», поскольку они могут обрабатываться так же, как и любой другой символ ASCII.

Однако, если вы спрашиваете, могут ли выходные данные base-64 содержать вкладки, ответ будет отрицательным. Следующая ссылка предназначена для статьи, подробно описывающей base-64, включая символы, которые считаются действительными:

http://en.wikipedia.org/wiki/Base64

Answer 2

Короткий ответ - нет, но Base64 также не может содержать возврат каретки.

Именно поэтому, если у вас есть несколько строк Base64, вы удаляете все возвраты каретки, переводы строк и все остальное, что отсутствует в алфавите Base64

Включает вкладки.

Answer 3

С wikipedia.com:

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

Как видите, символы табуляции не включены. Однако вы, конечно, можете закодировать символ табуляции в строку base64.

Answer 4

Конечно. Tab - это просто символ ASCII 9, который имеет представление base64, как и любое другое целое число.

Answer 5

Ха-ха, как вы видите из ответов, на самом деле это не такой простой ответ да нет.

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

Я хотел бы добавить, что на самом деле вам следует позаботиться о сохранении кодировки вашей строки, то есть преобразовать ее в массив байтов с правильной кодировкой (Unicode, UTF-8 и т. Д.), А затем преобразовать этот массив байтов в base64.

РЕДАКТИРОВАТЬ: простой тест.

private void button2_Click(object sender, EventArgs e)
{
  StringBuilder sb = new StringBuilder();
  string test = "The rain in spain falls \t mainly on the plain";
  sb.AppendLine(test);
  UTF8Encoding enc = new UTF8Encoding();
  byte[] b = enc.GetBytes(test);
  string cvtd = Convert.ToBase64String(b);
  sb.AppendLine(cvtd);
  byte[] c = Convert.FromBase64String(cvtd);
  string backAgain = enc.GetString(c);
  sb.AppendLine(backAgain);
  MessageBox.Show(sb.ToString());
}

Answer 6

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

Реализации ДОЛЖНЫ отклонять закодированные данные, если они содержат
символы вне базового алфавита при интерпретации базового кода
данные, если не спецификация ссылаясь на этот документ явно говорится иначе. Такие спецификации вместо этого может заявить, как MIME, что персонажи за пределами базы кодировка алфавита должна быть просто игнорируется при интерпретации данных ("быть либерал в том что ты принимаешь "). Обратите внимание, что это означает, что любой возврат соседней каретки / перевод строки (CRLF) символы составляют «не алфавитные символы» и являются проигнорирован.

Спецификации, такие как PEM ( RFC 1421 ) и MIME ( RFC 2045 ), указывают, что строки Base64 могут быть разбиты пробелами. В соответствии с RFC 822 , табуляция (HTAB) считается символом пробела.

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

Answer 7

Кажется, здесь много путаницы; и удивительно, что большинство ответов - «нет». Я не думаю, что это хороший канонический ответ. Причиной путаницы, вероятно, является тот факт, что Base64 не указан строго; существует множество практических реализаций и интерпретаций. Вы можете проверить текст ссылки для дальнейшего обсуждения этого вопроса.

В целом, однако, соответствующие кодеки base64 ДОЛЖНЫ понимать перевод строки, поскольку они определяются некоторыми определениями base64 (76 символьных сегментов, затем перевод строки и т. Д.). Из-за этого большинство декодеров также допускают пропуски отступов и, как правило, любые пробелы между 4-символьными «тройками» (так называются, поскольку они кодируют 3 байта).

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

Но я бы не стал добавлять вкладки сам, если генерировал контент base64, отправляемый в службу - будьте осторожны в том, что вы отправляете, (более) либерально в том, что вы получаете.

Answer 8

ДА!

Base64 используется для кодирования ЛЮБОГО 8-битного значения (от 0 до 255) в строку с использованием набора безопасных символов. Табуляция десятичная 9.

База 64 использует один из следующих наборов символов:

Data: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
URLs: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_

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

Answer 9

Convert.FromBase64String() в .NET Framework, похоже, не обращает на них внимания. Я считаю, что все пробелы в строке игнорируются.

string xxx = "ABCD\tDEFG";   //simulated Base64 encoded string w/added tab
Console.WriteLine(xxx);
byte[] xx = Convert.FromBase64String(xxx); // convert string back to binary
Console.WriteLine(BitConverter.ToString(xx));

Выход:

ABCD    DEFG
00-10-83-0C-41-46

Соответствующий пункт RFC-2045 (6: 8)

Кодированный выходной поток должен быть представлены в строках не более чем 76 символов каждый. Вся линия разрывы или другие символы не найденные в таблице 1 должны игнорироваться программное обеспечение для декодирования. В данных base64, символы, отличные от указанных в таблице 1, разрывы строк и прочее белое пробел вероятно указывает на передачу ошибка, о которой предупреждение сообщение или даже отклонение сообщения может быть уместным под некоторыми обстоятельства.