base64エンコードされた文字列の末尾に=記号があるのはなぜですか


322

base64エンコードとは何かbase64、C#でエンコードを計算する方法は知っていますが、文字列をbase64に変換する=と、最後にがあることを何度か確認しました。

いくつかの質問が浮上しました:

  1. ないbase64文字列は、常にで終わりますか=
  2. なぜ=最後に追加されるのですか?

9
これはC#とはまったく関係ありません。
BoltClock

19
実際、これはc#に関連しています。すべての言語に=が含まれるわけではありません。たとえば、多くのperlライブラリは=を省略しているため、ユーザーが使用している環境を知ることは実際に重要です。
ジェイコブ

非常に検出可能であるため、場合によっては難読化の有効性が低くなるようです。
dgo 2017

6
@ user1167442 Base64は難読化用ではありません。これは、バイナリデータ(またはUnicodeやその他の特殊文字を含む文字列)を文字列として転送するためのものです。
NH。

回答:


270

それはパディングとして機能します

より完全な答えは、base64でエンコードされた文字列は常にで終わるわけではなく、適切な長さに文字列をパディングする必要がある場合に=のみ、1または2で終わるということ=です。


3
「パディング文字が必要になる1つのケースは、複数のBase64エンコードファイルを連結することです。」
アンドレ・Puel

1
@AndréPuel:単一の再同期で=十分です。境界を見つけたい場合は、ターミネーターが常に存在している必要があります(必要な文字は1つだけです)。Base64のパディングコンセプト全体は単なる頭脳です...
6502

5
ただし、そのリンクはbase64とはまったく関係ありません。
NH。

1
base64イラストや例を使って効率的にパディングすることを説明する、関連性のある信頼できるリンクが投稿されたことを願っています。ウィキペディアへの現在のリンクは、@ NHのように絶対に無関係です。言及した。
Fr0zenFyr

1
@ Fr0zenFyrリンクが必要な場合は、en.wikipedia.org / wiki / Base64#Output_paddingが最適です。しかし、バドル答えは本当に良いものです(まだ投票に追いついていません)。
NH。

313

1-いいえ

2-短い回答として:65番目の文字( "="記号)は、メッセージのエンコードの最終プロセスでの補足としてのみ使用されます。

文字列が3文字の倍数の数値を持っている場合、「=」記号はありません。これは、Base64エンコーディングがそれぞれ3バイト(8ビット)を取り、ASCII標準で4つの印刷可能な文字として表すためです。

詳細:

(a)エンコードしたい場合

