บทความนี้เปรียบเทียบ การเข้ารหัส Unicodeในสภาพแวดล้อมสองประเภท ได้แก่ สภาพแวดล้อม แบบ 8 บิตที่สะอาดและสภาพแวดล้อมที่ห้ามใช้ ค่า ไบต์ที่มีบิตสูงสุดถูกตั้งค่าไว้ เดิมที ข้อห้ามดังกล่าวอนุญาตให้ใช้ลิงก์ที่ใช้ข้อมูลเพียงเจ็ดบิต แต่ข้อห้ามนี้ยังคงมีอยู่ในมาตรฐานบางอย่าง ดังนั้นซอฟต์แวร์ที่สอดคล้องกับมาตรฐานบางตัวจึงต้องสร้างข้อความที่สอดคล้องกับข้อจำกัดเหล่านั้นStandard Compression Scheme for Unicodeและ Binary Ordered Compression for Unicode ถูกยกเว้นจากตารางเปรียบเทียบ เนื่องจากเป็นการยากที่จะระบุขนาดของมันได้อย่างตรงไปตรงมา!

ไฟล์UTF-8ที่มีเฉพาะ อักขระ ASCII นั้น เหมือนกับไฟล์ ASCII ทุกประการ โปรแกรมรุ่นเก่าโดยทั่วไปสามารถจัดการกับไฟล์ที่เข้ารหัส UTF-8 ได้ แม้ว่าจะมีอักขระที่ไม่ใช่ ASCII อยู่ก็ตาม ตัวอย่างเช่น ฟังก์ชัน printf ในภาษา C สามารถพิมพ์สตริง UTF-8 ได้ เนื่องจากฟังก์ชันนี้จะมองหาเฉพาะอักขระ ASCII '%' เพื่อกำหนดรูปแบบสตริงเท่านั้น ไบต์อื่นๆ จะถูกพิมพ์ออกมาโดยไม่เปลี่ยนแปลง

UTF-16และUTF-32ไม่สามารถใช้งานร่วมกับไฟล์ ASCII ได้ ดังนั้นจึงจำเป็นต้องใช้ โปรแกรมที่รองรับ Unicodeในการแสดงผล พิมพ์ และจัดการไฟล์เหล่านั้น แม้ว่าจะทราบว่าไฟล์นั้นมีเฉพาะอักขระในชุดย่อย ASCII ก็ตาม เนื่องจากมีไบต์ศูนย์จำนวนมาก สตริงอักขระที่แสดงไฟล์ดังกล่าวจึงไม่สามารถจัดการได้ด้วยตรรกะการจัดการสตริงที่ลงท้ายด้วยค่าว่าง ทั่วไป ^{[ a ]}ความแพร่หลายของการจัดการสตริงโดยใช้ตรรกะนี้หมายความว่า แม้ในบริบทของระบบ UTF-16 เช่นWindowsและJavaไฟล์ข้อความ UTF-16 ก็ไม่ได้ถูกใช้กันอย่างแพร่หลาย แต่ยังคงใช้การเข้ารหัส 8 บิตแบบเก่า เช่น ASCII หรือISO-8859-1ซึ่งไม่รองรับ Unicode เลย หรือใช้ UTF-8 สำหรับ Unicode

โดยทั่วไปXMLจะถูกเข้ารหัสเป็น UTF-8 และตัวประมวลผล XML ทั้งหมดจะต้องรองรับ UTF-8 และ UTF-16 เป็นอย่างน้อย^{[ 1 ]}

UTF-8ต้องการ 8, 16, 24 หรือ 32 บิต (หนึ่งถึงสี่ไบต์ ) ในการเข้ารหัสอักขระ Unicode, UTF-16ต้องการ 16 หรือ 32 บิตในการเข้ารหัสอักขระ และUTF-32ต้องการ 32 บิตเสมอในการเข้ารหัสอักขระ

