ยูนิโค้ด

โลโก้ของUnicode Consortium
ชื่อเล่น	ชุดอักขระรหัสสากล (UCS) ไอโซ/อีอีซี 10646
ภาษา	สคริปต์ 172 รายการ ( รายการ )
มาตรฐาน	มาตรฐานยูนิโค้ด
รูปแบบการเข้ารหัส	ยูทีเอฟ-8 ยูทีเอฟ-16 GB18030 ยูทีเอฟ-32 โบคู เอสซีเอสยู ยูทีเอฟ-อีบีซีดีไอ (ไม่พบบ่อย) ยูทีเอฟ-7 ยูทีเอฟ-1 (ล้าสมัย)
นำหน้าโดย	มาตรฐาน ISO/IEC 8859และอื่นๆ
เว็บไซต์อย่างเป็นทางการ เว็บไซต์ทางเทคนิค

Unicode (หรือที่รู้จักกันในชื่อThe Unicode StandardและTUS ^{[ 1 ] [ 2 ]} ) เป็น มาตรฐาน การเข้ารหัสอักขระที่ดูแลโดยUnicode Consortium ซึ่งออกแบบมาเพื่อรองรับการใช้ข้อความใน ระบบการเขียนทั้งหมดของโลกที่สามารถแปลงเป็นดิจิทัลได้ เวอร์ชัน 17.0 ^{[ A ]}กำหนดอักขระ 159,801 ตัว และสคริปต์ 172 แบบ ^{[ 3 ]}ที่ใช้ในบริบททั่วไป วรรณกรรม วิชาการ และเทคนิคต่างๆ

Unicode ได้เข้ามาแทนที่ระบบเดิมที่มีชุดอักขระ ที่ไม่เข้ากันจำนวนมาก ซึ่งใช้ในภาษาและสถาปัตยกรรมคอมพิวเตอร์ที่แตกต่างกัน ชุดอักขระทั้งหมดเหล่านั้น รวมถึงอักขระเพิ่มเติมอีกมากมาย ได้ถูกรวมเข้าเป็นชุด Unicode ชุดเดียว Unicode ถูกใช้ในการเข้ารหัสข้อความส่วนใหญ่บนอินเทอร์เน็ต รวมถึงเว็บเพจ ส่วนใหญ่ และการรองรับ Unicode ที่เกี่ยวข้องได้กลายเป็นสิ่งที่ต้องพิจารณาโดยทั่วไปในการพัฒนาซอฟต์แวร์ในปัจจุบัน ในที่สุด Unicode ก็สามารถเข้ารหัสอักขระได้มากกว่า 1.1 ล้านตัว

ชุดอักขระ Unicode ได้รับการซิง โครไนซ์กับISO/IEC 10646 โดยแต่ละชุดมีรหัสเหมือนกันทุกประการ อย่างไรก็ตาม มาตรฐาน Unicodeไม่ได้เป็นเพียงแค่ชุดอักขระที่ใช้ในการกำหนดอักขระเท่านั้น เพื่อช่วยเหลือนักพัฒนาและนักออกแบบ มาตรฐานนี้ยังให้แผนภูมิและข้อมูลอ้างอิง รวมถึงภาคผนวกที่อธิบายแนวคิดที่เกี่ยวข้องกับสคริปต์ต่างๆ ซึ่งเป็นแนวทางในการนำไปใช้ หัวข้อที่ครอบคลุมโดยภาคผนวกเหล่านี้ ได้แก่การทำให้เป็นมาตรฐานของอักขระการประกอบและการแยกส่วนของ อักขระ การเรียงลำดับและทิศทาง^{[ 4 ]}

Unicode เข้ารหัสอีโมจิ 3,790 ตัว โดยมีการพัฒนาอย่างต่อเนื่องโดย Consortium ซึ่งเป็นส่วนหนึ่งของมาตรฐาน^{[ 5 ]}การนำ Unicode มาใช้อย่างแพร่หลายมีส่วนสำคัญอย่างมากต่อความนิยมของอีโมจินอกประเทศญี่ปุ่นในระยะเริ่มต้น

ข้อความ Unicode จะถูกประมวลผลและจัดเก็บเป็นข้อมูลไบนารีโดยใช้การเข้ารหัสแบบใดแบบหนึ่งซึ่งกำหนดวิธีการแปลงรหัสที่เป็นนามธรรมของมาตรฐานสำหรับอักขระให้เป็นลำดับของไบต์มาตรฐาน Unicodeเองได้กำหนดการเข้ารหัสไว้สามแบบ ได้แก่UTF -8 ^, UTF -16 ^และ UTF -32 แม้ว่าจะมี ^แบบอื่นๆ อีกหลายแบบก็ตาม UTF-8 เป็นแบบที่ใช้กันอย่างแพร่หลายที่สุด โดยมีส่วนต่างมากเนื่องจากความเข้ากันได้แบบย้อนหลังกับ ASCII

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

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

ในระดับนามธรรมที่สุด Unicode กำหนดหมายเลขเฉพาะที่เรียกว่ารหัสจุด (code point)ให้กับอักขระแต่ละตัว ประเด็นต่างๆ เกี่ยวกับการแสดงผลทางภาพ—รวมถึงขนาด รูปร่าง และรูปแบบ—นั้นตั้งใจให้ขึ้นอยู่กับดุลยพินิจของซอฟต์แวร์ที่แสดงผลข้อความนั้นๆ เช่นเว็บเบราว์ เซอร์ หรือโปรแกรมประมวลผลคำอย่างไรก็ตาม ด้วยเจตนาส่วนหนึ่งที่จะส่งเสริมการนำไปใช้งานอย่างรวดเร็ว ความเรียบง่ายของแบบจำลองดั้งเดิมนี้จึงมีความซับซ้อนมากขึ้นเมื่อเวลาผ่านไป และมีการปรับเปลี่ยนในทางปฏิบัติหลายประการตลอดการพัฒนามาตรฐานนี้

รหัสอักขระ 256 ตัวแรกนั้นสอดคล้องกับ มาตรฐาน ISO/IEC 8859-1โดยมีจุดประสงค์เพื่อลดความยุ่งยากในการแปลงข้อความที่เขียนด้วยอักษรยุโรปตะวันตกอยู่แล้ว เพื่อรักษาความแตกต่างที่เกิดจากการเข้ารหัสแบบเดิมต่างๆ และทำให้สามารถแปลงระหว่างการเข้ารหัสเหล่านั้นกับยูนิโค้ดได้โดยไม่สูญเสียข้อมูลใดๆอักขระหลายตัวที่เกือบจะเหมือนกันทั้งในด้านรูปลักษณ์และหน้าที่การใช้งาน จึงได้รับรหัสอักขระที่แตกต่างกัน ตัวอย่างเช่น บล็อก Halfwidth และ Fullwidth Formsครอบคลุมสำเนาความหมายทั้งหมดของอักษรละติน เนื่องจากระบบการเข้ารหัส CJK แบบเดิม มีทั้งอักขระ "fullwidth" (ตรงกับความกว้างของอักขระ CJK) และ "halfwidth" (ตรงกับอักษรละตินทั่วไป)

จุดเริ่มต้นของ Unicode สามารถสืบย้อนไปได้ถึงช่วงทศวรรษ 1980 โดยกลุ่มบุคคลที่มีความเชื่อมโยงกับมาตรฐานรหัสอักขระ (XCCS) ของXerox ^{[ 6 ]}ในปี 1987 โจ เบ็คเกอร์ พนักงานของ Xerox พร้อมด้วยลี คอลลินส์และมาร์ค เดวิสพนักงานของ Appleได้เริ่มตรวจสอบความเป็นไปได้ในการสร้างชุดอักขระสากล^{[ 7 ]}ด้วยข้อมูลเพิ่มเติมจากปีเตอร์ เฟนวิค และเดฟ ออปสแตด [ ^{6 ] เบ็}คเกอร์ได้เผยแพร่ร่างข้อเสนอสำหรับ "ระบบการเข้ารหัสอักขระข้อความสากล/หลายภาษา" ในเดือนสิงหาคม 1988 ซึ่งเรียกอย่างไม่เป็นทางการว่า Unicode เขาอธิบายว่า "ชื่อ 'Unicode' มีจุดประสงค์เพื่อสื่อถึงการเข้ารหัสที่เป็นเอกลักษณ์ เป็นหนึ่งเดียว และเป็นสากล" ^{[ 6 ]}

ในเอกสารฉบับนี้ที่มีชื่อว่าUnicode 88เบ็คเกอร์ได้สรุปแผนการใช้ ตัวอักษร 16 บิตไว้ดังนี้ : ^{[ 6 ]}

Unicode มีจุดประสงค์เพื่อตอบสนองความต้องการระบบเข้ารหัสข้อความสากลที่ใช้งานได้จริงและน่าเชื่อถือ Unicode อาจอธิบายได้คร่าว ๆ ว่าเป็น " ASCII แบบตัวอักขระกว้าง " ที่ขยายเป็น 16 บิต เพื่อรองรับอักขระของภาษาที่ใช้กันอยู่ทั่วโลก ในการออกแบบที่เหมาะสม 16 บิตต่ออักขระนั้นเพียงพอต่อวัตถุประสงค์นี้แล้ว

การตัดสินใจออกแบบนี้เกิดขึ้นบนพื้นฐานของสมมติฐานที่ว่าเฉพาะสคริปต์และตัวอักษรที่ใช้ "สมัยใหม่" เท่านั้นที่จะต้องมีการเข้ารหัส: ^{[ 6 ]}

Unicode ให้ความสำคัญกับการใช้งานได้ในอนาคตมากกว่าการอนุรักษ์อักขระโบราณ เป้าหมายหลักของ Unicode คืออักขระที่ตีพิมพ์ในข้อความสมัยใหม่ (เช่น ในหนังสือพิมพ์และนิตยสารทั้งหมดที่ตีพิมพ์ทั่วโลกในปี 1988) ซึ่งมีจำนวนน้อยกว่า 2¹⁴ ⁼ 16,384 อย่างแน่นอน นอกเหนือจากอักขระที่ใช้ในปัจจุบันแล้ว อักขระอื่นๆ อาจถูกกำหนดว่าล้าสมัยหรือหายาก ซึ่งเหมาะสมกว่าสำหรับการจดทะเบียนเพื่อใช้งานส่วนตัวมากกว่าที่จะนำไปเพิ่มภาระให้กับรายการอักขระ Unicode ที่มีประโยชน์ทั่วไปในที่สาธารณะ

ในช่วงต้นปี 1989 กลุ่มทำงาน Unicode ได้ขยายขอบเขตไปรวมถึง Ken Whistler และ Mike Kernaghan จาก Metaphor, Karen Smith-Yoshimura และ Joan Aliprand จากResearch Libraries Groupและ Glenn Wright จากSun Microsystems Research Libraries Group มีโซลูชันที่มีอยู่แล้วสำหรับชุดอักขระเอเชียตะวันออก ซึ่งกลายเป็นหนึ่งในข้อมูลป้อนเข้าสำหรับชุดอักขระ Unicode ^{[ 7 ]}ในปี 1990 Michel Suignard และ Asmus Freytag จากMicrosoftและ Rick McGowan จาก NeXTก็ได้เข้าร่วมกลุ่มด้วยเช่นกัน เมื่อสิ้นปี 1990 งานส่วนใหญ่ในการแมปมาตรฐานที่มีอยู่แล้วเสร็จสมบูรณ์ และร่างฉบับตรวจสอบขั้นสุดท้ายของ Unicode ก็พร้อมแล้ว

Unicode Consortiumได้รับการจดทะเบียนในแคลิฟอร์เนียเมื่อวันที่ 3 มกราคม พ.ศ. 2534 ^{[ 8 ]} และหนังสือ The Unicode Standardเล่มแรกได้รับการตีพิมพ์ในเดือนตุลาคมปีเดียวกัน เล่มที่สองซึ่งเพิ่มอักษรฮั่นเข้าไป ได้รับการตีพิมพ์ในเดือนมิถุนายน พ.ศ. 2535

