Чому base64 рядка містить "\ n"?

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

Вихід має повернення раніше Nw==. Який правильний спосіб генерувати base64 в Linux?

base64

— Тіна
джерело

Ви впевнені, що результат містить новий рядок, і це не лише обгортання вікна? Ця команда добре працювала для мене на Mac. Яку ОС ви використовуєте?

— Ян

RFC 2045, який визначає Base64, ПОТРІБНО вимагає нового рядка після 76 символів (макс.) Що змушує вас вважати, що ваш приклад не є правильним?

— MSalters

@MSalters RFC 4648 спеціально вирішує це питання. Реалізації НЕ ПОВИННІ додавати канали рядків до кодованих базовими даними, якщо специфікація, що посилається на цей документ, прямо не спрямовує базові кодери до додавання каналів рядків після певної кількості символів. => ця реалізація є некоректною згідно з RFC 4648, якщо вона стверджує, що дає "звичайний" вихід64-кодований вихід. Що ще цікавіше, GNU base64 (йдеться про питання?) Спеціально посилається на RFC 3548, який також вказує відсутність обгортання за замовчуванням і який RFC 4648 застаріває.

— Боб

@Bob: RFC мають трохи менше поваги до стабільності API; інструмент base64 не може просто змінити вихідний формат, не порушуючи сценарії.

— MSalters

@MSalters Я не можу бути впевнений, що старіша версія не існує, але GNU base64 був написаний у 2004 році, і AFAICT завжди стверджував, що дотримується RFC 3548. RFC 3548 містить той самий пункт "НЕ МОЖЕ додавати канали рядків". Тож навіть оригінальна реалізація була "неправильною". Принаймні, його реалізація не відповідає його документації. У будь-якому випадку ви запитали, чому приклад ОП є правильним, і посилаєтесь на RFC; моя відповідь - правильний RFC, який фактично визначає base64 ізольовано. Якщо ваша відповідь "з історичних причин", так і нехай, але ОП тут не помиляється.

— Боб

Відповіді:

151

Спробуйте:

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

Від man base64:

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

— Каміль Маціоровський
джерело

О людино, я завжди просто пропускав це tr. Приємно знати, що існує "правильний шлях".

— Score_Under

Пояснення, чому значення за замовчуванням не дорівнює нулю, для мене є загадкою.

— Дерік

@Dherik Я думаю, що це ввічливість щодо інструментів для обробки тексту. base64кодує довільні двійкові дані як текст. Інструменти, які очікують текст, зазвичай читають по одному рядку і можуть не справлятися з дуже довгими рядками . Якби -w 0за замовчуванням ви отримали за замовчуванням лише один рядок тексту; надзвичайно довгий рядок, якщо вхід був великий. Краще загортати за замовчуванням. Я думаю, що 76його обрали тому, що це менше, ніж те, 80що є своєрідним де-факто стандартом для терміналів .

— Каміль Маціоровський

@KamilMaciorowski дякую за інформацію. Щоразу, коли я використовував потрібну base64мені команду для передачі -w 0(і коли я забув, можуть статися дивні речі ...), тож ця поведінка за замовчуванням була мені дуже дивною.

— Дерік

Це поступається відповіді Каміля в системах, які підтримують -wможливість base64, але у випадках, коли це недоступно (наприклад, Alpine Linux, initramfsгак Arch Linux тощо), ви можете вручну обробити вихід бази64:

base64 some_file.txt | tr -d \\n

Це підхід грубої сили; замість того, щоб змусити програму співпрацювати, я використовую trбез розбору смужку кожного нового рядка на stdout.

— Score_Under
джерело