เครื่องมือแปลง Base64 - เครื่องมือแปลง Base64 ออนไลน์ฟรี

การเข้ารหัส Base64 คืออะไร?

Base64 เป็นวิธีเปลี่ยนข้อมูลใด ๆ รวมถึงข้อมูลไบนารีอย่างรูปภาพ ให้เป็นข้อความธรรมดาที่ประกอบด้วยตัวอักษร ตัวเลข และสัญลักษณ์บางส่วนเท่านั้น ตัวเข้ารหัส base64 จะแปลงข้อมูลเป็นรูปแบบข้อความนี้ ส่วน ตัวถอดรหัส base64 จะเปลี่ยนกลับเป็นข้อมูลเดิม โปรแกรมใช้ Base64 เพื่อส่งข้อมูลไบนารีผ่านระบบต่าง ๆ ได้อย่างปลอดภัย เช่น อีเมลหรือ JSON ซึ่งต้องการข้อความธรรมดา

Base64 ใช้ชุดอักขระจำนวน 64 ตัว:

• ตัวอักษรภาษาอังกฤษตัวพิมพ์ใหญ่ A–Z (จำนวน 26 ตัว)
• ตัวอักษรภาษาอังกฤษตัวพิมพ์เล็ก a–z (จำนวน 26 ตัว)
• ตัวเลข 0–9 (จำนวน 10 ตัว)
• สัญลักษณ์สองตัว โดยทั่วไปคือ + และ / (จำนวน 2 ตัว)

บางระบบยังใช้เครื่องหมายเท่ากับ (=) ท้ายผลลัพธ์เป็นแพดดิง แพดดิงไม่ใช่ส่วนหนึ่งของชุดอักขระจำนวน 64 ตัว แต่ใช้เติมความยาวให้ครบ

เหตุผลที่มี Base64

โปรโตคอลข้อความรุ่นเก่าจำนวนมาก รวมถึงอีเมล (SMTP) และบางส่วนของ HTTP ถูกสร้างขึ้นเพื่อรองรับข้อความ ASCII แบบ 7 บิต โปรโตคอลเหล่านี้อาจทำให้ไบต์ไบนารีดิบเสียหาย เช่น ไบต์ภายในรูปภาพ JPEG Base64 แก้ปัญหานี้ด้วยการแทนทุกไบต์โดยใช้อักขระที่ปลอดภัยและพิมพ์ได้เท่านั้น ด้วยเหตุนี้ ไฟล์แนบอีเมล รูปภาพที่ฝังในเว็บเพจ และฟิลด์ไบนารีภายใน JSON จึงมักถูกแปลงผ่าน Base64 ก่อน

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

วิธีใช้เครื่องมือนี้

1. พิมพ์หรือวางข้อความลงในช่องป้อนข้อมูล
2. เลือก "เข้ารหัสเป็น Base64" เพื่อแปลงข้อความเป็น Base64 หรือเลือก "ถอดรหัสจาก Base64" เพื่อแปลงสตริง Base64 กลับเป็นข้อความ
3. เปิดการแปลงแบบสดเพื่อให้ผลลัพธ์อัปเดตโดยอัตโนมัติขณะพิมพ์
4. คัดลอกผลลัพธ์ด้วยปุ่มคัดลอก

เครื่องมือนี้อ่านและเขียนข้อความ Unicode มาตรฐาน ดังนั้นตัวอักษรที่มีเครื่องหมายกำกับ สัญลักษณ์ และอีโมจิจึงเข้ารหัสและถอดรหัสได้ถูกต้อง ไม่ใช่แค่ตัวอักษรภาษาอังกฤษธรรมดา

การทำงานของการเข้ารหัส Base64

Base64 เปลี่ยนทุก 3 ไบต์ของข้อมูลนำเข้า (24 บิต) ให้เป็นอักขระผลลัพธ์ 4 ตัว (แต่ละตัวเก็บ 6 บิต) เพราะ 24 หารด้วย 6 เท่ากับ 4