อักขระยูนิโค้ด 128 ตัวแรกตั้งแต่ U+0000 ถึง U+007F ซึ่งใช้สำหรับตัวควบคุม C0 และอักขระละตินพื้นฐาน และตรงกับ ASCII นั้น เข้ารหัสโดยใช้ 8 บิตใน UTF-8, 16 บิตใน UTF-16 และ 32 บิตใน UTF-32 อักขระถัดไป 1,920 ตัว ตั้งแต่ U+0080 ถึง U+07FF แทนอักขระที่เหลือซึ่งใช้ในอักษรละตินเกือบทั้งหมดรวมถึงกรีกซิริลลิก คอป ติก อาร์เมเนียฮิบรูอาหรับซีเรียคทาอานาและเอ็นโคอักขระในช่วงนี้ต้องใช้ 16 บิตในการเข้ารหัสทั้งใน UTF-8 และ UTF-16 และ 32 บิตใน UTF-32 สำหรับรหัสอักขระ U+0800 ถึง U+FFFF ซึ่งเป็นอักขระที่เหลืออยู่ในระนาบภาษาพื้นฐาน (Basic Multilingual Plane)และสามารถแทนอักขระที่เหลือของภาษาต่างๆ ส่วนใหญ่ในโลกได้นั้น UTF-8 ต้องการ 24 บิตในการเข้ารหัสอักขระ ในขณะที่ UTF-16 ต้องการ 16 บิต และ UTF-32 ต้องการ 32 บิต ส่วนรหัสอักขระ U+010000 ถึง U+10FFFF ซึ่งแทนอักขระในระนาบเสริม (Supplementary Planes ) นั้น ต้องการ 32 บิตใน UTF-8, UTF-16 และ UTF-32 ตามลำดับ

ไฟล์จะสั้นกว่าใน UTF-8 เมื่อเทียบกับ UTF-16 หากมีจุดรหัส ASCII มากกว่าจุดรหัสในช่วง U+0800 ถึง U+FFFF ผู้สนับสนุน UTF-8 ในฐานะรูปแบบที่ต้องการโต้แย้งว่าเอกสารในโลกแห่งความเป็นจริงที่เขียนด้วยภาษาที่ใช้เฉพาะอักขระในช่วงสูงมักจะสั้นกว่าใน UTF-8 เนื่องจากการใช้ช่องว่าง ตัวเลข เครื่องหมายวรรคตอน บรรทัดใหม่ มาร์ก อัป HTMLหรือXML (เช่น ใน ไฟล์ docxหรือodt ) และคำและคำย่อที่ฝังอยู่ซึ่งเขียนด้วยตัวอักษรละตินอย่างกว้างขวาง^{[ 2 ]}ในทางตรงกันข้าม UTF-32 จะยาวกว่าเสมอ เว้นแต่จะไม่มีจุดรหัสที่น้อยกว่า U+10000

อักขระที่พิมพ์ได้ทั้งหมดในUTF-EBCDICใช้จำนวนไบต์อย่างน้อยเท่ากับใน UTF-8 และส่วนใหญ่ใช้มากกว่านั้น เนื่องจากการตัดสินใจอนุญาตให้เข้ารหัสรหัสควบคุม C1 เป็นไบต์เดียว สำหรับสภาพแวดล้อมเจ็ดบิตUTF-7มีประสิทธิภาพด้านพื้นที่มากกว่าการรวมกันของการเข้ารหัส Unicode อื่นๆ กับquoted-printableหรือbase64สำหรับข้อความเกือบทุกประเภท (ดู " สภาพแวดล้อมเจ็ดบิต " ด้านล่าง)

ข้อความที่มีการเข้ารหัสความยาวแปรผัน เช่น UTF-8 หรือ UTF-16 นั้นประมวลผลได้ยากกว่า หากจำเป็นต้องทำงานกับหน่วยรหัสแต่ละหน่วย แทนที่จะทำงานกับจุดรหัส การค้นหาจะไม่ได้รับผลกระทบจากว่าอักขระมีขนาดแปรผันหรือไม่ เนื่องจากการค้นหาลำดับของหน่วยรหัสไม่สนใจการแบ่งส่วน อย่างไรก็ตาม จำเป็นต้องมีการเข้ารหัสที่ซิงโครไนซ์ตัวเองซึ่งทั้ง UTF-8 และ UTF-16 มีคุณสมบัตินี้ ความเข้าใจผิดทั่วไปคือจำเป็นต้อง "ค้นหา อักขระตัวที่ n " และสิ่งนี้ต้องการการเข้ารหัสความยาวคงที่ แต่ในการใช้งานจริง จำนวนnได้มาจากการตรวจสอบอักขระn-1ตัวเท่านั้น ดังนั้นจึงจำเป็นต้องเข้าถึงตามลำดับอยู่ดี

สำหรับการประมวลผล รูปแบบควรค้นหา ตัดทอน และประมวลผลได้อย่างปลอดภัยโดยทั่วไป การเข้ารหัส Unicode ปกติทั้งหมดใช้หน่วยรหัสขนาดคงที่บางรูปแบบ ขึ้นอยู่กับรูปแบบและจุดรหัสที่จะเข้ารหัส หน่วยรหัสเหล่านี้อย่างน้อยหนึ่งหน่วยจะแทนจุดรหัส Unicode เพื่อให้ค้นหาและตัดทอนได้ง่าย ลำดับต้องไม่ปรากฏอยู่ภายในลำดับที่ยาวกว่าหรือข้ามขอบเขตของลำดับอื่นสองลำดับ UTF-8, UTF-16, UTF-32 และ UTF-EBCDIC มีคุณสมบัติที่สำคัญเหล่านี้ แต่UTF-7และGB 18030ไม่มี

