$ echo -n "apfjxkic-omyuobwd339805ak:60a06cd2ddfad610b9490d359d605407" | base64
YXBmanhraWMtb215dW9id2QzMzk4MDVhazo2MGEwNmNkMmRkZmFkNjEwYjk0OTBkMzU5ZDYwNTQw
Nw==
Выход имеет возврат раньше Nw==
. Как правильно генерировать base64 в Linux?
5
Вы уверены, что вывод содержит новую строку, и это не просто перенос окна? Эта команда отлично работала для меня на Mac. Какую ОС вы используете?
—
Ян
RFC 2045, который определил Base64, ТРЕБУЕТ перевод строки после 76 символов (макс.). Что заставляет вас думать, что ваш пример не правильный путь?
—
MSalters
@MSalters RFC 4648 специально решает эту проблему. Реализации НЕ ДОЛЖНЫ добавлять переводы строки к базовым кодированным данным, если только спецификация, ссылающаяся на этот документ, явно не предписывает базовым кодировщикам добавлять переводы строк после определенного количества символов. => эта реализация неверна в соответствии с RFC 4648, если она заявляет, что производит «простой» base64-кодированный вывод. Более интересно то, что руководства GNU base64 (в вопросе?) Конкретно ссылаются на RFC 3548, который также не определяет перенос по умолчанию и который RFC 4648 устарел.
—
Боб
@Bob: RFC немного меньше уважают стабильность API; инструмент base64 не может просто изменить свой формат вывода, не нарушая сценарии.
—
MSalters
@MSalters Я не могу быть уверен, что более старой версии не существует, но GNU base64 был написан в 2004 году, и AFAICT всегда утверждал, что следует RFC 3548. RFC 3548 содержит то же самое предложение «НЕ ДОЛЖНО добавлять переводы строк». Так что даже оригинальная реализация была «неправильной». По крайней мере, его реализация не соответствует документации. В любом случае, вы спросили, почему пример OP верен и ссылаются на RFC; Мой ответ - правильный RFC, который фактически определяет base64 изолированно. Если ваш ответ «по историческим причинам», пусть будет так, но ОП здесь не так.
—
Боб