ทำไม Base64 ถึงทำให้ไฟล์ใหญ่ขึ้น

บทความนี้อธิบายว่าทำไมผลลัพธ์ Base64 ใหญ่กว่าไบต์ต้นฉบับ ไม่ใช่คู่มือความปลอดภัย ถ้าต้องแยกการเข้ารหัสกับการเข้ารหัสลับ ให้ใช้ Base64 ไม่ใช่การเข้ารหัสลับ: มันทำอะไรจริง ๆ

ทำไม Base64 ถึงต้องใช้ที่มากกว่า

3 ไบต์คือ 24 บิต Base64 แบ่ง 24 บิตนั้นเป็น 4 กลุ่ม กลุ่มละ 6 บิต แต่ละกลุ่มแมปเป็นอักขระ Base64 หนึ่งตัว จึงได้ 3 ไบต์อินพุตเป็น 4 อักขระผลลัพธ์ เก็บเป็น 1 ไบต์ต่ออักขระ ASCII คือ 4 / 3 ≈ 1.333 — เพิ่มประมาณ 33.3%

• 3 ไบต์ (24 บิต)
• ↓
• แยกเป็น 4 กลุ่ม กลุ่มละ 6 บิต
• แต่ละกลุ่ม → อักขระ Base64 หนึ่งตัว
• ↓
• 4 อักขระ (มักเป็นข้อความ 4 ไบต์)

ตัวอย่างง่ายที่ตรวจได้

การเข้ารหัสเหล่านี้ตรงกับ Base64 แบบมีแพดดิ้งมาตรฐาน

Man

Man

Base64

TWFu

Man คือ 3 ไบต์ UTF-8/ASCII TWFu คือ 4 อักขระ: 3 → 4

Hello

Hello

Base64

SGVsbG8=

Hello คือ 5 ไบต์ SGVsbG8= คือ 8 อักขระ รวม = หนึ่งตัว ข้อมูลเล็กแพดดิ้งทำให้เปอร์เซ็นต์ดูใหญ่กว่า 33%

คำนวณขนาด Base64 อย่างไร

สำหรับ Base64 แบบมีแพดดิ้งมาตรฐาน encodedLength = 4 × ceil(originalBytes / 3)

ไบต์ต้นฉบับ	อักขระ Base64
1	4
2	4
3	4
4	8
5	8
6	8

1 หรือ 2 ไบต์ก็ได้ 4 อักขระอยู่ดี ใช้สูตร ไม่ใช่ 33% ตายตัว

แพดดิ้ง “=” หมายความว่าอะไร

เครื่องหมาย = แสดงว่าบล็อก 3 ไบต์สุดท้ายไม่เต็ม 1 ไบต์อินพุตใช้ = สองตัว 2 ไบต์ใช้หนึ่งตัว 3 ไบต์ไม่ใช้ แพดดิ้งไม่ใช่การเข้ารหัสลับและไม่ใช่ฟีเจอร์ความปลอดภัย

Base64URL ใช้ที่น้อยกว่าไหม

Base64URL เปลี่ยน + เป็น - และ / เป็น _ และ เข้ารหัส Base64 จะตัด = ท้ายตอนเข้ารหัส สตริงอาจสั้นลงเท่าจำนวน = นั้น โครงสร้าง 3 ไบต์ → 4 อักขระยังเหมือนเดิม ดังนั้น Base64URL ไม่ใช่รูปแบบไบนารีที่ประหยัดที่มากกว่า

ทำไมอินพุตจิ๋วถึงโตเกิน 33%

1 ไบต์ → 4 อักขระคือเพิ่มความยาว 300% 2 ไบต์ → 4 คือ 100% 3 ไบต์ → 4 ประมาณ 33.3% เมื่อ n โตขึ้น แพดดิ้งมีผลน้อยลงและภาระเข้าใกล้ประมาณ 33% Base64 ไม่ได้ใหญ่กว่าเสมอไปพอดี 33%

ทำไม Data URL แบบ Base64 ถึงใหญ่กว่าอีก

Data URL เติมคำนำหน้าอย่าง data:image/png;base64, ก่อนส่วนข้อมูล ไฟล์จิ๋วคำนำหน้านั้นอาจครองเปอร์เซ็นต์ เข้ารหัส Base64 ออก Base64 ดิบหรือ Data URL ได้ ผลลัพธ์ Data URL ใช้ชุดอักขระมาตรฐาน