1. นำไบต์ข้อมูลเข้าและเขียนให้อยู่ในรูปเลขฐานสอง
2. จัดกลุ่มบิตเป็นชุดละ 24 บิต (3 ไบต์)
3. แบ่งชุดบิตขนาด 24 บิตแต่ละชุดออกเป็นสี่ส่วน ส่วนละ 6 บิต
4. ค้นหาค่าตัวเลขขนาด 6 บิตแต่ละค่า (ตั้งแต่ 0 ถึง 63) ในชุดอักขระ Base64 แล้วเขียนอักขระที่ตรงกัน

หากความยาวข้อมูลนำเข้าไม่ใช่จำนวนเท่าของ 3 ชุดสุดท้ายจะสั้น ตัวเข้ารหัสจะเติมบิตศูนย์ แล้วเพิ่มอักขระ = ในผลลัพธ์ เพื่อให้ผลลัพธ์ยังจัดเป็นกลุ่มละ 4 ตัวได้:

• ไบต์ที่เหลือหนึ่งไบต์ให้ผลเป็นอักขระ Base64 2 ตัว และ ==
• ไบต์ที่เหลือสองไบต์ให้ผลเป็นอักขระ Base64 3 ตัว และ = หนึ่งตัว

ตัวอย่างการเข้ารหัส Base64

การเข้ารหัสคำว่า "Hello":

1. ค่า ASCII: 72, 101, 108, 108, 111
2. เลขฐานสอง: 01001000 01100101 01101100 01101100 01101111
3. 3 ไบต์แรก (24 บิต) แบ่งเป็นกลุ่มละ 6 บิตสี่กลุ่ม: 010010 000110 010101 101100 ซึ่งเป็นตัวเลข 18, 6, 21, 44 → อักขระ S, G, V, s
4. 2 ไบต์ที่เหลือ (16 บิต) แบ่งเป็นกลุ่มละ 6 บิตสามกลุ่ม โดยเติมบิตศูนย์ท้ายสุด 2 บิต: 011011 000110 111100 ซึ่งเป็นตัวเลข 27, 6, 60 → อักขระ b, G, 8
5. เนื่องจากเหลือ 2 ไบต์ จึงเพิ่ม = หนึ่งตัวที่ท้ายสุด
6. ผลลัพธ์: SGVsbG8=

การถอดรหัสจะย้อนขั้นตอนเหล่านี้: อักขระแต่ละตัวถูกแปลงกลับเป็นค่าตัวเลขขนาด 6 บิต จากนั้นนำบิตมาต่อกันเป็นสายข้อมูล และอ่านสายข้อมูลนั้นกลับออกมาเป็นไบต์ขนาด 8 บิต

สูตรคำนวณความยาวที่เข้ารหัสแบบ Base64

สำหรับข้อมูลนำเข้าขนาด n ไบต์ ความยาวที่เข้ารหัสเป็นจำนวนอักขระคือ:

encoded_length = 4 × ⌈n / 3⌉

โดย ⌈x⌉ หมายถึงการปัดขึ้นเป็นจำนวนเต็มถัดไป สูตรนี้แสดงให้เห็นว่าเอาต์พุต Base64 มีขนาดใหญ่กว่าข้อมูลนำเข้าประมาณหนึ่งในสามเสมอ: อักขระผลลัพธ์ 4 ตัวต่อข้อมูลนำเข้า 3 ไบต์ คิดเป็นการเพิ่มขึ้น 33%

Base64 ใช้ที่ใดบ้าง

