การบีบอัดแบบเรียงลำดับไบนารีสำหรับยูนิโค้ด ( BOCU ) เป็นรูปแบบการบีบอัดยูนิโค้ดที่เข้ากันได้กับMIME BOCU-1 ผสมผสานการใช้งานที่กว้างขวางของ UTF-8 เข้า กับความกะทัดรัดของรูปแบบการบีบอัดมาตรฐานสำหรับยูนิโค้ด (SCSU) การเข้ารหัสยูนิโค้ด นี้ ได้รับการออกแบบให้มีประโยชน์สำหรับการบีบอัดสตริงสั้นๆ และรักษาลำดับของจุดรหัส BOCU-1 ได้รับการกำหนดไว้ในบันทึกทางเทคนิคของยูนิโค้ด^{[ 1 ]}

เพื่อเปรียบเทียบ SCSU ถูกนำมาใช้เป็นรูปแบบการบีบอัด Unicode มาตรฐานที่มีอัตราส่วนไบต์ต่อโค้ดพอยต์คล้ายกับโค้ดเพจ เฉพาะภาษา SCSU ยังไม่ถูกนำมาใช้อย่างแพร่หลาย เนื่องจากไม่เหมาะสำหรับสื่อประเภท MIME "ข้อความ" ตัวอย่างเช่น SCSU ไม่สามารถใช้โดยตรงในอีเมลและโปรโตคอลที่คล้ายกันได้ SCSU ต้องการการออกแบบตัวเข้ารหัสที่ซับซ้อนเพื่อให้ได้ประสิทธิภาพที่ดี โดยทั่วไปแล้วzip , bzip2และอัลกอริธึมมาตรฐานอุตสาหกรรมอื่นๆ จะบีบอัดข้อความ Unicode จำนวนมากได้อย่างมีประสิทธิภาพมากกว่า^{[ 2 ]}

ทั้ง SCSU ^{[ 3 ]}และ BOCU-1 ^{[ 4 ]}เป็นชุดอักขระที่จดทะเบียน กับ IANA

ตัวเลขทั้งหมดในส่วนนี้เป็นเลขฐานสิบหกและช่วงตัวเลขทั้งหมดรวมอยู่ด้วย

รหัสจุดตั้งแต่U+0000ถึงU+0020จะถูกเข้ารหัสใน BOCU-1 เป็นค่าไบต์ที่สอดคล้องกัน รหัสจุดอื่นๆ ทั้งหมด (นั่นคือตั้งแต่U+0021ถึง) จะถูกเข้ารหัสเป็นผลต่างระหว่างรหัสจุด กับเวอร์ชันมาตรฐานของรหัสจุดที่เข้ารหัสล่าสุดที่ไม่ใช่ช่องว่าง ASCII ( ) สถานะเริ่มต้นคือการแมปการทำให้เป็นมาตรฐานมีดังนี้: U+D7FFU+E000U+10FFFFU+0020U+0040

ความแตกต่างระหว่างรหัสจุดปัจจุบันและรหัสจุดก่อนหน้าที่ปรับให้เป็นมาตรฐานจะถูกเข้ารหัสดังนี้:

แต่ละช่วงไบต์จะเรียงลำดับตามพจนานุกรมโดยไม่รวมค่าไบต์ 13 ค่าต่อไปนี้: 00 07 08 09 0A 0B 0C 0D 0E 0F 1A 1B 20ตัวอย่างเช่น ลำดับไบต์FC 06 FFซึ่งเข้ารหัสสำหรับความแตกต่างของ1156Bจะตามด้วยลำดับไบต์FC 10 01ซึ่งเข้ารหัสสำหรับความแตกต่าง1156Cของ

การป้อนข้อมูล ASCII ใดๆU+0000ยกเว้นU+007Fช่องว่างU+0020จะรีเซ็ตตัวเข้ารหัสเป็นค่าU+0040ว่าง เนื่องจากค่าที่กล่าวถึงข้างต้นครอบคลุมจุดรหัสสิ้นสุดบรรทัดU+000DและU+000Aเนื่องจาก ( 0D 0A) ตัวเข้ารหัสจึงอยู่ในสถานะที่ทราบ ณ จุดเริ่มต้นของแต่ละบรรทัด ดังนั้น ความเสียหายของไบต์เดียวจึงส่งผลกระทบต่อบรรทัดอย่างมากที่สุดหนึ่งบรรทัด สำหรับการเปรียบเทียบ ความเสียหายของไบต์เดียวในUTF-8ส่งผลกระทบต่อจุดรหัสอย่างมากที่สุดหนึ่งจุด และสำหรับSCSUอาจส่งผลกระทบต่อเอกสารทั้งหมด

