Try:
echo -n "apfjxkic-omyuobwd339805ak:60a06cd2ddfad610b9490d359d605407" | base64 -w 0
From man base64:
-w,--wrap=COLS
Wrap encoded lines afterCOLScharacter (default76). Use0to disable line wrapping.
A likely reason for 76 being the default is that Base64 encoding was to provide a way to include binary files in e-mails and Usenet postings which was intended for humans using monitors with 80 characters width. Having a 76-character width as default made that usecase easier.
tr. Good to know there's a "proper way".
– Score_Under
Jul 03 '17 at 17:05
base64 encodes arbitrary binary data as text. Tools that expect text usually read one line at a time and may not deal with very long lines well. If -w 0 was the default, you would get by default just one line of text; an enormously long line if the input was large. It's better to wrap by default. I think 76 was chosen because it's little less than 80 which is a sort of de-facto standard for terminals.
– Kamil Maciorowski
Jul 25 '19 at 21:32
base64 command I needed to pass the -w 0 (and when I forgot, weird things can happen...), so this default behaviour was very strange to me.
– Dherik
Jul 25 '19 at 21:35
On systems where the -w option to base64 is not available (e.g. Alpine Linux, an Arch Linux initramfs hook, etc.), you can manually process the output of base64:
base64 some_file.txt | tr -d \\n
This is the brute-force approach; instead of getting the program to co-operate, I am using tr to indiscriminately strip every newline on stdout.
echo 'dGVzdAo=' | base64 -d | tr -d \\n | base64
– Aubrey Lavigne
Mar 16 '21 at 00:32
-w option, including MacOSX..
– nnsense
Nov 01 '21 at 20:05
So please use echo -n to remove the line break before redirecting to base64; and use base64 -w 0 to prevent base64 itself to add line break into the output.
me@host:~
$ echo -n mypassword | base64 -w 0
bXlwYXNzd29yZA==me@host:~ # <<<<<<<<<<<<<<< notice that no line break added after "==" due to '-w 0'; so me@host is on the same line
$ echo -n 'mypassword' | base64 -w 0
bXlwYXNzd29yZA==me@host:~ # <<<<<<<<<<<<<<<<<< notice adding single quotes does not affect output, so you can use values containing spaces freely
A good way to verify is using od -c to show the actual chars.
me@host:~
$ echo -n bXlwYXNzd29yZA== | base64 -d | od -c
0000000 m y p a s s w o r d
0000012
You see no "\n" is added. But if you use "echo" without "-n", od will show "\n":
me@host:~
$ echo mypassword | base64 -w 0
bXlwYXNzd29yZAo=me@host:~
$ echo bXlwYXNzd29yZAo= | base64 -d | od -c
0000000 m y p a s s w o r d \n
0000013
At last, create a function will help you in the future:
base64-encode() {
if [ -z "$@" ]; then
echo "Encode string with base64; echoing without line break, and base64 does not print line break neither, to not introducing extra chars while redirecting. Provide the string to encode. "
return 1
fi
echo -n "$@" | base64 -w 0 # here I suppose string if containing space is already quoted
}
For anyone using openssl base64, you can use the -A flag:
-A Process base64 data on one line (requires -a)
-a Perform base64 encoding/decoding (alias -base64)
The following worked for me:
echo -n '{string}' | openssl base64 -A
java.util.Base64implements it. – Tiina Jul 04 '17 at 06:23\ns in the input? (I hope not, but who knows...) – marcelm Jul 04 '17 at 21:19\n, decoder throwsjava.lang.IllegalArgumentException: Illegal base64 character a– Tiina Jul 05 '17 at 00:48java.util.Base64.getMime{Encoder,Decoder}()respectively adds linebreaks (CRLF) and accepts/removes them – dave_thompson_085 Nov 18 '22 at 04:08