อักขระที่มีขนาดคงที่อาจเป็นประโยชน์ แต่ถึงแม้จะมีจำนวนไบต์คงที่ต่อจุดรหัส (เช่นใน UTF-32) ก็ไม่มีจำนวนไบต์คงที่ต่ออักขระที่แสดงผลเนื่องจากการรวมอักขระเมื่อพิจารณาถึงความไม่เข้ากันเหล่านี้และข้อบกพร่องอื่นๆ ระหว่างรูปแบบการเข้ารหัสต่างๆ การจัดการข้อมูล Unicode ด้วยโปรโตคอลเดียวกัน (หรือที่เข้ากันได้) ตลอดทั้งระบบและระหว่างอินเทอร์เฟซ (เช่น การใช้ API/ไลบรารี การจัดการอักขระ Unicode ในรูปแบบไคลเอ็นต์/เซิร์ฟเวอร์ เป็นต้น) โดยทั่วไปจะช่วยลดความซับซ้อนของกระบวนการทั้งหมดในขณะเดียวกันก็กำจัดแหล่งที่มาของข้อผิดพลาดที่อาจเกิดขึ้นได้

UTF-16 เป็นที่นิยมเนื่องจาก API หลายตัวมีมาตั้งแต่สมัยที่ Unicode มีความกว้างคงที่ 16 บิต (เรียกว่า UCS-2) อย่างไรก็ตาม การใช้ UTF-16 ทำให้ตัวอักขระที่อยู่นอกเหนือBasic Multilingual Planeกลายเป็นกรณีพิเศษ ซึ่งเพิ่มความเสี่ยงต่อข้อผิดพลาดที่เกี่ยวข้องกับการจัดการตัวอักขระเหล่านั้น ถึงกระนั้น โปรแกรมที่จัดการคู่ตัวอักขระทดแทนได้ไม่ดีก็อาจมีปัญหาในการรวมลำดับด้วยเช่นกัน ดังนั้นการใช้ UTF-32 จึงไม่น่าจะแก้ปัญหาทั่วไปของการจัดการตัวอักขระหลายหน่วยรหัสได้ไม่ดี

หากข้อมูลที่จัดเก็บไว้เป็นแบบ UTF-8 (เช่น เนื้อหาไฟล์หรือชื่อไฟล์) การเขียนระบบที่ใช้ UTF-16 หรือ UTF-32 เป็น API นั้นทำได้ยากมาก เนื่องจากข้อเท็จจริงที่มักถูกมองข้ามคือ อาร์เรย์ไบต์ที่ใช้โดย UTF-8 นั้นอาจมีลำดับที่ไม่ถูกต้องอยู่ ตัวอย่างเช่น เป็นไปไม่ได้ที่จะแก้ไขชื่อไฟล์ UTF-8 ที่ไม่ถูกต้องโดยใช้ API ของ UTF-16 เพราะไม่มีสตริง UTF-16 ใดที่จะแปลงเป็นชื่อไฟล์ที่ไม่ถูกต้องนั้นได้ แต่ในทางกลับกันนั้นไม่เป็นเช่นนั้น การแปลง UTF-16 ที่ไม่ถูกต้องให้เป็นสตริง UTF-8 ที่ไม่ซ้ำกัน (แม้ว่าในทางเทคนิคแล้วจะไม่ถูกต้อง) นั้นทำได้ง่ายมาก ดังนั้น API ของ UTF-8 จึงสามารถควบคุมทั้งไฟล์และชื่อ UTF-8 และ UTF-16 ได้ ทำให้ UTF-8 เป็นที่นิยมมากกว่าในสภาพแวดล้อมแบบผสมผสานดังกล่าว วิธีแก้ปัญหาที่น่าเสียดายแต่พบได้บ่อยกว่าในระบบ UTF-16 คือการตีความ UTF-8 เป็นการเข้ารหัสอื่น เช่นCP-1252และละเว้นการแปลงอักขระสำหรับข้อมูลที่ไม่ใช่ ASCII

