เครื่องมือข้อความและชีวิตประจำวัน · ชุดเครื่องมือ QR และบาร์โค้ด
QR Code สามารถเก็บข้อมูลได้มากขนาดไหน? เวอร์ชัน 1 ถึง 40 และอธิบายความจุ
· พื้นหลัง
คิวอาร์โค้ด การเข้ารหัส การใช้งาน
อธิบายเวอร์ชัน 40 QR ขนาดกริด โหมดการเข้ารหัส และการแก้ไขข้อผิดพลาดรวมกันเพื่อตั้งค่าความจุได้อย่างไร และเหตุใดค่าสูงสุดทางทฤษฎีจึงไม่ค่อยใช้งานได้จริง
โค้ดที่กลายเป็นสี่เหลี่ยมสีเทาที่อ่านไม่ได้ จะเกิดอะไรขึ้นเมื่อคุณเข้ารหัสย่อหน้าแทนที่จะเป็นลิงก์
ข้อความยาวๆ สามารถเปลี่ยนสัญลักษณ์ขนาดเล็กให้กลายเป็นช่องที่หนาแน่นของโมดูลเล็กๆ ได้ ก่อนที่ตัวเข้ารหัสจะปฏิเสธเสียอีก การเปลี่ยนแปลงการมองเห็นนั้นมีความสำคัญเนื่องจากความกว้างในการพิมพ์คงที่ทำให้พิกเซลหรือจุดเครื่องพิมพ์น้อยลงสำหรับแต่ละแถวและคอลัมน์ที่เพิ่ม
ความหนาแน่นสามารถมองเห็นได้ทั้งในตัวนับโมดูลและการพิสูจน์ทางกายภาพ ตัวสร้างอาจยอมรับบันทึกย่อขนาดยาว แต่การแสดงตัวอย่างขนาดคงที่ขณะนี้มีเซลล์ขนาดเล็กจำนวนมาก และการพิมพ์ในภายหลังอาจทำให้เซลล์เหล่านั้นเบลอ ความจุเป็นคำตอบว่าสามารถสร้างเมทริกซ์ได้หรือไม่ ไม่ใช่ว่าเครื่องพิมพ์และโทรศัพท์ที่เลือกจะสามารถแก้ไขได้หรือไม่ ลดเพย์โหลดก่อนที่จะลดระยะขอบหรือขนาดเซลล์ เนื่องจากการเปลี่ยนแปลงเหล่านั้นจะโจมตีหลักฐานที่มองเห็นได้ของเครื่องสแกน
เวอร์ชัน 1 ถึง 40 — 21×21 โมดูลเพิ่มขึ้นสี่ด้านต่อด้านเป็น 177×177 และสิ่งที่แต่ละขั้นตอนเพิ่ม
การใช้งานรองรับ QR เวอร์ชันตั้งแต่หนึ่งถึงสี่สิบ: 21 โมดูลต่อด้านในเวอร์ชันแรก จากนั้นเพิ่มอีกสี่โมดูลต่อด้านจนถึง 177 การเลือกอัตโนมัติจะเลือกเวอร์ชันที่เล็กที่สุดที่เหมาะกับเพย์โหลด UTF-8 ไบต์และระดับการแก้ไข
มิติข้อมูลเวอร์ชันมีบันไดสังเกตง่ายๆ: 21 โมดูลสำหรับเวอร์ชัน 1 จากนั้นโมดูลเพิ่มเติมอีก 4 โมดูลต่อด้านในแต่ละขั้นตอนจนถึง 177 การทดสอบจะตรวจสอบกฎมิติ `4n + 17` ในระดับการแก้ไข ToolAcre ขอการขึ้นต่อกันสำหรับการเลือกอัตโนมัติแทนที่จะเปิดเผยฟิลด์เวอร์ชัน ดังนั้นผู้ใช้ควรอ่านจำนวนโมดูลผลลัพธ์แทนที่จะบังคับให้ค้นหาตาราง
ความจุในชุดเครื่องมือนี้คือความจุโหมดไบต์ UTF-8 สูงสุดที่เผยแพร่ทุกโหมดอยู่นอกการใช้งาน
ตารางความจุทั่วไปจะแยกโหมดตัวเลข ตัวอักษร ไบต์ และคันจิออกจากกัน แต่ ToolAcre จงใจใช้โหมดไบต์สำหรับทุกเพย์โหลด การสร้างค่าสูงสุดในโหมดอื่นซ้ำอาจทำให้เครื่องมือนี้อธิบายผิด ดังนั้นความจุที่นี่จึงวัดเป็นไบต์ที่เข้ารหัส UTF-8
UTF-8 ความยาวไบต์อธิบายว่าทำไมการนับอักขระที่เท่ากันจึงสามารถทำงานแตกต่างออกไปได้ อักขระ ASCII `x` สี่สิบตัวใช้ไบต์น้อยกว่าอักขระภาษาญี่ปุ่นสี่สิบตัว และการทดสอบยืนยันว่าเพย์โหลดแบบหลายไบต์จำเป็นต้องมีเมทริกซ์ที่มีขนาดใหญ่เป็นอย่างน้อย แผงแสดงไบต์แทนที่จะเป็นอักขระด้วยเหตุนี้ ค่าสูงสุดที่เป็นตัวเลขหรือตัวอักษรและตัวเลขทั่วไปจะไม่ทำนาย ToolAcre เนื่องจากจะส่งทุกเพย์โหลดผ่านโหมดไบต์
ความจุขึ้นอยู่กับระดับการแก้ไขที่เลือก ใช้ขีดจำกัดไบต์ที่แน่นอนของการใช้งาน
เพดานที่ตรวจสอบแล้วคือ 2,953 bytes ที่ L, 2,331 ที่ M, 1,663 ที่ Q และ 1,273 ที่ H สิ่งเหล่านั้นเป็นค่าคงที่ในการใช้งาน ไม่ใช่คำมั่นสัญญาเกี่ยวกับคุณภาพการพิมพ์ที่ใช้งานได้จริง และการแก้ไขที่แข็งแกร่งยิ่งขึ้นทำให้มีพื้นที่น้อยลงสำหรับไบต์โหลด
เพดานที่กำหนดค่าที่แน่นอนยังกำหนดเส้นทางข้อผิดพลาด: 2,953 bytes ที่ L, 2,331 ที่ M, 1,663 ที่ Q และ 1,273 ที่ H ซึ่งเป็นตัวเลขการใช้งานที่ถูกต้องซึ่งจะแสดงในอินเทอร์เฟซ ไม่ควรแปลงเป็นการนับตัวอักษร เนื่องจากสำเนียงและอีโมจิมีความยาว UTF-8 แตกต่างกัน เมื่อค่าเกินความจุ การทำให้ค่าสั้นลงจะปลอดภัยกว่าการปล่อยเนื้อหาโดยไม่แจ้งให้ทราบ
เพดานที่ใช้งานได้จริง — ความละเอียดของกล้อง ขนาดการพิมพ์ และระยะการสแกนทำให้ช่วงการใช้งานต่ำกว่าเวอร์ชัน 40 มาก
เมทริกซ์ที่พอดีในทางเทคนิคอาจเป็นการออกแบบทางกายภาพที่ไม่ดีเมื่อพิมพ์มีขนาดเล็กเกินไปหรือมองจากระยะไกลเกินไป ความละเอียดของกล้อง โซนเงียบ คอนทราสต์ และวัสดุพิมพ์ลดเพดานในทางปฏิบัติ ซึ่งเป็นเหตุผลว่าทำไม URL แบบสั้นจึงมักนิยมใช้มากกว่าทั้งบันทึก
ระยะการใช้งานจริงขึ้นอยู่กับสัญลักษณ์ทั้งหมด การแก้ไขที่เข้มขึ้นจะทำให้เมทริกซ์มีขนาดใหญ่ขึ้นสำหรับข้อความที่เหมือนกัน ดังที่การทดสอบ 200 อักขระแสดงให้เห็นระหว่าง L และ H ที่ความกว้างการพิมพ์คงที่ ซึ่งจะย่อขนาดทุกโมดูล การเพิ่มการแก้ไขจึงไม่ปลอดภัยโดยอัตโนมัติ: ความซ้ำซ้อนอาจทนต่อความเสียหายบางส่วนได้ ในขณะที่ความหนาแน่นที่เพิ่มขึ้นทำให้การจับที่สะอาดทำได้ยากขึ้น เลือกระดับแล้วทดสอบโค้ดฟิสิคัลผลลัพธ์
ตัวอย่างการทำงาน: เปรียบเทียบจำนวนโมดูลที่สร้างขึ้นแทนที่จะทำนายเวอร์ชันที่แน่นอนจากหน่วยความจำ
สร้าง URL แบบสั้น ซึ่งเป็น vCard ที่รองรับและบันทึกย่อข้อความธรรมดาขนาดยาว จากนั้นเปรียบเทียบจำนวนโมดูลที่ส่งคืนและพิสูจน์การสแกน แหล่งที่มาไม่เปิดเผยตัวประมาณเวอร์ชันที่รับประกันสำหรับข้อความที่กำหนดเอง ดังนั้นให้สังเกตผลลัพธ์จริงแทนการเดา
สำหรับชุดตัวอย่าง ให้สร้าง HTTPS URL แบบสั้น ซึ่งเป็น vCard ที่รองรับ และโน้ต 500 อักขระที่ระดับการแก้ไขเดียวกัน บันทึกจำนวนไบต์และขนาดโมดูลแทนที่จะคาดการณ์เวอร์ชันที่แน่นอน vCard จะเพิ่มป้ายกำกับฟิลด์และตัวคั่นรอบๆ ข้อมูลผู้ติดต่อที่มองเห็นได้ ดังนั้นความยาวที่เข้ารหัสจึงไม่ได้เป็นเพียงผลรวมของสิ่งที่ปรากฏในแบบฟอร์มเท่านั้น
สิ่งนี้ไม่ครอบคลุมถึง - มีโครงสร้างผนวกเข้ากับหลายโค้ดและ Micro QR
ไม่มีการใช้การผนวกแบบมีโครงสร้างและ Micro QR ToolAcre ยังไม่แยกเพย์โหลดขนาดใหญ่ข้ามสัญลักษณ์ รายงานว่าเนื้อหายาวเกินไปและแนะนำให้ย่อให้สั้นลงหรือเลือกระดับการแก้ไขที่ต่ำกว่า
ToolAcre ไม่แบ่งข้อมูลออกเป็นหลาย ๆ รหัสและไม่มี Micro QR เพย์โหลดขนาดใหญ่จะส่งกลับข้อผิดพลาดแทนที่จะเป็นภาพบางส่วน หากบันทึกมีขนาดใหญ่เกินไป ให้โฮสต์ไว้ด้านหลัง URL ที่เสถียร หรือเลือกเครื่องมือเฉพาะทางที่มีรูปแบบหลายสัญลักษณ์และการสนับสนุนโปรแกรมอ่านตรงตามข้อกำหนด การตัดข้อความเป็นรูปภาพ QR ที่ไม่เกี่ยวข้องด้วยตนเองจะสร้างปัญหาการประกอบสำหรับเครื่องสแกนและผู้ใช้
Takeaway — เข้ารหัสตัวชี้แทนที่จะเป็นเพย์โหลดที่คุณสามารถทำได้ และให้ QR & Barcode Toolkit เลือกเวอร์ชันสำหรับเนื้อหาที่คุณป้อน
เข้ารหัสตัวชี้เมื่อปลายทางสามารถโฮสต์บันทึกที่ใหญ่กว่า เก็บ URL ที่มีอายุยาวนานไว้ภายใต้การควบคุมของคุณ และปล่อยให้ตัวสร้างเลือกเมทริกซ์ ความจุคืองบประมาณไบต์ ในขณะที่การใช้งานที่เชื่อถือได้คือการทดสอบระบบจริง
การดำเนินการคือลำดับชั้น: รักษาเนื้อหาที่ถูกต้อง ลบไบต์ที่ไม่จำเป็น เลือกระดับการแก้ไขที่เหมาะสม สังเกตเมทริกซ์ที่สร้างขึ้น จากนั้นปรับขนาดและทดสอบ ค่าสูงสุดทางทฤษฎีคือขอบเขตสุดท้ายของตัวเข้ารหัส ไม่ใช่เป้าหมายการออกแบบ พอยน์เตอร์แบบสั้นมักจะเหลือพื้นที่มากขึ้นสำหรับโมดูลที่แข็งแกร่ง และปล่อยให้เนื้อหาปลายทางเปลี่ยนแปลงโดยไม่ต้องเปลี่ยนการพิมพ์