เครื่องมือสำหรับนักพัฒนา · ตัวเข้ารหัสและตัวถอดรหัส Base64
URI ข้อมูลอธิบาย: data:image/png;base64 ทำงานอย่างไร และมาจากไหน
· พื้นหลัง
base64 การเข้ารหัส
ข้อมูล: แผน URL ถูกระบุไว้ใน 1998 เพื่อเป็นวิธีการฝังทรัพยากรขนาดเล็กลงในเพจโดยตรง โพสต์นี้จะอธิบายไวยากรณ์ เหตุใด Base64 จึงเป็นทางเลือก และเบราว์เซอร์จำกัดการใช้งานอย่างไร
ไอคอนประจำเว็บไซต์ที่เป็น 1,300 อักขระ URL — พบกับข้อมูล: URI ในป่าและอ่านส่วนต่างๆ ของมัน
ข้อมูล: URI ฝังทรัพยากรขนาดเล็กโดยตรงใน URL โดยหลีกเลี่ยงการร้องขอ HTTP แยกต่างหาก รูปแบบถูกระบุใน RFC 2397 (กำหนดใน 1998) และใช้ไวยากรณ์ที่มีรูปแบบ ประเภทสื่อทางเลือก ธงการเข้ารหัสเพิ่มเติม และเพย์โหลดเอง ตัวอย่างเช่น data:text/plain,hello เป็นข้อมูลข้อความธรรมดา URI ที่มีคำว่า สวัสดี เบราว์เซอร์จะประมวลผลสิ่งนี้ในลักษณะเดียวกับที่ประมวลผลคำขอ HTTP แต่แทนที่จะดึงเนื้อหาผ่านเครือข่าย เบราว์เซอร์จะถอดรหัสจาก URL เอง
URI ข้อมูลเป็นเรื่องธรรมดาที่สุดสำหรับรูปภาพขนาดเล็ก ไอคอน CSS และโปรแกรมทดสอบ ข้อมูล: URI พร้อมการเข้ารหัส Base64 มีลักษณะดังนี้: data:image/png;base64,iVBORw0K.... รายละเอียดคือ: data: เป็นรูปแบบ; image/png เป็นประเภทสื่อ ;base64 คือแฟล็กการเข้ารหัส สตริงแบบยาวคือไบต์รูปภาพที่เข้ารหัส Base64 เมื่อเบราว์เซอร์เห็น URL นี้ มันจะถอดรหัส Base64 เพื่อกู้คืนไบต์ดั้งเดิม จากนั้นเรนเดอร์รูปภาพโดยใช้ไบต์เหล่านั้น
การอ่านข้อมูล URI จากไวยากรณ์ที่มองเห็นได้ — ประเภทสื่อ เครื่องหมาย Base64 ที่เป็นตัวเลือก และเพย์โหลด
หากละเว้นการตั้งค่าสถานะการเข้ารหัส (data:text/html,<p>hello</p>) เพย์โหลดจะเป็นข้อความ UTF-8 ที่เข้ารหัสเปอร์เซ็นต์ ไม่ใช่ base64 การมีอยู่ของ ;base64 จะบอกเบราว์เซอร์ว่าจะใช้กฎการถอดรหัสใด ประเภทสื่อในข้อมูล: URI เป็นประเภท MIME ซึ่งเป็นสตริงประเภทเดียวกับที่ใช้ใน HTTP ส่วนหัวของประเภทเนื้อหา image/png, text/plain, application/json และ image/svg+xml เป็นตัวอย่างทั่วไป หากไม่มีการระบุประเภทสื่อสิ่งพิมพ์ ค่าเริ่มต้นจะเป็น text/plain;charset=US-ASCII.
เบราว์เซอร์จะต้องกำหนดวิธีการเรนเดอร์ไบต์ตามประเภทสื่อ: ถ้าระบุว่า image/png, ไบต์นั้นจะเป็น PNG; ถ้ามันบอกว่า text/html, เนื้อหาจะเป็น HTML การระบุประเภทสื่อสิ่งพิมพ์ที่ไม่ถูกต้องอาจทำให้เกิดผลลัพธ์ที่สับสนได้ ไฟล์ PNG ที่มีป้ายกำกับเป็น text/plain จะแสดงเป็นอักขระขยะแทนที่จะเป็นรูปภาพ Base64 เป็นทางเลือกในข้อมูล: URI สำหรับเนื้อหาข้อความ การเข้ารหัสเปอร์เซ็นต์ (การเข้ารหัสแบบเดียวกับที่ใช้ในสตริงข้อความค้นหา URL) มักจะมีขนาดกะทัดรัดกว่า base64 ข้อมูล URI ผู้บริโภคตัดสินใจว่าจะตีความเพย์โหลดจากประเภทสื่อและเครื่องหมายก่อนเครื่องหมายจุลภาคอย่างไร ตัวเข้ารหัส Base64 ระบุเฉพาะอักขระเพย์โหลดเท่านั้น จะไม่เพิ่มประเภท MIME เลือกว่าไบต์จะอธิบาย PNG หรือ SVG หรือตรวจสอบความถูกต้องของที่อยู่ที่ประกอบ
เหตุใด Base64 จึงเป็นทางเลือก — เพย์โหลดข้อความที่เข้ารหัสเปอร์เซ็นต์สำหรับ SVG และข้อความธรรมดาเทียบกับ Base64 สำหรับไบนารี
URI data:text/html,<p>Hello</p> มี HTML เป็นอักขระตามตัวอักษร (พร้อมการเข้ารหัสเปอร์เซ็นต์สำหรับอักขระพิเศษ เช่น เครื่องหมายคำพูดหรือวงเล็บมุม) Base64 มีประโยชน์สำหรับข้อมูลไบนารีที่ไม่สามารถแสดงเป็นข้อความได้ และในกรณีที่เพย์โหลดมีอักขระพิเศษหลายตัวที่การเข้ารหัสเปอร์เซ็นต์จะขยายตัว SVG ขนาดเล็กหรือไฟล์ข้อความอาจมีการเข้ารหัสเปอร์เซ็นต์ที่เล็กกว่า ไฟล์ไบนารีต้องเป็น base64 การสร้างข้อมูล: URI ด้วยมือจำเป็นต้องรู้ประเภทสื่อและการเข้ารหัส
สำหรับไอคอน SVG คุณสามารถใช้ data:image/svg+xml ตามด้วยมาร์กอัป SVG ที่เข้ารหัสเปอร์เซ็นต์ หรือไบต์ที่เข้ารหัส ;base64 และ base64 สำหรับการเข้ารหัสเปอร์เซ็นต์ ให้ล้อม SVG ใน data:image/svg+xml, จากนั้นเข้ารหัสเปอร์เซ็นต์ในวงเล็บเหลี่ยม เครื่องหมายคำพูด และอักขระพิเศษอื่นๆ ผลลัพธ์ที่ได้นั้นยาวแต่มนุษย์สามารถอ่านได้ สำหรับ base64 ให้ใช้ SVG ไบต์ เข้ารหัสเป็น base64 และสร้าง data:image/svg+xml;base64, จากนั้นต่อท้ายสตริง base64 โดยทั่วไป Base64 จะมีขนาดกะทัดรัดกว่าสำหรับไบนารี แต่สำหรับข้อความ SVG รูปแบบที่เข้ารหัสเปอร์เซ็นต์อาจสั้นกว่า
ตัวอย่างการทำงาน: การสร้างข้อมูล: URI สำหรับ SVG ขนาดเล็กด้วยมือ — เข้ารหัสมาร์กอัปเป็นข้อความและประกอบสตริง
เบราว์เซอร์และแอปพลิเคชันที่ใช้งานสามารถกำหนดขีดจำกัดหรือข้อจำกัดด้านนโยบายเกี่ยวกับ URI ข้อมูลได้ แต่พื้นที่เก็บข้อมูลนี้ไม่ได้กำหนดเพดานตัวเลขแบบพกพา การใช้หน่วยความจำ ลักษณะการทำงานของตัวแยกวิเคราะห์ และนโยบายความปลอดภัยยังขึ้นอยู่กับตำแหน่งที่ค่าปรากฏ ดังนั้นให้ทดสอบเบราว์เซอร์เป้าหมายที่แน่นอนและบริบทการฝังแทนที่จะอาศัยขีดจำกัดที่จดจำ
รูปภาพที่ฝัง 5 MB ในทุกไฟล์ HTML จะทำให้ขนาดหน้าขยาย URI ข้อมูลเหมาะที่สุดสำหรับทรัพยากรขนาดเล็ก: ไอคอน CSS รูปภาพขนาดเล็ก หรือข้อมูลทดสอบ สำหรับไฟล์ขนาดใหญ่ คำขอภายนอกจะเร็วกว่าเนื่องจากเบราว์เซอร์สามารถแคชการตอบสนองและนำมาใช้ซ้ำในหลายเพจได้ ข้อมูล: URI จะอยู่ในบรรทัดทุกครั้งที่โหลดหน้าเว็บ
ขอบเขตของเบราว์เซอร์และความปลอดภัยในการตรวจสอบในแอปพลิเคชันที่ใช้งานมากกว่าที่จะถือว่า
เกณฑ์ทั่วไปคือไม่กี่กิโลไบต์ ด้านล่างนั้น ข้อมูล: URI มีประสิทธิภาพ นอกเหนือจากนั้น ไฟล์ภายนอกมักจะเร็วกว่า นโยบายความปลอดภัยและเบราว์เซอร์จำกัดข้อมูล: URI การใช้งานในบางบริบท การนำทางระดับบนสุด (การคลิกลิงก์ที่ชี้ไปยังข้อมูล: URI ที่มีเนื้อหา HTML) มักจะถูกบล็อกเพื่อป้องกันฟิชชิ่ง ข้อมูล: URI ในแอตทริบิวต์ src ของสคริปต์สามารถดำเนินการ JavaScript ได้ตามใจชอบ ซึ่งทำให้เกิดความเสี่ยงด้านความปลอดภัย
เบราว์เซอร์ใช้กฎนโยบายความปลอดภัยของเนื้อหา (CSP) กับข้อมูล: URIs; CSP ที่เข้มงวดอาจห้ามโดยสิ้นเชิง ข้อมูล: URI ใน img src หรือ iframe src โดยปกติจะได้รับอนุญาต แต่การฝังในสไตล์หรือบริบทของสคริปต์อาจถูกจำกัด ตรวจสอบความเข้ากันได้ของเบราว์เซอร์และนโยบายความปลอดภัยของสภาพแวดล้อมเป้าหมายของคุณเสมอ URI ข้อมูลใน CSS เป็นเรื่องปกติสำหรับภาพพื้นหลังขนาดเล็ก ไวยากรณ์เหมือนกัน: url(data:image/png;base64,...).
โดยที่ข้อมูล: URI ยังคงเป็นเครื่องมือที่เหมาะสม — ไอคอน CSS รูปภาพอินไลน์ที่ปลอดภัยสำหรับอีเมล และโปรแกรมทดสอบ
ไฟล์ CSS ที่มีข้อมูลที่ฝังอยู่: สามารถจัดส่ง URI เป็นไฟล์เดียวพร้อมรูปภาพทั้งหมด ซึ่งช่วยลดคำขอ HTTP สิ่งนี้มีประโยชน์สำหรับชุดไอคอนขนาดเล็กหรือกราฟิกธรรมดา รูปภาพขนาดใหญ่ที่ฝังอยู่ใน CSS จะขยายไฟล์และทำให้การแยกวิเคราะห์ช้าลง เครื่องมือสร้างสมัยใหม่ (เช่น webpack) สามารถแปลงรูปภาพขนาดเล็กเป็นข้อมูลได้โดยอัตโนมัติ: URI ใน CSS และรูปภาพภายนอกเป็น URL ปกติ เพื่อปรับสมดุลประสิทธิภาพ
รูปแบบข้อมูล: URI ถูกกำหนดโดย RFC 2397 ซึ่งเป็นเอกสารขนาดสั้นที่ระบุไวยากรณ์ แต่ไม่ได้กำหนดว่าข้อมูลอยู่ที่ไหน: URI สามารถหรือไม่สามารถใช้ได้ ผู้จำหน่ายเบราว์เซอร์ได้เพิ่มข้อจำกัดของตนเองโดยพิจารณาจากข้อกังวลด้านความปลอดภัยและประสิทธิภาพ
สิ่งนี้ไม่ครอบคลุมถึง blob: URL, URL ของวัตถุ และการเข้าถึงระบบไฟล์
บางระบบมีข้อมูลที่เลิกใช้แล้ว: URI รองรับในบางบริบท (เช่น การดำเนินการในรูปแบบ CSP ระดับ 3) เพื่อป้องกันการละเมิด เมื่อใช้ข้อมูล: URI ให้ทดสอบในเบราว์เซอร์เป้าหมายของคุณ RFC บอกว่ารูปแบบนั้นถูกต้อง แต่นโยบายความปลอดภัยของเบราว์เซอร์อาจบล็อกรูปแบบนั้น
การสร้างข้อมูล: URI ด้วยตนเองถือเป็นเรื่องปกติในการผลิต เครื่องมือสร้างและไลบรารีส่วนใหญ่จัดการการแปลง แต่การทำความเข้าใจรูปแบบนั้นมีประโยชน์สำหรับการดีบัก หากคุณเห็น data:image/... URL แบบยาวใน CSS หรือ HTML คุณสามารถถอดรหัสได้ด้วยเครื่องมือตัวเข้ารหัสและตัวถอดรหัส Base64: ลบคำนำหน้า data:image/...;base64, วางสตริงที่เหลือลงในเครื่องมือ และถอดรหัสเพื่อดูไบต์จริง
Takeaway: รูปแบบขนาดเล็กที่มีไวยากรณ์ที่เข้มงวด — วิธีที่ตัวเข้ารหัสและตัวถอดรหัส Base64 จัดการกับขั้นตอนการเข้ารหัสข้อความ เพื่อให้คุณสามารถรวบรวม URI ที่ถูกต้องได้
สำหรับข้อมูล SVG: URI คุณสามารถถอดรหัสเปอร์เซ็นต์ในรูปแบบข้อความและอ่านมาร์กอัป XML ได้ การทำความเข้าใจกายวิภาคของข้อมูล: URI ช่วยให้แก้ไขปัญหาทรัพยากรที่ฝังตัวได้ง่ายขึ้น URI ข้อมูลเป็นมาตรฐานเว็บ (RFC 2397) ที่อนุญาตให้ฝังทรัพยากรเป็น URL ได้โดยตรง มีประสิทธิภาพสูงสุดสำหรับทรัพยากรขนาดเล็กและมีเสถียรภาพที่ไม่ได้รับประโยชน์จากการแยกแคช รูปแบบนี้ประกอบด้วยข้อกำหนดเฉพาะของประเภทสื่อทางเลือกและแฟล็กการเข้ารหัส (การเข้ารหัสแบบ base64 หรือเปอร์เซ็นต์โดยนัย)
จำเป็นต้องมีการเข้ารหัส Base64 สำหรับข้อมูลไบนารี แต่เป็นทางเลือกสำหรับข้อความ SVG ที่เข้ารหัสเป็นเปอร์เซ็นต์สามารถอ่านได้มากขึ้น นโยบายความปลอดภัยของเบราว์เซอร์จำกัดว่าข้อมูล: URI สามารถนำมาใช้ได้ ดังนั้นการทำความเข้าใจข้อจำกัดในสภาพแวดล้อมเป้าหมายของคุณจึงเป็นสิ่งสำคัญ เครื่องมือตัวเข้ารหัสและตัวถอดรหัส Base64 สามารถช่วยคุณเข้ารหัสทรัพยากรด้วยตนเองหรือถอดรหัส URI ที่ฝังอยู่เพื่อตรวจสอบเนื้อหา