ในปี พ.ศ. 2539 กลไกอักขระทดแทนได้รับการนำมาใช้ใน Unicode 2.0 ทำให้ Unicode ไม่จำกัดอยู่ที่ 16 บิตอีกต่อไป ส่งผลให้พื้นที่รหัสของ Unicode เพิ่มขึ้นเป็นมากกว่าหนึ่งล้านจุดรหัส ซึ่งทำให้สามารถเข้ารหัสสคริปต์โบราณจำนวนมาก เช่นอักษรฮีโรกลิฟของอียิปต์และอักขระที่ใช้น้อยหรือล้าสมัยอีกหลายพันตัวที่ไม่ได้คาดการณ์ว่าจะรวมอยู่ในมาตรฐาน ในบรรดาอักขระเหล่านี้มีอักขระ CJK ที่ใช้น้อยหลายตัว ซึ่งส่วนใหญ่ใช้ในชื่อเฉพาะ ทำให้มีความจำเป็นสำหรับการเข้ารหัสสากลมากกว่าที่สถาปัตยกรรม Unicode ดั้งเดิมคาดการณ์ไว้^{[ 9 ]}

Unicode Consortium เป็นองค์กรไม่แสวงหาผลกำไรที่ประสานงานการพัฒนา Unicode สมาชิกเต็มรูปแบบประกอบด้วยบริษัทซอฟต์แวร์และฮาร์ดแวร์คอมพิวเตอร์รายใหญ่ส่วนใหญ่ (และอีกไม่กี่บริษัท) ที่สนใจในมาตรฐานการประมวลผลข้อความ รวมถึง^Adobe , Apple , Google , IBM , Meta (เดิมคือ Facebook), Microsoft , NetflixและSAP ^{[ 10} ]

ตลอดหลายปีที่ผ่านมา ประเทศหรือหน่วยงานรัฐบาลหลายแห่งเป็นสมาชิกของ Unicode Consortium ^{[ 10 ]}

กลุ่มพันธมิตรนี้มีเป้าหมายที่ทะเยอทะยานในการแทนที่ระบบการเข้ารหัสอักขระที่มีอยู่เดิมด้วยยูนิโค้ดและรูปแบบการแปลงยูนิโค้ดมาตรฐาน (UTF) ในที่สุด เนื่องจากระบบที่มีอยู่เดิมหลายระบบมีขนาดและขอบเขตจำกัด และไม่เข้ากันกับสภาพแวดล้อม หลายภาษา

รางวัลUnicode Bulldogมอบให้แก่บุคคลที่ถือว่ามีอิทธิพลต่อการพัฒนา Unicode โดยผู้ที่ได้รับรางวัล ได้แก่Tatsuo Kobayashi , Thomas Milo, Roozbeh Pournader, Ken LundeและMichael Everson ^{[ 11 ]}

ณ เดือนกันยายน พ.ศ. 2568 มี สคริปต์ทั้งหมด 172 ^{[ 12 ]} ชุด ( อักษร , อักษรอะบูจิดาและอักษรพยางค์ ) ที่รวมอยู่ในยูนิโค้ด ซึ่งครอบคลุมระบบการเขียน หลักส่วนใหญ่ ที่ใช้ในปัจจุบัน^{[ 13 ] [ 14 ]} ยังคงมีสคริปต์ที่ยังไม่ได้เข้ารหัส โดยเฉพาะอย่างยิ่งสคริปต์ที่ใช้เป็นหลักในบริบททางประวัติศาสตร์ พิธีกรรม และวิชาการ นอกจากนี้ยังมี การเพิ่มตัวอักษรลงในสคริปต์ที่เข้ารหัสแล้ว รวมถึงสัญลักษณ์โดยเฉพาะอย่างยิ่งสำหรับคณิตศาสตร์และดนตรี

คณะกรรมการ Unicode Roadmap ( Michael Everson , Rick McGowan, Ken Whistler, VS Umamaheswaran) ^{[ 15 ]}ดูแลรายชื่อสคริปต์ที่เป็นผู้สมัครหรือผู้สมัครที่มีศักยภาพสำหรับการเข้ารหัสและการกำหนดบล็อกรหัสเบื้องต้นบนหน้า Unicode Roadmap ^{[ 16 ]} ของเว็บไซต์ Unicode Consortiumสำหรับสคริปต์บางส่วนใน Roadmap เช่นJurchenและสคริปต์ Khitan ขนาดใหญ่มีการเสนอการเข้ารหัสและกำลังดำเนินการตามกระบวนการอนุมัติ สำหรับสคริปต์อื่นๆ เช่นNumidianและRongorongoยังไม่มีการเสนอใดๆ และกำลังรอข้อตกลงเกี่ยวกับชุดอักขระและรายละเอียดอื่นๆ จากชุมชนผู้ใช้ที่เกี่ยวข้อง

อักษรประดิษฐ์สมัยใหม่บางส่วนที่ยังไม่ได้รับการบรรจุในยูนิโค้ด (เช่น อักษรเทงวาร์ ) หรือไม่เข้าเกณฑ์การบรรจุในยูนิโค้ดเนื่องจากขาดการใช้งานจริง (เช่น อักษรคลิงออน ) จะถูกระบุไว้ในConScript Unicode Registryพร้อมกับ การ กำหนดรหัส พื้นที่ใช้งานส่วนตัว ที่ไม่เป็นทางการแต่ใช้กันอย่างแพร่หลาย

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

โครงการ Script Encoding Initiative (SEI) ^{[ 17 ]}ซึ่งเป็นโครงการที่สร้างขึ้นโดย Deborah Anderson ที่มหาวิทยาลัยแคลิฟอร์เนีย เบิร์กลีย์ก่อตั้งขึ้นในปี 2545 โดยมีเป้าหมายเพื่อสนับสนุนข้อเสนอสำหรับสคริปต์ที่ยังไม่ได้รับการเข้ารหัสในมาตรฐาน ปัจจุบันบริหารงานโดย Anushah Hossain และ SEI ได้กลายเป็นแหล่งสำคัญของข้อเสนอเพิ่มเติมสำหรับมาตรฐานในช่วงไม่กี่ปีที่ผ่านมา^{[ 18 ]}แม้ว่า SEI จะร่วมมือกับ Unicode Consortium และกระบวนการมาตรฐาน ISO/IEC 10646 แต่ก็ดำเนินงานอย่างอิสระ โดยสนับสนุนการวิจัยทางเทคนิค ภาษาศาสตร์ และประวัติศาสตร์ที่จำเป็นในการเตรียมข้อเสนออย่างเป็นทางการ SEI รักษาฐานข้อมูลของสคริปต์ที่ยังไม่ได้รับการเข้ารหัสในมาตรฐาน Unicode บนเว็บไซต์ของโครงการ^{[ 19 ]}

สมาคมยูนิโค้ด (Unicode Consortium) ร่วมกับไอโซ (ISO) ได้พัฒนาระบบอักขระ ร่วมกัน หลังจากมีการเผยแพร่มาตรฐานยูนิโค้ด (The Unicode Standard ) ครั้งแรก โดยยูนิโค้ดและ ชุดอักขระรหัสสากล (UCS) ของไอโซใช้ชื่ออักขระและรหัสจุดที่เหมือนกัน อย่างไรก็ตาม เวอร์ชันของยูนิโค้ดแตกต่างจากเวอร์ชันของไอโซในสองประเด็นสำคัญ

ในขณะที่ UCS เป็นเพียงแผนที่อักขระแบบง่ายๆ Unicode กำหนดกฎ อัลกอริทึม และคุณสมบัติที่จำเป็นเพื่อให้สามารถทำงานร่วมกันได้ระหว่างแพลตฟอร์มและภาษาต่างๆ ดังนั้นมาตรฐาน Unicodeจึงมีข้อมูลมากกว่า ครอบคลุมหัวข้อเชิงลึก เช่น การเข้ารหัสแบบบิตการเรียงลำดับและการแสดงผล นอกจากนี้ยังให้แคตตาล็อกที่ครอบคลุมของคุณสมบัติอักขระ รวมถึงคุณสมบัติที่จำเป็นสำหรับการสนับสนุนข้อความแบบสองทิศทางตลอดจนแผนภูมิภาพและชุดข้อมูลอ้างอิงเพื่อช่วยผู้ใช้งาน ก่อนหน้านี้มาตรฐาน Unicodeถูกขายเป็นเล่มพิมพ์ที่มีข้อกำหนดหลักทั้งหมด ภาคผนวกมาตรฐาน^{[หมายเหตุ 1 ]}และแผนภูมิรหัส อย่างไรก็ตาม เวอร์ชัน 5.0 ที่เผยแพร่ในปี 2549 เป็นเวอร์ชันสุดท้ายที่พิมพ์ในลักษณะนี้ เริ่มตั้งแต่เวอร์ชัน 5.2 เป็นต้นไป สามารถซื้อได้เฉพาะข้อกำหนดหลักที่เผยแพร่เป็นหนังสือปกอ่อนแบบพิมพ์ตามสั่งเท่านั้น^{[ 20 ]}ในทางกลับกัน ข้อความฉบับเต็มเผยแพร่เป็นไฟล์ PDF ฟรีบนเว็บไซต์ Unicode

เหตุผลเชิงปฏิบัติสำหรับการเผยแพร่ในรูปแบบนี้เน้นให้เห็นถึงความแตกต่างที่สำคัญประการที่สองระหว่าง UCS และ Unicode นั่นคือ ความถี่ในการเผยแพร่เวอร์ชันที่อัปเดตและเพิ่มอักขระใหม่มาตรฐาน Unicodeได้เผยแพร่เวอร์ชันที่ขยายเพิ่มเติมเป็นประจำทุกปี บางครั้งอาจมีการเผยแพร่มากกว่าหนึ่งเวอร์ชันในหนึ่งปีปฏิทิน และในบางกรณีที่หายากซึ่งการเผยแพร่ตามกำหนดต้องถูกเลื่อนออกไป ตัวอย่างเช่น ในเดือนเมษายน 2020 หนึ่งเดือนหลังจากที่เผยแพร่เวอร์ชัน 13.0 แล้ว สมาคม Unicode ได้ประกาศว่าได้เปลี่ยนวันที่เผยแพร่เวอร์ชัน 14.0 โดยเลื่อนออกไปหกเดือนเป็นเดือนกันยายน 2021 เนื่องจาก สถานการณ์การระบาดของ COVID - 19

จนถึงปัจจุบัน มีการเผยแพร่ มาตรฐาน Unicode เวอร์ชันต่อไปนี้ เวอร์ชันอัปเดตซึ่งไม่มีการเปลี่ยนแปลงใดๆ ในชุดอักขระ จะถูกระบุด้วยตัวเลขที่สาม (เช่น "เวอร์ชัน 4.0.1") และจะถูกละเว้นในตารางด้านล่าง^{[ 21 ]}

มาตรฐาน Unicodeกำหนดพื้นที่รหัสไว้ดังนี้ : ^{[ 59 ]}ลำดับของจำนวนเต็มที่เรียกว่าจุดรหัส^{[ 60 ]}ในช่วงตั้งแต่ 0 ถึง1 114 111ระบุตามมาตรฐานเป็นU+0000 – U+10FFFF [ ^{61 ] พื้นที่}รหัสเป็นการแสดงมาตรฐาน Unicode ที่เป็นระบบและไม่ขึ้นกับสถาปัตยกรรม ข้อความจริงจะถูกประมวลผลเป็นข้อมูลไบนารีผ่านการเข้ารหัส Unicode หลายแบบ เช่นUTF- 8

ในการเขียนสัญลักษณ์มาตรฐานนี้ คำนำหน้าสองตัวอักษรU+จะอยู่หน้าจุดรหัสที่เขียนเสมอ และจุดรหัสเหล่านั้นจะเขียนเป็นเลขฐานสิบหก^{[หมายเหตุ 2 ]}จะต้องเขียนเลขฐานสิบหกอย่างน้อยสี่หลักเสมอ โดย เติม เลขศูนย์นำหน้าตามความจำเป็น ตัวอย่างเช่น จุดรหัสU+00F7 ÷ DIVISION SIGNจะถูกเติมเลขศูนย์นำหน้าสองตัว แต่U+13254 𓉔 EGYPTIAN HIEROGLYPH O004 ( ) จะไม่ถูกเติม เลขศูนย์นำหน้า ^{[ 63 ]}

