Perché una stringa codificata in base64 ha un segno = alla fine


322

So cos'è la base64codifica e come calcolare la base64codifica in C #, tuttavia ho visto più volte che quando converto una stringa in base64, c'è un =alla fine.

Sono arrivate alcune domande:

  1. Una base64stringa finisce sempre con =?
  2. Perché =viene aggiunto alla fine?

9
Questo non ha assolutamente nulla a che fare con C #.
BoltClock

19
In realtà è correlato a c #, non tutte le lingue includeranno il =, ad esempio molte librerie perl omettono il =, quindi conoscere l'ambiente che l'utente sta usando è effettivamente rilevante.
Jacob,

In un certo senso sembra che questo lo renda un metodo di offuscamento meno efficace in alcuni casi in quanto è abbastanza rilevabile.
fatto il

6
@ user1167442 Base64 non è per offuscamento. Serve per trasportare dati binari (o stringhe con unicode e altri caratteri speciali) come stringa.
NH.

Risposte:


270

Serve come imbottitura .

Una risposta più completa è che una stringa codificata in base64 non termina sempre con una =, terminerà con una o due solo =se sono necessarie per riempire la stringa della lunghezza corretta.


3
"Un caso in cui sono richiesti i caratteri di riempimento è la concatenazione di più file con codifica Base64."
André Puel,

1
@ AndréPuel: risincronizzare un singolo =sarebbe sufficiente. Se vuoi ritrovare i confini allora dovrebbe sempre essere presente un terminatore (ed è necessario solo un carattere). L'intero concetto di imbottitura di Base64 è solo un brainfart ...
6502

5
Tuttavia, quel collegamento è completamente irrilevante per base64.
NH.

1
Vorrei solo che fosse pubblicato un link pertinente e affidabile che spiegasse in modo base64efficiente il riempimento con illustrazioni ed esempi. Il presente link a Wikipedia è assolutamente irrilevante come @NH. menzionato.
Fr0zenFir

1
@ Fr0zenFyr Se vuoi un link, en.wikipedia.org/wiki/Base64#Output_padding è abbastanza buono. Ma la risposta di Badr è davvero migliore (non ha ancora raggiunto i voti).
NH.

313

1-No

2- Come risposta breve: il 65 ° carattere (segno "=") viene utilizzato solo come complemento nel processo finale di codifica di un messaggio.

Non avrai un segno '=' se la tua stringa ha un numero multiplo di 3 caratteri, perché la Base64codifica prende ogni tre byte (8 bit) e li rappresenta come quattro caratteri stampabili nello standard ASCII.

Dettagli :

(a) Se si desidera codificare

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

Base64tratterà (producendo 4 caratteri) con il primo blocco e il secondo (man mano che sono completi) ma per il terzo aggiungerà un doppio ==nell'output per completare i 4 caratteri necessari. Pertanto, il risultato sarà QUJD REVG Rw == (senza spazio)

(b) Se si desidera codificare ...

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

Allo stesso modo, verrà aggiunto solo un singolo =alla fine dell'output per ottenere 4 caratteri, il risultato sarà QUJD REVG R0g = (senza spazio)


26
Questo è più completo e chiaro di altre risposte e persino di Wikipedia e dovrebbe meritare più voti rispetto alla risposta accettata che non fa altro che indicare il link di Wikipedia. Complimenti a te! Upvoted!
ANewGuyInTown

2
@ANewGuyInTown Il link di Wikipedia nella soluzione accettata non è corretto, non ha nulla a che fare con il riempimento su base64. La pagina corretta è stata collegata da Legolas nella sua risposta di seguito
Fr0zenFyr


66

Da Wikipedia :

La sequenza finale "==" indica che l'ultimo gruppo conteneva solo un byte e "=" indica che conteneva due byte.

Quindi, questa è una sorta di imbottitura.


16
  1. No.
  2. Per riempire la stringa codificata Base64 con un multiplo di 4 caratteri di lunghezza, in modo che possa essere decodificata correttamente.

3
=Alla fine l' ho rimosso e l'ho provato per 1 milione di stringhe. La decodifica corrispondeva sempre.
vivek_23

15

È definito in RFC 2045 come un carattere speciale di riempimento se sono disponibili meno di 24 bit alla fine dei dati codificati.


11

Il segno di uguale (=) viene utilizzato come riempimento in alcune forme di codifica base64. L' articolo di Wikipedia su base64 contiene tutti i dettagli.