Base64 กับไบนารี อันไหนเล็กกว่า

ไบนารีดิบประหยัดที่กว่าสำหรับส่งและเก็บ Base64 ใหญ่กว่า แต่ปลอดภัยแบบข้อความใน JSON อีเมล และเส้นทางข้อความอย่างเดียว การเข้ารหัสไบนารีเป็นข้อความ ไม่ใช่การบีบอัด

Base64 บีบอัดไฟล์ไหม

ไม่ Base64 ไม่ใช่รูปแบบบีบอัด ข้อความที่เข้ารหัสมักใหญ่กว่าไบต์ต้นฉบับ ถ้าภายหลังใส่ gzip หรือ Brotli กับข้อความนั้น ความซ้ำบางส่วนอาจหดได้—ผลขึ้นกับข้อมูลและตัวบีบ gzip ไม่ได้ลบภาระ Base64 ทั้งหมด

ถ้า gzip Base64 จะเกิดอะไรขึ้น

การบีบอัด HTTP ลดรูปแบบซ้ำบางส่วนในข้อความ Base64 ได้ JPEG PNG หรือ ZIP มักบีบยากแม้เป็นไบต์ดิบ และ Base64 แล้ว gzip ก็ยังขึ้นกับกรณี ไม่มีเปอร์เซ็นต์เพิ่มสากลหลัง gzip

ควรเก็บไฟล์เป็น Base64 ไหม

Base64 ใส่ไบนารีลงช่อง JSON สินทรัพย์ฝังเล็ก API ข้อความอย่างเดียว คัดลอกวาง หรือ Data URL ได้ สำหรับไฟล์ใหญ่ ที่เก็บ หน่วยความจำ และขนาดเพย์โหลดโตหมด นั่นไม่ใช่ “อย่าใช้ Base64 กับไฟล์เลย”

ทำไม API JSON ถึงใช้ Base64 บ่อย

JSON ไม่มีชนิดไบนารีดิบในตัว API จึงมักใส่ไบต์ในสตริง Base64 สำหรับไฟล์ใหญ่ multipart/form-data ที่เก็บออบเจ็กต์ หรืออัปโหลดไบนารีตรง ๆ อาจเหมาะกว่า ไม่มีทางเลือกใดดีที่สุดเสมอ

ทำไมอีเมลใช้ Base64

MIME ใช้ Base64 ได้เพื่อให้ไฟล์แนบไบนารีเดินทางเป็นอักขระปลอดภัยต่อข้อความ ภาระขนาดเดิมยังอยู่ นี่คือรูปแบบขนส่ง ไม่ใช่ไฟล์ที่เล็กกว่า

เมื่อใดขนาดเพิ่มนั้นคุ้ม

ขนาดเพิ่มอาจคุ้มเมื่อไบนารีต้องอยู่ในข้อความ เพย์โหลดเล็ก API บังคับ Base64 หรือคุณต้องการ Data URL สำหรับมีเดียใหญ่ ถ้าอนุญาตให้ใช้ไบนารีดิบ

เมื่อใดควรเลี่ยง Base64

ข้ามสำหรับไฟล์ใหญ่ แบนด์วิดท์ตึง ส่งบ่อย หรือเมื่อมีเส้นทางไบนารีอยู่แล้ว—เป็นเรื่องสถานการณ์ ไม่ใช่ “Base64 เป็นนิสัยไม่ดี”

ความยาว Base64 มีแพดดิ้งที่ตรวจได้

จำนวนไบต์ต้นฉบับกับจำนวนอักขระ Base64 มีแพดดิ้งมาตรฐาน:

ไบต์ต้นฉบับ	อักขระ Base64
1	4
2	4
3	4
10	16
100	136
1,000	1,336

ทุกแถวตาม 4 × ceil(n / 3) นี่คือจำนวนอักขระ Base64

ตัวอย่าง: ไฟล์ 1,000 ไบต์จะใหญ่แค่ไหน

4 × ceil(1000 / 3) ceil(333.333…) = 334 และ 4 × 334 = 1336 ดังนั้น 1,000 ไบต์กลายเป็น 1,336 อักขระ Base64 เก็บเป็น UTF-8/ASCII แต่ละอักขระมัก 1 ไบต์—อย่าถือ 1,336 เป็นจำนวนไบต์ในหน่วยความจำที่แม่นยำ

Base64 ใช้หน่วยความจำมากกว่าที่ขนาดไฟล์บอกไหม