มีจำนวนทั้งหมด1,112,064จุดรหัสที่ถูกต้องภายในพื้นที่รหัส^[ 64 ^]ตัวเลขนี้เกิดจากข้อจำกัดของ การเข้ารหัสอักขระ UTF-16 ซึ่งสามารถเข้ารหัส จุด ^{รหัส 2¹⁶}จุดในช่วงU+0000ถึงU+FFFFยกเว้น จุดรหัส ^2¹¹จุดในช่วงU+D800ถึงU+DFFFซึ่งใช้เป็นคู่ตัวแทนเพื่อเข้ารหัส จุดรหัส ^2²⁰จุดในช่วงU+10000ถึงU+ 10FFFF

ปริภูมิรหัสยูนิโค้ดแบ่งออกเป็น 17 ระนาบโดยมีหมายเลขตั้งแต่ 0 ถึง 16 ระนาบที่ 0 คือระนาบหลายภาษาพื้นฐาน (Basic Multilingual Plane หรือ BMP) ซึ่งประกอบด้วยอักขระที่ใช้กันทั่วไปมากที่สุด จุดรหัสทั้งหมดใน BMP สามารถเข้าถึงได้ในรูปแบบหน่วยรหัสเดียวในการเข้ารหัส UTF-16 และสามารถเข้ารหัสได้ในหนึ่ง สอง หรือสามไบต์ใน UTF-8 จุดรหัสในระนาบที่ 1 ถึง 16 ( ระนาบเสริม ) สามารถเข้าถึงได้ในรูปแบบคู่ตัวแทน (surrogate pairs) ในUTF-16และเข้ารหัสในสี่ไบต์ในUTF- 8

ภายในแต่ละระนาบ อักขระจะถูกจัดสรรไว้ในบล็อก ที่มีชื่อ ซึ่งประกอบด้วยอักขระที่เกี่ยวข้องกัน ขนาดของบล็อกจะเป็นจำนวนเท่าของ 16 เสมอ และมักจะเป็นจำนวนเท่าของ 128 แต่ขนาดอื่นๆ นั้นไม่แน่นอน อักขระที่จำเป็นสำหรับสคริปต์ที่กำหนดอาจกระจายอยู่ทั่วหลายบล็อกที่แตกต่างกัน ซึ่งอาจไม่ต่อเนื่องกันภายในพื้นที่รหัส

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

