Mengapa Base64 menjadikan fail lebih besar?

Rencana ini menerangkan mengapa output Base64 lebih besar daripada bait asal. Ia bukan panduan keselamatan. Jika anda perlu membezakan pengekodan dengan penyulitan, gunakan Base64 bukan penyulitan: apa yang sebenarnya dilakukannya.

Mengapa Base64 memerlukan lebih ruang?

3 bait ialah 24 bit. Base64 membahagi 24 bit itu kepada 4 kumpulan 6 bit. Setiap kumpulan dipetakan kepada satu aksara Base64, jadi 3 bait input menjadi 4 aksara output. Disimpan sebagai 1 bait setiap aksara ASCII, itu 4 / 3 ≈ 1.333 — peningkatan kira-kira 33.3%.

• 3 bait (24 bit)
• ↓
• Dibahagi kepada 4 kumpulan 6 bit
• Setiap kumpulan → satu aksara Base64
• ↓
• 4 aksara (selalunya 4 bait teks)

Contoh ringkas yang boleh disemak

Pengekodan ini sepadan dengan Base64 berpenambalan piawai.

Man

Man

Base64

TWFu

Man ialah 3 bait UTF-8/ASCII. TWFu ialah 4 aksara: 3 → 4.

Hello

Hello

Base64

SGVsbG8=

Hello ialah 5 bait. SGVsbG8= ialah 8 aksara, termasuk satu =. Pada data kecil, penambalan menjadikan peratusan nampak lebih besar daripada 33%.

Bagaimana mengira saiz Base64?

Untuk Base64 berpenambalan piawai, encodedLength = 4 × ceil(originalBytes / 3).

Bait asal	Aksara Base64
1	4
2	4
3	4
4	8
5	8
6	8

1 atau 2 bait tetap menghasilkan 4 aksara. Gunakan formula, bukan 33% tetap.

Apa maksud penambalan “=”?

Tanda = menunjukkan blok 3 bait terakhir tidak penuh. 1 bait input menggunakan dua =; 2 bait menggunakan satu; 3 bait tidak menggunakan. Penambalan bukan penyulitan dan bukan ciri keselamatan.

Adakah Base64URL menggunakan kurang ruang?

Base64URL menukar + kepada - dan / kepada _, dan Encode Base64 menggugurkan = di hujung semasa mengekod. Rentetan boleh dipendekkan sebanyak aksara = itu. Struktur 3 bait → 4 aksara kekal sama, jadi Base64URL bukan format binari yang lebih jimat ruang.

Mengapa input yang amat kecil boleh membesar lebih daripada 33%?

1 bait → 4 aksara ialah peningkatan panjang 300%. 2 bait → 4 ialah 100%. 3 bait → 4 kira-kira 33.3%. Apabila n membesar, penambalan kurang ketara dan overhead menghampiri kira-kira 33%. Base64 tidak sentiasa tepat 33% lebih besar.

Mengapa Data URL Base64 lebih besar lagi?

Data URL menambah awalan seperti data:image/png;base64, sebelum muatan. Pada fail yang amat kecil, awalan itu boleh mendominasi peratusan. Encode Base64 boleh mengeluarkan Base64 mentah atau Data URL; output Data URL menggunakan abjad piawai.

Base64 vs binari: yang mana lebih kecil?

Binari mentah lebih jimat ruang untuk pemindahan dan storan. Base64 lebih besar, tetapi selamat sebagai teks dalam JSON, e-mel, dan laluan teks sahaja yang lain. Ini pengekodan binari-ke-teks, bukan mampatan.

Adakah Base64 memampatkan fail?

Tidak. Base64 bukan format mampatan. Teks yang dikodkan biasanya lebih besar daripada bait asal. Jika gzip atau Brotli kemudian digunakan pada teks itu, sebahagian lebihan mungkin mengecil—hasil bergantung pada data dan pemampat. gzip tidak menghapuskan overhead Base64 secara universal.

Apa berlaku jika Base64 di-gzip?

Mampatan HTTP boleh mengurangkan sebahagian corak berulang dalam teks Base64. JPEG, PNG atau ZIP kerap sukar dimampatkan walaupun sebagai bait mentah, dan Base64 kemudian gzip masih bergantung pada kes. Tiada peratusan tambahan sejagat selepas gzip.

Patutkah fail disimpan sebagai Base64?

Base64 boleh memuatkan binari ke medan JSON, aset sebaris kecil, API teks sahaja, salin/tampal, atau Data URL. Untuk fail besar, storan, memori dan saiz muatan semuanya membesar. Itu bukan “jangan sekali-kali guna Base64 untuk fail.”

Mengapa Base64 lazim dalam API JSON?

JSON tiada jenis binari mentah asli, jadi API kerap meletakkan bait dalam rentetan Base64. Untuk fail besar, multipart/form-data, storan objek, atau muat naik binari terus mungkin lebih sesuai. Tiada pilihan yang sentiasa terbaik.

