字符串的base64为什么包含“ \ n”？

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

输出的返回值为before Nw==。在Linux中生成base64的正确方法是什么？

base64

— 蒂纳·
source

您确定输出包含换行符，而不仅仅是换行吗？在Mac上，该命令对我来说效果很好。您正在使用什么操作系统？

— 伊恩（Ian）2007年

定义Base64的RFC 2045在76个字符（最多）之后需要换行。是什么让您认为您的榜样不正确？

— MSalters

@MSalters RFC 4648专门解决了该问题。实现必须禁止在基本编码数据中添加换行符，除非参考本文档的规范明确指示基本编码器在特定数量的字符后添加换行符。=>根据RFC 4648，此实现是不正确的，只要它声称会产生“普通” base64编码的输出即可。更有趣的是，GNU base64（有疑问吗？）联机帮助页专门引用了RFC 3548，该默认情况下也未指定任何包装，而RFC 4648已过时。

— 鲍勃（Bob）

@Bob：RFC对API稳定性的重视程度较低；base64工具不能不破坏脚本而只是改变其输出格式。

— MSalters

@MSalters我不能肯定不存在较旧的版本，但是GNU base64编写于2004年，AFAICT一直声称遵循RFC3548。RFC3548包含相同的“不得添加换行符”子句。因此，即使最初的实现也是“错误的”。至少，其实现与文档不匹配。无论如何，您都询问了OP的示例为什么正确并引用了RFC。我的回答是正确地定义了base64的正确RFC。如果您的回答是“出于历史原因”，就这样吧，但是OP在这里并没有错。

— 鲍勃

Answers:

150

尝试：

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

来自man base64：

-w，--wrap=COLS
在COLS字符后包裹编码的行（默认值76）。使用0禁用自动换行。

— 卡米尔·马乔洛夫斯基（Kamil Maciorowski）
source

噢，老兄，我总是把它吹过去tr。很高兴知道有一种“正确的方法”。

— Score_

为什么默认值不为零的解释对我来说是个谜。

— Dherik

@Dherik我想这是对文本处理工具的礼貌。base64将任意二进制数据编码为文本。预期文本的工具通常一次只能读取一行，而可能无法很好地处理很长的行。如果-w 0是默认值，则默认情况下您将只获得一行文本；如果输入很大，则行会非常长。最好默认包装。我认为76之所以选择它80，是因为它比终端的事实上的标准少得多。

— 卡米尔Maciorowski

@KamilMaciorowski谢谢您提供的信息。每次使用该base64命令时，我都需要传递-w 0（并且当我忘记时，可能会发生奇怪的事情...），因此这种默认行为对我来说很奇怪。

— Dherik

这不如Kamil在支持的-w选项的系统上的回答逊色base64，但是对于不可用的情况（例如Alpine Linux，Arch Linux initramfs钩子等），您可以手动处理base64的输出：

base64 some_file.txt | tr -d \\n

这是蛮力的方法；我tr习惯于不加选择地剥离标准输出上的每个换行符，而不是让程序进行合作。

— Score_Under
source