• ไฟล์แนบอีเมล (MIME) อีเมลถูกสร้างขึ้นเพื่อรองรับข้อความ ดังนั้นไฟล์แนบจึงถูกแปลงเป็น Base64 ก่อนส่ง ทำให้ไฟล์แนบมีขนาดใหญ่กว่าต้นฉบับประมาณ 33%
• Data URI รูปภาพขนาดเล็กสามารถฝังไว้โดยตรงใน HTML หรือ CSS ในรูปข้อความ เช่น data:image/png;base64,iVBORw0KGgo... ทำให้ไม่ต้องร้องขอไฟล์แยกต่างหาก วิธีนี้เหมาะที่สุดกับไฟล์ขนาดเล็ก เพราะไฟล์ขนาดใหญ่จะทำให้หน้าเว็บมีขนาดมากขึ้นและไม่สามารถแคชแยกต่างหากได้
• API และ JSON JSON ไม่มีวิธีดั้งเดิมสำหรับเก็บข้อมูลไบนารีดิบ ดังนั้นไฟล์ไบนารีที่ส่งผ่าน API แบบ JSON จึงมักถูกเข้ารหัสเป็น Base64 ก่อน
• การยืนยันตัวตนพื้นฐานของ HTTP ส่วนหัว Authorization จะเข้ารหัสชื่อผู้ใช้และรหัสผ่านเป็น Base64 เช่น Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ= วิธีนี้ไม่ปลอดภัยด้วยตัวมันเอง เพราะผู้ที่ดักรับข้อมูลสามารถอ่านข้อมูลรับรองได้ ดังนั้นควรใช้การยืนยันตัวตนพื้นฐานผ่าน HTTPS เท่านั้น
• JSON Web Token (JWT) แต่ละส่วนจากทั้งหมดสามส่วนของ JWT จะถูกเข้ารหัสด้วย Base64URL ซึ่งเป็นรูปแบบที่ปลอดภัยสำหรับใส่ไว้ใน URL
• การเก็บข้อมูลไบนารีเป็นข้อความ ฐานข้อมูลหรือไฟล์กำหนดค่าที่รับเฉพาะข้อความอาจเก็บข้อมูลไบนารีเป็นสตริง Base64

Base64 เมื่อเปรียบเทียบกับการเข้ารหัสแบบอื่น

Base64 ที่ปลอดภัยสำหรับ URL แทนที่อักขระมาตรฐาน + และ / ด้วย - และ _ เนื่องจาก + และ / มีความหมายพิเศษภายใน URL วิธีนี้ใช้กับ JWT พารามิเตอร์คำค้นของ URL และชื่อไฟล์ เครื่องมือนี้สร้างผลลัพธ์ Base64 มาตรฐาน การแปลงเป็นรูปแบบที่ปลอดภัยสำหรับ URL ทำได้เพียงสลับอักขระสองตัวนี้

Base32 ใช้ชุดอักขระจำนวน 32 ตัว ดังนั้นแต่ละตัวจึงเก็บข้อมูลได้ 5 บิต แทนที่จะเป็น 6 บิต โดยแปลงทุก 5 ไบต์เป็นอักขระ 8 ตัว มีส่วนเกิน 60% (8 ÷ 5 = 1.6) เมื่อเทียบกับ 33% สำหรับ Base64 มักเลือกใช้ Base32 เมื่อผลลัพธ์ต้องเขียนด้วยมือหรืออ่านทางโทรศัพท์ เพราะไม่มีตัวอักษรพิมพ์เล็กพิมพ์ใหญ่ปะปนกันและหลีกเลี่ยงอักขระที่สับสนได้ง่าย

เลขฐานสิบหก ใช้อักขระ 16 ตัว (0–9, A–F) และต้องใช้อักขระ 2 ตัวต่อไบต์ ทำให้ขนาดเพิ่มเป็นสองเท่า (ส่วนเกิน 100%) มักใช้แสดงค่าแฮช สี และที่อยู่ MAC ซึ่งความอ่านง่ายสำคัญกว่าขนาดที่กะทัดรัด

กรณีที่ไม่ควรใช้ Base64

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

ข้อผิดพลาดที่พบบ่อย

• ข้ามการแปลงเป็น UTF-8 การเข้ารหัสข้อความที่มีตัวอักษรพร้อมเครื่องหมายกำกับหรืออีโมจิโดยไม่แปลงเป็นไบต์ UTF-8 ก่อน อาจทำให้ผลลัพธ์เสียหาย
• ตัดแพดดิงออก บางระบบลบอักขระ = ท้ายสตริง ตัวถอดรหัสส่วนใหญ่ยังทำงานได้หากเติมแพดดิงกลับจนความยาวเป็นจำนวนเท่าของ 4 แต่ไม่ใช่ทุกตัวที่ยอมรับรูปแบบนี้ ดังนั้นการเก็บแพดดิงไว้จึงปลอดภัยกว่า
• มีการขึ้นบรรทัดใหม่หลงเหลือ ตัวเข้ารหัสรุ่นเก่าที่ใช้ MIME จะแทรกการขึ้นบรรทัดใหม่ทุก ๆ 76 อักขระ ตัวถอดรหัสสมัยใหม่ส่วนใหญ่ต้องการสตริงต่อเนื่องบรรทัดเดียวโดยไม่มีการขึ้นบรรทัดใหม่
• ใช้รูปแบบสลับกัน Base64 มาตรฐานและ Base64 ที่ปลอดภัยสำหรับ URL ใช้อักขระต่างกันในสองตำแหน่งเดียวกันของชุดอักขระ การถอดรหัสด้วยรูปแบบผิดจะให้ข้อมูลไร้ความหมายหรือเกิดข้อผิดพลาด