Mengapa Base64 digunakan dalam e-mel?

MIME boleh menggunakan Base64 supaya lampiran binari bergerak sebagai aksara selamat untuk teks. Overhead saiz yang sama masih terpakai. Ini perwakilan pengangkutan, bukan fail yang lebih kecil.

Bila saiz tambahan itu berbaloi?

Saiz tambahan boleh berbaloi apabila binari mesti berada dalam teks, muatan kecil, API memerlukan Base64, atau anda perlukan Data URL. Untuk media besar, utamakan binari mentah jika sistem membenarkan.

Bila patut elakkan Base64?

Langkau untuk fail besar, jalur lebar ketat, pemindahan kerap, atau apabila laluan binari sudah wujud—ia situasional, bukan “Base64 ialah amalan buruk.”

Panjang Base64 berpenambalan yang boleh disemak

Kiraan bait asal dan kiraan aksara Base64 berpenambalan piawai:

Bait asal	Aksara Base64
1	4
2	4
3	4
10	16
100	136
1,000	1,336

Semua baris mengikut 4 × ceil(n / 3). Ini kiraan aksara Base64.

Contoh: berapa besar fail 1,000 bait?

4 × ceil(1000 / 3). ceil(333.333…) = 334, dan 4 × 334 = 1336. Jadi 1,000 bait menjadi 1,336 aksara Base64. Disimpan sebagai UTF-8/ASCII, setiap aksara biasanya 1 bait—jangan anggap 1,336 sebagai kiraan bait memori yang tepat.

Bolehkah Base64 menggunakan lebih memori daripada saiz fail?

Sesetengah masa jalan menyimpan rentetan dengan lebih daripada 1 bait setiap aksara, dan mengekod/menyahkod boleh mengekalkan penimbal bersama rentetan. Penggunaan memori tidak tepat sama dengan panjang aksara.

Panduan keputusan saiz yang ringkas

Jika sistem menerima binari mentah, utamakan itu demi saiz. Jika hanya teks dibenarkan, Base64 mungkin sesuai. Untuk muatan besar, semak laluan muat naik binari. Untuk teks selamat URL, pertimbangkan Base64URL—pengembangan 3-ke-4 kekal.

• Perlu menghantar data binari
• ↓
• Binari mentah dibenarkan? Utamakan binari demi saiz
• Medan teks sahaja? Base64 mungkin sesuai
• Muatan besar? Semak laluan muat naik binari
• Perlukan teks selamat URL? Pertimbangkan Base64URL
• ↓
• Jangka teks kira-kira 33% lebih banyak pada input besar

Kodkan atau nyahkod Base64 dalam pelayar anda

NEXNARA Encode Base64 mengekod dan menyahkod teks, serta boleh menukar fail kepada Base64 atau Data URL dan menukar Base64 kembali kepada fail.

Teks menggunakan bait UTF-8, kemudian Base64—bukan ASCII sahaja. Pilih Standard atau Base64URL. Output fail boleh Base64 mentah atau Data URL (abjad piawai). Input tidak sah ditolak. Bait bukan UTF-8 perlu ke fail, bukan nyahkod teks.

Fail melebihi 10 MB mungkin melambatkan tab (amaran). Fail melebihi 32 MB disekat.

Pengekodan dan nyahkod berlaku dalam pelayar anda. Fail tidak dihantar ke pelayan NEXNARA untuk alat ini. Iklan dan ciri tapak lain masih menggunakan rangkaian.

Tampal teks atau fail dalam Encode Base64 dan bandingkan bait asal dengan panjang yang dikodkan.

FAQ

Mengapa Base64 meningkatkan saiz fail?

Ia memetakan 3 bait (24 bit) kepada 4 aksara (4 × 6 bit). Disimpan sebagai teks, itu kira-kira satu pertiga lebih banyak untuk input besar.

Adakah Base64 sentiasa 33% lebih besar?

Tidak. Input besar menghampiri kira-kira 33.3%. Input yang amat kecil boleh membesar lebih kerana penambalan. Gunakan 4 × ceil(n / 3).

Berapa lebih besar Base64 berbanding binari?

Panjang berpenambalan piawai ialah 4 × ceil(n / 3) aksara. Awalan Data URL menambah lagi.

Adakah mampatan Base64 mengurangkan saiz fail?

Base64 tidak memampatkan. Gzip atau Brotli pada teks yang dikodkan mungkin mengecilkan sebahagian; ia tidak menghapuskan overhead dalam setiap kes.

Adakah Base64URL menggunakan kurang ruang?

Ia boleh menggugurkan penambalan =, jadi rentetan mungkin 0–2 aksara lebih pendek. Struktur pengekodan 3-ke-4 kekal sama.

Patutkah saya guna Base64 untuk fail besar?

Hanya jika anda perlukan teks. Untuk pemindahan besar atau kerap, laluan binari sering lebih kecil. Base64 tidak sentiasa salah untuk API.