เดอะจุดรหัส 1024จุดในช่วงU+D800 – U+DBFFเรียกว่า จุดรหัส ทดแทนสูงและจุดรหัสในช่วงU+DC00 – U+DFFF (รหัสจุด (code points) จำนวน 1024 รหัส เรียกว่า รหัสจุดเซอร์โรเก ตต่ำ (low-surrogate code points) รหัส จุดเซอร์โรเกตสูง (high-surrogate code point) ตามด้วยรหัสจุดเซอร์โรเกตต่ำ (low-surrogate code point) จะก่อให้เกิดคู่เซอร์โรเกต (surrogate pair) ใน UTF-16 เพื่อแสดงรหัสจุดที่มากกว่าU+FFFFโดยหลักการแล้ว รหัสจุดเหล่านี้ไม่สามารถนำไปใช้ในลักษณะอื่นได้ แต่ในทางปฏิบัติมักละเลยกฎนี้ โดยเฉพาะอย่างยิ่งเมื่อไม่ได้ใช้ UTF-16

ชุดรหัสจุดจำนวนเล็กน้อยรับประกันว่าจะไม่มีการกำหนดให้กับอักขระใดๆ แม้ว่าบุคคลที่สามอาจใช้รหัสจุดเหล่านี้ได้อย่างอิสระตามดุลยพินิจของตนก็ตาม มีอักขระที่ไม่ใช่อักขระ เหล่านี้ 66 ตัว ได้แก่U+FDD0 – U+FDEFและรหัสจุดสองตัวสุดท้ายในแต่ละระนาบทั้ง 17 ระนาบ (เช่นU+FFFE , U+FFFF , U+1FFFE , U+1FFFF , ..., U+10FFFE , U+10FFFF ) ชุดของอักขระที่ไม่ใช่อักขระเหล่านี้มีความเสถียร และจะไม่มีการกำหนดอักขระที่ไม่ใช่อักขระใหม่ๆ อีกต่อไป^{[ 65 ]}เช่นเดียวกับอักขระทดแทน กฎที่ว่าอักขระเหล่านี้ไม่สามารถใช้ได้มักถูกละเลย แม้ว่าการทำงานของเครื่องหมายลำดับไบต์จะถือว่าU+FFFEจะไม่เป็นรหัสจุดแรกในข้อความก็ตาม การยกเว้นอักขระทดแทนและอักขระที่ไม่ใช่อักขระทำให้เหลือมีรหัสจุดให้ใช้งาน ได้ 1,111,998 รหัส

รหัสจุด สำหรับการใช้งานส่วนตัวถือว่าได้รับการกำหนดแล้ว แต่โดยเจตนาจะไม่มีการตีความที่ระบุไว้ในมาตรฐาน Unicode ^{[ 66 ]}ดังนั้นการแลกเปลี่ยนรหัสจุดดังกล่าวจึงต้องอาศัยข้อตกลงที่เป็นอิสระระหว่างผู้ส่งและผู้รับเกี่ยวกับการตีความ มีพื้นที่ใช้งานส่วนตัวสามแห่งในพื้นที่รหัส Unicode:

• พื้นที่ใช้งานส่วนบุคคล: U+E000 – U+F8FF ((6400ตัวอักษร)
• พื้นที่ใช้งานส่วนตัวเพิ่มเติม-A: U+F0000 – U+FFFFD (( 65,534ตัวอักษร)
• พื้นที่ใช้งานส่วนตัวเพิ่มเติม-B: U+100000 – U+10FFFD (( 65,534ตัวอักษร)

อักขระ กราฟิก คืออักขระที่ มาตรฐานยูนิโค้ดกำหนดให้มีความหมายเฉพาะ โดยอาจมี รูปร่าง เป็นสัญลักษณ์ ที่มองเห็นได้ หรืออาจแทนพื้นที่ที่มองเห็นได้ ณ ยูนิโค้ด 17.0 มีอยู่ดังนี้อักขระกราฟิก 159,629 ตัว

อักขระ จัดรูปแบบคือ อักขระที่ไม่มีลักษณะปรากฏให้เห็น แต่Hอาจมีผลต่อลักษณะหรือพฤติกรรมของอักขระข้างเคียง ตัวอย่างเช่นU+200C ZERO WIDTH NON-JOINERและU+200D ZERO WIDTH JOINERอาจใช้เพื่อเปลี่ยนพฤติกรรมการจัดรูปแบบเริ่มต้นของอักขระที่อยู่ติดกัน (เช่น เพื่อยับยั้งการเชื่อมตัวอักษร หรือขอให้สร้างการเชื่อมตัวอักษร) Unicode 17.0 มีอักขระจัดรูปแบบทั้งหมด 172 ตัว

รหัสอักขระ 65 จุด ในช่วงU+0000 – U+001FและU+007F – U+009Fถูกสงวนไว้เป็นรหัสควบคุมซึ่งสอดคล้องกับรหัสควบคุม C0 และ C1ตามที่กำหนดไว้ในISO/IEC 6429 U +0009 TAB , U+000A LINE FEEDและU+000D CARRIAGE RETURNเป็นรหัสที่ใช้กันอย่างแพร่หลายในข้อความที่ใช้ Unicode ในปรากฏการณ์ที่เรียกว่าmojibakeรหัสอักขระ C1 จะถูกถอดรหัสอย่างไม่ถูกต้องตาม ชุดรหัส Windows-1252ซึ่งเคยใช้กันอย่างแพร่หลายในบริบทของยุโรปตะวันตก

อักขระกราฟิก อักขระรูปแบบ อักขระรหัสควบคุม และอักขระใช้งานส่วนตัว เรียกรวมกันว่าอักขระที่กำหนด (assigned characters ) ส่วนรหัสจุด สงวน (reserved code points) คือรหัสจุดที่ถูกต้องและพร้อมใช้งาน แต่ยังไม่ได้ถูกกำหนดให้ใช้ ณ ยูนิโค้ด 17.0 มีรหัสจุดสงวนอยู่ดังนี้รหัสจุดสงวน 814 664

ชุดของอักขระกราฟิกและรูปแบบที่กำหนดโดย Unicode ไม่สอดคล้องโดยตรงกับชุดของอักขระนามธรรมที่สามารถแสดงได้ภายใต้ Unicode Unicode เข้ารหัสอักขระโดยการเชื่อมโยงอักขระนามธรรมกับจุดรหัสเฉพาะ^{[ 67 ]}อย่างไรก็ตาม อักขระนามธรรมบางตัวไม่ได้ถูกเข้ารหัสเป็นอักขระ Unicode ตัวเดียว และอักขระนามธรรมบางตัวอาจถูกแสดงใน Unicode ด้วยลำดับของอักขระสองตัวขึ้นไป ตัวอย่างเช่น ตัวอักษรละตินตัวเล็ก "i" ที่มีogonekจุดเหนือและเครื่องหมายเน้นเสียงซึ่งเป็นสิ่งที่จำเป็นในภาษาลิทัวเนียจะถูกแสดงด้วยลำดับอักขระU+012F ; U+0307 ; U+0301 Unicode รักษารายชื่อลำดับอักขระที่มีชื่อเฉพาะสำหรับอักขระนามธรรมที่ไม่ได้เข้ารหัสโดยตรงใน Unicode ^{[ 68 ]}

อักขระที่กำหนดทั้งหมดมีชื่อเฉพาะและไม่สามารถเปลี่ยนแปลงได้ ซึ่งใช้ระบุอักขระเหล่านั้น ความไม่เปลี่ยนแปลงนี้ได้รับการรับประกันตั้งแต่เวอร์ชัน 2.0 ของมาตรฐาน Unicodeโดยนโยบายความเสถียรของชื่อ^{[ 65 ]}ในกรณีที่ชื่อมีข้อบกพร่องร้ายแรงและทำให้เข้าใจผิด หรือมีข้อผิดพลาดในการพิมพ์อย่างร้ายแรง อาจมีการกำหนด ชื่อแทน อย่างเป็นทางการ ที่แอปพลิเคชันควรใช้แทนชื่ออักขระอย่างเป็นทางการ ตัวอย่างเช่นU+A015 ꀕ YI SYLLABLE WUมีชื่อแทนอย่างเป็นทางการว่า YI SYLLABLE ITERATION MARKและU+FE18 ︘ PRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRAKCET ( sic ⁾มีชื่อแทนอย่างเป็นทางการว่า PRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRAKCET ^{[ 69} ]

Unicode มีกลไกสำหรับการปรับเปลี่ยนอักขระ ซึ่งช่วยขยายขอบเขตของสัญลักษณ์ที่รองรับได้อย่างมาก รวมถึงการใช้เครื่องหมายเสริมที่ผู้ใช้สามารถเพิ่มต่อท้ายอักขระหลักได้ สามารถใช้เครื่องหมายเสริมหลายตัวพร้อมกันกับอักขระเดียวกันได้ นอกจากนี้ Unicode ยังมี รูปแบบ สำเร็จรูปของตัวอักษร/เครื่องหมายเสริมส่วนใหญ่ที่ใช้กันทั่วไป ซึ่งทำให้การแปลงไปมาระหว่างการเข้ารหัสแบบเดิมง่ายขึ้น และช่วยให้แอปพลิเคชันสามารถใช้ Unicode เป็นรูปแบบข้อความภายในได้โดยไม่ต้องสร้างอักขระเสริมขึ้นเอง ตัวอย่างเช่นéสามารถแสดงใน Unicode ได้เป็นU+0065 e LATIN SMALL LETTER Eตามด้วยU+0301 ◌́ COMBINING ACUTE ACCENTและเทียบเท่ากับอักขระสำเร็จรูปU+00E9 é LATIN SMALL LETTER E WITH ACUTEดังนั้น ผู้ใช้มักมีวิธีการเข้ารหัสอักขระเดียวกันหลายวิธีที่เทียบเท่ากัน กลไกความเท่าเทียมกัน ตามแบบแผน ภายในมาตรฐาน Unicodeช่วยให้มั่นใจได้ถึงการแลกเปลี่ยนที่ใช้งานได้จริงของการเข้ารหัสที่เทียบเท่ากันเหล่านี้

ตัวอย่างหนึ่งของเรื่องนี้เกิดขึ้นกับอักษรเกาหลีฮันกุล : ยูนิโค้ดมีกลไกสำหรับการประกอบพยางค์ฮันกุลจาก ส่วนประกอบย่อย ฮันกุลจาโม แต่ละส่วน อย่างไรก็ตาม มันก็ยังมีข้อจำกัดอื่นๆ อีกด้วย11,172รูปแบบของการผสมพยางค์สำเร็จรูปที่สร้างจาก jamo ที่พบได้บ่อย ที่สุด

ปัจจุบัน อักษรจีน ญี่ปุ่น และเกาหลี (CJK)มีรหัสเฉพาะสำหรับส่วนประกอบที่ไม่สามารถประกอบกันได้ และรูปแบบที่ประกอบขึ้นแล้วเท่านั้น อักษรฮั่นส่วนใหญ่ถูกประกอบขึ้นโดยเจตนาจาก หรือสร้างขึ้นใหม่จากส่วนประกอบทางอักขรวิธีที่เรียบง่ายกว่าที่เรียกว่าส่วนประกอบ (radicals ) ดังนั้นในทางทฤษฎีแล้ว Unicode น่าจะสามารถทำให้สามารถประกอบส่วนประกอบเหล่านี้ได้เช่นเดียวกับที่ทำกับอักษรฮันกึล แม้ว่าวิธีนี้จะช่วยลดจำนวนจุดรหัสที่จำเป็นลงได้อย่างมาก รวมถึงอนุญาตให้สังเคราะห์อักษรใหม่ๆ ได้มากมายโดยใช้อัลกอริทึม แต่ความซับซ้อนของรากศัพท์ของอักษรและลักษณะที่เกิดขึ้นภายหลังของระบบส่วนประกอบ (radicals) ทำให้ข้อเสนอนี้มีความซับซ้อนอย่างมาก อันที่จริง ความพยายามในการออกแบบการเข้ารหัส CJK บนพื้นฐานของการประกอบส่วนประกอบ (radicals) นั้นประสบกับความยากลำบากอันเนื่องมาจากความเป็นจริงที่ว่า อักษรจีนไม่ได้แยกส่วนได้ง่ายหรือสม่ำเสมอเหมือนกับอักษรฮันกึล

บล็อกอักษรรากศัพท์ CJKถูกกำหนดให้อยู่ในช่วงU+2E80 – U+2EFFและอักษรรากศัพท์ Kangxiถูกกำหนดให้อยู่ในช่วงU+2F00 – U+2FDFบล็อกลำดับคำอธิบายอักษรภาพครอบคลุมช่วงU+2FF0 – U+2FFBแต่มาตรฐาน Unicodeเตือนไม่ให้ใช้อักษรเหล่านี้เป็นตัวแทนทางเลือกสำหรับอักษรที่เข้ารหัสไว้ที่อื่น:

กระบวนการนี้แตกต่างจากการเข้ารหัสอักษรภาพอย่างเป็นทางการ ไม่มีคำอธิบายที่เป็นมาตรฐานสำหรับอักษรภาพที่ยังไม่ได้เข้ารหัส ไม่มีความหมายที่กำหนดให้กับอักษรภาพที่ได้รับการอธิบาย และไม่มีความเท่าเทียมกันที่กำหนดไว้สำหรับอักษรภาพที่ได้รับการอธิบาย ในเชิงแนวคิด คำอธิบายอักษรภาพนั้นคล้ายคลึงกับวลีภาษาอังกฤษที่ว่า "ตัว 'e' ที่มีเครื่องหมายเน้นเสียงแหลมอยู่" มากกว่าลำดับตัวอักษร <U+0065, U+0301>

เทวนาการีddhrya -ligature (द् + ध् + र् + य = द्ध्र्य) ของ JanaSanskritSans ^{[ 70 ]}

ภาษาอาหรับลาม- อะลิฟมัด ( ل ‎+ ‎ ا ‎= ‎ لا )

อักษรหลายตัว รวมถึงอักษรอาหรับและอักษรเทวนาครีมีกฎการเขียนพิเศษที่กำหนดให้ต้องมีการรวมตัวอักษรบางรูปแบบเข้าด้วยกันเพื่อ สร้าง รูปแบบการเชื่อมตัวอักษรพิเศษ กฎที่ควบคุมการสร้างการเชื่อมตัวอักษรนั้นค่อนข้างซับซ้อน ทำให้ต้องใช้เทคโนโลยีการจัดรูปแบบอักษรพิเศษ เช่น ACE (Arabic Calligraphic Engine โดย DecoType ในช่วงทศวรรษ 1980 และใช้ในการสร้างตัวอย่างอักษรอาหรับทั้งหมดในฉบับพิมพ์ของมาตรฐาน Unicode ) ซึ่งกลายเป็นต้นแบบสำหรับOpenType (โดย Adobe และ Microsoft), Graphite (โดยSIL International ) หรือAAT (โดย Apple)

นอกจากนี้ ยังมีการฝังคำสั่งไว้ในฟอนต์เพื่อบอกระบบปฏิบัติการถึงวิธีการแสดงผลลำดับตัวอักษรต่างๆ อย่างถูกต้อง วิธีแก้ปัญหาอย่างง่ายสำหรับการวางเครื่องหมายรวมเสียงหรือเครื่องหมายกำกับเสียง คือ การกำหนดความกว้างของเครื่องหมายเป็นศูนย์ และวางตัวอักขระไว้ทางซ้ายหรือขวาของระยะห่างด้านซ้าย (ขึ้นอยู่กับทิศทางการเขียนที่ต้องการใช้) เครื่องหมายที่จัดการด้วยวิธีนี้จะปรากฏอยู่เหนือตัวอักษรใดๆ ที่อยู่ข้างหน้า แต่จะไม่ปรับตำแหน่งสัมพันธ์กับความกว้างหรือความสูงของตัวอักขระพื้นฐาน ซึ่งอาจดูไม่สวยงามและอาจทับซ้อนกับตัวอักขระบางตัว การเรียงซ้อนอย่างแท้จริงเป็นไปไม่ได้ แต่สามารถประมาณได้ในบางกรณี (ตัวอย่างเช่น สระรวมเสียงและเครื่องหมายวรรณยุกต์ของภาษาไทยสามารถกำหนดความสูงที่แตกต่างกันได้ตั้งแต่เริ่มต้น) โดยทั่วไป วิธีนี้จะมีประสิทธิภาพเฉพาะในฟอนต์แบบโมโนสเปซ แต่สามารถใช้เป็นวิธีการแสดงผลสำรองเมื่อวิธีการที่ซับซ้อนกว่าล้มเหลว

ชุดย่อยของ Unicode หลายชุดได้รับการกำหนดมาตรฐาน: Microsoft Windows ตั้งแต่Windows NT 4.0รองรับWGL-4ที่มีอักขระ 657 ตัว ซึ่งถือว่ารองรับภาษาในยุโรปร่วมสมัยทั้งหมดที่ใช้อักษรละติน กรีก หรือซีริลลิก ชุดย่อยมาตรฐานอื่นๆ ของ Unicode ได้แก่ Multilingual European Subsets: ^{[ 71 ]} MES-1 (เฉพาะอักษรละติน; 335 อักขระ), MES-2 (ละติน กรีก และซีริลลิก; 1062 อักขระ) ^{[ 72 ]}และ MES-3A & MES-3B (ชุดย่อยขนาดใหญ่สองชุด ไม่แสดงไว้ที่นี่) MES-2 ประกอบด้วยอักขระทุกตัวใน MES-1 และ WGL-4

มาตรฐานDIN 91379 ^{[ 73 ]}กำหนดชุดย่อยของตัวอักษร Unicode อักขระพิเศษ และลำดับของตัวอักษรและเครื่องหมายกำกับเสียง เพื่อให้สามารถแสดงชื่อได้อย่างถูกต้องและเพื่อลดความซับซ้อนในการแลกเปลี่ยนข้อมูลในยุโรป มาตรฐานนี้รองรับภาษาทางการทั้งหมดของประเทศในสหภาพยุโรป รวมถึงภาษาเยอรมันซึ่งเป็นภาษาของชนกลุ่มน้อย และภาษาทางการของไอซ์แลนด์ ลิกเตนสไตน์ นอร์เวย์ และสวิตเซอร์แลนด์ เพื่อให้สามารถแปลงชื่อในระบบการเขียนอื่นๆ เป็นอักษรละตินตามมาตรฐาน ISO ที่เกี่ยวข้อง จึงมีการจัดเตรียมชุดตัวอักษรพื้นฐานและเครื่องหมายกำกับเสียงที่จำเป็นทั้งหมดไว้

ซอฟต์แวร์แสดงผลที่ไม่สามารถประมวลผลอักขระ Unicode ได้อย่างเหมาะสม มักจะแสดงผลเป็นสี่เหลี่ยมเปิด หรือเป็นU+FFFDเพื่อระบุตำแหน่งของอักขระที่ไม่รู้จัก ระบบบางระบบได้พยายามให้ข้อมูลเพิ่มเติมเกี่ยวกับอักขระดังกล่าวฟอนต์ Last Resort ของ Apple จะแสดงสัญลักษณ์ทดแทนที่ระบุช่วง Unicode ของอักขระ และฟอนต์ Unicode fallbackของSIL Internationalจะแสดงกล่องที่แสดงค่าเลขฐานสิบหกของอักขระนั้น

มีการกำหนดกลไกหลายอย่างสำหรับการจัดเก็บชุดรหัสอักขระเป็นชุดไบต์

Unicode กำหนดวิธีการแมปสองวิธี ได้แก่ การเข้ารหัส Unicode Transformation Format (UTF) และ การเข้ารหัส Universal Coded Character Set (UCS) การเข้ารหัสจะแมป (อาจเป็นส่วนย่อยของ) ช่วงของจุดรหัส Unicode ไปยังลำดับของค่าในช่วงขนาดคงที่บางช่วง ซึ่งเรียกว่าหน่วยรหัสการเข้ารหัส UTF ทั้งหมดจะแมปจุดรหัสไปยังลำดับไบต์ที่ไม่ซ้ำกัน^{[ 74 ]}ตัวเลขในชื่อของการเข้ารหัสระบุจำนวนบิตต่อหน่วยรหัส (สำหรับการเข้ารหัส UTF) หรือจำนวนไบต์ต่อหน่วยรหัส (สำหรับการเข้ารหัส UCS และUTF-1 ) UTF-8 และ UTF-16 เป็นการเข้ารหัสที่ใช้กันทั่วไปมากที่สุดUCS-2เป็นส่วนย่อยที่ล้าสมัยของ UTF-16; UCS-4 และ UTF-32 มีฟังก์ชันการทำงานที่เทียบเท่ากัน

การเข้ารหัส UTF ได้แก่:

• UTF-8ซึ่งใช้หน่วย 8 บิตหนึ่งถึงสี่หน่วยต่อจุดรหัส^{[หมายเหตุ 3 ]}และมีความเข้ากันได้สูงสุดกับASCII
• UTF-16ใช้หน่วย 16 บิตหนึ่งหน่วยต่อจุดรหัสต่ำกว่าU+010000และใช้ หน่วย 16 บิตสองหน่วย คู่หนึ่งต่อจุดรหัสในช่วงU+010000ถึงU+10FFFF
• UTF-32ซึ่งใช้หน่วย 32 บิตหนึ่งหน่วยต่อหนึ่งจุดรหัส
• UTF-EBCDICซึ่งไม่ได้ระบุไว้ในมาตรฐาน Unicodeนั้น ใช้หน่วย 8 บิตจำนวน 1 ถึง 5 หน่วยต่อจุดรหัส โดยมีจุดประสงค์เพื่อเพิ่มความเข้ากันได้กับEBCDIC ให้มากที่สุด

UTF-8 ใช้หน่วย 8 บิต ( ไบต์ ) หนึ่งถึงสี่หน่วยต่อจุดรหัส และเนื่องจากมีขนาดกะทัดรัดสำหรับอักษรละตินและเข้ากันได้กับ ASCII จึงเป็นมาตรฐานการเข้ารหัสที่ใช้กันอย่างแพร่หลายสำหรับการแลกเปลี่ยนข้อความ Unicode FreeBSD และ ระบบปฏิบัติการ Linux รุ่นล่าสุดส่วนใหญ่ใช้ UTF-8 เป็นตัวแทนโดยตรงของการเข้ารหัสแบบเดิมในการจัดการข้อความทั่วไป

การเข้ารหัส UCS-2 และ UTF-16 กำหนดเครื่องหมายลำดับไบต์ (BOM) ของยูนิโค้ดสำหรับใช้ที่จุดเริ่มต้นของไฟล์ข้อความ ซึ่งอาจใช้สำหรับการตรวจจับลำดับไบต์ (หรือ การตรวจ จับลำดับไบต์แบบ endianness ) BOM ที่เข้ารหัสเป็นU+FEFF ZERO WIDTH NO-BREAK SPACEมีคุณสมบัติที่สำคัญคือความไม่กำกวมในการจัดลำดับไบต์ใหม่ โดยไม่คำนึงถึงการเข้ารหัสยูนิโค้ดที่ใช้U+FFFE (ผลลัพธ์ของการสลับไบต์U+FEFF ) ไม่เท่ากับอักขระที่ถูกต้อง และU+FEFFในตำแหน่งอื่นที่ไม่ใช่จุดเริ่มต้นของข้อความจะสื่อถึงช่องว่างที่ไม่เว้นวรรคที่มีความกว้างเป็นศูนย์

อักขระเดียวกันที่แปลงเป็น UTF-8 จะกลายเป็นลำดับไบต์EF BB BFมาตรฐานUnicodeอนุญาตให้ BOM "ทำหน้าที่เป็นลายเซ็นสำหรับข้อความที่เข้ารหัส UTF-8 โดยที่ชุดอักขระไม่ได้ทำเครื่องหมายไว้" ^{[ 75 ]}นักพัฒนาซอฟต์แวร์บางรายได้นำไปใช้กับการเข้ารหัสอื่นๆ รวมถึง UTF-8 เพื่อพยายามแยกแยะ UTF-8 ออกจากหน้าโค้ด 8 บิตในพื้นที่ อย่างไรก็ตามRFC 3629ซึ่งเป็นมาตรฐาน UTF-8 แนะนำให้ห้ามใช้เครื่องหมายลำดับไบต์ในโปรโตคอลที่ใช้ UTF-8 แต่ได้กล่าวถึงกรณีที่อาจไม่สามารถทำได้ นอกจากนี้ ข้อจำกัดมากมายเกี่ยวกับรูปแบบที่เป็นไปได้ใน UTF-8 (ตัวอย่างเช่น จะไม่มีไบต์เดี่ยวๆ ที่มีบิตสูงตั้งค่าไว้) หมายความว่าควรจะสามารถแยกแยะ UTF-8 ออกจากการเข้ารหัสอักขระอื่นๆ ได้โดยไม่ต้องอาศัย BOM  

ใน UTF-32 และ UCS-4 หน่วยรหัส 32 บิต หนึ่ง หน่วยทำหน้าที่แทนจุดรหัสของอักขระใดๆ ได้โดยตรง (แม้ว่าลำดับไบต์ซึ่งแตกต่างกันไปในแต่ละแพลตฟอร์มจะส่งผลต่อวิธีการแสดงผลของหน่วยรหัสเป็นลำดับไบต์ก็ตาม) ในการเข้ารหัสอื่นๆ จุดรหัสแต่ละจุดอาจถูกแทนด้วยจำนวนหน่วยรหัสที่แตกต่างกัน UTF-32 ถูกใช้กันอย่างแพร่หลายในการแทนข้อความภายในโปรแกรม (ตรงข้ามกับข้อความที่จัดเก็บหรือส่งผ่าน) เนื่องจากระบบปฏิบัติการ Unix ทุกระบบที่ใช้ คอมไพเลอร์ GCCในการสร้างซอฟต์แวร์จะใช้ UTF-32 เป็นมาตรฐานการเข้ารหัส " อักขระกว้าง " เวอร์ชันล่าสุดของ ภาษาโปรแกรม Python (เริ่มตั้งแต่เวอร์ชัน 2.2) ยังสามารถกำหนดค่าให้ใช้ UTF-32 เป็นการแทนสตริง Unicode ได้อย่างมีประสิทธิภาพ ซึ่งเป็นการเผยแพร่การเข้ารหัสดังกล่าวในซอฟต์แวร์ ระดับสูง

Punycodeเป็นรูปแบบการเข้ารหัสอีกรูปแบบหนึ่ง ซึ่งช่วยให้สามารถเข้ารหัสสตริง Unicode ลงในชุดอักขระที่จำกัดซึ่งรองรับโดยระบบชื่อโดเมน (DNS) ที่ใช้ASCIIการเข้ารหัสนี้ถูกใช้เป็นส่วนหนึ่งของIDNAซึ่งเป็นระบบที่ช่วยให้สามารถใช้ชื่อโดเมนแบบสากล (Internationalized Domain Names)ในทุกสคริปต์ที่รองรับโดย Unicode ข้อเสนอในอดีตและปัจจุบันถือเป็นอดีตไปแล้ว ได้แก่UTF-5และUTF- 6

GB18030เป็นรูปแบบการเข้ารหัสอีกรูปแบบหนึ่งของยูนิโค้ด จากสำนักมาตรฐานแห่งประเทศจีนเป็นชุดอักขระ อย่างเป็นทางการ ของสาธารณรัฐประชาชนจีน (PRC) BOCU-1และSCSUเป็นรูปแบบการบีบอัดข้อมูลของยูนิโค้ด เอกสารRFC ในวันเอพริลฟูลส์ปี 2005 ได้กำหนดการเข้ารหัส UTF ล้อเลียนสองแบบ คือUTF-9และUTF- 18

เว็บไซต์ Wikibooks มีหนังสือเกี่ยวกับหัวข้อ: Unicode/เวอร์ชัน

Unicode ในรูปแบบUTF-8เป็นการเข้ารหัสที่ใช้กันมากที่สุดสำหรับเวิลด์ไวด์เว็บตั้งแต่ปี 2008 ^{[ 76 ]}มีการใช้งานอย่างแพร่หลาย และเนื้อหาที่ไม่ใช่ UTF-8 ส่วนใหญ่จะพบในรูปแบบการเข้ารหัส Unicode อื่นๆ เช่นUTF-16ณ ปี 2024 UTF-8 คิดเป็นสัดส่วนเฉลี่ย 98.3% ของหน้าเว็บทั้งหมด (และ 983 จาก 1,000 หน้าเว็บที่มีอันดับสูงสุด) ^{[ 77 ]}แม้ว่าหลายหน้าเว็บจะใช้เพียง อักขระ ASCIIในการแสดงเนื้อหา แต่ UTF-8 ได้รับการออกแบบโดยใช้ ASCII 8 บิตเป็นส่วนย่อย และแทบไม่มีเว็บไซต์ใดประกาศการเข้ารหัสของตนเป็น ASCII แทนที่จะเป็น UTF-8 อีกต่อไป^{[ 78 ]}มากกว่าหนึ่งในสามของภาษาที่ติดตามมีการใช้ UTF-8 100%

โปรโตคอลอินเทอร์เน็ตทั้งหมดที่ดูแลโดยInternet Engineering Task Forceเช่นFile Transfer Protocol (FTP) ^[ 79 ^{] จำเป็น}ต้องรองรับ UTF-8 นับตั้งแต่มีการเผยแพร่RFC 2277ในปี 1998 ซึ่งระบุว่าโปรโตคอล IETF ทั้งหมด "ต้องสามารถใช้ชุดอักขระ UTF-8 ได้" ^{[ 80 ]} 

Unicode ได้กลายเป็นรูปแบบการเข้ารหัสหลักสำหรับการประมวลผลและการจัดเก็บข้อความภายใน แม้ว่าข้อความจำนวนมากยังคงถูกจัดเก็บในรูปแบบการเข้ารหัสแบบเก่า แต่ Unicode ถูกนำมาใช้เกือบทั้งหมดในการสร้างระบบประมวลผลข้อมูลใหม่ ผู้ใช้งานกลุ่มแรกมักใช้UCS-2 (รูปแบบการเข้ารหัสแบบสองไบต์คงที่ซึ่งเป็นรุ่นก่อนหน้าของ UTF-16) และต่อมาได้เปลี่ยนมาใช้UTF-16 (มาตรฐานปัจจุบันที่มีความยาวแปรผัน) เนื่องจากเป็นวิธีที่ก่อให้เกิดผลกระทบน้อยที่สุดในการเพิ่มการรองรับอักขระที่ไม่ใช่ BMP ระบบที่เป็นที่รู้จักดีที่สุดคือWindows NT (และรุ่นต่อๆ มา เช่น 2000 , XP , Vista , 7 , 8 , 10และ11 ) ซึ่งใช้ UTF-16 เป็นการเข้ารหัสอักขระภายในเพียงอย่างเดียว สภาพแวดล้อมไบต์โค้ดของ Javaและ . NET , macOSและKDEก็ใช้ UTF-16 สำหรับการแสดงผลภายในเช่นกัน การสนับสนุน Unicode บางส่วนสามารถติดตั้งได้บนWindows 9xผ่านทาง Microsoft Layer for Unicode

UTF-8 (เดิมพัฒนาขึ้นสำหรับPlan 9 ) ^{[ 81 ]}ได้กลายเป็นการเข้ารหัสการจัดเก็บข้อมูลหลักบน ระบบปฏิบัติการ ที่คล้าย Unix ส่วนใหญ่ (แม้ว่าจะมีการใช้การเข้ารหัสอื่น ๆ โดยไลบรารีบางแห่ง) เนื่องจากเป็นการทดแทนชุดอักขระ ASCII แบบขยายแบบดั้งเดิมได้ค่อนข้างง่ายUTF-8 ยังเป็นการเข้ารหัส Unicode ที่ใช้กันมากที่สุดในเอกสารHTML บน World Wide Webอีก ด้วย

โปรแกรมแสดงผลข้อความหลายภาษาที่ใช้ Unicode ได้แก่UniscribeและDirectWriteสำหรับ Microsoft Windows, ATSUIและCore Textสำหรับ macOS และPangoสำหรับGTK+และเดสก์ท็อป GNOME

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

ISO/IEC 14755 [ ^{82 ] ซึ่ง}กำหนดมาตรฐานวิธีการป้อนอักขระ Unicode จากจุดรหัส ได้ระบุวิธีการหลายวิธี มีวิธีพื้นฐานโดยลำดับเริ่มต้นจะตามด้วยการแสดงเลขฐานสิบหกของจุดรหัสและลำดับสิ้นสุดนอกจากนี้ยังมีวิธีการป้อนแบบเลือกหน้าจอที่ระบุไว้ โดยอักขระจะแสดงอยู่ในตารางบนหน้าจอ เช่นเดียวกับโปรแกรมแผนที่อักขระ

เครื่องมือออนไลน์สำหรับค้นหาจุดรหัสของอักขระที่รู้จัก ได้แก่ Unicode Lookup ^{[ 83 ]}โดย Jonathan Hedley และ Shapecatcher ^{[ 84 ]}โดย Benjamin Milde ใน Unicode Lookup ผู้ใช้ป้อนคีย์การค้นหา (เช่น "เศษส่วน") และรายการอักขระที่ตรงกันพร้อมจุดรหัสจะถูกส่งกลับ ใน Shapecatcher โดยอิงตามบริบทของรูปร่างผู้ใช้วาดอักขระในกล่อง และรายการอักขระที่ใกล้เคียงกับภาพวาดพร้อมจุดรหัสจะถูกส่งกลับ

MIMEกำหนดกลไกสองแบบที่แตกต่างกันสำหรับการเข้ารหัสอักขระที่ไม่ใช่ ASCII ในอีเมล ขึ้นอยู่กับว่าอักขระเหล่านั้นอยู่ในส่วนหัวของอีเมล (เช่น "หัวเรื่อง:") หรือในเนื้อหาข้อความ ในทั้งสองกรณี จะมีการระบุชุดอักขระดั้งเดิมรวมถึงการเข้ารหัสการถ่ายโอน สำหรับการส่งอีเมลแบบ Unicode แนะนำให้ใช้ ชุดอักขระUTF-8 และการเข้ารหัสการถ่ายโอน Base64หรือQuoted-printableขึ้นอยู่กับว่าข้อความส่วนใหญ่ประกอบด้วย อักขระ ASCIIหรือไม่ รายละเอียดของกลไกทั้งสองแบบนั้นระบุไว้ในมาตรฐาน MIME และโดยทั่วไปแล้วจะถูกซ่อนไว้จากผู้ใช้ซอฟต์แวร์อีเมล

IETF ได้กำหนด^{[ 85 ] [ 86 ]}กรอบงานสำหรับอีเมลสากลโดยใช้ UTF-8 และได้อัปเดต^{[ 87 ] [ 88 ] [ 89 ] [ 90 ]}โปรโตคอลหลายรายการตามกรอบงานนั้น

การนำ Unicode มาใช้ในอีเมลนั้นค่อนข้างช้า ข้อความภาษาเอเชียตะวันออกบางส่วนยังคงเข้ารหัสด้วยระบบเข้ารหัสเช่นISO-2022และอุปกรณ์บางอย่าง เช่น โทรศัพท์มือถือ ยังไม่สามารถจัดการข้อมูล Unicode ได้อย่างถูกต้อง อย่างไรก็ตาม การสนับสนุนกำลังดีขึ้นเรื่อยๆ ผู้ให้บริการอีเมลฟรีรายใหญ่หลายราย เช่นYahoo! Mail , GmailและOutlook.com ต่าง ก็รองรับ Unicode แล้ว

คำแนะนำ ทั้งหมดของ W3Cใช้ Unicode เป็นชุดอักขระเอกสารตั้งแต่ HTML 4.0 เป็นต้นมาเว็บเบราว์เซอร์รองรับ Unicode โดยเฉพาะ UTF-8 มานานหลายปีแล้ว ก่อนหน้านี้เคยมีปัญหาในการแสดงผลซึ่งส่วนใหญ่เกิดจาก ปัญหาที่เกี่ยวข้องกับ ฟอนต์เช่น Microsoft Internet Explorer เวอร์ชัน 6 และเก่ากว่านั้น จะไม่แสดงโค้ดพอยต์จำนวนมากเว้นแต่จะระบุอย่างชัดเจนให้ใช้ฟอนต์ที่มีโค้ดพอยต์เหล่านั้น^{[ 91 ]}

แม้ว่ากฎไวยากรณ์อาจส่งผลต่อลำดับที่อนุญาตให้ตัวอักษรปรากฏ แต่ เอกสาร XML (รวมถึงXHTML ) ตามคำจำกัดความ^{[ 92 ]}ประกอบด้วยตัวอักษรจากจุดรหัส Unicode ส่วนใหญ่ ยกเว้น:

• FFFE หรือ FFFF
• รหัสควบคุม C0ส่วนใหญ่
• รหัสจุด D800–DFFF ที่ไม่ได้กำหนดไว้อย่างถาวร

อักขระ HTML จะแสดงผลโดยตรงเป็นไบต์ตามการเข้ารหัสของเอกสาร หากการเข้ารหัสรองรับ หรือผู้ใช้สามารถเขียนเป็นตัวเลขอ้างอิงอักขระโดยอิงจากรหัส Unicode ของอักขระนั้น ตัวอย่างเช่น การอ้างอิงΔ, Й, ק, م, ๗, あ, , 叶, 葉และ말(หรือค่าตัวเลขเดียวกันที่แสดงในรูปแบบเลขฐานสิบหก โดยมี&#xเป็นคำนำหน้า) ควรแสดงผลบนเบราว์เซอร์ทั้งหมดเป็น Δ, Й, ק ,م, , , あ, 叶, 葉 และ 말

เมื่อระบุURIเช่นURLใน คำขอ HTTPอักขระที่ไม่ใช่ ASCII จะต้องถูก เข้ารหัส ด้วย เปอร์เซ็นต์

โดยหลักการแล้ว Unicode ไม่ได้สนใจฟอนต์โดยตรงแต่ถือว่าฟอนต์เป็นเพียงทางเลือกในการใช้งาน^{[ 93 ]}อักขระใดๆ ก็ตามอาจมีรูปแบบการเขียนได้ หลายแบบ ตั้งแต่ตัวหนา ตัวเอียง และตัวอักษรพื้นฐานที่พบได้ทั่วไป ไปจนถึงรูปแบบการตกแต่งที่ซับซ้อน ฟอนต์จะ "เป็นไปตามมาตรฐาน Unicode" หากสามารถเข้าถึงสัญลักษณ์ในฟอนต์ได้โดยใช้จุดรหัสที่กำหนดไว้ในมาตรฐาน Unicode [ ^{94 ] มาตรฐาน}ไม่ได้ระบุจำนวนอักขระขั้นต่ำที่ต้องรวมอยู่ในฟอนต์ ฟอนต์บางแบบจึงมีอักขระให้เลือกใช้น้อยมาก

ฟอนต์ฟรีและฟอนต์ขายปลีกที่ใช้ Unicode มีให้เลือกใช้อย่างแพร่หลาย เนื่องจากTrueTypeและOpenTypeรองรับ Unicode (และWeb Open Font Format (WOFF และWOFF2 ) ก็ใช้พื้นฐานจากฟอนต์เหล่านี้) รูปแบบฟอนต์เหล่านี้จะแมปจุดรหัส Unicode กับสัญลักษณ์ แต่ไฟล์ฟอนต์ OpenType และ TrueType มีข้อจำกัดอยู่ที่ 65,535 สัญลักษณ์ ไฟล์คอลเลกชันมีกลไก "โหมดช่องว่าง" เพื่อเอาชนะข้อจำกัดนี้ในไฟล์ฟอนต์เดียว (อย่างไรก็ตาม ฟอนต์แต่ละตัวในคอลเลกชันยังคงมีข้อจำกัด 65,535 สัญลักษณ์อยู่) ไฟล์คอลเลกชัน TrueType โดยทั่วไปจะมีนามสกุลไฟล์เป็น ".ttc"

มี ฟอนต์หลายพันแบบในท้องตลาด แต่มีฟอนต์น้อยกว่าสิบแบบเท่านั้น—บางครั้งเรียกว่าฟอนต์ "แพน-ยูนิโค้ด"—ที่พยายามรองรับอักขระส่วนใหญ่ของยูนิโค้ด ในทางกลับกันฟอนต์ ที่ใช้ยูนิโค้ด มักจะเน้นการรองรับเฉพาะ ASCII พื้นฐานและสคริปต์หรือชุดอักขระหรือสัญลักษณ์เฉพาะเท่านั้น มีเหตุผลหลายประการที่สนับสนุนแนวทางนี้: แอปพลิเคชันและเอกสารไม่ค่อยจำเป็นต้องแสดงผลอักขระจากระบบการเขียนมากกว่าหนึ่งหรือสองระบบ; ฟอนต์มักต้องการทรัพยากรในสภาพแวดล้อมการประมวลผล; และระบบปฏิบัติการและแอปพลิเคชันแสดงให้เห็นถึงความฉลาดที่เพิ่มขึ้นในการดึงข้อมูลสัญลักษณ์จากไฟล์ฟอนต์แยกต่างหากตามความจำเป็น เช่นการแทนที่ฟอนต์นอกจากนี้ การออกแบบชุดคำสั่งการแสดงผลที่สอดคล้องกันสำหรับสัญลักษณ์หลายหมื่นตัวถือเป็นงานที่ยากลำบากอย่างยิ่ง การลงทุนเช่นนี้จะทำให้ผลตอบแทนลดลงสำหรับแบบอักษรส่วนใหญ่

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

ในส่วนของอักขระขึ้นบรรทัดใหม่ Unicode ได้แนะนำU+2028 LINE SEPARATORและU+2029 PARAGRAPH SEPARATORซึ่งเป็นการพยายามนำเสนอโซลูชันของ Unicode สำหรับการเข้ารหัสย่อหน้าและบรรทัดในเชิงความหมาย โดยอาจเข้ามาแทนที่โซลูชันต่างๆ ของแต่ละแพลตฟอร์ม ในการทำเช่นนั้น Unicode ก็ได้เสนอทางออกสำหรับโซลูชันแบบเดิมที่ขึ้นอยู่กับแพลตฟอร์ม อย่างไรก็ตาม มีโซลูชันของ Unicode เพียงไม่กี่แห่งที่นำอักขระคั่นบรรทัดและย่อหน้าของ Unicode เหล่านี้มาใช้เป็นอักขระจบบรรทัดมาตรฐานเพียงอย่างเดียว แต่แนวทางทั่วไปในการแก้ปัญหานี้คือการทำให้เป็นมาตรฐานของอักขระขึ้นบรรทัดใหม่ ซึ่งทำได้ด้วยระบบข้อความ CocoaในmacOSและข้อแนะนำของ W3C XML และ HTML ในแนวทางนี้ อักขระขึ้นบรรทัดใหม่ที่เป็นไปได้ทั้งหมดจะถูกแปลงภายในให้เป็นอักขระขึ้นบรรทัดใหม่ทั่วไป (ซึ่งไม่สำคัญว่าจะเป็นอักขระใด เนื่องจากเป็นการดำเนินการภายในเพื่อการแสดงผลเท่านั้น) กล่าวอีกนัยหนึ่ง ระบบข้อความสามารถจัดการอักขระนั้นเป็นอักขระขึ้นบรรทัดใหม่ได้อย่างถูกต้อง โดยไม่คำนึงถึงการเข้ารหัสจริงของอินพุต

กลุ่มวิจัยอักษรภาพ (IRG) มีหน้าที่ให้คำแนะนำแก่ Consortium และ ISO เกี่ยวกับการรวมอักษรฮั่น หรือ Unihan โดยเฉพาะอย่างยิ่งการเพิ่มอักษรภาพ CJK ที่รวมเป็นหนึ่งเดียวและเข้ากันได้ลงในชุดอักษรภาพ IRG ประกอบด้วยผู้เชี่ยวชาญจากแต่ละภูมิภาคที่ใช้อักษรจีน มาแต่เดิม อย่างไรก็ตาม แม้จะมีการพิจารณาภายในคณะกรรมการ การรวมอักษรฮั่นก็ยังคงเป็นหนึ่งในประเด็นที่มีการโต้แย้งมากที่สุดของมาตรฐาน Unicodeนับตั้งแต่เริ่มโครงการ^{[ 95 ]}

มาตรฐานชุดอักขระที่มีอยู่ เช่นJIS X 0208 ของญี่ปุ่น (เข้ารหัสโดยShift JIS ) ได้กำหนดเกณฑ์การรวม ซึ่งหมายถึงกฎสำหรับการพิจารณาว่าเมื่อใดที่อักขระภาษาจีนแบบต่างๆจะถือว่าเป็นความแตกต่างของลายมือ/แบบอักษร (และรวมเข้าด้วยกัน) เทียบกับความแตกต่างของการสะกดคำ (ซึ่งจะต้องเข้ารหัสแยกต่างหาก) แบบจำลองอักขระของ Unicode สำหรับอักขระ CJK นั้นอิงตามเกณฑ์การรวมที่ใช้โดย JIS X 0208 เช่นเดียวกับเกณฑ์ที่พัฒนาโดยสมาคมเพื่อรหัสภาษาจีนทั่วไปในประเทศจีน^{[ 96 ]}

เนื่องจากหลักการของมาตรฐานในการเข้ารหัสความหมายแทนที่จะเป็นรูปแบบต่างๆ Unicode จึงได้รับการวิพากษ์วิจารณ์ว่าไม่ได้กำหนดรหัสจุดให้กับ ตัวอักษร คันจิ ที่หายากและโบราณบางตัว ซึ่งอาจทำให้การประมวลผลชื่อภาษาญี่ปุ่นโบราณและไม่ค่อยพบเห็นมีความซับซ้อนมากขึ้น เนื่องจากเน้นย้ำเป็นพิเศษว่าภาษาจีน ญี่ปุ่น และเกาหลีมีตัวอักษรร่วมกันหลายตัว การรวมฮั่นจึงบางครั้งถูกมองว่าเป็นการปฏิบัติต่อทั้งสามภาษาเหมือนเป็นสิ่งเดียวกัน^{[ 97 ]}ความแตกต่างในระดับภูมิภาคของรูปแบบตัวอักษรที่คาดหวัง ในแง่ของแบบแผนการพิมพ์และหลักสูตรการเขียนด้วยลายมือ ไม่ได้อยู่ตามขอบเขตของภาษาเสมอไป แม้ว่าฮ่องกงและไต้หวันจะเขียนภาษาจีนโดยใช้ ตัวอักษร จีนดั้งเดิมแต่รูปแบบตัวอักษรที่นิยมใช้ก็แตกต่างกันระหว่างฮ่องกงและไต้หวันในบางกรณี^{[ 98 ]}

มีการเข้ารหัสทางเลือกอื่นๆ ที่ใช้ไม่บ่อยนัก ซึ่งมักมีมาก่อน Unicode โดยมีรูปแบบตัวอักษรที่แตกต่างจากแบบแผนนี้ โดยมีเป้าหมายเพื่อรักษารูปแบบตัวอักษรที่แตกต่างกันระหว่างรูปแบบตัวอักษรในภูมิภาคและ/หรือรูปแบบตัวอักษรที่ไม่เป็นมาตรฐาน ตัวอย่างหนึ่งคือTRON Codeซึ่งเป็นที่นิยมในหมู่ผู้ใช้บางรายสำหรับการจัดการข้อความภาษาญี่ปุ่นโบราณ แม้ว่าจะไม่ได้รับการยอมรับอย่างกว้างขวางในหมู่ประชาชนชาวญี่ปุ่น อีกตัวอย่างหนึ่งคือ การเข้ารหัส CCCIIซึ่งระบบห้องสมุดในฮ่องกงไต้หวันและสหรัฐอเมริกา ใช้ การ เข้ารหัสเหล่านี้มีข้อเสียในการใช้งานทั่วไป ทำให้ การเข้ารหัส Big5 (เปิดตัวในปี 1984 สี่ปีหลังจาก CCCII) กลายเป็นที่นิยมมากกว่า CCCII นอกระบบห้องสมุด^{[ 99 ]}แม้ว่างานที่Appleซึ่งอิงตาม CJK Thesaurus ของ Research Libraries Groupซึ่งใช้ในการรักษารูปแบบ EACC ของ CCCII จะเป็นหนึ่งในบรรพบุรุษโดยตรงของ ชุด Unihan ของ Unicode แต่ Unicode ก็ได้นำรูปแบบการรวมแบบ JIS มาใช้^{[ 96 ]}

ยูนิโค้ดเวอร์ชันแรกสุดมีอักขระฮั่นน้อยกว่า 21,000 ตัว ส่วนใหญ่จำกัดอยู่เฉพาะอักขระที่ใช้กันทั่วไปในปัจจุบัน แต่ในเวอร์ชัน 17.0 มาตรฐานนี้ได้เข้ารหัสอักขระฮั่นมากกว่า 101,000 ตัวแล้ว และยังคงมีการพัฒนาเพิ่มเติมอีกหลายพันตัว ซึ่งส่วนใหญ่เป็นอักขระทางประวัติศาสตร์และอักขระสำเนียงต่างๆ ที่ใช้กันทั่วโลก ในกลุ่มประเทศที่ใช้ ภาษาจีน

แบบอักษรสมัยใหม่มีวิธีการแก้ไขปัญหาในทางปฏิบัติบางประการในการแสดงอักษรฮั่นที่เป็นเอกภาพด้วยการแสดงภาพกราฟิกตามภูมิภาคต่างๆ ตาราง OpenType 'locl' ช่วยให้ตัวแสดงผลสามารถเลือกสัญลักษณ์ที่แตกต่างกันสำหรับแต่ละจุดรหัสตามภาษาท้องถิ่นของข้อความ^{[ 100 ]}ลำดับการเปลี่ยนแปลงของ Unicodeยังสามารถให้คำอธิบายประกอบในข้อความสำหรับการเลือกสัญลักษณ์ที่ต้องการได้ ซึ่งต้องลงทะเบียนตัวแปรเฉพาะในฐานข้อมูลการเปลี่ยนแปลงอักษรภาพ

หากสัญลักษณ์ที่เหมาะสมสำหรับตัวอักษรในสคริปต์เดียวกันแตกต่างกันเฉพาะตัวเอียง โดยทั่วไปแล้ว Unicode จะรวมสัญลักษณ์เหล่านั้นเข้าด้วยกัน ดังที่เห็นได้จากการเปรียบเทียบสัญลักษณ์ตัวเอียงของตัวอักษรเจ็ดตัวที่มักปรากฏในข้อความภาษารัสเซีย ภาษาบัลแกเรียแบบดั้งเดิม ภาษามาซิโดเนีย และภาษาเซอร์เบียทางด้านขวา ซึ่งหมายความว่าความแตกต่างจะแสดงผ่านเทคโนโลยีฟอนต์อัจฉริยะหรือการเปลี่ยนฟอนต์ด้วยตนเอง เทคนิค OpenType 'locl' เดียวกันนี้ถูกนำมาใช้^{[ 101 ]}

สำหรับการใช้งานในอักษรตุรกีและอักษรอาเซอร์ไบจานยูนิโค้ดได้รวมอักษรIตัวเล็กแบบไม่มีจุด (ı) และ อักษร Iตัวใหญ่แบบมีจุด ( İ ) ไว้แยกต่างหาก อย่างไรก็ตาม จะใช้ตัวอักษร ASCII ทั่วไปสำหรับอักษร i ตัวเล็กแบบมีจุดและอักษรI ตัวใหญ่แบบไม่มีจุด ซึ่งตรงกับวิธีการจัดการในมาตรฐานISO 8859-9 รุ่นก่อนหน้า ดังนั้น การเปรียบเทียบแบบไม่คำนึงถึงตัวพิมพ์ใหญ่-เล็กสำหรับภาษาเหล่านั้นจึงต้องใช้กฎที่แตกต่างจากการเปรียบเทียบแบบไม่คำนึงถึงตัวพิมพ์ใหญ่-เล็กสำหรับภาษาอื่นๆ ที่ใช้อักษรละติน^{[ 102 ] [ 103 ]}ซึ่งอาจมีผลกระทบต่อความปลอดภัยหากตัวอย่างเช่น รหัส การตรวจสอบความปลอดภัยหรือการควบคุมการเข้าถึงอาศัยการเปรียบเทียบแบบไม่คำนึงถึงตัวพิมพ์ใหญ่-เล็ก^{[ 103 ]}

ในทางตรงกันข้ามตัวอักษร eth (ð) ของไอซ์แลนด์ตัวอักษร D ที่มีขีด (đ)และตัวอักษร D ที่มีหาง (ɖ)ซึ่งโดยปกติ^{[หมายเหตุ 4 ]}จะมีลักษณะเหมือนกันในตัวพิมพ์ใหญ่ (Đ) จะได้รับการปฏิบัติในทางตรงกันข้าม และเข้ารหัสแยกกันในทั้งสองรูปแบบตัวพิมพ์ (ตรงกันข้ามกับISO 6937 รุ่นก่อนหน้า ซึ่งรวมรูปแบบตัวพิมพ์ใหญ่เข้าด้วยกัน) แม้ว่าวิธีนี้จะช่วยให้สามารถเปรียบเทียบแบบไม่คำนึงถึงตัวพิมพ์ใหญ่และตัวพิมพ์เล็กโดยไม่จำเป็นต้องรู้ภาษาของข้อความ แต่วิธีนี้ก็มีปัญหาเช่นกัน ซึ่งต้องใช้มาตรการรักษาความปลอดภัยที่เกี่ยวข้องกับการโจมตีด้วยตัวอักษรที่เหมือนกัน^{[ 104 ]}

การที่ตัวอักษรi ตัวเล็ก จะต้องคงรูปเดิมเมื่อมีการใช้เครื่องหมายกำกับเสียงหรือไม่นั้น ขึ้นอยู่กับธรรมเนียมปฏิบัติในท้องถิ่นด้วย

Unicode มี โฮโมกลิฟจำนวนมากซึ่งหลายตัวมีลักษณะคล้ายคลึงหรือเหมือนกับตัวอักษร ASCII การแทนที่ตัวอักษรเหล่านี้อาจทำให้ตัวระบุหรือ URL ดูถูกต้อง แต่กลับนำไปยังตำแหน่งที่แตกต่างจากที่คาดไว้^{[ 105 ]}นอกจากนี้ โฮโมกลิฟยังสามารถใช้ในการจัดการเอาต์พุตของระบบประมวลผลภาษาธรรมชาติ (NLP) ได้อีกด้วย ^{[ 106 ]}การแก้ไขปัญหานี้จำเป็นต้องไม่อนุญาตให้ใช้ตัวอักษรเหล่านี้ แสดงผลแตกต่างกัน หรือกำหนดให้ตัวอักษรเหล่านี้แปลงเป็นตัวระบุเดียวกัน^{[ 107 ]} ซึ่ง ทั้งหมดนี้มีความซับซ้อนเนื่องจากชุดตัวอักษรมีขนาดใหญ่และเปลี่ยนแปลงอยู่ตลอดเวลา^{[ 108 ] [ 109 ]}

นักวิจัยสองคนจาก มหาวิทยาลัยเคมบริดจ์และมหาวิทยาลัยเอดินบะระได้ออกคำแนะนำด้านความปลอดภัยในปี 2021 โดยระบุว่าเครื่องหมาย BiDiสามารถใช้เพื่อทำให้โค้ดส่วนใหญ่ทำงานแตกต่างไปจากที่ปรากฏ ปัญหาดังกล่าวถูกตั้งชื่อว่า " Trojan Source " ^{[ 110 ]}เพื่อเป็นการตอบสนอง โปรแกรมแก้ไขโค้ดจึงเริ่มเน้นเครื่องหมายเพื่อระบุการเปลี่ยนแปลงทิศทางข้อความที่ถูกบังคับ^{[ 111 ]}

การเข้ารหัส UTF -8และUTF-16ไม่ยอมรับลำดับหน่วยรหัสที่เป็นไปได้ทั้งหมด การใช้งานจะแตกต่างกันไปเมื่ออ่านลำดับที่ไม่ถูกต้อง ซึ่งนำไปสู่ช่องโหว่ด้านความปลอดภัย^{[ 112 ] [ 113 ]}

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

ต้องมีการจัดเตรียมการแมป แบบอินเจกทีฟระหว่างอักขระในชุดอักขระดั้งเดิมที่มีอยู่และอักขระในยูนิโค้ด เพื่ออำนวยความสะดวกในการแปลงเป็นยูนิโค้ดและอนุญาตให้ทำงานร่วมกับซอฟต์แวร์ดั้งเดิมได้ การขาดความสอดคล้องกันในการแมปต่างๆ ระหว่างการเข้ารหัสภาษาญี่ปุ่นรุ่นก่อนๆ เช่นShift-JISหรือEUC-JPและยูนิโค้ด ทำให้เกิด ความไม่ตรงกันของ การแปลงรูปแบบไปกลับโดยเฉพาะอย่างยิ่งการแมปอักขระ JIS X 0208 '～' (1-33, ขีดกลาง) ซึ่งใช้กันอย่างแพร่หลายในข้อมูลฐานข้อมูลดั้งเดิม ไปยังU+FF5E～FULLWIDTH TILDE (ในMicrosoft Windows ) หรือU+301C〜WAVE DASH (ผู้จำหน่ายรายอื่น) ^{[ 114 ]}

โปรแกรมเมอร์คอมพิวเตอร์ชาวญี่ปุ่นบางคนคัดค้าน Unicode เนื่องจาก Unicode กำหนดให้พวกเขาต้องแยกการใช้U+005C \ REVERSE SOLIDUS (แบ็กสแลช) และU+00A5 ¥ YEN SIGNซึ่งถูกแมปเป็น 0x5C ใน JIS X 0201 และมีโค้ดเก่าจำนวนมากที่ใช้รูปแบบนี้^{[ 115 ]} (การเข้ารหัสนี้ยังแทนที่เครื่องหมายทิลเด '~' 0x7E ด้วยเครื่องหมายแมครอน '¯' ซึ่งปัจจุบันคือ 0xAF) การแยกอักขระเหล่านี้มีอยู่ในISO 8859-1มานานก่อน Unicode

อักษรอินเดียเช่นทมิฬและเทวนาครีแต่ละอักษรจะได้รับการจัดสรรจุดรหัสเพียง 128 จุด ซึ่งตรงกับ มาตรฐาน ISCIIการแสดงผลข้อความอินเดีย Unicode อย่างถูกต้องนั้นจำเป็นต้องแปลงลำดับตรรกะของอักขระที่จัดเก็บไว้ให้เป็นลำดับภาพ และสร้างตัวเชื่อม (หรือที่เรียกว่าตัวเชื่อม) จากส่วนประกอบต่างๆ นักวิชาการท้องถิ่นบางคนโต้แย้งสนับสนุนการกำหนดจุดรหัส Unicode ให้กับตัวเชื่อมเหล่านี้ ซึ่งขัดกับแนวปฏิบัติสำหรับระบบการเขียนอื่นๆ แม้ว่า Unicode จะมีตัวเชื่อมภาษาอาหรับและตัวเชื่อมอื่นๆ บางส่วนเพื่อวัตถุประสงค์ในการเข้ากันได้กับเวอร์ชันก่อนหน้าเท่านั้น^{[ 116 ] [ 117 ] [ 118 ]}การเข้ารหัสตัวเชื่อมใหม่ใดๆ ใน Unicode จะไม่เกิดขึ้น ส่วนหนึ่งเป็นเพราะชุดของตัวเชื่อมนั้นขึ้นอยู่กับแบบอักษร และ Unicode เป็นการเข้ารหัสที่ไม่ขึ้นอยู่กับการเปลี่ยนแปลงของแบบอักษร ปัญหาประเภทเดียวกันนี้เกิดขึ้นกับอักษรทิเบตในปี พ.ศ. 2546 เมื่อสำนักงานมาตรฐานแห่งประเทศจีนเสนอให้เข้ารหัสพยางค์ทิเบตที่ประกอบขึ้นล่วงหน้า 956 พยางค์^{[ 119 ]}แต่พยางค์เหล่านี้ถูกปฏิเสธการเข้ารหัสโดยคณะกรรมการ ISO ที่เกี่ยวข้อง ( ISO/IEC JTC 1/SC 2 ) ^{[ 120 ]}

การสนับสนุน อักษรไทยได้รับการวิพากษ์วิจารณ์เกี่ยวกับการเรียงลำดับตัวอักษรไทย สระ เ, แ, โ, อุ, ไ ที่เขียนไว้ทางซ้ายของพยัญชนะที่อยู่ข้างหน้าจะเรียงตามลำดับภาพแทนที่จะเป็นลำดับเสียง ซึ่งแตกต่างจากการแสดงอักษรอินเดียอื่นๆ ใน Unicode ความซับซ้อนนี้เกิดจากการที่ Unicode สืบทอดมาตรฐานอุตสาหกรรมไทย 620ซึ่งทำงานในลักษณะเดียวกัน และเป็นวิธีที่ภาษาไทยถูกเขียนบนแป้นพิมพ์มาโดยตลอด ปัญหาการเรียงลำดับนี้ทำให้กระบวนการเรียงลำดับของ Unicode ซับซ้อนขึ้นเล็กน้อย ต้องใช้การค้นหาในตารางเพื่อเรียงลำดับตัวอักษรไทยใหม่สำหรับการเรียงลำดับ^{[ 97 ]}แม้ว่า Unicode จะนำการเข้ารหัสตามลำดับการพูดมาใช้ ก็ยังคงมีปัญหาในการเรียงลำดับคำตามลำดับพจนานุกรม เช่น คำว่าแสดง[sa dɛːŋ] "perform" ขึ้นต้นด้วยกลุ่มพยัญชนะ "live" (โดยมีสระในตัวสำหรับพยัญชนะ "ส") สระ แ- ในการออกเสียงจะอยู่หลัง ด แต่ในพจนานุกรม คำนี้จะถูกเรียงตามที่เขียน โดยสระจะอยู่หลัง ส

โดยทั่วไปแล้ว อักษรที่มีเครื่องหมายกำกับเสียงสามารถแสดงได้ทั้งในรูปแบบอักษรประกอบเดี่ยว หรือในรูปแบบลำดับของอักษรพื้นฐานบวกกับเครื่องหมายที่ไม่เว้นวรรคอย่างน้อยหนึ่งตัว ตัวอย่างเช่น ḗ (อักษร e ประกอบเดี่ยวที่มีขีดบนและเครื่องหมายเน้นเสียงด้านบน) และ ḗ (อักษร e ตามด้วยขีดบนและเครื่องหมายเน้นเสียงด้านบน) ควรแสดงผลเหมือนกัน โดยปรากฏเป็นอักษรeที่มีขีดบน (◌̄) และเครื่องหมายเน้นเสียง (◌́) แต่ในทางปฏิบัติ ลักษณะที่ปรากฏอาจแตกต่างกันไปขึ้นอยู่กับโปรแกรมแสดงผลและแบบอักษรที่ใช้ในการแสดงอักษรเหล่านั้น ในทำนองเดียวกันจุดใต้ตัวอักษรซึ่งจำเป็นในการถอดเสียงภาษาอินเดียเป็น อักษร โรมัน มักจะวางผิดตำแหน่ง อักขระ Unicode ที่แมปกับ glyph ที่ประกอบขึ้นล่วงหน้าสามารถนำมาใช้ได้ในหลายกรณี จึงช่วยหลีกเลี่ยงปัญหาดังกล่าว แต่ในกรณีที่ไม่มีการเข้ารหัสอักขระที่ประกอบขึ้นล่วงหน้า ปัญหามักจะแก้ไขได้โดยการใช้ฟอนต์ Unicode เฉพาะทาง เช่นCharis SILซึ่งใช้ เทคโนโลยี Graphite , OpenType ('gsub') หรือAATสำหรับคุณสมบัติการแสดงผลขั้นสูง

มาตรฐาน Unicodeได้กำหนดกฎเกณฑ์ที่มุ่งรับประกันความเสถียร^{[ 121 ]}ขึ้นอยู่กับความเข้มงวดของกฎเกณฑ์ การเปลี่ยนแปลงอาจถูกห้ามหรืออนุญาต ตัวอย่างเช่น "ชื่อ" ที่กำหนดให้กับจุดรหัสไม่สามารถและจะไม่เปลี่ยนแปลง แต่คุณสมบัติ "สคริปต์" มีความยืดหยุ่นมากกว่าตามกฎของ Unicode เอง ในเวอร์ชัน 2.0 Unicode ได้เปลี่ยน "ชื่อ" จุดรหัสหลายจุดจากเวอร์ชัน 1 ในขณะเดียวกัน Unicode ระบุว่านับจากนี้เป็นต้นไป ชื่อที่กำหนดให้กับจุดรหัสจะไม่เปลี่ยนแปลงอีกต่อไป ซึ่งหมายความว่าเมื่อมีการเผยแพร่ข้อผิดพลาด ข้อผิดพลาดเหล่านี้จะไม่สามารถแก้ไขได้ แม้ว่าจะเป็นเรื่องเล็กน้อย (ดังเช่นที่เกิดขึ้นในกรณีหนึ่งกับการสะกดBRAKCETแทนBRACKETในชื่ออักขระ) ในปี 2006 มีการเผยแพร่รายการความผิดปกติในชื่ออักขระเป็นครั้งแรก และ ณ เดือนมิถุนายน 2021 มีอักขระ 104 ตัวที่มีปัญหาที่ระบุไว้^{[ 122 ]}ตัวอย่างเช่น:

• U+034F ͏ ตัวเชื่อมกราฟีมรวม : ไม่เชื่อมกราฟีม ^{[ 122 ]}
• U+2118 ℘ SCRIPT CAPITAL P : นี่คือตัวอักษรเล็ก ตัวอักษรใหญ่คือ U+1D4AB 𝒫 MATHEMATICAL SCRIPT CAPITAL P . ^{[ 123 ]}
• U+A015 ꀕ YI SYLLABLE WU : นี่ไม่ใช่พยางค์อี๋ แต่เป็นเครื่องหมายการทำซ้ำของอี๋
• U+FE18 ︘ รูปแบบการนำเสนอสำหรับวงเล็บเลนติคูลาร์สีขาวแนวตั้งด้านขวา :วงเล็บสะกดผิด ^{[ 124 ]} (แก้ไขข้อผิดพลาดในการสะกดโดยใช้ชื่อนามแฝง Unicode )

ในขณะที่ Unicode กำหนดตัวระบุสคริปต์ (ชื่อ) เป็น " Phags_Pa " ในชื่อตัวอักษรของสคริปต์นั้น จะมีการเพิ่มเครื่องหมายยัติภังค์: U+A840 ꡀ PHAGS-PA LETTER KA [ ^{125 ] [ 126 ] อย่างไรก็ตาม}นี่ไม่ใช่ความผิดปกติ แต่เป็นกฎ: เครื่องหมายยัติภังค์จะถูกแทนที่ด้วยเครื่องหมายขีดล่างในตัวระบุสคริปต์^{[ 125 ]}

• การเปรียบเทียบการเข้ารหัส Unicode
• ส่วนประกอบสากลสำหรับยูนิโค้ด (ICU) ซึ่งปัจจุบันคือ ICU- TCเป็นส่วนหนึ่งของยูนิโค้ด
• รายการรหัสไบนารี
• รายการอักขระยูนิโค้ด
• รายการอ้างอิงเอนทิตีอักขระ XML และ HTML
• ชุดอักขระมัลติไบต์ของโลตัส (LMBCS) เป็นการพัฒนาคู่ขนานที่มีจุดประสงค์คล้ายคลึงกัน
• แบบอักษร Unicode แบบโอเพนซอร์ส
• สัญลักษณ์ทางศาสนาและทางการเมืองในยูนิโค้ด
• มาตรฐานที่เกี่ยวข้องกับยูนิโค้ด
• สัญลักษณ์ยูนิโค้ด
• ชุดอักขระเข้ารหัสสากล

• Haralambous, Yannis; Martin Dürst (2019). "Unicode จากมุมมองทางภาษาศาสตร์". ใน Haralambous, Yannis (บรรณาธิการ). รายงานการประชุม Graphemics in the 21st Century, Brest 2018. Brest: Fluxus Editions. หน้า  167–183 . doi : 10.36824/2018-graf-hara1 . ISBN 978-2-9570549-1-6.

• บริษัท ยูนิโคด จำกัด
  • เว็บไซต์ทางเทคนิคของ Unicode
    • มาตรฐานยูนิโค้ด
      • ตารางรหัสอักขระยูนิโค้ด
      • ดัชนีชื่ออักขระยูนิโค้ด
• แหล่งข้อมูล Unicode ของ Alan Wood  – ประกอบด้วยรายชื่อโปรแกรมประมวลผลคำที่รองรับ Unicode; แบบอักษรและตัวอักษรถูกจัดกลุ่มตามประเภท; ตัวอักษรแสดงในรูปแบบรายการ ไม่ใช่ตาราง
• ฟอนต์สำรอง Unicode BMP – แสดงค่า Unicode 6.1 ของอักขระใดๆ ในเอกสาร รวมถึงในพื้นที่ใช้งานส่วนตัว แทนที่จะแสดงค่า glyph จริงๆ
• ระบบการเขียนของโลกระบบการเขียนที่รู้จักทั้งหมด 293 ระบบ พร้อมสถานะ Unicode (128 ระบบยังไม่ได้รับการเข้ารหัส ณ เดือนมิถุนายน 2024)