ABCDEFG <=> [ ABC] [ DEF] [G

Base64最初のブロックと2番目のブロック(完成したもの)を処理(4文字を生成)しますが、3番目のブロックでは、==必要な4文字を完成させるために出力にdoubleを追加します。したがって 、結果は QUJD REVG Rwになります。 == (スペースなし)

(b)エンコードしたい場合...

ABCDEFGH <=> [ ABC] [ DEF] [GH

同様に、=出力の最後に1つだけ追加して4文字を取得し、結果は QUJD REVG R0g = (スペースなし)になります。


26
これは、他の回答やWikipediaよりも完全で明確であり、Wikipediaのリンクを指すだけである承認された回答よりも多くの投票に値するはずです。どうぞよろしくお願いいたします。賛成です!
ANewGuyInTown

2
@ANewGuyInTown受け入れられたソリューションのウィキペディアリンクは正しくありません。base64のパディングとは関係ありません。正しいページは、以下の
Fr0zenFyr


66

ウィキペディアから:

最後の「==」シーケンスは、最後のグループに1バイトしか含まれていないことを示し、「=」は2バイトが含まれていることを示しています。

したがって、これはある種のパディングです。


16
  1. 番号。
  2. 正しくデコードできるように、Base64でエンコードされた文字列を4文字の倍数の長さに埋め込む。

3
=最後にを削除し、これを100万個の文字列に対してテストしました。デコードは常に一致しています。
vivek_23

15

エンコードされたデータの最後に24ビット未満が使用可能な場合、RFC 2045で特別なパディング文字として定義されています。


11

等号(=)は、base64エンコーディングの特定の形式でパディングとして使用されます。Wikipediaの記事をbase64には、すべての詳細を持っています。


2
「==が1バイトで、「=」が2バイトである理由の論理を説明できますか?理解できません。入力方法:「どんな肉欲の喜び」。「YW55IGNhcm5hbCBwbGVhc3VyZS4 =」という結果を得ることができる一方で、「どんな肉欲の喜び」も「YW55IGNhcm5hbCBwbGVhc3VyZQ ==」という結果を得ることができますか?
2013年

14
「==」が1バイトで「=」が2バイトであるのは、そうではありません。それはあなたが常にあなたの全体の文字列に4バイトの倍数を持っている必要がある場合です。したがって、それが得られるまで「=」記号でパディングします。最初の文字列は2番目の文字列よりも1文字多いため、必要な「=」の埋め込みは1つ少なくなります。
Sam Holloway 2013年

2
この回答はコメントであるはずですか?
Fr0zenFyr

9

パディングです。http://en.wikipedia.org/wiki/Base64から:

理論的には、欠落バイト数はBase64の桁数から計算できるため、パディング文字はデコードに必要ありません。一部の実装では、パディング文字は必須ですが、他の実装では使用されません。パディング文字が必要となる1つのケースは、複数のBase64エンコードファイルを連結することです。


1
「パディング文字が必要になる1つのケースは、複数のBase64エンコードファイルを連結すること」に関する部分です。間違っている。たとえば、各ファイルのソースバイトが3バイト長である2つのbase64ファイルを連結する場合、base64文字列は4文字長で、パディングバイトはありません。これら2つのbase64文字列を連結する場合、連結された文字列に基づいてsoleyが開始および停止する場所を特定する方法はありません。したがって、base64パディングを使用してそれを支援することはできません。この問題は3で割り切れるバイト長の任意のファイルのために存在します
ロン・C

1
私はそれが最終的な結果が入力の連結でなければならない場合を意味すると思います。たとえばdecode(encode(A)+encode(B))=A+B、パディングは使用できますが、パディングは使用できません。
Thomas Leonard

おそらくしかし、そのような制限された使用は、エンコードされた文字列が一緒に連結されるときにエンコードされた文字列を分離する一般的なケースでパディング文字に依存することを許可しません。私はそれをそのように使用できると考えている開発者を助けるためだけに言及します。
ロンC

1
私はあなたの反対が本当にパディングとデリミタの概念の違いを強調していると思います。連結の結果には、通常、それを元に戻すのに十分な情報が含まれているとは考えられていません。「c3dpenpsZXJz」が元々「c3dpenps」+「ZXJz」だったか「c3dp」+「enpsZXJz」だったかはわかりません。しかし、「swizzlers」が元々「swi」+「zzlers」だったのか、「swizzl」+「ers」だったのかもわかりません。
GargantuChet 2017

1
関連するBase64パディング回答から私のコメントをコピーする:> Base64連結['='パディング付き]により、エンコーダーはチャンクサイズを3の倍数に揃える負担なしに、大きなチャンクを並列に処理できます。同様に、実装の詳細として、3の倍数ではないサイズの内部データバッファーをフラッシュする必要があるエンコーダーがそこにある場合があります。
Andre D

7

http://www.hcidata.info/base64.htm

「メアリー・ハッド」をBase 64にエンコード

この例では、単純なテキスト文字列( "Mary had")を使用していますが、データが何であっても(グラフィックファイルなど)原則は保持されます。入力データの各24ビットを32ビットの出力に変換するために、Base 64エンコーディングは24ビットを6ビットの4つのチャンクに分割します。私たちが最初に気づく問題は、「メアリーがいた」が3バイトの倍数ではなく、8バイトの長さであるということです。このため、最後のビットグループは4ビットのみです。これを修正するには、「0」のビットを2つ追加し、最後に「=」を置くことでこの事実を思い出します。Base 64に変換されるテキスト文字列が7バイト長の場合、最後のグループは2ビットでした。この場合、「0」の4つのビットを追加し、最後に「==」を置くことでこの事実を覚えています。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.