เครื่องมือสำหรับนักพัฒนา · ตัวเข้ารหัสและตัวถอดรหัส Base64
ประวัติโดยย่อของ Base64: จาก uuencode และ PEM ไปจนถึงตัวอักษรของวันนี้
· พื้นหลัง
base64 การเข้ารหัส
ตัวอักษรของ Base64 เป็นบันทึกฟอสซิลของปัญหาการขนส่งในช่วงปี 1980 โพสต์นี้ติดตามเชื้อสายจาก uuencode ผ่าน Mail-Enhanced Mail ไปที่ MIME และ RFC 4648 และอธิบายตัวเลือกการออกแบบแต่ละรายการ
เหตุใดตัวอักษรจึงไม่เป็นเพียง 0–63 ในลำดับที่ชัดเจน — คำถามที่ย้อนกลับไปสี่ทศวรรษ
Base64 ไม่ได้มีรูปแบบที่สมบูรณ์เป็นมาตรฐาน ตัวอักษร (A-Z, a-z, 0-9, +, /) เป็นบันทึกฟอสซิลของการทดลองเข้ารหัสมานานหลายทศวรรษ โดยแต่ละการทดลองพยายามแก้ไขปัญหาเดียวกัน นั่นคือ วิธีแสดงข้อมูลไบนารี่ในรูปแบบข้อความที่ยังคงอยู่ในอีเมลในปี 1970 และ 1980, USENET และเครื่องมือ Unix เรื่องราวครอบคลุม uuencode บน Unix, เมลปรับปรุงความเป็นส่วนตัว (RFC 1421) ใน 1993, MIME (RFC 2045) ใน 1996 และสุดท้าย RFC 4648 ใน 2006 รวมตัวแปรทั้งหมด
การทำความเข้าใจประวัตินี้จะอธิบายว่าทำไมอักขระบางตัวถึงอยู่ในตัวอักษร และเหตุใด RFC จึงปล่อยให้ตัวเลือกบางอย่างแก่ผู้ใช้ uuencode ย่อมาจากการเข้ารหัส Unix-to-Unix เป็นเครื่องมือแรกในการแก้ปัญหาการขนส่ง 7-บิตบน Unix สร้างใน 1980 โดยเข้ารหัส 3 bytes (24 bits) แต่ละตัวเป็น 4 อักขระจากตัวอักษร 64 อักขระ ตัวอักษร uuencode คือ ASCII 32 (เว้นวรรค) ถึง ASCII 95 (ขีดล่างและเครื่องหมายวรรคตอนอื่นๆ) ที่เลือกเนื่องจากอักขระเหล่านั้นสามารถพิมพ์บนเทอร์มินัลใดก็ได้ พื้นที่เก็บข้อมูลแสดงตัวอักษรที่ใช้งานอยู่ในปัจจุบัน แต่ไม่มีหลักฐานที่เก็บถาวรว่าใครเลือกลำดับนั้นหรือทำไมตัวละครทุกตัวถึงชนะ หัวข้อจึงแคบลง: ผังปัจจุบันสามารถตรวจสอบได้อย่างแน่นอน ในขณะที่แรงจูงใจและวันที่จำเป็นต้องมีเอกสารทางประวัติศาสตร์หลักที่ไม่ได้รวมอยู่ที่นี่
เหตุใดตัวอักษรจึงดูเป็นประวัติศาสตร์ — ขอบเขตที่พื้นที่เก็บข้อมูลนี้ไม่ได้บันทึกไว้
อย่างไรก็ตาม พื้นที่ว่างเป็นอักขระเข้ารหัสเป็นปัญหา: โปรแกรมแก้ไขข้อความและระบบเมลจะตัดช่องว่างต่อท้าย ส่งผลให้เอาต์พุตเสียหาย ตัวอักษรไม่เหมาะ แต่ทำงานได้ดีพอสำหรับการถ่ายโอนไฟล์ Unix-to-Unix เมลปรับปรุงความเป็นส่วนตัว (RFC 1421, 1992) เป็นความพยายามในช่วงแรกๆ ในการสร้างมาตรฐานอีเมลที่เข้ารหัส มีการเข้ารหัส Base64 ของตัวเอง (RFC 1341 สำหรับ MIME ซึ่ง RFC 1421 มีมาก่อนในข้อกำหนดแต่ล่าช้าในการนำไปใช้)
RFC 1421 Base64 ใช้ตัวอักษร A-Z, a-z, 0-9, +, / (ตัวอักษรฐาน 64 สมัยใหม่) และตัดบรรทัดที่อักขระ 64 ตัวอักษรนี้หลีกเลี่ยงการเว้นวรรคและอักขระที่เป็นปัญหาอื่นๆ อักขระทุกตัวสามารถพิมพ์ได้อย่างชัดเจน และไม่สับสนกับรหัสควบคุมหรือรูปแบบชุดอักขระประจำชาติ ความยาวบรรทัด 64 อักขระตรงกับความกว้างของเทอร์มินัลกระดาษในช่วงปี 1980 และเป็นการประนีประนอมในทางปฏิบัติสำหรับการอ่าน Uuencode เป็นของประวัติศาสตร์โดยรอบ แต่เครื่องมือนี้ไม่สามารถอ่านหรือเขียนตัวอักษรได้ การปฏิบัติต่อให้เป็น Base64 ที่สามารถใช้แทนกันได้จะเป็นข้อผิดพลาดของรูปแบบ การเปรียบเทียบที่เป็นประโยชน์ในที่นี้จำกัดอยู่ที่ปัญหาที่ใช้ร่วมกันในการแสดงไบต์ด้วยอักขระที่พิมพ์ได้
การเข้ารหัสก่อนหน้านี้เป็นบริบท ไม่ใช่หลักฐานการดำเนินการ
RFC 1421 ไม่ได้ถูกนำมาใช้กันอย่างแพร่หลายสำหรับอีเมลที่เข้ารหัส แต่ตัวอักษร Base64 ยังคงอยู่ MIME (ส่วนขยายจดหมายทางอินเทอร์เน็ตอเนกประสงค์ RFC 2045, 1996) ใช้ RFC 1421 ตัวอักษร Base64 แต่เปลี่ยนการตัดบรรทัดจาก 64 เป็น 76 อักขระ เหตุผลนั้นไม่ใช่เรื่องทางเทคนิคแต่เป็นในอดีต: บล็อก PEM (จดหมายที่ปรับปรุงความเป็นส่วนตัว) มีความยาว 64 อักขระ และ MIME เลือกขีดจำกัดที่แตกต่างออกไปเล็กน้อยเพื่อหลีกเลี่ยงความสับสนกับ PEM ในการแยกวิเคราะห์อัตโนมัติ
MIME Base64 กลายเป็นมาตรฐานสำหรับไฟล์แนบในอีเมล และเป็นเวอร์ชัน Base64 ที่ใช้กันอย่างแพร่หลายที่สุดในปัจจุบัน RFC 2045 ยังกำหนดค่าการเข้ารหัสการถ่ายโอนเนื้อหาอื่นๆ (7bit, 8bit, เครื่องหมายคำพูด-พิมพ์ได้) โดยให้ตัวเลือกระบบเมลตามประเภทเนื้อหา ตัวเลือกตัวอักษรจะหลีกเลี่ยงอักขระที่แตกต่างกันระหว่าง ASCII และ EBCDIC (การเข้ารหัสอักขระเมนเฟรม IBM) อักขระ A-Z, a-z, 0-9, + และ / เหมือนกันในการเข้ารหัสทั้งสอง PEM-บล็อกสไตล์สามารถจดจำได้เนื่องจากป้ายกำกับล้อมรอบวัสดุที่เข้ารหัส ToolAcre สามารถประมวลผลเนื้อหา Base64 ที่แยกออกมาได้หลังจากที่ป้ายกำกับเหล่านั้นถูกลบออก ไม่สามารถระบุได้ว่าข้อกำหนดการเก็บถาวรแบบใดที่ใช้แบบแผนที่กำหนดเป็นครั้งแรก และบทความนี้ไม่ได้แสร้งทำเป็นว่าแผนผังต้นทางตอบคำถามนั้น
PEM-ชุดเกราะเป็นรูปแบบที่ทันสมัยที่สังเกตได้ โดยไม่ต้องอ้างเรื่องราวต้นกำเนิด
อักขระ เช่น วงเล็บเปิดและวงเล็บปิดแตกต่างกันระหว่าง ASCII และ EBCDIC จึงถูกแยกออก สิ่งนี้มีความสำคัญในช่วงทศวรรษ 1980 และต้นทศวรรษ 1990 เมื่อการถ่ายโอนข้อมูลเมนเฟรมไปยังยูนิกซ์เป็นเรื่องปกติ ตัวอักษรยังหลีกเลี่ยงเครื่องหมายแบ็กสแลช เครื่องหมายคำพูดเดี่ยวและเครื่องหมายคำพูดคู่ ซึ่งมีความหมายพิเศษในสตริง C และไวยากรณ์ของเชลล์ สามารถฝังสตริง Base64 ในโปรแกรม C หรือเชลล์สคริปต์ได้โดยไม่ต้อง Escape อักขระเกือบทุกตัว
RFC 3548 (2006) รวมการเข้ารหัส Base64, base32 และ base16 โดยสังเกตว่า MIME, PEM และแอปพลิเคชันอื่นๆ ทั้งหมดใช้แนวคิดที่คล้ายกัน แต่มีกฎการเติมและตัวอักษรที่แตกต่างกัน RFC 4648 (2006 เผยแพร่ควบคู่ไปกับ RFC 3548) เป็นมาตรฐานปัจจุบัน และกำหนดตระกูลการเข้ารหัสห้าตระกูลพร้อมเวกเตอร์ทดสอบสำหรับแต่ละรายการ RFC ยังบันทึกประวัติ: เอกสารใดที่กำหนดการเข้ารหัส อะไรเปลี่ยนแปลงระหว่างเวอร์ชัน และเหตุใดจึงตัดสินใจเลือก ตัวเลือกการตัดอักขระ 76 ของตัวเข้ารหัสและการลบช่องว่างของตัวถอดรหัสทำให้ตัวอย่างที่มีรูปทรง MIME สามารถทดสอบได้ ข้อเท็จจริงในการใช้งานเหล่านั้นไม่ได้พิสูจน์ประวัติที่สมบูรณ์ของมาตรฐานเมล สิ่งเหล่านี้แสดงให้เห็นถึงพฤติกรรมความเข้ากันได้สมัยใหม่ที่ผู้อ่านสามารถทำซ้ำได้โดยตรงในแผงควบคุมและการทดสอบ
MIME-การห่อสไตล์เป็นตัวเลือกตัวเข้ารหัส โดยไม่ต้องสร้างประวัติมาตรฐานขึ้นมาใหม่
นักพัฒนาส่วนใหญ่พบเฉพาะ base64 และ base64url ใน RFC 4648; ประวัติได้รับการบันทึกไว้สำหรับผู้ที่จำเป็นต้องใช้เวอร์ชันเก่า Base64url (RFC 4648 ส่วน 5) แทนที่เครื่องหมายบวกด้วยเครื่องหมายขีดกลางและเครื่องหมายทับด้วยขีดล่างเพื่อหลีกเลี่ยงอักขระที่สงวนไว้ URL สตริง base64 ที่มี + และ / จะต้องเข้ารหัสเปอร์เซ็นต์ใน URL (%2B และ %2F); base64url หลีกเลี่ยงสิ่งนั้น
JWT (JSON Web Token) ใช้ base64url โดยไม่มีช่องว่างภายใน แอปพลิเคชั่นบางตัวใช้ base64url พร้อมช่องว่างภายใน RFC กำหนดตัวแปรทั้งสอง มันขึ้นอยู่กับแอปพลิเคชันที่จะเลือก ความแปรปรวนนี้คือสาเหตุที่ตัวถอดรหัส JWT และตัวถอดรหัสอีเมล Base64 อาจสร้างเอาต์พุตที่แตกต่างกันสำหรับสตริงอินพุตเดียวกัน (อันหนึ่งคาดหวัง base64url ส่วนอีกอันคาดหวัง base64) ตัวอักษร กฎการเติม และการตัดบรรทัดล้วนเกิดจากข้อจำกัดในทางปฏิบัติของระบบจริง การพกพาถือเป็นข้อจำกัดด้านตัวอักษรการขนส่งได้ดีที่สุด แทนที่จะเป็นการตรวจสอบประวัติของแต่ละสัญลักษณ์ ตัวอักษรและตัวเลขยังคงมองเห็นได้ชัดเจนในระบบข้อความทั่วไป ในขณะที่เครื่องหมายวรรคตอนสุดท้ายจะแตกต่างกันใน URL-เซฟโหมด เหตุผลในการคัดเลือกทางประวัติศาสตร์ที่แน่นอนถูกละเว้นโดยไม่มีหลักฐานเบื้องต้น
ความสะดวกในการพกพาเป็นข้อจำกัดในการออกแบบ ไม่ใช่บัญชีที่ตรวจสอบแล้วสำหรับตัวเลือกตัวละครแต่ละตัว
ชุดอักขระ 64 ถูกเลือกสำหรับการแสดงข้ามการเข้ารหัส ตัวอักษรได้รับการแก้ไขโดย RFC 1341 และ 1421 และ MIME; กฎการเติมมาจากการจัดตำแหน่ง 3 ไบต์ และการขึ้นบรรทัดใหม่มาจากข้อจำกัดในการส่งอีเมล การใช้งานที่ละเว้นประวัตินี้อาจสร้างการเข้ารหัสใหม่หรือลืมตัวพิมพ์เล็ก RFC 4648 test vector (foobar สร้าง Zm9vYmFy) เป็นวิธีการตรวจสอบว่าการใช้งานเป็นไปตามมาตรฐาน
ทางเลือกสมัยใหม่ เช่น base85 (ใช้ในบางบริบท) มีอยู่ แต่ base64 ยังคงโดดเด่นเนื่องจากโมเมนตัมในอดีตและเพราะมันดีเพียงพอ Base64 ไม่ใช่การเข้ารหัสที่มีขนาดกะทัดรัดที่สุด (base85 และ base91 มีความหนาแน่นมากกว่า) แต่เป็นแบบเรียบง่าย เป็นสากล และผ่านการพิสูจน์แล้ว สิ่งที่ระบุได้อย่างชัดเจนคือคู่ตัวอักษรปัจจุบัน: มาตรฐานลงท้ายด้วยเครื่องหมายบวกและเครื่องหมายทับ URL-ใช้แทนยัติภังค์และขีดล่างอย่างปลอดภัย การหุ้มและการหุ้มเป็นตัวเลือกที่แยกจากกัน การทดสอบครอบคลุมทั้งโหมดและช่องว่างภายในที่ขาดหายไป โดยให้หลักฐานที่สามารถทำซ้ำได้สำหรับพฤติกรรมปัจจุบัน แทนที่จะเป็นลำดับเหตุการณ์ที่อนุมาน
สิ่งที่พื้นที่เก็บข้อมูลพิสูจน์เกี่ยวกับมาตรฐานปัจจุบันและตัวอักษร URL-safe
ค่าใช้จ่ายขนาด 33 เปอร์เซ็นต์เป็นที่ยอมรับสำหรับการใช้งานส่วนใหญ่ ตัวอักษรมีความเสถียรในการใช้งาน RFC มีความชัดเจนเพียงพอว่าการเบี่ยงเบนมักจะเกิดขึ้นโดยเจตนา (เช่น การละเว้นการเติมหรือการจัดการช่องว่าง) แทนที่จะเป็นความเข้าใจผิดโดยไม่ได้ตั้งใจ
การทำความเข้าใจประวัติ Base64 อธิบายว่าทำไมมันถึงเป็นเช่นนั้น อักขระบวกและเครื่องหมายทับเป็นตัวเลือกโดยเจตนาเพื่อหลีกเลี่ยงความคลุมเครือในการเข้ารหัสอักขระที่แตกต่างกัน กฎการเติมมาจากการจัดกลุ่ม 3 ไบต์ Base85 และ Ascii85 ใช้ขนาดและตัวอักษรของกลุ่มที่แตกต่างกันและอยู่นอกเหนือการใช้งาน การกล่าวถึงพวกเขาไม่ได้ทำให้หน้านี้กลายเป็นตัวแปลงสำหรับพวกเขา การเปรียบเทียบความหนาแน่นหรือประวัติจะต้องใช้แหล่งที่มาและเวกเตอร์ทดสอบนอกเหนือจากไฟล์ Base64 ที่ได้รับการตรวจสอบสำหรับโมดูลนี้
ประเด็นสำคัญ: อักขระทุกตัวถูกเลือกด้วยเหตุผล - วิธีที่ตัวเข้ารหัสและตัวถอดรหัส Base64 ใช้ตัวอักษรมาตรฐานที่ส่งผลให้
การตัดบรรทัดมาจากอีเมล การตัดสินใจแต่ละครั้งมีขึ้นเพื่อแก้ไขปัญหาจริงกับระบบจริง ปัจจุบัน Base64 ส่วนใหญ่จะใช้ในบริบท (JWT, API, URI ข้อมูล) โดยที่ประวัติไม่สำคัญ แต่กฎตัวอักษรและช่องว่างภายในได้รับการสืบทอดมาจาก MIME และ PEM ถึง RFC 4648
การอ่าน RFC หนึ่งครั้งและเข้ารหัสสตริงทดสอบในเครื่องมือตัวเข้ารหัสและตัวถอดรหัส Base64 จะเชื่อมโยงมาตรฐานปัจจุบันเข้ากับรากฐานทางประวัติศาสตร์ ตัวอักษรมาตรฐานที่ได้จะปรากฏให้เห็นทุกครั้งที่อินพุตถึงดัชนีหกสิบสองหรือหกสิบสาม ใช้ตัวอย่างที่สร้างตำแหน่งเหล่านั้น สลับ URL-โหมดปลอดภัย และเปรียบเทียบเฉพาะเครื่องหมายวรรคตอนที่เปลี่ยนแปลงเท่านั้น การทดลองดังกล่าวแสดงให้เห็นถึงรูปแบบในปัจจุบันโดยไม่ต้องอาศัยเรื่องราวที่ไม่ได้รับการสนับสนุนเกี่ยวกับการประดิษฐ์ของมัน