BOCU-1 มีความทนทานในระดับเดียวกันสำหรับข้อความอินพุตที่ไม่มีค่าที่กล่าวถึงข้างต้นด้วยรหัสรีเซ็ตพิเศษ0xFFเมื่อตัวถอดรหัสพบอ็อกเท็ตนี้ มันจะรีเซ็ตสถานะเป็นU+0040เหมือนกับการสิ้นสุดบรรทัด การใช้0xFFไบต์รีเซ็ตไม่เป็นที่แนะนำในข้อกำหนดของ BOCU-1 เนื่องจากขัดแย้งกับเป้าหมายการออกแบบอื่นๆ ของ BOCU-1 โดยเฉพาะอย่างยิ่งลำดับไบนารี

การใช้ลายเซ็นเสริมU+FEFFที่จุดเริ่มต้นของข้อความที่เข้ารหัส BOCU-1 ซึ่งก็คือลำดับไบต์ BOCU-1 FB EE 28จะเปลี่ยนสถานะเริ่มต้นU+0040เป็นU+FEC0กล่าวอีกนัยหนึ่งคือ ไม่สามารถลบลายเซ็นออกได้ง่ายๆ เหมือนในระบบการเข้ารหัส Unicode อื่นๆ ส่วนใหญ่ การเพิ่มไบต์รีเซ็ตหลังจากลายเซ็น ( FB EE 28 FF) อาจช่วยหลีกเลี่ยงผลกระทบนี้ได้ แต่ข้อกำหนด BOCU-1 ไม่แนะนำให้ใช้วิธีนี้

ในทางทฤษฎีUTF-1และUTF-8สามารถเข้ารหัส ชุด UCS-4 ดั้งเดิม ที่มี 31 บิตได้ถึง ส่วน7FFFFFFFBOCU-1 และUTF-16สามารถเข้ารหัสชุดUnicodeU+0000 สมัยใหม่ได้ตั้งแต่ ถึง โดยไม่รวมจุดรหัส ที่ได้รับการป้องกันU+10FFFF 13 จุดซึ่งเข้ารหัสเป็นอ็อกเท็ตเดี่ยว BOCU-1 สามารถใช้อ็อกเท็ตในการเข้ารหัสแบบหลายไบต์ได้ BOCU-1 ต้องการอย่างมากที่สุดสี่ไบต์ ประกอบด้วยไบต์นำและไบต์ตามหนึ่งถึงสามไบต์ ไบต์ตามจะเข้ารหัสความแตกต่าง " โมดูลัส 243" (ฐาน 243) ที่เหลืออยู่ ไบต์นำจะกำหนดจำนวนไบต์ตามและความแตกต่างเริ่มต้น ไบต์รีเซ็ตไม่ได้รับการป้องกันและสามารถปรากฏเป็นไบต์ตามได้ ${\displaystyle 256-13=243}$0xFF

ก่อนวันที่ 16 พฤศจิกายน 2022 อัลกอริทึม BOCU ทั่วไปได้รับการคุ้มครองโดยสิทธิบัตรของสหรัฐอเมริกาหมายเลข 6,737,994 ซึ่งยังกล่าวถึงการใช้งาน BOCU-1 โดยเฉพาะด้วย^{[ 5 ]}สิทธิบัตรนี้ได้หมดอายุแล้ว

IBMซึ่งจ้างนักประดิษฐ์ BOCU-1 ทั้งสองคนในขณะที่สร้างขึ้น ระบุในบันทึกทางเทคนิคของ Unicode ว่าผู้ใช้งาน "เวอร์ชัน BOCU-1 ที่สอดคล้องอย่างสมบูรณ์" ต้องติดต่อ IBM เพื่อขอใบอนุญาตที่ไม่ต้องเสียค่าลิขสิทธิ์^{[ 6 ]} BOCU-1 เป็นรูปแบบการบีบอัด Unicode เพียงอย่างเดียวที่อธิบายไว้ในเว็บไซต์ Unicode ที่ทราบกันว่ามีข้อจำกัด ด้าน ทรัพย์สินทางปัญญา

By contrast, IBM also filed for a patent on UTF-EBCDIC, but it chose in that case to make the documentation and encoding scheme "freely available to anyone concerned towards making the transformation format as part of the UCS standards", instead of requiring implementers to request a license.^[7]

W3C and WHATWG HTML standards prohibit supporting BOCU-1 (and SCSU, CESU-8, UTF-7, EBCDIC, and UTF-32) in HTML documents^[8][9] because HTML was not designed with non-ASCII-compatible encodings in mind. In the past, cross-site scripting vulnerabilities due to browsers' poor handling of such encodings have been demonstrated.^[10]

• UTF-1 contains a comparison of the UTF-1, UTF-8, and BOCU-1 designs
• International Components for Unicode A library that can convert between BOCU-1 and other Unicode encodings