ตัวเข้ารหัสและถอดรหัส Base32

ข้อความธรรมดาจะถูกเข้ารหัสเป็น UTF-8 ก่อน แล้วจึงแปลงเป็น Base32
0 อักขระขาเข้า

เข้ารหัสและถอดรหัส Base32 ออนไลน์พร้อม 4 รูปแบบ แปลงไฟล์ ควบคุม padding แสดง hex และดาวน์โหลดในเครื่องสำหรับ secret TOTP และ ID ที่อ่านง่าย

คำแนะนำที่เกี่ยวข้อง

Base58 การเข้ารหัสและถอดรหัส

การเข้ารหัส Base64

URL Safe Base64

เลขฐานสิบหก (Hex)

แปลงไฟล์เป็น Base64

ถอดรหัส Base64

Base32 คืออะไร?

Base32 คือการเข้ารหัสจากไบนารีเป็นข้อความ โดยแทน byte ด้วยอักขระที่พิมพ์ได้ 32 ตัว รูปแบบมาตรฐานมาจาก RFC 4648 และใช้ A-Z กับ 2-7 ทุก 5 bit จะกลายเป็น 1 อักขระ ดังนั้นผลลัพธ์มักใหญ่กว่าข้อมูลเดิมประมาณ 60%

Base32 ไม่ใช่รูปแบบที่สั้นที่สุด แต่เหมาะเมื่ออยากลดอักขระพิเศษ ใช้ในระบบไม่สนใจตัวพิมพ์ใหญ่เล็ก หรือมีสตริงที่คนต้องอ่านและพิมพ์ เช่น secret TOTP ค่า DNS/config บางชนิด รหัสเปิดใช้งาน และ ID ที่อ่านง่าย

หน้านี้รองรับ RFC 4648 Base32, Base32hex, Crockford Base32 และ z-base-32 พร้อม validation แบบเข้มงวด การควบคุม padding การตัดบรรทัด การแปลงข้อความ/ไฟล์ และมุมมอง hex

กรณีการใช้งาน

  • ตรวจสอบว่า secret สำหรับ TOTP/OTP เป็น Base32 มาตรฐานหรือไม่ หรือแปลงเป็น Crockford หรือ z-base-32 เพื่อให้อ่านง่ายขึ้น
  • แปลงข้อมูลไบนารี เช่น configuration, ชิ้นส่วน certificate, offline activation code หรือ resource fingerprint ให้เป็นสตริงที่อ่านง่ายและไม่มีสัญลักษณ์พิเศษมากเกินไป
  • ดีบักค่า Base32 จากระบบภายนอกที่ล้มเหลวเพราะ padding หาย เลือก variant ผิด หรือความยาวผิดปกติ
  • ตรวจ payload Base32 ที่ไม่รู้ชนิดเป็น UTF-8 หรือ hex ก่อน แล้วค่อยดาวน์โหลดเป็นไฟล์ไบนารีหากจำเป็น

วิธีการใช้งาน

  1. เลือก variant ที่ถูกต้องก่อน: RFC 4648, Base32hex, Crockford หรือ z-base-32
  2. เมื่อต้อง encode ให้เลือกข้อความหรือไฟล์ แล้วตั้งค่า padding, ตัวพิมพ์เล็ก และความกว้างการตัดบรรทัด
  3. เมื่อต้อง decode ให้วางสตริง Base32 และเปิด strict validation หากต้องการตรวจความยาวกับ padding
  4. ดูผลลัพธ์ตามชนิดของ payload เป็นข้อความ, hex หรือไฟล์ไบนารีสำหรับดาวน์โหลด

คุณสมบัติ

  • สลับระหว่าง Base32 4 รูปแบบ: RFC 4648, Base32hex, Crockford และ z-base-32
  • รองรับข้อความและไฟล์: เข้ารหัสข้อความ UTF-8 หรือไฟล์ในเครื่องเป็น Base32
  • ดูผลลัพธ์เป็นข้อความ UTF-8, hex หรือไฟล์ไบนารีที่ดาวน์โหลดได้
  • ควบคุม padding, ตัวพิมพ์เล็ก และการตัดบรรทัดที่ 64, 76 หรือความกว้างเอง
  • ตรวจความยาวและ padding แบบเข้มงวดในเบราว์เซอร์โดยไม่อัปโหลดข้อมูล

ควรใช้ Base32, Base64 หรือ Base58 เมื่อไร?

ทั้งสามรูปแบบแปลงข้อมูลไบนารีเป็นสตริงที่พิมพ์ได้ แต่เหมาะกับงานคนละแบบ

รูปแบบเหมาะที่สุดสำหรับข้อแลกเปลี่ยน
Base32secret ของ TOTP, ID ที่อ่านง่าย และระบบที่ไม่สนตัวพิมพ์เล็กใหญ่ปลอดภัยต่อการอ่านและพิมพ์มากขึ้น แต่ผลลัพธ์ยาวกว่า Base64
Base64การส่งข้อความ/ไฟล์ทั่วไป, Data URL และ API payloadสั้นกว่า แต่มี +, / และ = ได้; งาน URL หรือชื่อไฟล์มักต้องใช้ URL-safe variantตัวเข้ารหัส Base64Base64 URL Safe
Base58ที่อยู่ที่ต้องคัดลอกด้วยมือ, QR payload สั้น ๆ และ ID แบบ blockchainลดความสับสน 0/O/I/l แต่ไม่ได้อยู่ในตระกูล RFC 4648ตัวเข้ารหัส/ถอดรหัส Base58

Best Practices

ยืนยัน variant ก่อนดีบัก

