$ echo -n "apfjxkic-omyuobwd339805ak:60a06cd2ddfad610b9490d359d605407" | base64
YXBmanhraWMtb215dW9id2QzMzk4MDVhazo2MGEwNmNkMmRkZmFkNjEwYjk0OTBkMzU5ZDYwNTQw
Nw==
输出在
Nw==之前有返回值。在Linux中生成base64的正确方法是什么？
#1 楼
试试：echo -n "apfjxkic-omyuobwd339805ak:60a06cd2ddfad610b9490d359d605407" | base64 -w 0
从
man base64：-w，--wrap=COLS 在
COLS字符后换行编码的行（默认为76 ）。使用0禁用换行。76默认是一个可能的原因是Base64编码旨在提供一种在电子邮件和Usenet帖子中包含二进制文件的方法对于使用宽度为80个字符的显示器的用户。默认具有76个字符的宽度使该用例更加容易。评论
哦，老兄，我总是把它通过tr来传送。很高兴知道有一种“正确的方法”。
–Score_Under
17年7月3日在17:05
为什么默认值不为零的解释对我来说还是一个谜。
– Dherik
19年7月25日在21:01
@Dherik我想这是对文本处理工具的礼貌。 base64将任意二进制数据编码为文本。预期文本的工具通常一次只能读取一行，而可能无法很好地处理很长的行。如果-w 0是默认值，则默认情况下您将只获得一行文本；如果输入很大，则行会非常长。最好默认包装。我认为之所以选择76，是因为它略低于80，这是一种事实上的终端标准。
–卡米尔·马乔洛夫斯基（Kamil Maciorowski）
19年7月25日在21:32
@KamilMaciorowski谢谢您提供的信息。每次我使用base64命令时，都需要传递-w 0（并且当我忘记时，可能会发生奇怪的事情……），所以这种默认行为对我来说很奇怪。
– Dherik
19年7月25日在21:35
@Dherik一个可能的原因是base64编码提供了一种在电子邮件和Usenet帖子中包含二进制文件的方法，该方法旨在供使用80个字符宽度的显示器的用户使用。默认使用76个字符的宽度使该用例更加容易。
–索比昂·拉文·安德森（ThorbjørnRavn Andersen）
20年1月20日在6:19
#2 楼
在支持-w的base64选项的系统上，这不如Kamil的回答，但是对于那些不可用的情况（例如Alpine Linux，Arch Linux initramfs钩子等），您可以手动处理base64的输出： /> base64 some_file.txt | tr -d \n
这是蛮力的方法；我没有使用程序来合作，而是使用
tr随意删除stdout上的每个换行符。评论
如果可用，请务必使用锤子。
– dna
20-09-16在11:56
评论
您确定输出包含换行符，而不仅仅是换行吗？该命令对我在Mac上正常工作。您正在使用什么操作系统？定义Base64的RFC 2045，必须在76个字符（最多）之后使用换行符。是什么让您认为自己的榜样不正确？
@MSalters RFC 4648专门解决了该问题。实现必须禁止在基本编码数据中添加换行符，除非参考本文档的规范明确指示基本编码器在特定数量的字符后添加换行符。 =>根据RFC 4648，此实现是不正确的，只要它声称会产生“普通” base64编码的输出即可。更有趣的是，GNU base64（有问题吗？）联机帮助页专门引用了RFC 3548，默认情况下它也未指定任何换行，而RFC 4648已过时。
@Bob：RFC对API稳定性的重视程度较低； base64工具不能不破坏脚本而只是改变其输出格式。
@MSalters我不能肯定不存在较旧的版本，但是GNU base64编写于2004年，AFAICT一直声称遵循RFC3548。RFC3548包含相同的“不得添加换行符”子句。因此，即使最初的实现也是“错误的”。至少，其实现与文档不匹配。无论如何，您都询问了OP的示例为什么正确并引用了RFC。我的回答是正确地定义了base64的正确RFC。如果您的答案是“出于历史原因”，就这样吧，但是OP在这里并没有错。