เครื่องมือสำหรับนักพัฒนา · ตัวเข้ารหัสและตัวถอดรหัส Base64
Base64 ทำให้ข้อมูลของคุณใหญ่แค่ไหน? ค่าใช้จ่าย 4/3 ได้ผลแล้ว
· มันทำงานอย่างไร
base64 การเข้ารหัส ผลงาน
เอาต์พุต Base64 มีขนาดใหญ่กว่าอินพุตประมาณหนึ่งในสาม รวมทั้งแพดดิ้งและอาจมีการขึ้นบรรทัดใหม่ บทความนี้อธิบายสูตรที่แน่นอนและใช้กับขนาดที่พบได้จริงเพื่อให้ประเมินต้นทุนได้
ไอคอน 30 KB ที่กลายเป็น 40 KB ในกลุ่ม — การก้าวกระโดดที่เป็นรูปธรรมซึ่งทำให้การตรวจสอบบิลด์ประหลาดใจ
ไอคอน 30 KB แทรกอยู่ในบรรทัด Base64 ในไฟล์ CSS จะกลายเป็น 40 KB และมีคำถามเกี่ยวกับการสร้างเกิดขึ้น: 10 KB เพิ่มเติมมาจากไหน ปัจจัยการขยายสำหรับ Base64 จะเป็น 4/3: เสมอ ทุกๆ อินพุตสามไบต์จะสร้างเอาต์พุตสี่ไบต์ (อักขระสี่ตัว) สำหรับอินพุต 30 KB (30,000 bytes) ให้หารด้วย 3 เพื่อให้ได้ 10,000 กลุ่ม คูณด้วย 4 เพื่อให้ได้เอาต์พุต 40,000 bytes
คณิตศาสตร์เป็นสิ่งที่กำหนดได้และหลีกเลี่ยงไม่ได้: Base64 ไม่ใช่รูปแบบการบีบอัด หากเนื้อหาในบรรทัดมีค่าใช้จ่ายแบนด์วิดท์เพิ่มขึ้น 33% และการโหลดหน้าเว็บเร็วขึ้นเนื่องจากมีคำขอ HTTP น้อยลงเพียงหนึ่งคำขอ นั่นก็คุ้มค่าที่จะวัดผล หากมีค่าใช้จ่ายเพิ่มขึ้น 33% และโหลดช้าลง การแทรกในบรรทัดก็ไม่คุ้มค่า อัตราส่วน 4/3 มาจากรูปแบบบิต สามไบต์คือ 24 bits; อักขระ Base64 สี่ตัวมี 24 bits (แต่ละตัวมีหกบิต)
เหตุใด 4/3 จึงเป็นพื้น — หกบิตต่ออักขระเทียบกับแปดต่อไบต์ และที่มาของโอเวอร์เฮดที่เหลือ
จนถึงตอนนี้ อัตราส่วนคือ 1:1 แต่อักขระ Base64 เป็นข้อความ (ASCII 0–127) และอักขระเฉลี่ย ASCII ในการเข้ารหัส UTF-8 หรือ Latin-1 คือหนึ่งไบต์ ดังนั้นอักขระ Base64 สี่ตัวจึงเป็นเอาต์พุตสี่ไบต์สำหรับอินพุตสามไบต์ อัตราส่วนของ 4/3. สิ่งนี้ไม่เป็นสากล: หาก Base64 ถูกเอาต์พุตเป็นรูปแบบไบนารี (หนึ่งไบต์ต่ออักขระ บรรจุเป็นหกบิต) อัตราส่วนจะเป็น 3/4 (การบีบอัด)
เนื่องจาก Base64 ได้รับการออกแบบมาสำหรับการส่งข้อความ จึงใช้อักขระข้อความ และค่าใช้จ่ายคือ 33% เพิ่มขนาด การเติมเพิ่มระยะขอบเล็กน้อยในตอนท้าย หากความยาวอินพุตเป็นทวีคูณของสาม ก็ไม่จำเป็นต้องมีการเติม หากความยาวอินพุต 1 mod 3 (หนึ่งไบต์สั้นจากหลายตัว) อักขระเสริมสองตัว = ถูกเพิ่ม ซึ่งจะทำให้เอาต์พุตเพิ่มขึ้น 2 หาก 2 mod 3 อักขระเสริมหนึ่งตัว = ถูกเพิ่ม โดยเพิ่มขึ้น 1
สูตรที่แน่นอนพร้อมช่องว่างภายใน — อักขระ ceil(n/3) × 4 และเอฟเฟกต์สำหรับอินพุตของ 1, 2 และ 3 bytes
สำหรับอินพุตขนาดใหญ่ อัตรากำไรจะน้อยมาก: อินพุต 300 ไบต์ต้องมีอักขระ 400 บวกกับอักขระเสริมไม่เกินสองตัว ซึ่งผลต่างน้อยกว่า 0.5% สำหรับอินพุตขนาดเล็ก (1–3 bytes) การเติมจะมีอิทธิพลเหนือ: หนึ่งไบต์จะสร้าง YQ== (สี่อักขระ) การขยาย 4x แต่โดยเฉลี่ยแล้วไฟล์ต่างๆ จะถูกครอบงำโดยไฟล์ขนาดใหญ่ สูตรที่แน่นอนคืออักขระ ceil(n / 3) × 4 โดยที่ n คือจำนวนไบต์ของอินพุต
สำหรับ n = 1, เพดาน(1/3) × 4 = 1 × 4 = 4. สำหรับ n = 2, เพดาน(2/3) × 4 = 1 × 4 = 4. สำหรับ n = 3, เพดาน(3/3) × 4 = 1 × 4 = 4. สำหรับ n = 4, เพดาน(4/3) × 4 = 2 × 4 = 8. สำหรับ n = 30000, เพดาน(30000/3) × 4 = 10000 × 4 = 40000. กรณีอินพุตขนาดเล็กอธิบายว่าทำไม “ประมาณหนึ่งในสาม” จึงไม่แม่นยำสำหรับทุกค่า หนึ่งไบต์ยังคงใช้บล็อกสี่อักขระ เช่นเดียวกับสองไบต์ อัตราส่วนเข้าใกล้สี่ในสามเท่านั้นเนื่องจากกลุ่มสามไบต์ที่สมบูรณ์จำนวนมากครองบล็อกเบาะสุดท้าย
ตัวอย่างการทำงาน: การวัดสตริง 20 อักขระ UTF-8 — นับไบต์แทนที่จะเป็นอักขระ จากนั้นจึงวัดความยาว Base64
ฟังก์ชั่นเพดานบัญชีสำหรับกลุ่มสุดท้ายไม่ครบจำนวนในสาม เมื่อ n มีขนาดใหญ่ขึ้น ceil(n/3) เข้าใกล้ n/3, ดังนั้นเอาต์พุตจึงเข้าใกล้ (n/3) × 4 = 4n/3, อัตราส่วน 4/3
วัดสตริงที่เป็นรูปธรรม: 20 อักขระผสม ASCII สำเนียง และอีโมจิ จำนวนอักขระคือ 15 ใน JavaScript (อีโมจินับหนึ่ง) UTF-8 จำนวนไบต์แตกต่างกัน: ASCII ตัวอักษร 1 byte แต่ละตัว ตัวอักษรเน้นเสียง 2 bytes (0xC3 0xA9 สำหรับ é), อีโมจิ 4 bytes (0xF0 0x9F 0x98 0x80) เครื่องมือรายงานอักขระ UTF-16 จุดโค้ด Unicode และ UTF-8 ไบต์แยกกัน ความแตกต่างดังกล่าวป้องกันไม่ให้ประโยคยี่สิบอักขระที่มีสัญลักษณ์หลายไบต์มีราคาเท่ากับยี่สิบไบต์ ความยาวที่เข้ารหัสเป็นไปตามจำนวนไบต์ ไม่ใช่สิ่งที่มนุษย์นับบนหน้าจอ
การขึ้นบรรทัดใหม่และการตัดคำ MIME — การจัดรูปแบบคอลัมน์ 76 จะเพิ่มค่าอีกสองสามเปอร์เซ็นต์อย่างไร
รวมประมาณ 18 bytes. Base64 เข้ารหัสสิ่งเหล่านี้: ceil(18/3) × 4 = 6 × 4 = 24 ตัวอักษร เนื่องจาก 18 หลายเท่าของสาม ไม่จำเป็นต้องมีการเติม เอาต์พุต Base64 คือ 24 ตัวอักษร เพิ่มการเข้ารหัส 24 - 18 = 6 bytes, หรือ 33% ยืนยัน 4/3 สูตร. MIME การห่อ Base64 จะแนะนำค่าใช้จ่ายเพิ่มเติม คลาสสิค MIME ห่อที่ 76 ตัวอักษรต่อบรรทัดและเพิ่มขึ้นบรรทัดใหม่
เอาต์พุต Base64 ขนาด 400 อักขระจะกลายเป็นประมาณ 405 bytes โดยมีการขึ้นบรรทัดใหม่ สำหรับทุก ๆ 76 อักขระของเอาต์พุต Base64 จะมีการแทรกไบต์ขึ้นบรรทัดใหม่หนึ่งไบต์ สำหรับไฟล์ขนาดใหญ่ ให้เพิ่มน้อยกว่า 2% สำหรับไฟล์แนบในอีเมล รูปแบบบรรทัดใหม่เป็นมาตรฐานและคาดหวังโดย parsers เครื่องมือยอมรับ Base64 ที่ห่อไว้และถอดรหัสอย่างถูกต้อง การโต้ตอบการบีบอัดทำให้การวิเคราะห์ขนาดซับซ้อน ข้อมูลไบนารีดิบ (รูปภาพ วิดีโอ) บีบอัดแตกต่างจากข้อความ Base64 ToolAcre แทรกบรรทัดใหม่หลังจากแต่ละส่วน 76 อักขระที่กำหนดค่าไว้ และไม่รวมบรรทัดใหม่เหล่านั้นจากการวัดอักขระที่เข้ารหัสที่แสดง งบประมาณรูปแบบลวดต้องเพิ่มตัวแยกกลับ การเปรียบเทียบการวัดที่มองเห็นเพียงอย่างเดียวจะอธิบายสัญลักษณ์ Base64 ไม่ใช่ทุกไบต์ที่สิ้นสุดบรรทัดที่ส่ง
การโต้ตอบการบีบอัด - เหตุใดข้อความ Base64 จึงมีแนวโน้มที่จะบีบอัดได้แย่กว่าไบต์ดิบที่เป็นตัวแทน
สตริง Base64 อาจบีบอัดเป็น 60% ขนาดด้วย gzip และรูปภาพอาจบีบอัดเป็น 25% เนื่องจาก gzip ค้นหารูปแบบไบต์ที่ซ้ำกัน การแสดงข้อความ (ตัวอักษร A–Z บวก + / หรือ - _) จึงมีการซ้ำซ้อนน้อยกว่าการแสดงข้อมูลไบนารี รูปภาพในบรรทัดที่มีการบีบอัดมักจะมีค่าใช้จ่ายในโค้ดมากกว่าการฝังแบบแยกกัน สำหรับแบบอักษรที่มีความซับซ้อนเป็นพิเศษซึ่งมีสัญลักษณ์หลายตัว การอินไลน์ Base64 อาจไม่มีประสิทธิภาพ
การวิเคราะห์การแลกเปลี่ยนขึ้นอยู่กับบริบทเฉพาะ การอินไลน์ข้อมูลขนาดเล็ก URI (10–50 bytes) อาจคุ้มค่าที่จะหลีกเลี่ยงคำขอ HTTP การฝังเนื้อหาขนาดใหญ่ (100 KB) อาจไม่เป็นเช่นนั้น การบีบอัดขึ้นอยู่กับรูปแบบทั้งในแหล่งที่มาและการแสดง Base64 ดังนั้นเปอร์เซ็นต์ค่าโสหุ้ยการบีบอัดสากลจึงไม่ซื่อสัตย์ วัดสินทรัพย์จริงก่อนและหลังการบีบอัดการตอบสนองโดยรอบ ต้นทุนที่แน่นอนคือจำนวนอักขระที่ไม่บีบอัดที่กำหนดโดยสูตรบล็อก
สิ่งนี้ไม่ครอบคลุมถึง — การวัดประสิทธิภาพการเรนเดอร์หรือการถอดรหัส และการเพิ่มประสิทธิภาพเฉพาะรูปแบบ เช่น WebP
หากเนื้อหาบน CDN ใกล้กับผู้ใช้ การหลีกเลี่ยงคำขอจะไม่ได้รับประโยชน์ หากเนื้อหาบนเซิร์ฟเวอร์เดียวกันและการโหลดต้องมีการเดินทางไปกลับเพิ่มเติม การอินไลน์อาจสมเหตุสมผล การวัดเป็นสิ่งสำคัญ: ใช้สูตรในการคำนวณขนาดอินไลน์ เพิ่มจำนวนอักขระในไฟล์ CSS หรือ HTML วัดขนาดบันเดิลทั้งหมดและเวลาในการโหลด
33% ค่าใช้จ่ายแน่นอน; ผลประโยชน์ด้านประสิทธิภาพไม่ได้ URL-safe Base64 (base64url) มีอัตราส่วน 4/3 เหมือนกัน มีเพียงอักขระที่แตกต่างกัน การลบช่องว่างภายในจะบันทึกอักขระสองตัวในกรณีที่แย่ที่สุด สำหรับไฟล์ขนาดใหญ่ไม่สำคัญ สำหรับโทเค็น JWT (สามส่วน base64url รวมจุดเข้าด้วยกัน) การถอดช่องว่างภายในออกเป็นเรื่องปกติ แต่ช่วยประหยัดพื้นที่ได้น้อยมาก ขนาดจริงคือเนื้อหาโทเค็น ไม่ใช่การเข้ารหัสโอเวอร์เฮด ความเร็วในการเรนเดอร์ การถอดรหัสรูปภาพ และรูปแบบอื่น เช่น WebP จำเป็นต้องมีการวัดที่แตกต่างกัน สตริง Base64 ที่สั้นกว่าไม่ได้หมายความถึงการวาดภาพที่เร็วขึ้น และเครื่องมือแบบข้อความเท่านั้นนี้ไม่ยอมรับไฟล์รูปภาพ การสนับสนุนที่เชื่อถือได้คือเลขคณิตสำหรับข้อความ UTF-8 ที่ป้อนในแผง
ประเด็นสำคัญ: ตั้งงบประมาณเพิ่มอีกหนึ่งในสาม — ตัวเข้ารหัสและตัวถอดรหัส Base64 ให้ความยาวที่เข้ารหัสจริงของข้อความใด ๆ ได้อย่างไร เพื่อให้คุณสามารถวัดผลแทนที่จะคาดเดา
การบีบอัดยังเข้ารหัสข้อความในทำนองเดียวกัน ไม่ว่าอักขระสองตัวสุดท้ายจะเป็น == หรือสตริงสั้นกว่านั้นแทบจะไม่ทำให้เอาต์พุต gzip แตกต่างกันเลย ตัวเข้ารหัสและตัวถอดรหัส Base64 รายงานทั้งจำนวนไบต์อินพุตและจำนวนอักขระเอาต์พุตทันที สำหรับการเข้ารหัสข้อความใดๆ สามารถดูการเพิ่มขนาดที่แน่นอนได้ สำหรับสตริง UTF-8 ที่มีอักขระหลายไบต์ เครื่องมือจะแสดงจำนวนอักขระ (สิ่งที่เห็น) แตกต่างจากจำนวนไบต์ (สิ่งที่เข้ารหัส Base64)
ก 10-สตริงอักขระอาจเป็น 15 bytes หากมีสำเนียงและอีโมจิ 20 อักขระของเอาต์พุต Base64 แทน 4/3 อัตราส่วนตามจำนวนตัวอักษร การทำความเข้าใจความแตกต่างทำให้กระจ่างว่าทำไมการใส่ไอคอนอีโมจิหนักๆ ในบรรทัดจึงมีราคาแพงกว่า ASCII ศิลปะ: ไม่ใช่อิโมจิมีราคาสูงกว่า UTF-8 ไบต์ที่เป็นตัวแทน สำหรับค่าอินไลน์ที่เป็นตัวเลือก ให้บันทึกเครื่องมือ UTF-8จำนวนไบต์และจำนวนอักขระที่เข้ารหัสเคียงข้างกัน แล้วรวม URI คำนำหน้า, CSS ไวยากรณ์และการห่อใดๆ ที่ปลายทางต้องการ การวัดที่สมบูรณ์นั้นมีประโยชน์มากกว่าการทำซ้ำเปอร์เซ็นต์ที่ปัดเศษโดยไม่มีค่าใช้จ่ายในการจัดเฟรม