เครื่องมือสำหรับนักพัฒนา · ตัวเข้ารหัสและตัวถอดรหัส Base64
เหตุใดการวาง Base64 จึงล้มเหลวในการถอดรหัส: การตัดบรรทัด การขึ้นบรรทัดใหม่ และเครื่องหมายคำพูดอัจฉริยะ
· เหตุใดจึงสำคัญ
base64 การเข้ารหัส
Base64 ไม่ค่อยหยุดพักระหว่างทาง มันแตกในคลิปบอร์ด โพสต์นี้จะรวบรวมข้อผิดพลาดในการคัดลอกและวางที่ทำให้เกิดข้อผิดพลาดเกี่ยวกับอักขระและความยาวที่ไม่ถูกต้อง รวมถึงวิธีระบุข้อผิดพลาดอย่างรวดเร็ว
กุญแจที่ทำงานในเทอร์มินัลแต่ใช้งานไม่ได้ในเบราว์เซอร์ — อักขระที่มองไม่เห็นหนึ่งตัวและการค้นหาสองชั่วโมง
วิศวกรคัดลอกคีย์ API จากเทอร์มินัลเพื่อทดสอบในสคริปต์ รหัสทำงานได้ดีในเทอร์มินัล แต่ล้มเหลวด้วยอักขระที่ไม่ถูกต้องเมื่อวางลงในเครื่องมือเบราว์เซอร์ สองชั่วโมงต่อมา หลังจากค้นหาโค้ด การกำหนดค่า และเอกสาร พวกเขาก็ค้นพบอักขระที่มองไม่เห็นตัวหนึ่ง บรรทัดใหม่ที่ท้ายคีย์ ซึ่งเพิ่มด้วยเสียงสะท้อนหรือคัดลอกจากบรรทัดพรอมต์เทอร์มินัล กลายเป็นอักขระพิเศษที่ทำให้ตัวถอดรหัส Base64 เสียหาย กุญแจถูกต้อง คลิปบอร์ดไม่ได้ ข้อมูล Base64 มีความน่าเชื่อถือเมื่อส่งทางอิเล็กทรอนิกส์ ตรวจสอบและตรวจสอบ มันพังเกือบทั้งหมดในระหว่างการคัดลอกและวางด้วยตนเอง
การตัดบรรทัดในเทอร์มินัล การขึ้นบรรทัดใหม่ต่อท้ายจากเอาต์พุตคำสั่ง การทดแทนคำพูดอัจฉริยะในโปรแกรมแก้ไขข้อความแบบ Rich Text และอักขระ Unicode ที่ซ่อนอยู่จากการคัดลอกและวางระหว่างแอปพลิเคชันต่างๆ ล้วนทำให้เกิดข้อผิดพลาดที่ดูเหมือนว่า Base64 จะใช้งานไม่ได้เมื่อปัญหาจริงอยู่ที่วิธีการคัดลอก โพสต์นี้จะรวบรวมข้อผิดพลาดที่พบบ่อยที่สุดและแสดงวิธีระบุและแก้ไขข้อผิดพลาดแต่ละรายการอย่างรวดเร็ว ตัวอักษร Base64 ประกอบด้วยตัวอักษรตัวพิมพ์ใหญ่และตัวพิมพ์เล็ก ตัวเลข เครื่องหมายบวก เครื่องหมายทับ และอักขระเสริม (เครื่องหมายเท่ากับ) RFC 4648 มีความเฉพาะเจาะจง: สตริง Base64 มาตรฐานประกอบด้วยอักขระเหล่านั้นเท่านั้น บวกกับช่องว่างเพิ่มเติมหากมีการตัดบรรทัด
การตัดบรรทัดจากเทอร์มินัล ไคลเอนต์อีเมล และการจัดรูปแบบ PEM — ทำไมการแบ่งคอลัมน์ 76 จึงดีสำหรับตัวถอดรหัสบางตัว และเป็นอันตรายถึงชีวิตสำหรับผู้อื่น
เครื่องมือจำนวนมากยอมรับการเบี่ยงเบน: พวกเขายอมรับ URL รูปแบบที่ปลอดภัยโดยใช้เครื่องหมายขีดกลางและขีดล่างแทนเครื่องหมายบวกและเครื่องหมายทับ หรือไม่ก็ละเว้นการขึ้นบรรทัดใหม่ ตัวถอดรหัสที่เข้มงวดซึ่งตามหลัง RFC จะปฏิเสธสิ่งใดก็ตามที่อยู่นอกชุดอักขระที่คาดไว้ และล้มเหลวโดยมีข้อผิดพลาดของอักขระที่ไม่ถูกต้อง ข้อความแสดงข้อผิดพลาดมักจะตั้งชื่ออักขระที่ละเมิดหรือบันทึกย่อว่าสตริงไม่สามารถถอดรหัสได้เลย เมื่อวาง Base64 จากอีเมล เทอร์มินัล ประวัติการแชท หรือเอกสารที่จัดรูปแบบ อักขระที่มองไม่เห็นหรือการแทนที่อักขระมักจะหลุดเข้ามาและทำให้การถอดรหัสล้มเหลว ข้อมูลนั้นใช้ได้ การถ่ายโอนคลิปบอร์ดทำให้เสียหาย
การตัดบรรทัดเป็นสาเหตุที่พบบ่อยที่สุดของข้อผิดพลาด Base64 ที่ถูกวาง และยังเป็นวิธีแก้ไขได้ง่ายที่สุดอีกด้วย เครื่องมือเทอร์มินัลตัดเอาต์พุตที่ 76 อักขระต่อบรรทัดหรือบางครั้ง 80 โดยแทรกบรรทัดใหม่และดำเนินการต่อในบรรทัดถัดไป ตัวเข้ารหัสจำนวนมาก รวมถึงไลบรารีที่เข้ารหัส Base64 บางตัวจะรวมเอาต์พุตไว้ที่ขอบเขต 76 อักขระเดียวกันเพื่อให้เข้ากันได้กับอีเมล MIME เมื่อคุณคัดลอกสตริง Base64 ที่ห่อไว้จากเทอร์มินัล บรรทัดใหม่จะตามมา
การขึ้นบรรทัดใหม่ต่อท้ายจากเครื่องมือ echo และคลิปบอร์ด - ไบต์พิเศษที่กลายเป็นอักขระพิเศษ
ตัวถอดรหัสบางตัวยอมรับและละเว้นการขึ้นบรรทัดใหม่โดยอัตโนมัติ คนอื่นปฏิเสธว่าเป็นอักขระที่ไม่ถูกต้อง การแก้ไขคือการลบบรรทัดใหม่และช่องว่างทั้งหมด หากสตริง Base64 ถูกพันข้ามหลายบรรทัดในเทอร์มินัล ให้เลือกบรรทัดทั้งหมด คัดลอกลงในโปรแกรมแก้ไข และลบบรรทัดใหม่ทั้งหมด
คัดลอกสตริงบรรทัดเดียวที่ได้และวางลงในตัวถอดรหัส นี่เป็นสิ่งแรกที่ต้องลองเมื่อวางล้มเหลว การขึ้นบรรทัดใหม่ต่อท้ายจากยูทิลิตี้ echo และคลิปบอร์ดเป็นอีกสาเหตุหนึ่งที่พบบ่อย คำสั่ง echo $API_KEY พิมพ์คีย์ตามด้วยการขึ้นบรรทัดใหม่ ซึ่งเป็นพฤติกรรมมาตรฐานของคำสั่ง หากคุณคัดลอกเอาต์พุตนั้นโดยตรง การขึ้นบรรทัดใหม่จะรวมอยู่ในสำเนาด้วย เทอร์มินัลบางตัวจะเพิ่มการขึ้นบรรทัดใหม่เพิ่มเติมเมื่อคุณคัดลอก และผู้จัดการคลิปบอร์ดบางตัวจะคงหรือทำซ้ำการขึ้นบรรทัดใหม่ อาการจะเหมือนกับการตัดบรรทัด: มีอักขระพิเศษที่ส่วนท้ายของสตริงที่ไม่อยู่ใน Base64
เครื่องหมายคำพูดอัจฉริยะ การเว้นวรรคแบบไม่แยก และอักขระที่มีความกว้างเป็นศูนย์ — วิธีที่โปรแกรมแก้ไขข้อความแบบ Rich-Text เขียนข้อความธรรมดาใหม่
การแก้ไขก็ทำได้ง่ายไม่แพ้กัน: ตัดส่วนปลายของสตริงที่วางในโปรแกรมแก้ไขของคุณก่อนที่จะพยายามถอดรหัส ลบช่องว่างนำหน้าและต่อท้ายและอักขระใดๆ ที่ดูเหมือนขึ้นบรรทัดใหม่ หากสตริงสั้นพอ คุณสามารถพิมพ์อีกครั้งด้วยตนเองได้ แต่สำหรับคีย์ที่ยาว การตัดด้วยตนเองอย่างระมัดระวังจะเร็วกว่า เครื่องหมายคำพูดอัจฉริยะ การเว้นวรรคแบบไม่แยก และการทดแทน Unicode อื่นๆ ถือเป็นกับดักที่ละเอียดอ่อน โปรแกรมแก้ไขข้อความแบบ Rich Text เช่น Word จะแปลงเครื่องหมายคำพูดตรงเป็นเครื่องหมายคำพูดแบบโค้งโดยอัตโนมัติ แปลงเครื่องหมายยัติภังค์สามตัวเป็นเครื่องหมาย em-dash และแปลงลำดับช่องว่างบางอย่างให้เป็นช่องว่างที่ไม่แยก หากมีใครวางสตริง Base64 ลงในเอกสารแล้วคุณคัดลอกสตริงดังกล่าวจากเอกสารที่จัดรูปแบบลงในเครื่องมือ การแทนที่เหล่านั้นจะเกิดขึ้นด้วย
เครื่องหมายคำพูดคู่ตรง (") จะกลายเป็นคู่โค้งซ้ายและขวา ซึ่งทั้ง 2 คู่นี้ใช้ Base64 ไม่ได้ ช่องว่างที่ไม่แยก (U+00A0) มีลักษณะเหมือนกันกับช่องว่างปกติ แต่มีรหัสอักขระที่แตกต่างกัน และ parsers ทั้งหมดไม่รู้จักว่าเป็นช่องว่าง วิธีแก้ไขคือให้วางลงในโปรแกรมแก้ไขข้อความธรรมดาก่อน ซึ่งจะละทิ้งการจัดรูปแบบทั้งหมด หากคุณวางจากเอกสาร Word หรือแชทที่จัดรูปแบบแล้ว ให้วางลงในโปรแกรมแก้ไขข้อความธรรมดาหรือ HTML textarea และตรวจสอบอักขระแปลก ๆ จากนั้นคัดลอกจากเวอร์ชันข้อความธรรมดาเพื่อใช้ในเครื่องมือของคุณ
การตัดทอนและการสูญเสียการเติม - การตรวจสอบ length-modulo-4 ที่บอกคุณว่าอักขระหายไป
การตัดทอนเกิดขึ้นเมื่อสตริงถูกตัดออกระหว่างการคัดลอกหรือวาง สตริง Base64 ที่ยาวมากอาจเกินขีดจำกัดของคลิปบอร์ดในบางระบบ หรือไม่สามารถคัดลอกได้เนื่องจากข้อบกพร่องของแอปพลิเคชัน ผลลัพธ์ที่ได้คือสตริงที่สั้นลงซึ่งไม่สมบูรณ์ สตริง Base64 ต้องมีความยาวเป็นจำนวนเท่าของสี่หลังจากใช้การเติม ถ้าความยาวไม่เป็นจำนวนเท่าของสี่ จะถูกตัดทอนหรือเสียหาย ข้อความแสดงข้อผิดพลาดมักจะระบุว่าความยาวของสตริงไม่ถูกต้องหรืออักขระหายไป การแก้ไขจำเป็นต้องรู้ว่าสิ่งใดถูกคัดลอกมาแต่แรก
หากคุณสามารถตรวจสอบแหล่งที่มาได้อีกครั้ง ให้คัดลอกอีกครั้งอย่างระมัดระวัง ถ้าไม่เช่นนั้น การตัดทอนจะไม่สามารถกู้คืนได้ การสูญเสียการเติมเป็นปัญหาที่เกี่ยวข้อง: บางครั้งการเติม Base64 ที่มีเครื่องหมายเท่ากับจะถูกตัดออกเพื่อบันทึกสองสามไบต์ แอปพลิเคชันบางรายการละเว้นช่องว่างภายในและบางแอปพลิเคชันจำเป็นต้องใช้ หากเดิมเชือกถูกบุนวมไว้และขาดหายไป ให้เพิ่มกลับเข้าไป สตริง Base64 ควรมี 0, 1 หรือ 2 ต่อท้ายเท่ากับเครื่องหมาย โดยที่ความยาวทั้งหมดจะเป็นผลคูณของสี่ หากไม่มีและความยาวไม่เป็นทวีคูณของสี่ ช่องว่างภายในอาจหายไป
ตัวอย่างการทำงาน: การซ่อมแซมสตริงที่พันและถูกตัดทอน — ทำความสะอาดทีละขั้นตอนจนกว่าจะถอดรหัส
ตัวอย่างการทำงานจะแสดงการซ่อมแซมเหล่านี้ทีละขั้นตอน สมมติว่าคีย์ API ที่คัดลอกมาปรากฏเช่นนี้ในตัวแก้ไขของคุณ: VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0Cg== เริ่มต้นด้วยการระบุปัญหา Cg== ต่อท้ายเป็นเลขคี่ Cg เป็น base64 สำหรับอักขระขึ้นบรรทัดใหม่ (ฐานสิบหก 0A) และเครื่องหมายพิเศษ == หมายถึงมีบางสิ่งเพิ่มเข้ามา ลบ Cg== ต่อท้ายแล้วลอง VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0 นั่นยังไม่ถูกต้อง ความยาวคือ 37 อักขระ ไม่ใช่ผลคูณของสี่ ตัดอีกครั้ง: VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0 (อักขระ 35 ยังคงผิด) ตรวจสอบแหล่งที่มาดั้งเดิม สตริงที่ถูกต้องคือ VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0 (อักขระ 32) โดยมีช่องว่างภายในที่เหมาะสม: VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0 เพิ่ม: VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0=
ทดสอบในตัวถอดรหัส สิ่งนี้ถอดรหัสเป็นนี่ไม่ใช่ความลับจริงๆ ในแต่ละขั้นตอน ให้ใช้ตัวเข้ารหัสและตัวถอดรหัส Base64 เพื่อทดสอบสตริงปัจจุบัน แก้ไขปัญหาที่ระบุ และทดสอบอีกครั้งจนกว่าจะถอดรหัส การทุจริตภายในไบต์ Base64 เองไม่สามารถแก้ไขได้โดยตัวถอดรหัส หากไบต์เสียหายจริงจากการขนส่ง การส่งข้อมูล หรือการจัดเก็บ Base64 เองก็ไม่สามารถตรวจพบได้ RFC ระบุอักขระที่ถูกต้อง ตัวละครใดๆ ที่อยู่นอกชุดนั้นเป็นงานถอดรหัสที่ต้องจับ ความเสียหายของไบต์ใดๆ เช่น 0 กลายเป็น 1 ตรงกลางอักขระ Base64 จะสร้างโค้ดอักขระที่แตกต่างออกไปโดยสิ้นเชิง และ Base64 เพียงอย่างเดียวตรวจไม่พบ
สิ่งนี้ไม่ครอบคลุมถึงความเสียหายภายในไบต์ที่เข้ารหัสซึ่ง Base64 เองก็ไม่สามารถตรวจพบได้
เช็คซัมหรือลายเซ็นดิจิทัลใช้ในการตรวจจับความเสียหายประเภทนี้ และจะต้องคำนวณบนข้อมูลไบนารีดั้งเดิมก่อนการเข้ารหัส Base64 หากคุณถอดรหัสสตริง Base64 และผลลัพธ์เป็นขยะหรือแตกต่างจากที่คุณคาดไว้ ความเสียหายจะเกิดขึ้นก่อนการเข้ารหัสหรือระหว่างการส่ง ไม่ใช่ในขั้นตอนการคัดลอกวาง นี่เป็นสิ่งที่หาได้ยากในทางปฏิบัติ ความล้มเหลวส่วนใหญ่เป็นปัญหาเกี่ยวกับการคัดลอกและวางเช่นเดียวกับปัญหาข้างต้น แนวทางที่เป็นระบบในการดีบักความล้มเหลวในการคัดลอกและวาง Base64 คือการทดสอบปัญหาที่อาจเกิดขึ้นแต่ละรายการตามลำดับ ขั้นแรก ลบช่องว่างและการขึ้นบรรทัดใหม่ทั้งหมด จากนั้นตัดช่องว่างนำหน้าและต่อท้ายและอักขระที่หลงทาง
จากนั้นตรวจสอบความยาวแบบโมดูโลสี่และเพิ่มช่องว่างภายในหากจำเป็น วางแต่ละเวอร์ชันลงในตัวเข้ารหัสและตัวถอดรหัส Base64 แล้วดูว่าถอดรหัสหรือไม่ หากการตรวจสอบความยาวล้มเหลว ให้ถามว่าสตริงถูกตัดทอนและดึงข้อมูลจากแหล่งต้นฉบับหรือไม่ หากการตรวจสอบตัวอักษรล้มเหลวและคุณเห็นอักขระที่ผิดปกติ ให้มองหาเครื่องหมายคำพูดอัจฉริยะหรือการแทนที่ Unicode และแทนที่ด้วย ASCII ที่เทียบเท่ากัน ใช้เครื่องมือออนไลน์ที่แสดงอักขระที่ไม่ถูกต้องตามชื่อ เพื่อให้คุณสามารถระบุและลบอักขระเหล่านั้นได้ ตัวเข้ารหัสและตัวถอดรหัส Base64 ทำสิ่งนี้กับอักขระที่ไม่ถูกต้องทุกตัว โดยระบุว่าอักขระตัวใดไม่อยู่ในตัวอักษร
ประเด็นสำคัญ: ตรวจสอบความยาวและตัวอักษรก่อนตำหนิข้อมูล — ตัวเข้ารหัสและตัวถอดรหัส Base64 ช่วยให้คุณมีสถานที่ที่รวดเร็วเพื่อทดสอบการซ่อมแซมแต่ละครั้งได้อย่างไร
ใช้คำติชมนั้นเพื่อแก้ไขอักขระแต่ละตัวและดำเนินการต่อจนกว่าสตริงจะถอดรหัส การป้องกันง่ายกว่าการแก้ไข เมื่อคุณรู้ว่าคุณจะต้องใช้สตริง Base64 อีกครั้ง ให้คัดลอกในลักษณะที่คงการจัดรูปแบบไว้ อย่าวางลงในเอกสาร Rich Text เก็บไว้ในไฟล์ข้อความธรรมดาหรือพื้นที่ข้อความที่กำหนดซึ่งไม่มีการทดแทน หากมีคนส่งสตริง Base64 ให้คุณในข้อความที่จัดรูปแบบแล้ว โปรดขอให้พวกเขาส่งสตริงนั้นอีกครั้งในรูปแบบโค้ดหรือข้อความธรรมดา หากคุณต้องคัดลอกจากแหล่งที่มีการจัดรูปแบบ ให้วางลงในโปรแกรมแก้ไขข้อความธรรมดาก่อนและตรวจสอบสตริงก่อนใช้งาน
ทดสอบสตริงในตัวเข้ารหัสและตัวถอดรหัส Base64 ทันทีที่คุณมีก่อนที่คุณจะเชื่อถือ หากล้มเหลว คุณสามารถขอสำเนาใหม่ได้ในขณะที่ยังเข้าถึงแหล่งที่มาได้ หากคุณรอจนกว่าสตริงเก่าหรือแหล่งที่มาหายไป การแก้ไขการตัดทอนหรือความเสียหายจะเป็นไปไม่ได้ ตัวเข้ารหัสและตัวถอดรหัส Base64 ช่วยให้คุณสามารถทดสอบสตริงใดๆ ได้อย่างรวดเร็วก่อนตัดสินใจใช้งาน ทดสอบตั้งแต่เนิ่นๆ และทดสอบบ่อยๆ เพื่อให้สามารถตรวจพบข้อผิดพลาดในการคัดลอกวางได้ทันที