คำถามที่พบบ่อย

Base64 เป็นรูปแบบการเข้ารหัสลับหรือไม่ ไม่ใช่ Base64 เป็นการเข้ารหัสข้อความที่ย้อนกลับได้ ไม่ใช่การเข้ารหัสลับ ทุกคนสามารถถอดรหัสสตริงดังกล่าวได้ทันทีโดยไม่ต้องใช้รหัสผ่าน หากข้อมูลต้องเก็บเป็นความลับ ให้ใช้อัลกอริทึมการเข้ารหัสลับ เช่น AES

ทำไม Base64 จึงทำให้ข้อมูลมีขนาดใหญ่ขึ้น เพราะใช้อักขระเต็มหนึ่งตัวเพื่อเก็บข้อมูลเพียง 6 บิต ขณะที่ไบต์ดิบหนึ่งไบต์เก็บข้อมูลได้ 8 บิต การแปลง 3 ไบต์ (24 บิต) เป็นอักขระ 4 ตัว ทำให้ผลลัพธ์มีขนาด 4/3 หรือใหญ่กว่าข้อมูลนำเข้าประมาณ 33%

Base64 เข้ารหัสรูปภาพและไฟล์ไบนารีอื่น ๆ ได้หรือไม่ ได้ ไฟล์ไบนารีใด ๆ รวมถึงรูปภาพ PDF และเสียง สามารถเข้ารหัสเป็น Base64 และถอดกลับเป็นไบต์เดิมได้ครบทุกไบต์ วิธีนี้มักใช้กับรูปภาพขนาดเล็กที่ฝังใน HTML หรือ CSS แต่ไม่เหมาะกับไฟล์ขนาดใหญ่

Base64 กับ Base64URL ต่างกันอย่างไร Base64URL แทนอักขระมาตรฐาน + และ / ด้วย - และ _ ทำให้ผลลัพธ์สามารถใส่ใน URL หรือชื่อไฟล์ได้อย่างปลอดภัยโดยไม่ต้องใช้การหลีกอักขระเพิ่มเติม JWT ใช้ Base64URL ด้วยเหตุนี้

ทำไมสตริง Base64 ของฉันจึงเกิดข้อผิดพลาด "invalid" เมื่อถอดรหัส สาเหตุที่พบบ่อยที่สุดคือมีอักขระที่ไม่อยู่ในชุดอักขระ Base64 เช่น - และ _ ซึ่งใช้ในรูปแบบที่ปลอดภัยสำหรับ URL หรือสตริงมีความยาวมากกว่าจำนวนเท่าของ 4 อยู่หนึ่งตัว สตริง Base64 ที่ถูกต้องจะไม่มีความยาวลักษณะนี้ การถอดรหัสยังล้มเหลวเมื่อไบต์ที่ถอดรหัสแล้วไม่ใช่ข้อความ UTF-8 ที่ถูกต้อง เครื่องมือนี้จะละเว้นช่องว่างและการขึ้นบรรทัดใหม่ภายในสตริง และยังถอดรหัสสตริงที่ลบแพดดิง = ท้ายสตริงออกแล้วได้

Base64 มีที่มาอย่างไร เทคนิคนี้มีต้นกำเนิดย้อนกลับไปถึงรูปแบบยุคแรกสำหรับส่งข้อมูลไบนารีผ่านระบบจดหมายที่รับเฉพาะข้อความในช่วงทศวรรษ 1980 และได้รับการกำหนดมาตรฐานอย่างเป็นทางการเป็นส่วนหนึ่งของ MIME ใน RFC 2045 เมื่อปี 1996 ข้อกำหนดอ้างอิงปัจจุบันสำหรับ Base64, Base32 และ Base16 คือ RFC 4648