Warum hat eine Base64-codierte Zeichenfolge am Ende ein = -Zeichen?

320

Ich weiß, was base64Codierung ist und wie die base64Codierung in C # berechnet wird. Ich habe jedoch mehrmals gesehen, dass beim Konvertieren eines Strings in base64 =am Ende ein Code steht .

Ein paar Fragen kamen auf:

Endet eine base64Zeichenfolge immer mit =?
Warum wird =am Ende ein angehängt?

encoding base64

— Santosh Singh
quelle

9

Dies hat absolut nichts mit C # zu tun.

— BoltClock

19

Tatsächlich hängt es mit c # zusammen, nicht alle Sprachen enthalten das =, zum Beispiel lassen viele Perl-Bibliotheken das = weg, sodass es tatsächlich relevant ist, die vom Benutzer verwendete Umgebung zu kennen.

— Jacob

Es scheint so, als ob es in einigen Fällen eine weniger effektive Methode zur Verschleierung ist, da es durchaus nachweisbar ist.

— dgo

6

@ user1167442 Base64 ist nicht zur Verschleierung. Es dient zum Transportieren von Binärdaten (oder Zeichenfolgen mit Unicode und anderen Sonderzeichen) als Zeichenfolge.

— NH.

268

Es dient als Polsterung .

Eine vollständigere Antwort ist, dass eine Base64-codierte Zeichenfolge nicht immer mit a endet =, sondern nur mit einer oder zwei, =wenn sie erforderlich sind, um die Zeichenfolge auf die richtige Länge aufzufüllen.

— Andrew Hare
quelle

3

"Ein Fall, in dem Füllzeichen erforderlich sind, ist die Verkettung mehrerer Base64-codierter Dateien."

— André Puel

1

@ AndréPuel: Eine einzige Synchronisierung =würde ausreichen. Wenn Sie die Grenzen zurückfinden möchten, sollte immer ein Terminator vorhanden sein (und es wird immer noch nur ein Zeichen benötigt). Das gesamte Polsterungskonzept von Base64 ist nur ein Brainfart ...

— 6502

5

Dieser Link ist für base64 jedoch völlig irrelevant.

— NH.

1

Ich wünschte nur, ein relevanter und zuverlässiger Link würde veröffentlicht, der das base64effiziente Auffüllen mit Abbildungen und Beispielen erklärt. Der vorliegende Link zu Wikipedia ist wie @NH absolut irrelevant. erwähnt.

— Fr0zenFyr

1

@ Fr0zenFyr Wenn Sie einen Link möchten, ist en.wikipedia.org/wiki/Base64#Output_padding ziemlich gut. Aber die Antwort von Badr ist wirklich besser (sie hat nur noch keine Stimmen eingeholt).

— NH.

309

1-Nr

2- Als kurze Antwort: Das 65. Zeichen ("=" Zeichen) wird nur als Ergänzung beim endgültigen Codierungsprozess einer Nachricht verwendet.

Sie haben kein '=' - Zeichen, wenn Ihre Zeichenfolge ein Vielfaches von 3 Zeichen hat, da die Base64Codierung jeweils drei Bytes (8 Bit) benötigt und diese im ASCII-Standard als vier druckbare Zeichen darstellt.

Einzelheiten :

(a) Wenn Sie codieren möchten

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

Base64behandelt (erzeugt 4 Zeichen) den ersten Block und den zweiten (da sie vollständig sind), aber für den dritten wird ein Doppel ==in der Ausgabe hinzugefügt , um die 4 benötigten Zeichen zu vervollständigen. Das Ergebnis ist also QUJD REVG Rw == (ohne Leerzeichen)

(b) Wenn Sie codieren möchten ...

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

In ähnlicher Weise wird =am Ende der Ausgabe nur eine einzige hinzugefügt , um 4 Zeichen zu erhalten. Das Ergebnis ist QUJD REVG R0g = (ohne Leerzeichen).

— Badr Bellaj
quelle

26

Dies ist vollständiger und klarer als andere Antworten und sogar Wikipedia und sollte mehr Stimmen verdienen als die akzeptierte Antwort, die nur auf den Wikipedia-Link verweist. Hut ab! Upvoted!

— ANewGuyInTown

2

@ANewGuyInTown Der Wikipedia-Link in der akzeptierten Lösung ist falsch. Er hat nichts mit dem Auffüllen von base64 zu tun. Die richtige Seite wurde von Legolas in seiner Antwort unten

— verlinkt

Eine weitere gute (IMHO) Antwort zum

— Thema

1

Ziemlich gute Erklärung 👌

— Jorge Wander Santana Ureña

66

Aus Wikipedia :

Die letzte Sequenz '==' gibt an, dass die letzte Gruppe nur ein Byte enthielt, und '=' gibt an, dass sie zwei Bytes enthielt.

Dies ist also eine Art Polsterung.

— Legolas
quelle

16

Nein.
So füllen Sie die Base64-codierte Zeichenfolge auf ein Vielfaches von 4 Zeichen auf, damit sie korrekt decodiert werden kann.

— Ian Kemp
quelle

3

Ich habe das =am Ende entfernt und dies für 1 Million Saiten getestet. Die Dekodierung stimmte immer überein.

— vivek_23

15

Es wird in RFC 2045 als spezielles Füllzeichen definiert, wenn am Ende der codierten Daten weniger als 24 Bit verfügbar sind.

— iandotkelly
quelle

1

Link zu tools.ietf.org/rfc/rfc2045.txt verschoben

— Tom Hundt

11

