Perché la base64 di una stringa contiene "\ n"?

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

L'output ha un ritorno prima Nw==. Qual è il modo corretto di generare base64 in Linux?

base64

— Tiina
fonte

Sei sicuro che l'output contenga una nuova riga e non si tratti solo del wrapping della finestra? Quel comando ha funzionato bene per me su Mac. Quale sistema operativo stai usando?

— Ian,

RFC 2045, che ha definito Base64, RICHIEDE una nuova riga dopo 76 caratteri (max). Cosa ti fa pensare che il tuo esempio non sia il modo corretto?

— Salterio

@MSalters RFC 4648 risolve specificamente questo problema. Le implementazioni NON DEVONO aggiungere feed di riga ai dati codificati in base a meno che la specifica che fa riferimento a questo documento non indichi esplicitamente ai codificatori di base di aggiungere feed di riga dopo un numero specifico di caratteri. => questa implementazione non è corretta secondo RFC 4648, purché pretenda di produrre output con codifica base64 "semplice". Ancora più interessante, le manpage GNU base64 (in questione?) Si riferiscono specificamente a RFC 3548, che specifica anche nessun avvolgimento di default e quali RFC 4648 oscilla.

— Bob

@Bob: gli RFC hanno un po 'meno rispetto per la stabilità delle API; uno strumento base64 non può semplicemente cambiare il formato di output senza interrompere gli script.

— MSalters il

@MSalters Non posso essere certo che non esista una versione precedente, ma GNU base64 è stato scritto nel 2004 e AFAICT ha sempre affermato di seguire RFC 3548. RFC 3548 contiene la stessa clausola "DEVE NON aggiungere feed di riga". Quindi anche l'implementazione originale era "sbagliata". Per lo meno, la sua implementazione non corrisponde alla sua documentazione. Ad ogni modo, hai chiesto perché l'esempio di OP è corretto e hai fatto riferimento a un RFC; la mia risposta è la RFC corretta che in realtà definisce base64 in isolamento. Se la tua risposta è "per motivi storici", così sia, ma OP non è sbagliato qui.

— Bob

Risposte:

151

Provare:

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

Da man base64:

-w, --wrap=COLS
Avvolgere le righe codificate dopo il COLScarattere (impostazione predefinita 76). Utilizzare 0per disabilitare il ritorno a capo.

— Kamil Maciorowski
fonte

Oh amico, l'ho sempre convalidato tr. Buono a sapersi che esiste un "modo corretto".

— Score_Under

La spiegazione del perché il valore predefinito non è zero è un mistero per me.

— Dherik, il

@Dherik Immagino sia per gentile concessione degli strumenti di elaborazione del testo. base64codifica dati binari arbitrari come testo. Gli strumenti che prevedono il testo di solito leggono una riga alla volta e potrebbero non gestire bene le righe molto lunghe . Se -w 0fosse l'impostazione predefinita, otterresti per impostazione predefinita solo una riga di testo; una linea enormemente lunga se l'input era grande. È meglio avvolgere per impostazione predefinita. Penso che sia 76stato scelto perché è poco meno di quello 80che è una sorta di standard di fatto per i terminali .

— Kamil Maciorowski il

@KamilMaciorowski grazie per le informazioni. Ogni volta che ho usato il base64comando avevo bisogno di passare il -w 0(e quando ho dimenticato, possono accadere cose strane ...), quindi questo comportamento predefinito è stato molto strano per me.

— Dherik, il

Ciò è inferiore alla risposta di Kamil sui sistemi che supportano l' -wopzione base64, ma per i casi in cui ciò non è disponibile (ad es. Alpine Linux, un initramfshook Arch Linux , ecc.), È possibile elaborare manualmente l'output di base64:

base64 some_file.txt | tr -d \\n

Questo è l'approccio della forza bruta; invece di far cooperare il programma, sto usando trper spogliare indiscriminatamente ogni nuova riga su stdout.

— Score_Under
fonte