Почему base64 строки содержит "\ n"?

15700
Tiina 
$ echo -n "apfjxkic-omyuobwd339805ak:60a06cd2ddfad610b9490d359d605407" | base64 YXBmanhraWMtb215dW9id2QzMzk4MDVhazo2MGEwNmNkMmRkZmFkNjEwYjk0OTBkMzU5ZDYwNTQw Nw==

Выход имеет возврат раньше Nw==. Как правильно генерировать base64 в Linux?

снимок экрана терминала

60
Вы уверены, что вывод содержит новую строку, и это не просто перенос окна? Эта команда отлично работала для меня на Mac. Какую ОС вы используете? Ian 7 лет назад 5
@lan, вы также можете увидеть это на http://www.motobit.com/util/base64-decoder-encoder.asp Tiina 7 лет назад 0
RFC 2045, который определил Base64, ТРЕБУЕТ перевод строки после 76 символов (макс.). Что заставляет вас думать, что ваш пример _не_ правильный путь? MSalters 7 лет назад 45
@MSalters [RFC 4648] (https://tools.ietf.org/html/rfc4648) специально решает эту проблему. * Реализации НЕ ДОЛЖНЫ добавлять переводы строки к базовым кодированным данным, если только спецификация, ссылающаяся на этот документ, явно не предписывает базовым кодировщикам добавлять переводы строки после определенного количества символов. * => Эта реализация неверна в соответствии с RFC 4648, если она утверждает, что производит "простой" base64-закодированный вывод. Более интересно то, что руководства GNU base64 (в вопросе?) Конкретно ссылаются на RFC 3548, который также не определяет перенос по умолчанию и который RFC 4648 устарел. Bob 7 лет назад 22
@MSalters Потому что я полагал, что «кодировка base 64 не содержит пробелов / tab / \ n», и именно так ее реализует java.util.Base64. Tiina 7 лет назад 0
@Bob: RFC немного меньше уважают стабильность API; инструмент base64 не может просто изменить свой формат вывода, не нарушая сценарии. MSalters 7 лет назад 4
@MSalters Я не могу быть уверен, что более старой версии не существует, но GNU base64 была написана в 2004 году, и AFAICT всегда утверждал, что следует RFC 3548. RFC 3548 содержит то же самое предложение «НЕ ДОЛЖНО добавлять переводы строк». Так что даже оригинальная реализация была «неправильной». По крайней мере, его реализация не соответствует документации. В любом случае, вы спросили, почему пример OP верен и ссылаются на RFC; Мой ответ - правильный RFC, который фактически определяет base64 изолированно. Если ваш ответ «по историческим причинам», пусть будет так, но ОП здесь не так. Bob 7 лет назад 2
Кажется, что это беспорядок: https://en.wikipedia.org/wiki/Base64#Implementations_and_history Итак, в целом, base64 несовместима с самим собой. Отлично. Oskar Skog 7 лет назад 2
Существуют ли реализации декодирования base64, которые молча не принимают `\ n`s на входе? (Надеюсь нет, но кто знает ...) marcelm 7 лет назад 0
@marcelm в java, если строка base64 содержит `\ n`, декодер генерирует` java.lang.IllegalArgumentException: недопустимый символ base64 a` Tiina 7 лет назад 2
Кстати, в вашем примере цель base64 неясна, так как ввод - это уже текст ascii, поэтому base64 будет только без необходимости раздувать размер данных. Sarge Borsch 7 лет назад 0
Хотя примером мог быть ASCII, не совсем безопасно предполагать, что контент, которым занимается OP, всегда будет ASCII. kayleeFrye_onDeck 7 лет назад 0

2 ответа на вопрос

119
Kamil Maciorowski

Пытаться:

echo -n "apfjxkic-omyuobwd339805ak:60a06cd2ddfad610b9490d359d605407" | base64 -w 0

От man base64:

-w, --wrap=COLS
Обтекание закодированных строк после COLSсимвола (по умолчанию 76). Используйте 0для отключения переноса строк.

О, чувак, я всегда просто передавал это через `tr`. Приятно знать, что есть "правильный путь". Score_Under 7 лет назад 16
46
Score_Under

Это уступает ответу Камиля на системах, которые поддерживают -wопцию base64, но для случаев, когда это недоступно (например, Alpine Linux, initramfsхук Arch Linux и т. Д.), Вы можете вручную обработать вывод base64:

base64 some_file.txt | tr -d \\n

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

Похожие вопросы