Das Gleichheitszeichen (=) wird in bestimmten Formen der Base64-Codierung als Auffüllung verwendet. Der Wikipedia-Artikel auf base64 enthält alle Details.

— Sam Holloway
quelle

2

Können Sie die Logik erklären, warum "==" 1 Byte und "=" 2 Byte ist? Ich kann es einfach nicht verstehen. Wie kommt es zu Eingaben: "Jedes fleischliche Vergnügen." könnte das Ergebnis "YW55IGNhcm5hbCBwbGVhc3VyZS4 =" erhalten, während "jedes fleischliche Vergnügen" das Ergebnis "YW55IGNhcm5hbCBwbGVhc3VyZQ ==" erhalten könnte?

— null

14

In diesem Fall ist '==' nicht 1 Byte und '=' 2 Byte. Es ist der Fall, dass Sie immer ein Vielfaches von 4 Bytes in Ihrer gesamten Zeichenfolge haben müssen. Sie füllen also mit '=' Zeichen, bis Sie das bekommen. Die erste Zeichenfolge hat ein Zeichen mehr als die zweite Zeichenfolge, sodass ein Auffüllen weniger '=' erforderlich ist.

— Sam Holloway

2

Soll diese Antwort ein Kommentar sein?

— Fr0zenFyr

9

Es ist Polsterung. Von http://en.wikipedia.org/wiki/Base64 :

Theoretisch wird das Füllzeichen für die Decodierung nicht benötigt, da die Anzahl der fehlenden Bytes aus der Anzahl der Base64-Ziffern berechnet werden kann. In einigen Implementierungen ist das Auffüllzeichen obligatorisch, in anderen wird es nicht verwendet. Ein Fall, in dem Füllzeichen erforderlich sind, ist das Verketten mehrerer Base64-codierter Dateien.

— Thomas Leonard
quelle

1

Der Teil über "Ein Fall, in dem Füllzeichen erforderlich sind, ist die Verkettung mehrerer Base64-codierter Dateien." ist falsch. Wenn Sie beispielsweise zwei base64-Dateien verketten, bei denen die Quellbytes für jede Datei 3 Byte lang sind, sind die base64-Zeichenfolgen 4 Zeichen lang und haben keine Auffüllbytes. Wenn Sie diese beiden base64-Zeichenfolgen verketten, können Sie nicht feststellen, wo eine auf der verketteten Zeichenfolge basiert und wo sie stoppt. Es wird also nicht funktionieren, sich auf das Base64-Padding zu verlassen, um dies zu unterstützen. Dieses Problem tritt für jede Datei mit Bytelängen auf, die gleichmäßig durch 3 teilbar sind.

— Ron C

1

Ich denke, es bedeutet den Fall, dass das Endergebnis die Verkettung der Eingaben sein sollte. zB decode(encode(A)+encode(B))=A+Bfunktioniert mit Polsterung aber nicht ohne.

— Thomas Leonard

Vielleicht, aber eine solche eingeschränkte Verwendung erlaubt es nicht, sich auf die Auffüllzeichen für den allgemeinen Fall des Trennens codierter Zeichenfolgen zu verlassen, wenn die codierten Zeichenfolgen miteinander verkettet sind. Ich erwähne es nur, um Entwicklern zu helfen, die vielleicht denken, dass sie es so verwenden können.

— Ron C

1

Ich denke, Ihr Einwand hebt wirklich nur den Unterschied zwischen den Konzepten Polsterung und Abgrenzung hervor. Es wird im Allgemeinen nicht erwartet, dass die Ergebnisse der Verkettung genügend Informationen enthalten, um sie umkehrbar zu machen. Sie werden nicht wissen, ob "c3dpenpsZXJz" ursprünglich "c3dpenps" + "ZXJz" oder "c3dp" + "enpsZXJz" war. Sie wissen aber auch nicht, ob "swizzlers" ursprünglich "swi" + "zzlers" oder "swizzl" + "ers" war.

— GargantuChet

1

Durch Kopieren meines Kommentars aus einer verwandten Base64-Padding-Antwort :> Mit der Base64-Verkettung [mit '=' Padding] können Encoder große Chunks parallel verarbeiten, ohne die Chunk-Größen auf ein Vielfaches von drei ausrichten zu müssen. In ähnlicher Weise könnte es als Implementierungsdetail einen Encoder geben, der einen internen Datenpuffer mit einer Größe leeren muss, die kein Vielfaches von drei ist.

— Andre D

7

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

Codierung von "Mary had" in Base 64

In diesem Beispiel verwenden wir eine einfache Textzeichenfolge ("Mary had"), aber das Prinzip gilt unabhängig von den Daten (z. B. Grafikdatei). Um jeweils 24 Bit Eingabedaten in 32 Bit Ausgabe umzuwandeln, teilt die Base 64-Codierung die 24 Bit in 4 Blöcke zu 6 Bit auf. Das erste Problem, das wir bemerken, ist, dass "Mary had" kein Vielfaches von 3 Bytes ist - es ist 8 Bytes lang. Aus diesem Grund ist die letzte Gruppe von Bits nur 4 Bits lang. Um dies zu beheben, fügen wir zwei zusätzliche Bits von '0' hinzu und erinnern uns an diese Tatsache, indem wir am Ende ein '=' setzen. Wenn die in Base 64 zu konvertierende Textzeichenfolge 7 Byte lang gewesen wäre, hätte die letzte Gruppe 2 Bits gehabt. In diesem Fall hätten wir vier zusätzliche Bits von '0' hinzugefügt und uns an diese Tatsache erinnert, indem wir am Ende '==' gesetzt hätten.

— Dev
quelle