UTF-16 และ UTF-32 ไม่ได้ กำหนด ลำดับไบต์ไว้ ดังนั้นจึงต้องเลือกลำดับไบต์เมื่อรับข้อมูลผ่านเครือข่ายแบบไบต์ หรืออ่านข้อมูลจากหน่วยเก็บข้อมูลแบบไบต์ ซึ่งอาจทำได้โดยการใช้เครื่องหมายลำดับไบต์ที่จุดเริ่มต้นของข้อความ หรือกำหนดให้เป็นแบบบิ๊กเอนเดียน (RFC 2781) ส่วนUTF-8 , UTF-16BE , UTF-32BE , UTF-16LEและUTF-32LEนั้นใช้ลำดับไบต์มาตรฐานเดียวกัน จึงไม่มีปัญหาดังกล่าว

หากสตรีมไบต์เกิดความเสียหายการเข้ารหัสบางแบบจะกู้คืนได้ดีกว่าแบบอื่น UTF-8 และ UTF-EBCDIC ดีที่สุดในเรื่องนี้ เนื่องจากสามารถซิงโครไนซ์ใหม่ได้เสมอหลังจากไบต์ที่เสียหายหรือหายไปที่จุดเริ่มต้นของจุดรหัสถัดไป ในขณะที่ GB 18030 ไม่สามารถกู้คืนได้จนกว่าจะถึงอักขระ ASCII ที่ไม่ใช่ตัวเลขถัดไป UTF-16 สามารถจัดการกับ ไบต์ ที่เปลี่ยนแปลงได้ แต่ไม่สามารถจัดการกับไบต์ ที่หายไปจำนวนคี่ซึ่งจะทำให้ข้อความที่ตามมาทั้งหมดผิดเพี้ยน (แม้ว่าจะสร้างอักขระที่ไม่ธรรมดาและ/หรืออักขระที่ไม่ได้กำหนดไว้ก็ตาม) ^{[ b ]}หากบิตหายไป บิตทั้งหมดจะทำให้ข้อความที่ตามมาผิดเพี้ยน แม้ว่า UTF-8 จะสามารถซิงโครไนซ์ใหม่ได้ เนื่องจากขอบเขตไบต์ที่ไม่ถูกต้องจะสร้าง UTF-8 ที่ไม่ถูกต้องในข้อความเกือบทั้งหมดที่ยาวกว่าไม่กี่ไบต์

ตารางด้านล่างแสดงจำนวนไบต์ต่อจุดรหัสสำหรับช่วงยูนิโค้ดต่างๆ คำอธิบายเพิ่มเติมใดๆ ที่จำเป็นจะรวมอยู่ในตารางแล้ว ตัวเลขเหล่านี้ตั้งอยู่บนสมมติฐานว่าค่าใช้จ่ายเพิ่มเติมที่จุดเริ่มต้นและจุดสิ้นสุดของบล็อกข้อความนั้นมีน้อยมาก

ตารางนี้อาจไม่ครอบคลุมทุกกรณีพิเศษ ดังนั้นจึงควรใช้เพื่อการประมาณและการเปรียบเทียบเท่านั้น ในการกำหนดขนาดของข้อความในรูปแบบการเข้ารหัสอย่างแม่นยำ โปรดดูข้อกำหนดเฉพาะจริง

ลำดับไบต์ (Endianness) ไม่มีผลต่อขนาด ( UTF-16BEและUTF-32BEมีขนาดเท่ากับUTF-16LEและUTF-32LEตามลำดับ) การใช้ UTF-32 ภายใต้ quoted-printable นั้นทำได้ยากมาก แต่หากนำไปใช้ จะทำให้แต่ละโค้ดพอยต์ใช้พื้นที่ 8-12 ไบต์ (โดยเฉลี่ยประมาณ 10 ไบต์) โดยเฉพาะอย่างยิ่งสำหรับ BMP แต่ละโค้ดพอยต์จะใช้พื้นที่มากกว่าโค้ดเดียวกันใน quoted-printable/UTF-16 ถึง 6 ไบต์ ส่วน Base64/UTF-32 ใช้พื้นที่5 ไบต์+1/3 ไบต์สำหรับรหัสอักขระ ใดๆ

อักขระควบคุม ASCII ภายใต้รูปแบบ quoted-printable หรือ UTF-7 อาจแสดงได้โดยตรงหรือเข้ารหัส (escaped) ความจำเป็นในการหลีกเลี่ยงอักขระควบคุมใดๆ ขึ้นอยู่กับหลายสถานการณ์ แต่ โดยทั่วไปแล้ว การขึ้นบรรทัดใหม่ในข้อมูลข้อความจะถูกเข้ารหัสโดยตรง

