文字列のbase64に「\ n」が含まれているのはなぜですか？

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

出力にはbeforeがありNw==ます。Linuxでbase64を生成する正しい方法は何ですか？

base64

— ティーナ
ソース

出力に改行が含まれており、ウィンドウの折り返しだけではありませんか？このコマンドは、Macでうまく機能しました。どのOSを使用していますか？

— イアン

Base64を定義したRFC 2045では、76文字（最大）の後に改行が必要です。あなたの例が正しい方法ではないと思う理由は何ですか？

— –MSalters

@MSalters RFC 4648 は、特にこの問題に対処しています。このドキュメントを参照する仕様が、特定の文字数の後に改行を追加するように明示的にベースエンコーダーに指示しない限り、実装はベースエンコードデータに改行を追加してはなりません。=>この実装は、「プレーンな」base64エンコード出力を生成することを主張している限り、RFC 4648に応じて正しくありません。さらに興味深いことに、GNU base64（疑問？）のマンページは、RFC 3548を具体的に参照しています。RFC3548では、デフォルトでラッピングも指定されておらず、RFC 4648は廃止されています。

— ボブ

@Bob：RFCのAPIの安定性に対する敬意はやや劣ります。base64ツールは、スクリプトを壊さずに出力形式を変更することはできません。

— –MSalters

@MSalters古いバージョンが存在しないことは確信できませんが、GNU base64は2004年に記述され、AFAICTは常にRFC 3548に従うと主張しました。RFC3548には同じ「MUST NOT add line feeds」節が含まれます。したがって、元の実装でさえ「間違っていました」。少なくとも、その実装はドキュメントと一致しません。とにかく、OPの例が正しい理由を尋ね、RFCを参照しました。私の応答は、実際にbase64を単独で定義する正しいRFCです。あなたの答えが「歴史的な理由」である場合、そうですが、ここでOPは間違っていません。

— ボブ

回答:

151

試してください：

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

からman base64：

-w、--wrap=COLS
エンコードされた行をCOLS文字の後にラップします（デフォルト76）。0行の折り返しを無効にするために使用します。

— カミル・マシオロウスキ
ソース

ああ、私はいつもこれをパイプでつないでいたtr。「適切な方法」があることを知っておくと良いでしょう。

— Score_Under

デフォルト値がゼロでない理由についての説明は、私にとって謎です。

— デリック

@Dherik テキスト処理ツールに対する礼儀だと思います。base64任意のバイナリデータをテキストとしてエンコードします。テキストを期待するツールは、通常、一度に1行を読み取り、非常に長い行をうまく処理できない場合があります。-w 0がデフォルトだった場合、デフォルトでテキストが1行だけ表示されます。入力が大きい場合、非常に長い行。デフォルトでラップする方が適切です。それが端末の一種の事実上の標準である76よりも少し少ないため、私は選ばれたと思います。80

— カミル・マシオロウスキ

@KamilMaciorowski情報ありがとうございます。base64コマンドを使用するたびに、渡す必要がありました-w 0（そして、忘れてしまったとき、奇妙なことが起こる可能性があります...）、このデフォルトの動作は私にとって非常に奇妙でした。

— デリック

これは、の-wオプションをサポートするシステムでのKamilの回答に劣りますがbase64、それが利用できない場合（Alpine Linux、Arch Linux initramfsフックなど）、base64の出力を手動で処理できます。

base64 some_file.txt | tr -d \\n

これはブルートフォースアプローチです。プログラムを協力させるのではなく、tr標準出力のすべての改行を無差別に削除するために使用しています。

— Score_Under
ソース