เข้ารหัสและถอดรหัส Base64 / URL / JWT
เข้ารหัสและถอดรหัส Base64 หรือ URL และดูส่วนหัวกับเพย์โหลดของ JWT ในเบราว์เซอร์
วิธีใช้
- วางหรือพิมพ์ข้อมูลในช่อง “ข้อความหรือ JWT” ได้แก่ ข้อความธรรมดาที่จะเข้ารหัส สตริง Base64 หรือสตริงที่เข้ารหัสแบบเปอร์เซ็นต์ที่จะถอดรหัส หรือ JWT ที่ต้องการตรวจดู
- คลิก “เข้ารหัส Base64” หรือ “ถอดรหัส Base64” เพื่อแปลงระหว่างข้อความกับ Base64 หรือคลิก “เข้ารหัส URL” หรือ “ถอดรหัส URL” เพื่อใส่หรือถอดการเข้ารหัสแบบเปอร์เซ็นต์ ผลลัพธ์หรือข้อความแสดงข้อผิดพลาดจะปรากฏในช่อง “ผลลัพธ์”
- หากต้องการตรวจดูโทเค็น ให้วางโทเค็นโดยจะมีคำนำหน้า Bearer หรือไม่ก็ได้ แล้วคลิก “ถอดรหัส JWT” ส่วนหัวและเพย์โหลดจะแสดงเป็น JSON แบบเยื้องบรรทัด และหากเพย์โหลดมีเคลม iat, nbf หรือ exp เคลมเหล่านั้นจะแสดงไว้ใน “เคลมเวลาของ JWT” โดยค่าที่เป็นตัวเลขจะถูกแปลงเป็นเวลา UTC และเวลาท้องถิ่นของคุณ
- คลิก “คัดลอกผลลัพธ์” เพื่อคัดลอกผลลัพธ์ หากต้องการย้อนการเข้ารหัส ให้วางข้อความที่เข้ารหัสแล้วลงในช่อง “ข้อความหรือ JWT” แล้วคลิกปุ่มถอดรหัสที่ตรงกัน การถอดรหัสแล้วเข้ารหัสกลับอาจไม่ได้ค่าเดิมทุกตัวอักษร Base64 แบบ URL-safe หรือแบบไม่มี padding จะกลับมาเป็นชุดอักขระมาตรฐานพร้อม padding = ในกรณีที่จำเป็น และ “เข้ารหัส URL” จะเปลี่ยนเครื่องหมาย + ที่ “ถอดรหัส URL” คงไว้ให้เป็น %2B
คำถามที่พบบ่อย
ข้อความหรือโทเค็นที่ฉันวางถูกส่งไปที่ใดหรือไม่
ไม่ การเข้ารหัสและถอดรหัสทำงานในเบราว์เซอร์ของคุณด้วย JavaScript และสิ่งที่คุณป้อนจะไม่ถูกส่งไปยัง LeedyBox JWT มักใช้เป็นข้อมูลยืนยันตัวตนสำหรับการเข้าสู่ระบบ และใครก็ตามที่มีโทเค็นอาจใช้งานได้จนกว่าโทเค็นจะหมดอายุหรือถูกเพิกถอน จึงควรดูแลโทเค็นที่ยังใช้งานได้เหมือนรหัสผ่าน และไม่แชร์ในภาพหน้าจอหรือแชท
ทำไม “ถอดรหัส Base64” จึงแจ้งว่าข้อมูลไม่ใช่ข้อความ UTF-8 ที่ถูกต้อง
“ถอดรหัส Base64” จะแสดงไบต์ที่ถอดรหัสแล้วเป็นข้อความ UTF-8 และจะหยุดพร้อมข้อผิดพลาดนี้เมื่อไบต์เหล่านั้นไม่ใช่ UTF-8 ที่ถูกต้อง เช่น รูปภาพ PNG หรือ JPEG ไฟล์ PDF ส่วนใหญ่ และข้อมูลที่บีบอัด และบ่อยครั้งรวมถึงข้อความที่บันทึกด้วยการเข้ารหัสอักขระแบบอื่นอย่าง Latin-1 หรือ Shift_JIS เครื่องมือนี้ไม่บันทึกไบต์ที่ถอดรหัสแล้วเป็นไฟล์ จึงควรใช้กับ Base64 ที่เก็บข้อความ Data URI อย่าง data:image/png;base64,... จะถูกปฏิเสธว่าเป็น Base64 ที่ไม่ถูกต้อง เพราะเครื่องหมายทวิภาค อัฒภาค และจุลภาคไม่ใช่อักขระของ Base64
รองรับ Base64 แบบ URL-safe และค่าที่ไม่มี padding หรือไม่
รองรับเมื่อถอดรหัส “ถอดรหัส Base64” รับได้ทั้งชุดอักขระมาตรฐาน (+ และ /) และชุดอักขระแบบ URL-safe (- และ _) ไม่ว่าจะมี padding = หรือไม่ และจะข้ามช่องว่างกับการขึ้นบรรทัดใหม่ “เข้ารหัส Base64” ให้ผลเป็นชุดอักขระมาตรฐานพร้อม padding หากต้องการรูปแบบ URL-safe ที่ใช้ใน JWT ให้แทน + ด้วย - แทน / ด้วย _ และลบเครื่องหมาย = ท้ายสุดออก ข้อความจะถูกเข้ารหัสเป็น UTF-8 ตรงตามที่ป้อน ช่องว่างหรือการขึ้นบรรทัดใหม่ท้ายข้อความจึงทำให้ผลลัพธ์เปลี่ยนไป และการขึ้นบรรทัดใหม่ในช่องจะถูกเข้ารหัสเป็น LF
ควรใช้ “เข้ารหัส URL” กับ URL ทั้งหมดหรือไม่
โดยทั่วไปไม่ควร “เข้ารหัส URL” ทำงานเหมือน encodeURIComponent ของ JavaScript คือเข้ารหัสแบบเปอร์เซ็นต์ทุกอักขระยกเว้น A–Z, a–z, 0–9 และ - _ . ! ~ * ' ( ) ดังนั้นอักขระ / ? & = : และ # ที่กำหนดโครงสร้างของ URL ก็จะถูกเข้ารหัสด้วย ควรใช้กับส่วนเดียวของ URL เช่น ค่าของพารามิเตอร์คิวรีหนึ่งตัว ช่องว่างจะกลายเป็น %20 และอักขระที่ไม่ใช่ ASCII จะถูกเข้ารหัสตามไบต์ UTF-8 ของอักขระนั้น เช่น é จะกลายเป็น %C3%A9
ทำไมเครื่องหมายบวกจึงไม่ถูกแปลงเป็นช่องว่าง และ “ถอดรหัส URL” จะแจ้งข้อผิดพลาดเมื่อใด
“ถอดรหัส URL” ทำงานเหมือน decodeURIComponent ของ JavaScript คือถอดรหัสลำดับ escape แบบ %XX และคง + ไว้ตามเดิม เพราะในไวยากรณ์ URL ทั่วไป (RFC 3986) + ไม่ได้หมายถึงช่องว่าง ข้อมูลฟอร์ม HTML (application/x-www-form-urlencoded) ซึ่งสตริงคิวรีจำนวนมากใช้ จะเข้ารหัสช่องว่างเป็น + ดังนั้นสำหรับข้อมูลแบบนี้ ให้แทน + ทุกตัวด้วยช่องว่างก่อนถอดรหัส ส่วนเครื่องหมายบวกจริงในรูปแบบนั้นจะเขียนเป็น %2B และยังถอดรหัสได้ถูกต้อง ข้อผิดพลาดจะเกิดขึ้นเมื่อ % ไม่ได้ตามด้วยเลขฐานสิบหกสองหลัก เช่นใน 50% off หรือเมื่อไบต์ที่ถูก escape ไม่ใช่ UTF-8 ที่ถูกต้อง เช่นใน %E2%82
“ถอดรหัส JWT” อ่านโทเค็นแบบใดได้บ้าง
โทเค็นในรูปแบบย่อสามส่วน header.payload.signature ที่ JWT แบบมีลายเซ็น (JWS) ใช้ รวมถึงโทเค็นที่ไม่มีลายเซ็นซึ่งส่วนลายเซ็นว่างเปล่า เครื่องมือไม่ได้ตรวจสอบส่วนลายเซ็น โทเค็นที่ถอดรหัสได้จึงไม่ได้พิสูจน์ว่าเป็นของจริง โทเค็นที่เข้ารหัสลับ (JWE) มีห้าส่วนและอ่านเพย์โหลดไม่ได้หากไม่มีคีย์ จึงจะได้ข้อผิดพลาดด้านรูปแบบ ส่วนหัวหรือเพย์โหลดที่ถอดรหัสจาก Base64 แล้วไม่ได้เป็น JSON หรือเพย์โหลดที่เป็นค่าเดี่ยว เช่น สตริงหรือตัวเลข แทนที่จะเป็นออบเจ็กต์ JSON จะทำให้เกิดข้อความ “ข้อผิดพลาดในการอ่าน JWT” จำนวนเต็มที่มากกว่า 9,007,199,254,740,991 ในส่วนหัวหรือเพย์โหลดอาจถูกปัดเศษเมื่อเบราว์เซอร์อ่าน JSON ดังนั้น ID ตัวเลขที่ยาวอาจแสดงหลักท้าย ๆ ไม่ตรงกับค่าจริง
เวลา exp, nbf และ iat แสดงอย่างไร และโทเค็นจะถูกระบุว่าหมดอายุเมื่อใด
ค่าเหล่านี้จะอ่านเป็นเวลา Unix หน่วยวินาทีตามที่มาตรฐาน JWT (RFC 7519) กำหนด และแสดงเป็นเวลา UTC และเวลาท้องถิ่นของคุณ “หมดอายุแล้ว” และ “ยังไม่มีผล” มาจากการเปรียบเทียบ exp และ nbf กับนาฬิกาของอุปกรณ์ ณ ตอนที่คุณคลิก “ถอดรหัส JWT” โดยไม่เผื่อเวลาสำหรับนาฬิกาที่คลาดเคลื่อน หากนาฬิกาไม่ตรง สถานะก็จะไม่ถูกต้อง เซิร์ฟเวอร์อาจยอมให้เวลาคลาดเคลื่อนได้เล็กน้อย ซึ่งมักไม่เกินไม่กี่นาที ในช่วงใกล้เวลา exp หรือ nbf เซิร์ฟเวอร์จึงอาจตัดสินต่างจากสถานะที่แสดงที่นี่ เวลาที่เขียนเป็นสตริง เช่น "1700000000" จะถูกแจ้งว่า “ไม่ใช่ Unix timestamp แบบตัวเลขที่ถูกต้อง”