เครื่องมือสำหรับนักพัฒนา · ตัวเข้ารหัสและตัวถอดรหัส Base64
เหตุใดไฟล์แนบในอีเมลจึงเป็น Base64: MIME, 7-บิตการขนส่งและ 76-บรรทัดคอลัมน์
· พื้นหลัง
base64 การเข้ารหัส
อีเมลถูกสร้างขึ้นสำหรับข้อความ 7 บิต ASCII และไฟล์แนบต้องพอดีกับข้อความนั้น โพสต์นี้ติดตามวิธีที่ MIME นำ Base64 มาใช้ เหตุใดบรรทัดจึงถูกล้อมด้วยอักขระ 76 และความหมายของขนาดและการดีบัก
ไฟล์แนบที่มาถึงเสียหายผ่านรีเลย์เก่า — ปัญหา 8 บิตที่ MIME ถูกคิดค้นขึ้นเพื่อแก้ไข
อีเมลได้รับการออกแบบในปี 1970 และ 1980 สำหรับข้อความ 7 บิต ASCII เท่านั้น SMTP ซึ่งเป็นโปรโตคอลที่รองรับอีเมล คาดว่าแต่ละบรรทัดจะมีอักขระได้สูงสุด 998 ตัว หรือเท่ากับ 7-บิต ASCII (อักขระ 0-127) การส่งไฟล์ไบนารีเช่น PDF หรือรูปภาพโดยตรงผ่าน SMTP จะล้มเหลว: ไบต์ 128-255 จะเสียหายหรือถูกปฏิเสธโดยเมลเซิร์ฟเวอร์และรีเลย์เก่า ไฟล์แนบต้องมีการเข้ารหัส MIME (ส่วนขยายจดหมายทางอินเทอร์เน็ตอเนกประสงค์ RFC 2045) แก้ไขปัญหานี้โดยการกำหนดค่าส่วนหัวการเข้ารหัสการถ่ายโอนเนื้อหา รวมถึง base64 ซึ่งแสดงถึงลำดับไบต์ใดๆ ที่เป็นข้อความ 7 บิต ASCII
MIME มีตัวเลือกการเข้ารหัสการถ่ายโอนเนื้อหาหลายตัวเลือก: 7bit (ไม่มีการเข้ารหัส เพื่อความปลอดภัยเท่านั้น ASCII), 8bit (สำหรับเซิร์ฟเวอร์ที่รองรับ 8-บิตไบต์ ไม่ใช่สากล), เครื่องหมายคำพูดที่พิมพ์ได้ (เข้ารหัสเฉพาะไบต์ที่ไม่ปลอดภัย ทำให้ ASCII สามารถอ่านได้) และ base64 (เข้ารหัสทุกอย่าง เพิ่มความเข้ากันได้สูงสุด) Base64 ได้รับเลือกสำหรับไฟล์แนบแบบไบนารีเนื่องจากมีความเรียบง่าย ได้มาตรฐาน และรับประกันความปลอดภัยบนระบบเมลใดๆ ไม่ว่าจะเก่าแค่ไหนหรือ 7-บิตเท่านั้นก็ตาม ข้อเสียคือขนาด: Base64 มีขนาดใหญ่กว่าไบต์ดั้งเดิมประมาณหนึ่งในสาม
ปัญหาการขนส่ง Base64 แก้ไข - แทนไบต์ที่กำหนดเองด้วยอักขระที่พิมพ์ได้
3 KB PDF กลายเป็นข้อความ Base64 ประมาณ 4 KB ขีดจำกัดบรรทัด 76 อักขระมาจาก RFC 2045
SMTP อนุญาตให้มีบรรทัดยาวได้ถึง 998 อักขระ แต่ระบบอีเมลแบบเก่าและตัวกรองสแปมบางตัวจะปฏิเสธบรรทัดที่ยาว RFC 2045 ระบุว่า MIME บรรทัด Base64 ต้องมีความยาวไม่เกิน 76 อักขระ (บวกกับการลงท้ายบรรทัด CRLF) ดังนั้นเมลเซิร์ฟเวอร์จะไม่หยุดการขนส่ง ขีดจำกัดไม่ใช่เรื่องมหัศจรรย์ มันเป็นการประนีประนอมในอดีตระหว่างความสามารถในการอ่าน (อักขระ 76 เหมาะกับเทอร์มินัลส่วนใหญ่ในช่วงปี 1980) ความเข้ากันได้กับระบบเก่า และการหลีกเลี่ยงการตรวจพบว่าเป็นรูปแบบสแปมหรือไวรัส
ตัวเลือกเอาต์พุตที่มองเห็นได้ในเครื่องมือนี้ - การเติมตามรูปแบบบัญญัติและการตัดอักขระ 76 แบบเสริม
ระบบเมลสมัยใหม่มักจะสนับสนุนบรรทัดที่ยาวกว่า แต่การเข้ารหัสเป็นบรรทัดอักขระ 76 ช่วยให้มั่นใจว่าไฟล์แนบจะส่งถึงผู้รับที่เก่าที่สุดด้วยซ้ำ หลังจาก RFC 2045 กำหนด MIME Base64, RFC 4288 (ประเภทสื่อ) และ RFC 2183 (การจัดการเนื้อหา) ได้เพิ่มวิธีมาตรฐานในการติดป้ายกำกับไฟล์แนบ ข้อความที่มีไฟล์แนบ PDF ประกอบด้วยส่วนหัว Content-Transfer-Encoding: base64, ส่วนหัว Content-Type: application/pdf และ PDF ไบต์ที่เข้ารหัสเป็น Base64 พร้อมด้วยบรรทัดอักขระ 76 โปรแกรมอ่านเมลถอดรหัสบรรทัดโดยลบตัวแบ่งบรรทัด (CRLF อักขระ) จากนั้นถอดรหัส Base64 เพื่อกู้คืนไบต์ต้นฉบับ
การถอดรหัสไฟล์แนบ MIME Base64 จำเป็นต้องละเว้นช่องว่าง RFC บอกว่า: ตัวถอดรหัสจะต้องข้ามการขึ้นบรรทัดใหม่ (อักขระ CR และ LF) ระหว่างการถอดรหัส นี่คือเหตุผลว่าทำไมตัวถอดรหัส Base64 ที่ยอมรับช่องว่างจึงใช้งานได้จริง เมล MIME จริงส่วนใหญ่จะมีการขึ้นบรรทัดใหม่ ตัวถอดรหัสบางตัวเข้มงวดและปฏิเสธช่องว่าง (เหมาะสำหรับบริบทเช่น JWT ซึ่งไม่ควรมีการขึ้นบรรทัดใหม่) ในขณะที่ตัวถอดรหัสบางตัวผ่อนปรนและข้ามช่องว่าง (เหมาะสำหรับ MIME)
ตัวเลือก 76 อักขระในทางปฏิบัติ - วิธีที่ตัวเข้ารหัสแทรกและตัวถอดรหัสละเว้นการขึ้นบรรทัดใหม่
เครื่องมือเข้ารหัสและถอดรหัส Base64 สามารถรองรับทั้งสองอย่าง: ยอมรับไฟล์แนบที่วางหลายบรรทัดและละเว้นการขึ้นบรรทัดใหม่ระหว่างการถอดรหัส ผลกระทบต่อขนาดสามารถคาดเดาได้ RFC 2045 การตัดแบบ base64 จะเพิ่มหนึ่ง CRLF (2 bytes) ต่อ 76 อักขระของเอาต์พุต สำหรับไฟล์ 10 KB นั้น Base64 มีค่าประมาณ 13.3 KB บวก CRLF ทุก ๆ 76 อักขระ รวมประมาณ 13.5 KB โอเวอร์เฮดนั้นเพิ่มอีกประมาณหนึ่งในสามไบต์
โดยปกติแล้วจะระบุขีดจำกัดขนาดอีเมลสำหรับขนาดที่เข้ารหัส ไม่ใช่ขนาดไฟล์ต้นฉบับ เมลเซิร์ฟเวอร์ที่มีขีดจำกัด 25 MB หมายถึง 25 MB ของข้อความที่เข้ารหัส ไม่ใช่ 25 MB ของไฟล์แนบ การคำนวณขนาดไฟล์ต้นฉบับต้องหารด้วย 1.33 (หรือถ้าให้เจาะจงกว่านั้นคือ 4 หารด้วย 3) การเข้ารหัสที่ยกมาพิมพ์ได้เป็นอีกทางเลือกหนึ่งที่ทำให้ ASCII ที่สามารถพิมพ์ได้ไม่เปลี่ยนแปลง และเข้ารหัสเฉพาะไบต์ 128-255 และอักขระพิเศษสองสามตัว
ตัวอย่างการทำงาน: การอ่านแหล่งข้อความดิบ — ค้นหาส่วน Base64 และถอดรหัสไฟล์แนบข้อความขนาดเล็ก
ไฟล์ข้อความที่มี ASCII ส่วนใหญ่จะยังคงสามารถอ่านได้หากคุณเปิดแหล่งข้อความดิบ Base64 ทำให้ทุกอย่างสับสน แม้แต่ข้อความธรรมดา ASCII Quoted-printable ไม่ค่อยได้ใช้กับไฟล์ไบนารี่ (ซึ่งจะไม่มีประสิทธิภาพมากนักสำหรับ PDF) แต่บางครั้งก็ใช้สำหรับข้อความ โปรแกรมอ่านเมลจะเลือกการเข้ารหัสตามประเภทไฟล์แนบ เบราว์เซอร์มักจะไม่ถามผู้ใช้ว่าจะใช้การเข้ารหัสใด
เนื้อความ Base64 ของข้อความอีเมลเป็นเพียงไบต์ ไม่ใช่ไฟล์แยกต่างหาก เมื่อคุณเห็นไฟล์แนบในตัวอ่านเมล แสดงว่าผู้อ่านได้ถอดรหัส Base64 แล้วและกำลังแสดงไฟล์ต้นฉบับ
ค่าใช้จ่ายด้านขนาดในทางปฏิบัติ — เพิ่มอีกประมาณหนึ่งในสามไบต์ และเหตุใดจึงระบุขีดจำกัดขนาดเมลสำหรับขนาดที่เข้ารหัส
หากคุณดูแหล่งที่มาของข้อความดิบ (ตัวเลือกในโปรแกรมรับส่งเมลส่วนใหญ่) คุณจะเห็นส่วนหัว MIME และเนื้อหาที่เข้ารหัส Base64 เครื่องมือเข้ารหัสและถอดรหัส Base64 สามารถช่วยคุณถอดรหัสส่วนของแหล่งข้อความได้ด้วยตนเอง คัดลอกส่วน Base64 ลบตัวแบ่งบรรทัด และวางลงในเครื่องมือ
ไฟล์แนบหลายรายการในข้อความ MIME ใช้ขอบเขตหลายส่วน แต่ละส่วนมีส่วนหัวของตัวเอง (ประเภทเนื้อหา การเข้ารหัสการถ่ายโอนเนื้อหา) และเนื้อหา ข้อความทางเลือกในรูปแบบข้อความธรรมดาจะปรากฏเป็นส่วนหนึ่ง และแต่ละไฟล์แนบจะปรากฏเป็นอีกส่วนหนึ่ง สตริงขอบเขตแยกส่วนต่างๆ จะถูกเลือกไม่ให้ปรากฏในเนื้อหาส่วนใดส่วนหนึ่ง โปรแกรมอ่านเมลจะสร้างข้อความขึ้นใหม่โดยแยกวิเคราะห์ขอบเขตและถอดรหัสแต่ละส่วนตามส่วนหัว Content-Transfer-Encoding
สิ่งนี้ไม่ครอบคลุมถึง - ส่วนหัวของคำที่เข้ารหัส, S/MIME และส่วนขยาย 8BITMIME ในเชิงลึก
RFC 2045 การเข้ารหัส base64 ไม่เป็นสากลในปัจจุบัน ระบบเมลบางระบบรองรับการขนส่ง 8 บิต และไม่จำเป็นต้องใช้ base64 อีกต่อไป บางระบบใช้ชื่อการเข้ารหัสที่แตกต่างกันหรือเพิ่มส่วนหัวที่กำหนดเอง แต่ base64 ที่มีบรรทัดอักขระ 76 ยังคงเป็นตัวเลือกที่เข้ากันได้มากที่สุดสำหรับไฟล์แนบที่ต้องเข้าถึงระบบเมลใดๆ ทุกที่ เมื่อคุณแนบไฟล์โดยใช้โปรแกรมรับส่งเมล ไคลเอ็นต์มักจะเลือก base64 โดยอัตโนมัติสำหรับไฟล์ไบนารี จัดการการตัดบรรทัด และเพิ่มส่วนหัว MIME
การทำความเข้าใจกลไกนี้จะช่วยให้คุณแก้ไขจุดบกพร่องเมื่อเอกสารแนบดูเหมือนเสียหายหรือเมื่อคุณทำงานกับแหล่งข้อความด้วยตนเอง การสร้างหรือแยกวิเคราะห์ข้อความอีเมลขาออกจำเป็นต้องมีความเข้าใจโครงสร้าง MIME ไลบรารีควรจัดการการเข้ารหัส การตัดบรรทัด และส่วนหัว ปกติคุณจะไม่สร้าง MIME ด้วยตนเอง แต่หากคุณกำลังแยกวิเคราะห์แหล่งที่มาของข้อความดิบ (การดีบั๊กปัญหาการส่ง หรือแยกไฟล์แนบโดยทางโปรแกรม) การรู้ว่า Content-Transfer-Encoding: base64 หมายความว่าเนื้อหาต่อไปนี้คือ 76- character-wrapped base64 จะช่วยให้คุณใช้ตัวถอดรหัสที่ถูกต้องได้
ประเด็นสำคัญ: Base64 เป็นเลเยอร์ความเข้ากันได้ของอีเมล - วิธีที่ตัวเข้ารหัสและตัวถอดรหัส Base64 ช่วยให้คุณอ่านส่วนข้อความขนาดเล็กจากข้อความดิบในเครื่องได้อย่างไร
base64 นั้นเป็นมาตรฐาน RFC 4648; การตัดคำและส่วนหัว MIME มีไว้สำหรับอีเมลโดยเฉพาะ ไฟล์แนบในอีเมลคือ base64 เนื่องจากอีเมลถูกสร้างขึ้นสำหรับข้อความธรรมดา และ base64 เป็นเลเยอร์ความเข้ากันได้สากลที่ง่ายที่สุดในการส่งข้อมูลไบนารีผ่านโปรโตคอลแบบข้อความเท่านั้น ขีด จำกัด บรรทัด 76 อักขระเป็นสิ่งที่สร้างขึ้นในอดีตของเทอร์มินัลและเครือข่ายที่ช้าในทศวรรษ 1980 แต่ยังคงเป็นมาตรฐานสำหรับความเข้ากันได้
การทำความเข้าใจประวัตินี้จะอธิบายว่าทำไม MIME ถึงมีอยู่ เหตุใดจึงมีตัวเลือกการเข้ารหัสหลายตัว และเหตุใด base64 จึงยังคงเป็นค่าเริ่มต้นสำหรับไฟล์แนบ แม้ว่าระบบเมลสมัยใหม่จะสามารถรองรับไบนารีได้โดยตรง ตัวเข้ารหัสและตัวถอดรหัส Base64 ช่วยให้คุณทำงานกับ MIME เนื้อความด้วยตนเองเพื่อตรวจสอบหรือแก้ไขข้อบกพร่องของการเข้ารหัส