ปัญหา Base32 ที่พบบ่อยไม่ได้มาจาก algorithm แต่เกิดจาก alphabet หรือ variant ไม่ตรงกัน หากระบบปลายทางต้องการ Base32hex, Crockford หรือ z-base-32 ผลลัพธ์แบบมาตรฐานอาจดูถูกต้องแต่ใช้งานไม่ได้

ดู hex ก่อนสรุปว่าเป็นข้อความ

ผลลัพธ์หลัง decode ไม่จำเป็นต้องเป็นข้อความ UTF-8 เสมอไป มุมมอง hex ช่วยแยกได้เร็วว่า payload เป็น certificate, header ของรูปภาพ, archive, random key หรือข้อความธรรมดา

ใช้ Crockford หรือ z-base-32 เมื่อต้องพิมพ์เอง

ถ้าเป้าหมายคือการลดความผิดพลาดจากคนมากกว่าการยึด RFC 4648 อย่างเคร่งครัด variant เหล่านี้ช่วยลดความสับสน เช่น O/0 และ I/1

อย่าบังคับทุกขั้นให้อยู่ใน Base32

หลาย workflow ขั้นต่อไปเหมาะกับ Base64, hex หรือไฟล์ต้นฉบับมากกว่า การเปลี่ยน format ตามงานมักสะดวกกว่า

ตัวเข้ารหัส Base64Hex

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

ควรเลือก Base32 หรือ Base64 เมื่อใด?

Base64 สั้นกว่าและใช้ทั่วไปกว่า ส่วน Base32 เหมาะเมื่ออยากลดอักขระพิเศษ ใช้ระบบไม่สนใจตัวพิมพ์ใหญ่เล็ก หรือ secret TOTP ที่คนต้องอ่านและพิมพ์

RFC 4648, Base32hex, Crockford และ z-base-32 ต่างกันอย่างไร?

ต่างกันที่ alphabet และกฎความทนทานต่อข้อผิดพลาด RFC 4648 เป็นมาตรฐานทั่วไป Base32hex ใช้ตัวเลขก่อน Crockford เหมาะกับการพิมพ์มือ และ z-base-32 เน้นตัวพิมพ์เล็กที่อ่านง่าย

Tại sao một số chuỗi Base32 kết thúc bằng =?

RFC 4648 Base32/Base32hex thường dùng = làm padding, còn Crockford và z-base-32 thường bỏ qua.

Decoded output looks wrong

Dữ liệu gốc có thể không phải UTF-8. Hãy xem hex hoặc tải tệp nhị phân.

File conversion supported?

Có. Bạn có thể chuyển tệp sang Base32 rồi khôi phục lại byte nhị phân.

Data upload?

Không. Việc xử lý diễn ra cục bộ trong trình duyệt.

การแก้ไขปัญหา

ทำไมค่าของฉันไม่ตรงกับผลลัพธ์จากระบบภายนอก?

ตรวจ variant ก่อน Base32 มาตรฐาน, Base32hex, Crockford และ z-base-32 ใช้ alphabet ต่างกัน ความต่างเพียงเล็กน้อยก็ทำให้ผลลัพธ์เปลี่ยนทั้งชุด

ทำไม strict mode แจ้งว่าความยาวไม่ถูกต้อง?

อินพุตอาจขาด padding มีอักขระที่ไม่ถูกต้อง หรือถูกสร้างจาก variant อื่น ลองปิด strict mode เพื่อดูเนื้อหาคร่าว ๆ แล้วกลับไปแก้สตริงต้นฉบับ

ทำไมข้อความหลัง decode ว่างหรืออ่านไม่ออก?

ข้อมูลเดิมอาจไม่ใช่ข้อความ UTF-8 แต่อาจเป็นไฟล์ไบนารีหรือ byte สุ่ม ให้ดูแบบ hex หรือดาวน์โหลด binary ที่ decode แล้ว

อภิธานศัพท์

RFC 4648 Base32
รูปแบบ Base32 มาตรฐานที่ใช้บ่อยที่สุด ใช้ A-Z และ 2-7 และอาจมี padding =
Base32hex
รูปแบบลำดับ hexadecimal จาก RFC 4648 ใช้อักขระ 0-9 และ A-V
Crockford Base32
รูปแบบที่เป็นมิตรต่อมนุษย์ ตัด I, L, O, U และยอมรับ O/0 กับ I/1/L/1 ตอนถอดรหัส
z-base-32
รูปแบบสำหรับการป้อนโดยมนุษย์ มักเป็นตัวพิมพ์เล็กและไม่มี padding
padding
อักขระ = ท้ายสตริงที่ใช้เติมความยาวของ Base32 มาตรฐาน

ตารางสรุป 4 variant ของ Base32

หากยังไม่แน่ใจว่าจะเลือก variant ใด ให้ดู alphabet และการใช้งานทั่วไปก่อน

VariantAlphabetมักใช้ =การใช้งานทั่วไป
RFC 4648A-Z + 2-7โดยทั่วไปใช้TOTP และความเข้ากันได้กับ Base32 มาตรฐาน
Base32hex0-9 + A-Vโดยทั่วไปใช้การเรียงตามตัวเลขหรือ field เฉพาะของ protocol
Crockford0-9 + A-Z (without I/L/O/U)โดยทั่วไปไม่ใช้การพิมพ์ด้วยมือ, short code และการทนต่อ typo
z-base-32ybndrfg8ejkmcpqxot1uwisza345h769โดยทั่วไปไม่ใช้สตริงตัวพิมพ์เล็กที่อ่านง่ายกว่า

ความยาวและ padding ของ Base32 มาตรฐาน

ใน RFC 4648 / Base32hex จำนวน = ท้ายสตริงขึ้นอยู่กับจำนวน byte ต้นฉบับ

จำนวน byte inputจำนวนอักขระ Base32 ที่มีข้อมูลpadding = ที่ต้องใช้
126
244
353
471
580

Authoritative References