Mengapa string yang disandikan base64 memiliki tanda = di bagian akhir


322

Saya tahu apa itu base64pengkodean dan bagaimana menghitung base64pengkodean dalam C #, namun saya telah melihat beberapa kali bahwa ketika saya mengubah string menjadi base64, ada =pada akhirnya.

Beberapa pertanyaan muncul:

  1. Apakah base64senar selalu diakhiri =?
  2. Mengapa =bisa ditambahkan pada akhirnya?

9
Ini sama sekali tidak ada hubungannya dengan C #.
BoltClock

19
Sebenarnya ini terkait dengan c #, tidak semua bahasa akan menyertakan =, misalnya banyak perpustakaan perl menghilangkan =, jadi mengetahui lingkungan yang digunakan pengguna sebenarnya relevan.
Jacob

Sepertinya ini membuatnya menjadi metode kebingungan yang kurang efektif dalam beberapa kasus karena cukup terdeteksi.
Lakukan

6
@ user1167442 Base64 bukan untuk kebingungan. Ini untuk mengangkut data biner (atau string dengan unicode dan karakter khusus lainnya) sebagai string.
NH.

Jawaban:


270

Ini berfungsi sebagai bantalan .

Jawaban yang lebih lengkap adalah bahwa string yang disandikan base64 tidak selalu berakhir dengan a =, itu hanya akan berakhir dengan satu atau dua =jika mereka diminta untuk memasukkan string ke panjang yang tepat.


3
"Satu kasus di mana karakter padding diperlukan adalah menyatukan beberapa file yang disandikan Base64."
André Puel

1
@ AndréPuel: menyelaraskan kembali satu pun =sudah cukup. Jika Anda ingin menemukan batasan kembali maka terminator harus selalu ada (dan masih hanya satu karakter yang diperlukan). Konsep padding keseluruhan dari Base64 hanyalah sebuah pemikiran ...
6502

5
Tautan itu benar-benar tidak relevan dengan base64.
NH.

1
Saya hanya berharap tautan yang relevan dan andal telah diposting yang menjelaskan tentang pengisian secara base64efisien dengan ilustrasi dan contoh. Tautan saat ini ke wikipedia sama sekali tidak relevan seperti @NH. tersebut.
Fr0zenFyr

1
@ Fr0zenFyr Jika Anda menginginkan tautan, en.wikipedia.org/wiki/Base64#Output_padding cukup bagus. Tetapi jawaban oleh Badr benar-benar lebih baik (hanya belum mendapatkan suara).
NH.

313

1-Tidak

2- Sebagai jawaban singkat: Karakter ke-65 ("=" tanda) hanya digunakan sebagai pelengkap dalam proses akhir penyandian pesan.

Anda tidak akan memiliki tanda '=' jika string Anda memiliki kelipatan angka 3 karakter, karena Base64pengodean mengambil masing-masing tiga byte (8bits) dan mewakili mereka sebagai empat karakter yang dapat dicetak dalam standar ASCII.

Detail:

(Sebuah) Jika Anda ingin menyandikan

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

Base64akan menangani (menghasilkan 4 karakter) dengan blok pertama dan yang kedua (setelah selesai) tetapi untuk yang ketiga akan menambahkan dua kali lipat ==dalam output untuk menyelesaikan 4 karakter yang diperlukan. Jadi, hasilnya akan QUJD REVG Rw == (tanpa spasi)

(b) Jika Anda ingin menyandikan ...

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

Demikian pula, itu akan menambahkan hanya satu =di akhir output untuk mendapatkan 4 karakter hasilnya akan QUJD REVG R0g = (tanpa spasi)


26
Ini lebih lengkap dan jelas daripada jawaban lain dan bahkan Wikipedia dan harus mendapatkan lebih banyak suara daripada jawaban yang diterima yang tidak lain menunjukkan tautan wikipedia. Kudos untuk Anda! Terpilih!
ANewGuyInTown

2
@ ANewGuyInTown tautan wikipedia dalam solusi yang diterima salah, itu tidak ada hubungannya dengan padding pada base64. Halaman yang benar dikaitkan oleh Legolas dalam jawabannya di bawah ini
Fr0zenFyr


66

Dari Wikipedia :

Urutan '==' akhir menunjukkan bahwa grup terakhir hanya berisi satu byte, dan '=' menunjukkan bahwa itu berisi dua byte.

Jadi, ini semacam padding.


16
  1. Tidak.
  2. Untuk menyambung string yang disandikan Base64 ke kelipatan 4 karakter, sehingga dapat didekodekan dengan benar.

3
Saya menghapus =di akhir dan menguji ini untuk 1 juta string. Penguraiannya selalu cocok.
vivek_23

15

Ini didefinisikan dalam RFC 2045 sebagai karakter padding khusus jika kurang dari 24 bit tersedia di akhir data yang disandikan.


11