BOCU-1และSCSUเป็นวิธีการบีบอัดข้อมูล Unicode สองวิธีการเข้ารหัส ของทั้งสองวิธีนี้ ขึ้นอยู่กับความถี่ในการใช้งานข้อความ โดยส่วนใหญ่ข้อความจะใช้ตัวอักษรเดียวกัน เช่นละตินซิริลลิกกรีกเป็นต้นการใช้งานปกติเช่นนี้ทำให้สามารถบีบอัดข้อความจำนวนมากให้เหลือประมาณ 1 ไบต์ต่อจุดรหัสได้ การเข้ารหัสแบบมีสถานะเหล่านี้ทำให้การเข้าถึงข้อความแบบสุ่มในตำแหน่งใดๆ ของสตริงทำได้ยากขึ้น

วิธีการบีบอัดข้อมูลสองแบบนี้ไม่มีประสิทธิภาพเท่ากับวิธีการบีบอัดข้อมูลอื่นๆ เช่นzipหรือbzip2วิธีการบีบอัดข้อมูลทั่วไปเหล่านั้นสามารถบีบอัดข้อมูลจำนวนมากให้เหลือเพียงไม่กี่ไบต์ได้ วิธีการบีบอัดข้อมูล SCSUและBOCU-1จะบีบอัดได้ไม่เกิน 25% ของข้อความที่เข้ารหัสเป็น UTF-8, UTF-16 หรือ UTF-32 ซึ่งเป็นไปตามทฤษฎี ในขณะที่วิธีการบีบอัดข้อมูลทั่วไปอื่นๆ สามารถบีบอัดได้เหลือเพียง 10% ของขนาดข้อความเดิม วิธีการบีบอัดข้อมูลทั่วไปเหล่านั้นต้องการอัลกอริทึมที่ซับซ้อนกว่าและข้อความจำนวนมากเพื่อให้ได้อัตราการบีบอัดที่ดี

เอกสารทางเทคนิค Unicode หมายเลข 14มีการเปรียบเทียบรูปแบบการบีบอัดข้อมูลโดยละเอียดเพิ่มเติม

มีการเสนอให้ใช้ UTF-5 และ UTF-6 สำหรับการทำให้ชื่อโดเมนเป็นสากล (IDN) ข้อเสนอ UTF-5 ใช้การเข้ารหัสฐาน 32 ในขณะที่ Punycode (ในบรรดาสิ่งอื่นๆ และไม่ตรงเป๊ะ) ใช้การเข้ารหัส ฐาน 36ชื่อUTF-5สำหรับหน่วยรหัส 5 บิตนั้นอธิบายได้ด้วยสมการ 2⁵ ⁼ 32 ส่วนที่ 2 "คำจำกัดความของ UTF-5" ของ RFC ชี้แจงโครงสร้างที่ผิดปกติของ UTF-5: ^{[ 3 ]}

ใน UTF-5 อักขระแต่ละตัวจะถูกเข้ารหัสโดยใช้ลำดับของอ็อกเท็ต 1 ถึง 8 ตัว [...] โปรดทราบว่า UTF-5 ไม่ใช่ลำดับของควินเท็ต แต่เป็นลำดับของอ็อกเท็ต โดยที่อ็อกเท็ตแต่ละตัวอยู่ในช่วงตัวอักษรและตัวเลข ตัวอักษรและตัวเลขในบริบทนี้หมายถึง A ถึง V (ตัวพิมพ์ใหญ่เท่านั้น) และ 0 ถึง 9

ข้อเสนอ UTF-6 ได้เพิ่มการเข้ารหัสความยาวต่อเนื่องให้กับ UTF-5 โดยที่6หมายถึงUTF-5 บวก 1 ^{[ 4 ]}

ต่อมา IETF IDN WG ได้นำ Punycodeที่มีประสิทธิภาพมากกว่ามาใช้เพื่อจุดประสงค์นี้^{[ 5 ]}

UTF-1ไม่ได้รับการยอมรับอย่างจริงจัง ในขณะที่ UTF-8 ถูกใช้งานบ่อยกว่ามาก

การเข้ารหัสnonet UTF-9 และ UTF-18เป็น ข้อกำหนด RFC ที่เป็นเรื่องตลกในวันเอพริลฟูลส์แม้ว่า UTF-9 จะเป็นรูปแบบการแปลง Unicode nonet ที่ใช้งานได้จริง และ UTF-18 เป็นการเข้ารหัส nonet ที่ใช้งานได้จริงสำหรับจุดรหัสที่ไม่ใช่ Private-Use ทั้งหมดใน Unicode 12 และต่ำกว่า แม้ว่าจะไม่สามารถใช้งานได้กับSupplementary Private Use Areasหรือบางส่วนของ Unicode 13 และสูงกว่าก็ตาม