2
Potresti spiegare la logica del perché "==" è 1 byte e "=" è 2 byte? Non riesco proprio a capirlo. Come mai input: "qualsiasi piacere carnale". potrebbe ottenere il risultato "YW55IGNhcm5hbCBwbGVhc3VyZS4 =", mentre "qualsiasi piacere carnale" potrebbe ottenere il risultato "YW55IGNhcm5hbCBwbGVhc3VyZQ =="?
null

14
Non è così che '==' è 1 byte e '=' è 2 byte. È necessario disporre sempre di un multiplo di 4 byte nell'intera stringa. Quindi rimuovi i segni '=' fino a quando non li ottieni. La prima stringa ha un carattere in più rispetto alla seconda stringa, quindi è richiesto un numero minore di '=' di riempimento.
Sam Holloway,

2
Questa risposta dovrebbe essere un commento?
Fr0zenFir

9

È imbottitura. Da http://en.wikipedia.org/wiki/Base64 :

In teoria, il carattere di riempimento non è necessario per la decodifica, poiché il numero di byte mancanti può essere calcolato dal numero di cifre Base64. In alcune implementazioni, il carattere di riempimento è obbligatorio, mentre per altri non viene utilizzato. Un caso in cui sono richiesti i caratteri di riempimento è la concatenazione di più file codificati Base64.


1
La parte relativa a "Un caso in cui sono richiesti i caratteri di riempimento è la concatenazione di più file codificati Base64". è sbagliato. Ad esempio, quando si concatenano due file base64 in cui i byte di origine per ciascun file sono lunghi 3 byte, le stringhe di base64 saranno lunghe 4 caratteri e non avranno byte di riempimento. Quando si concatenano queste due stringhe base64 non ci sarà modo di dire dove si inizia e si si ferma esclusivamente sulla stringa concatenata. Quindi fare affidamento sull'imbottitura base64 per aiutare con questo non funzionerà. Questo problema si presenterà per qualsiasi file con lunghezza in byte uniformemente divisibile per 3.
Ron C

1
Immagino significhi il caso in cui il risultato finale dovrebbe essere la concatenazione degli input. ad esempio decode(encode(A)+encode(B))=A+Bfunziona con imbottitura ma non senza.
Thomas Leonard,

forse, ma un uso così limitato non consente di fare affidamento sui caratteri di riempimento per il caso generale di separazione delle stringhe codificate quando le stringhe codificate vengono concatenate insieme. Lo dico solo per aiutare gli sviluppatori che potrebbero pensare di poterlo usare in quel modo.
Ron C,

1
Penso che la tua obiezione evidenzi davvero solo la differenza tra i concetti di imbottitura e delimitazione. I risultati della concatenazione non devono generalmente includere informazioni sufficienti per renderlo reversibile. Non saprai se "c3dpenpsZXJz" era originariamente "c3dpenps" + "ZXJz" o "c3dpenps + +" enpsZXJz ". Ma non sai nemmeno se "swizzlers" era originariamente "swi" + "zzlers" o "swizzl" + "ers".
GargantuChet,

1
Copiando il mio commento da una risposta di imbottitura Base64 correlata :> La concatenazione Base64 [con imbottitura '='] consente agli encoder di elaborare blocchi di grandi dimensioni in parallelo senza l'onere di allineare le dimensioni del blocco a un multiplo di tre. Allo stesso modo, come dettaglio di implementazione, potrebbe esserci un codificatore là fuori che deve svuotare un buffer di dati interno di una dimensione che non è un multiplo di tre.
Andre D,

7

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

Codifica di "Maria aveva" in Base 64

In questo esempio stiamo usando una semplice stringa di testo ("Mary had") ma il principio vale qualunque sia il dato (es. File grafico). Per convertire ogni 24 bit di dati di input in 32 bit di output, la codifica Base 64 divide i 24 bit in 4 blocchi di 6 bit. Il primo problema che notiamo è che "Mary was" non è un multiplo di 3 byte, è lungo 8 byte. Per questo motivo, l'ultimo gruppo di bit è lungo solo 4 bit. Per porre rimedio a questo, aggiungiamo due ulteriori bit di '0' e ricordiamo questo fatto mettendo un '=' alla fine. Se la stringa di testo da convertire in Base 64 fosse lunga 7 byte, l'ultimo gruppo avrebbe avuto 2 bit. In questo caso avremmo aggiunto altri quattro bit di '0' e ricorderemo questo fatto mettendo '==' alla fine.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.