Tanda sama dengan (=) digunakan sebagai pengisi dalam bentuk pengkodean base64 tertentu. The artikel Wikipedia pada base64 memiliki semua rincian.


2
Bisakah Anda menjelaskan logika mengapa "==" adalah 1 byte dan "=" adalah 2 byte? Saya tidak bisa memahaminya. Bagaimana bisa input: "kesenangan duniawi." bisa mendapatkan hasil "YW55IGNhcm5hbCBwbGVhc3VyZS4 =", sementara "kesenangan duniawi" bisa mendapatkan hasil "YW55IGNhcm5hbCBwbGVhc3VyZQ =="?
null

14
Bukan berarti '==' adalah 1 byte dan '=' adalah 2 byte. Itu kasus yang Anda butuhkan untuk selalu memiliki kelipatan 4 byte di seluruh string Anda. Jadi Anda pad dengan tanda '=' sampai Anda mendapatkannya. String pertama memiliki satu karakter lebih dari string kedua, sehingga dibutuhkan satu 'padding' yang lebih sedikit.
Sam Holloway

2
Apakah jawaban ini seharusnya menjadi komentar?
Fr0zenFyr

9

Ini padding. Dari http://en.wikipedia.org/wiki/Base64 :

Secara teori, karakter padding tidak diperlukan untuk decoding, karena jumlah byte yang hilang dapat dihitung dari jumlah digit Base64. Dalam beberapa implementasi, karakter padding adalah wajib, sedangkan untuk yang lain tidak digunakan. Satu kasus di mana karakter padding diperlukan adalah menyatukan beberapa file yang disandikan Base64.


1
Bagian tentang "Satu kasus di mana karakter padding diperlukan adalah menyatukan beberapa file yang disandikan Base64." salah. Misalnya ketika menggabungkan dua file base64 di mana byte sumber untuk setiap file adalah 3 byte panjang string base64 akan menjadi 4 karakter dan tidak memiliki padding byte. Ketika Anda menggabungkan dua string base64 ini, tidak akan ada cara untuk mengetahui di mana seseorang memulai dan satu berhenti berdasarkan satu-satunya pada string yang digabungkan. Jadi mengandalkan pad base64 untuk membantu dengan itu tidak akan berhasil. Masalah ini akan ada untuk file apa pun dengan panjang byte yang dapat habis dibagi 3.
Ron C

1
Saya kira itu berarti kasus di mana hasil akhir harus menjadi gabungan dari input. misalnya decode(encode(A)+encode(B))=A+Bbekerja dengan padding tetapi bukan tanpa.
Thomas Leonard

mungkin tetapi penggunaan terbatas seperti itu tidak memungkinkan char padding (s) untuk diandalkan untuk kasus umum memisahkan string yang dikodekan ketika string yang dikodekan digabungkan bersama-sama. Saya hanya menyebutkannya untuk membantu pengembang yang mungkin berpikir mereka dapat menggunakannya dengan cara itu.
Ron C

1
Saya pikir keberatan Anda hanya menyoroti perbedaan antara konsep padding dan delimiting. Hasil penggabungan umumnya tidak diharapkan untuk memasukkan informasi yang cukup untuk membuatnya reversibel. Anda tidak akan tahu apakah "c3dpenpsZXJz" awalnya "c3dpenps" + "ZXJz" atau "c3dp" + "enpsZXJz". Tetapi Anda juga tidak tahu apakah "swizzlers" pada awalnya "swi" + "zzlers" atau "swizzl" + "ers".
GargantuChet

1
Menyalin komentar saya dari jawaban padding Base64 terkait :> Rangkaian base64 [dengan '=' padding] memungkinkan pembuat enkode memproses potongan besar secara paralel tanpa beban menyelaraskan ukuran potongan ke kelipatan tiga. Demikian pula, sebagai detail implementasi, mungkin ada encoder di luar sana yang perlu menyiram buffer data internal dengan ukuran yang bukan kelipatan dari tiga.
Andre D

7

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

Pengkodean "Mary harus" ke Basis 64

Dalam contoh ini kita menggunakan string teks sederhana ("Mary punya") tetapi prinsipnya tetap berlaku apa pun datanya (misalnya file grafik). Untuk mengonversi setiap 24 bit data input menjadi 32 bit output, pengkodean Basis 64 membagi 24 bit menjadi 4 potongan 6 bit. Masalah pertama yang kita perhatikan adalah bahwa "Mary punya" bukan kelipatan 3 byte - panjangnya 8 byte. Karena ini, kelompok bit terakhir hanya 4 bit. Untuk mengatasinya, kami menambahkan dua bit ekstra '0' dan mengingat fakta ini dengan meletakkan '=' di akhir. Jika string teks yang akan dikonversi ke Base 64 adalah 7 byte panjang, grup terakhir akan memiliki 2 bit. Dalam hal ini kita akan menambahkan empat bit tambahan '0' dan mengingat fakta ini dengan meletakkan '==' di akhir.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.