บางรันไทม์เก็บสตริงเกิน 1 ไบต์ต่ออักขระ และการเข้ารหัส/ถอดอาจเก็บทั้งบัฟเฟอร์กับสตริงพร้อมกัน การใช้หน่วยความจำไม่เท่ากับความยาวอักขระพอดี

แนวตัดสินใจเรื่องขนาดอย่างง่าย

ถ้าระบบรับไบนารีดิบได้ ให้เลือกทางนั้นเพื่อขนาด ถ้าได้แต่ข้อความ Base64 อาจเหมาะ เพย์โหลดใหญ่ให้ตรวจเส้นทางอัปโหลดไบนารี ต้องการข้อความปลอดภัยต่อ URL ให้พิจารณา Base64URL—การขยาย 3 เป็น 4 ยังอยู่

• ต้องส่งข้อมูลไบนารี
• ↓
• ใช้ไบนารีดิบได้? เลือกไบนารีเพื่อขนาด
• ช่องข้อความอย่างเดียว? Base64 อาจเหมาะสม
• เพย์โหลดใหญ่? ตรวจเส้นทางอัปโหลดไบนารี
• ต้องการข้อความปลอดภัยต่อ URL? พิจารณา Base64URL
• ↓
• คาดว่าข้อความเพิ่มประมาณ 33% บนอินพุตใหญ่

เข้ารหัสหรือถอด Base64 ในเบราว์เซอร์

NEXNARA เข้ารหัส Base64 เข้ารหัสและถอดข้อความ และเปลี่ยนไฟล์เป็น Base64 หรือ Data URL แล้วเปลี่ยน Base64 กลับเป็นไฟล์ได้

ข้อความใช้ไบต์ UTF-8 แล้วจึง Base64—ไม่จำกัด ASCII เลือก Standard หรือ Base64URL ผลลัพธ์ไฟล์เป็น Base64 ดิบหรือ Data URL (ชุดอักขระมาตรฐาน) อินพุตไม่ถูกต้องจะถูกปฏิเสธ ไบต์ที่ไม่ใช่ UTF-8 ต้องไปที่ไฟล์ ไม่ใช่ถอดเป็นข้อความ

ไฟล์เกิน 10 MB อาจทำให้แท็บช้า (คำเตือน) ไฟล์เกิน 32 MB จะถูกบล็อก

การเข้ารหัสและถอดเกิดในเบราว์เซอร์ของคุณ ไฟล์ไม่ถูกส่งไปเซิร์ฟเวอร์ NEXNARA สำหรับเครื่องมือนี้ โฆษณาและฟีเจอร์อื่นของไซต์ยังใช้เครือข่าย

วางข้อความหรือไฟล์ใน เข้ารหัส Base64 แล้วเทียบไบต์ต้นฉบับกับความยาวหลังเข้ารหัส

FAQ

ทำไม Base64 เพิ่มขนาดไฟล์

มันแมป 3 ไบต์ (24 บิต) เป็น 4 อักขระ (4 × 6 บิต) เก็บเป็นข้อความแล้วอินพุตใหญ่มักเพิ่มประมาณหนึ่งในสาม

Base64 ใหญ่กว่า 33% เสมอไหม

ไม่ อินพุตใหญ่เข้าใกล้ประมาณ 33.3% อินพุตจิ๋วอาจโตมากกว่าเพราะแพดดิ้ง ใช้ 4 × ceil(n / 3)

Base64 ใหญ่กว่าไบนารีเท่าใด

ความยาวมีแพดดิ้งมาตรฐานคือ 4 × ceil(n / 3) อักขระ คำนำหน้า Data URL เพิ่มอีก

การบีบอัด Base64 ลดขนาดไฟล์ไหม

Base64 ไม่บีบอัด Gzip หรือ Brotli บนข้อความที่เข้ารหัสอาจหดบางส่วน แต่ไม่ได้ลบภาระในทุกกรณี

Base64URL ใช้ที่น้อยกว่าไหม

มันตัดแพดดิ้ง = ได้ สตริงอาจสั้นลง 0–2 อักขระ โครงสร้างเข้ารหัส 3 เป็น 4 เหมือนเดิม

ควรใช้ Base64 กับไฟล์ใหญ่ไหม

เฉพาะเมื่อต้องการข้อความ สำหรับส่งใหญ่หรือบ่อย เส้นทางไบนารีมักเล็กกว่า Base64 ไม่ผิดเสมอไปสำหรับ API