เครื่องมือแปลง Base64

ชุดอักขระมาตรฐานกับแบบ URL-safe

Base64 ต้องใช้สัญลักษณ์ 64 ตัว หกสิบสองตัวแรกไม่มีใครเถียง คือ A–Z, a–z, 0–9 ส่วนสองตัวสุดท้ายคือจุดที่สองแบบต่างกัน เพราะตัวที่นึกออกก่อนดันมีความหมายอยู่แล้วใน URL

การถอดรหัสที่นี่รับได้ทั้งสองชุดไม่ว่าจะติ๊กช่องหรือไม่ และเติม padding ที่ขาดกลับให้ เพราะข้อมูลที่คัดลอกมาจาก JWT หรือไฟล์ PEM มักไม่มีทั้งสองอย่าง

ทำไมผลลัพธ์ถึงใหญ่ขึ้นหนึ่งในสาม

Base64 เขียนข้อมูลทุก 3 ไบต์ใหม่เป็น 4 ตัวอักษร ผลลัพธ์จึงมีขนาดราว 133% ของข้อมูลเดิมเสมอ บวกอักขระ padding อีกไม่เกินสองตัว

3 ไบต์   → 4 ตัวอักษร
          100 KB   → ประมาณ 137 KB
          1 MB     → ประมาณ 1.37 MB

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

Base64 ไม่ใช่การเข้ารหัสลับ

เรื่องนี้ควรพูดตรง ๆ เพราะคนสับสนกันบ่อยมาก Base64 คือการแปลงรูปแบบที่ย้อนกลับได้ และไม่มีกุญแจ ใครที่อ่านสตริงที่แปลงแล้วได้ ก็อ่านข้อมูลต้นฉบับได้ และเบราว์เซอร์ทุกตัวมีตัวถอดรหัสติดมาอยู่แล้ว

การเอารหัสผ่าน API key หรือ token มาแปลงเป็น Base64 ช่วยกันได้แค่สายตาที่มองผ่าน ๆ เท่านั้น ถ้ามันต้องเป็นความลับจริง สิ่งที่ต้องใช้คือการเข้ารหัสลับ พร้อมกุญแจที่เก็บไว้คนละที่กับข้อมูลที่แปลงแล้ว

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

รองรับภาษาไทยและอิโมจิไหม

รองรับ ระบบจะแปลงข้อความเป็นไบต์ UTF-8 ก่อนเข้ารหัส ฟังก์ชัน btoa() ที่มากับเบราว์เซอร์จะ error เมื่อเจอตัวอักษรนอก Latin-1 เครื่องมือแปลง Base64 หลายตัวจึงพังตั้งแต่ตัวอักษรไทยตัวแรก

โหมด URL-safe มีไว้ทำอะไร

Base64 มาตรฐานใช้ + และ / ซึ่งมีความหมายอยู่แล้วใน URL ชุด URL-safe จะใช้ - และ _ แทน และตัด padding ออก ส่วนการถอดรหัสรับได้ทั้งสองแบบไม่ว่าจะติ๊กช่องนี้หรือไม่

ถอดรหัส Base64 ที่ไม่มี padding หรือมีการขึ้นบรรทัดได้ไหม

ได้ทั้งสองแบบ Base64 ที่คัดลอกมาจากไฟล์ PEM ส่วนหัวอีเมล หรือ JWT มักถูกตัดบรรทัดหรือไม่มี padding ระบบจึงข้ามช่องว่างและเติม padding กลับให้

ทำไม Base64 ที่ได้ถึงใหญ่กว่าของเดิมเสมอ

ใหญ่ขึ้นราวหนึ่งในสาม และเลี่ยงไม่ได้ เพราะ Base64 หยิบข้อมูลทีละสามไบต์แล้วเขียนออกมาเป็นสี่ตัวอักษร ผลลัพธ์จึงเป็นสี่ส่วนสามของต้นฉบับก่อนเติม padding ซึ่งเป็นที่มาของตัวเลข 33% ที่คนพูดกัน นี่คือราคาของรูปแบบนี้ มันมีไว้ส่งข้อมูลไบนารีผ่านช่องทางที่รับได้แต่ตัวอักษร เช่นเนื้อในอีเมลหรือค่าใน JSON ถ้าไฟล์ใหญ่อยู่แล้ว การฝังเป็น data URL จะทำให้หน้าเว็บที่มันอยู่หนักขึ้นอย่างรู้สึกได้ ซึ่งเป็นเหตุผลที่คนมักมาเสียใจทีหลัง

Base64 ใช้ซ่อนข้อมูลได้ไหม

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

ทำไมถอด JWT ด้วยตัวถอดทั่วไปแล้วพังตรงท้าย

เพราะ JWT ใช้ชุดอักขระแบบ URL-safe ไม่ใช่มาตรฐาน สองแบบนี้ต่างกันแค่สองตัวอักษร คือ - กับ _ แทนที่ + กับ / และ JWT มักตัดเครื่องหมาย = ท้ายออกด้วย ตัวถอดที่รับเฉพาะมาตรฐานจึงสะดุดตรงนั้น เครื่องมือนี้รับทั้งสองแบบเสมอ ไม่ว่าจะติ๊กช่อง URL-safe หรือไม่

ข้อมูลของฉันถูกอัปโหลดไหม

ไม่ การเข้ารหัสและถอดรหัสเกิดขึ้นในเบราว์เซอร์ของคุณ และนโยบายความปลอดภัยของเว็บกำหนด connect-src ‘none’ เบราว์เซอร์จึงบล็อกการเรียกเครือข่ายจากหน้านี้