จุดเริ่มต้นของ 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) นั้นประสบกับความยากลำบากอันเนื่องมาจากความเป็นจริงที่ว่า อักษรจีนไม่ได้แยกส่วนได้ง่ายหรือสม่ำเสมอเหมือนกับอักษรฮันกึล

The CJK Radicals Supplement block is assigned to the range U+2E80–U+2EFF, and the Kangxi radicals are assigned to U+2F00–U+2FDF. The Ideographic Description Sequences block covers the range U+2FF0–U+2FFB, but The Unicode Standard warns against using its characters as an alternate representation for characters encoded elsewhere:

This process is different from a formal encoding of an ideograph. There is no canonical description of unencoded ideographs; there is no semantic assigned to described ideographs; there is no equivalence defined for described ideographs. Conceptually, ideographic descriptions are more akin to the English phrase "an 'e' with an acute accent on it" than to the character sequence <U+0065, U+0301>.

The Devanāgarīddhrya-ligature (द् + ध् + र् + य = द्ध्र्य) of JanaSanskritSans^[70]

The Arabiclām-alif ligature (ل‎+‎ا‎=‎لا)

Many scripts, including Arabic and Devanāgarī, have special orthographic rules that require certain combinations of letterforms to be combined into special ligature forms. The rules governing ligature formation can be quite complex, requiring special script-shaping technologies such as ACE (Arabic Calligraphic Engine by DecoType in the 1980s and used to generate all the Arabic examples in the printed editions of The Unicode Standard), which became the proof of concept for OpenType (by Adobe and Microsoft), Graphite (by SIL International), or AAT (by 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 ที่เกี่ยวข้อง จึงมีการจัดเตรียมชุดตัวอักษรพื้นฐานและเครื่องหมายกำกับเสียงที่จำเป็นทั้งหมดไว้

Rendering software that cannot process a Unicode character appropriately often displays it as an open rectangle, or as U+FFFD to indicate the position of the unrecognized character. Some systems have made attempts to provide more information about such characters. Apple's Last Resort font will display a substitute glyph indicating the Unicode range of the character, and the SIL International's Unicode fallback font will display a box showing the hexadecimal scalar value of the character.

Several mechanisms have been specified for storing a series of code points as a series of bytes.

Unicode defines two mapping methods: the Unicode Transformation Format (UTF) encodings, and the Universal Coded Character Set (UCS) encodings. An encoding maps (possibly a subset of) the range of Unicode code points to sequences of values in some fixed-size range, termed code units. All UTF encodings map code points to a unique sequence of bytes.^[74] The numbers in the names of the encodings indicate the number of bits per code unit (for UTF encodings) or the number of bytes per code unit (for UCS encodings and UTF-1). UTF-8 and UTF-16 are the most commonly used encodings. UCS-2 is an obsolete subset of UTF-16; UCS-4 and UTF-32 are functionally equivalent.

UTF encodings include:

• UTF-8, which uses one to four 8-bit units per code point,^{[note 3]} and has maximal compatibility with ASCII
• UTF-16, which uses one 16-bit unit per code point below U+010000, and a surrogate pair of two 16-bit units per code point in the range U+010000 to U+10FFFF
• UTF-32, which uses one 32-bit unit per code point
• UTF-EBCDIC, not specified as part of The Unicode Standard, which uses one to five 8-bit units per code point, intended to maximize compatibility with EBCDIC

UTF-8 uses one to four 8-bit units (bytes) per code point and, being compact for Latin scripts and ASCII-compatible, provides the de facto standard encoding for the interchange of Unicode text. It is used by FreeBSD and most recent Linux distributions as a direct replacement for legacy encodings in general text handling.

The UCS-2 and UTF-16 encodings specify the Unicode byte order mark (BOM) for use at the beginnings of text files, which may be used for byte-order detection (or byte endianness detection). The BOM, encoded as U+FEFFZERO WIDTH NO-BREAK SPACE, has the important property of unambiguity on byte reorder, regardless of the Unicode encoding used; U+FFFE (the result of byte-swapping U+FEFF) does not equate to a legal character, and U+FEFF in places other than the beginning of text conveys the zero-width non-break space.

The same character converted to UTF-8 becomes the byte sequence EF BB BF. The Unicode Standard allows the BOM "can serve as a signature for UTF-8 encoded text where the character set is unmarked".^[75] Some software developers have adopted it for other encodings, including UTF-8, in an attempt to distinguish UTF-8 from local 8-bit code pages. However RFC 3629, the UTF-8 standard, recommends that byte order marks be forbidden in protocols using UTF-8, but discusses the cases where this may not be possible. In addition, the large restriction on possible patterns in UTF-8 (for instance there cannot be any lone bytes with the high bit set) means that it should be possible to distinguish UTF-8 from other character encodings without relying on the BOM.

In UTF-32 and UCS-4, one 32-bit code unit serves as a fairly direct representation of any character's code point (although the endianness, which varies across different platforms, affects how the code unit manifests as a byte sequence). In the other encodings, each code point may be represented by a variable number of code units. UTF-32 is widely used as an internal representation of text in programs (as opposed to stored or transmitted text), since every Unix operating system that uses the GCC compilers to generate software uses it as the standard "wide character" encoding. Recent versions of the Python programming language (beginning with 2.2) may also be configured to use UTF-32 as the representation for Unicode strings, effectively disseminating such encoding in high-level coded software.

Punycode, another encoding form, enables the encoding of Unicode strings into the limited character set supported by the ASCII-based Domain Name System (DNS). The encoding is used as part of IDNA, which is a system enabling the use of Internationalized Domain Names in all scripts that are supported by Unicode. Earlier and now historical proposals include UTF-5 and UTF-6.

GB18030 is another encoding form for Unicode, from the Standardization Administration of China. It is the official character set of the People's Republic of China (PRC). BOCU-1 and SCSU are Unicode compression schemes. The April Fools' Day RFC of 2005 specified two parody UTF encodings, UTF-9 and UTF-18.

Unicode has become the dominant scheme for the internal processing and storage of text. Although a great deal of text is still stored in legacy encodings, Unicode is used almost exclusively for building new information processing systems. Early adopters tended to use UCS-2 (the fixed-length two-byte obsolete precursor to UTF-16) and later moved to UTF-16 (the variable-length current standard), as this was the least disruptive way to add support for non-BMP characters. The best known such system is Windows NT (and its descendants, 2000, XP, Vista, 7, 8, 10, and 11), which uses UTF-16 as the sole internal character encoding. The Java and .NET bytecode environments, macOS, and KDE also use it for internal representation. Partial support for Unicode can be installed on Windows 9x through the Microsoft Layer for Unicode.

UTF-8 (originally developed for Plan 9)^[81] has become the main storage encoding on most Unix-like operating systems (though others are also used by some libraries) because it is a relatively easy replacement for traditional extended ASCII character sets. UTF-8 is also the most common Unicode encoding used in HTML documents on the World Wide Web.

Multilingual text-rendering engines which use Unicode include Uniscribe and DirectWrite for Microsoft Windows, ATSUI and Core Text for macOS, and Pango for GTK+ and the GNOME desktop.

Because keyboard layouts cannot have simple key combinations for all characters, several operating systems provide alternative input methods that allow access to the entire repertoire.

ISO/IEC 14755,^[82] which standardises methods for entering Unicode characters from their code points, specifies several methods. There is the Basic method, where a beginning sequence is followed by the hexadecimal representation of the code point and the ending sequence. There is also a screen-selection entry method specified, where the characters are listed in a table on a screen, such as with a character map program.

Online tools for finding the code point for a known character include Unicode Lookup^[83] by Jonathan Hedley and Shapecatcher^[84] by Benjamin Milde. In Unicode Lookup, one enters a search key (e.g. "fractions"), and a list of corresponding characters with their code points is returned. In Shapecatcher, based on Shape context, one draws the character in a box and a list of characters approximating the drawing, with their code points, is returned.

MIME defines two different mechanisms for encoding non-ASCII characters in email, depending on whether the characters are in email headers (such as the "Subject:"), or in the text body of the message; in both cases, the original character set is identified as well as a transfer encoding. For email transmission of Unicode, the UTF-8 character set and the Base64 or the Quoted-printable transfer encoding are recommended, depending on whether much of the message consists of ASCII characters. The details of the two different mechanisms are specified in the MIME standards and generally are hidden from users of email software.

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 is not in principle concerned with fonts per se, seeing them as implementation choices.^[93] Any given character may have many allographs, from the more common bold, italic and base letterforms to complex decorative styles. A font is "Unicode compliant" if the glyphs in the font can be accessed using code points defined in The Unicode Standard.^[94] The standard does not specify a minimum number of characters that must be included in the font; some fonts have quite a small repertoire.

Free and retail fonts based on Unicode are widely available, since TrueType and OpenType support Unicode (and Web Open Font Format (WOFF and WOFF2) is based on those). These font formats map Unicode code points to glyphs, but OpenType and TrueType font files are restricted to 65,535 glyphs. Collection files provide a "gap mode" mechanism for overcoming this limit in a single font file. (Each font within the collection still has the 65,535 limit, however.) A TrueType Collection file would typically have a file extension of ".ttc".

Thousands of fonts exist on the market, but fewer than a dozen fonts—sometimes described as "pan-Unicode" fonts—attempt to support the majority of Unicode's character repertoire. Instead, Unicode-based fonts typically focus on supporting only basic ASCII and particular scripts or sets of characters or symbols. Several reasons justify this approach: applications and documents rarely need to render characters from more than one or two writing systems; fonts tend to demand resources in computing environments; and operating systems and applications show increasing intelligence in regard to obtaining glyph information from separate font files as needed, i.e., font substitution. Furthermore, designing a consistent set of rendering instructions for tens of thousands of glyphs constitutes a monumental task; such a venture passes the point of diminishing returns for most typefaces.

Unicode partially addresses the newline problem that occurs when trying to read a text file on different platforms. Unicode defines a large number of characters that conforming applications should recognize as line terminators.

In terms of the newline, Unicode introduced U+2028LINE SEPARATOR and U+2029PARAGRAPH SEPARATOR. This was an attempt to provide a Unicode solution to encoding paragraphs and lines semantically, potentially replacing all of the various platform solutions. In doing so, Unicode does provide a way around the historical platform-dependent solutions. Nonetheless, few if any Unicode solutions have adopted these Unicode line and paragraph separators as the sole canonical line ending characters. However, a common approach to solving this issue is through newline normalization. This is achieved with the Cocoa text system in macOS and also with W3C XML and HTML recommendations. In this approach, every possible newline character is converted internally to a common newline (which one does not really matter since it is an internal operation just for rendering). In other words, the text system can correctly treat the character as a newline, regardless of the input's actual encoding.

Unicode has a large number of homoglyphs, many of which look very similar or identical to ASCII letters. Substitution of these can make an identifier or URL that looks correct, but directs to a different location than expected.^[105] Additionally, homoglyphs can also be used for manipulating the output of natural language processing (NLP) systems.^[106] Mitigation requires disallowing these characters, displaying them differently, or requiring that they resolve to the same identifier;^[107] all of this is complicated due to the huge and constantly changing set of characters.^[108][109]

A security advisory was released in 2021 by two researchers, one from the University of Cambridge and the other from the University of Edinburgh, in which they assert that the BiDi marks can be used to make large sections of code do something different from what they appear to do. The problem was named "Trojan Source".^[110] In response, code editors started highlighting marks to indicate forced text-direction changes.^[111]

The UTF-8 and UTF-16 encodings do not accept all possible sequences of code units. Implementations vary in what they do when reading an invalid sequence, which has led to security bugs.^[112][113]

Unicode was designed to provide code-point-by-code-point round-trip format conversion to and from any preexisting character encodings, so that text files in older character sets can be converted to Unicode and then back and get back the same file, without employing context-dependent interpretation. That has meant that inconsistent legacy architectures, such as combining diacritics and precomposed characters, both exist in Unicode, giving more than one method of representing some text. This is most pronounced in the three different encoding forms for Korean Hangul. Since version 3.0, any precomposed characters that can be represented by a combined sequence of already existing characters can no longer be added to the standard to preserve interoperability between software using different versions of Unicode.

Injective mappings must be provided between characters in existing legacy character sets and characters in Unicode to facilitate conversion to Unicode and allow interoperability with legacy software. Lack of consistency in various mappings between earlier Japanese encodings such as Shift-JIS or EUC-JP and Unicode led to round-trip format conversion mismatches, particularly the mapping of the character JIS X 0208 '～' (1-33, WAVE DASH), heavily used in legacy database data, to either U+FF5E～FULLWIDTH TILDE (in Microsoft Windows) or U+301C〜WAVE DASH (other vendors).^[114]

Some Japanese computer programmers objected to Unicode because it requires them to separate the use of U+005C\REVERSE SOLIDUS (backslash) and U+00A5¥YEN SIGN, which was mapped to 0x5C in JIS X 0201, and a lot of legacy code exists with this usage.^[115] (This encoding also replaces tilde '~' 0x7E with macron '¯', now 0xAF.) The separation of these characters exists in ISO 8859-1, from long before Unicode.

Indic scripts such as Tamil and Devanagari are each allocated only 128 code points, matching the ISCII standard. The correct rendering of Unicode Indic text requires transforming the stored logical order characters into visual order and the forming of ligatures (also known as conjuncts) out of components. Some local scholars argued in favor of assignments of Unicode code points to these ligatures, going against the practice for other writing systems, though Unicode contains some Arabic and other ligatures for backward compatibility purposes only.^{[116][117][118]} Encoding of any new ligatures in Unicode will not happen, in part, because the set of ligatures is font-dependent, and Unicode is an encoding independent of font variations. The same kind of issue arose for the Tibetan script in 2003 when the Standardization Administration of China proposed encoding 956 precomposed Tibetan syllables,^[119] but these were rejected for encoding by the relevant ISO committee (ISO/IEC JTC 1/SC 2).^[120]

Thai alphabet support has been criticized for its ordering of Thai characters. The vowels เ, แ, โ, ใ, ไ that are written to the left of the preceding consonant are in visual order instead of phonetic order, unlike the Unicode representations of other Indic scripts. This complication is due to Unicode inheriting the Thai Industrial Standard 620, which worked in the same way, and was the way in which Thai had always been written on keyboards. This ordering problem complicates the Unicode collation process slightly, requiring table lookups to reorder Thai characters for collation.^[97] Even if Unicode had adopted encoding according to spoken order, it would still be problematic to collate words in dictionary order. E.g., the word แสดง[sadɛːŋ] "perform" starts with a consonant cluster "สด" (with an inherent vowel for the consonant "ส"), the vowel แ-, in spoken order would come after the ด, but in a dictionary, the word is collated as it is written, with the vowel following the ส.

Characters with diacritical marks can generally be represented either as a single precomposed character or as a decomposed sequence of a base letter plus one or more non-spacing marks. For example, ḗ (precomposed e with macron and acute above) and ḗ (e followed by the combining macron above and combining acute above) should be rendered identically, both appearing as an e with a macron (◌̄) and acute accent (◌́), but in practice, their appearance may vary depending upon what rendering engine and fonts are being used to display the characters. Similarly, underdots, as needed in the romanization of Indic languages, will often be placed incorrectly. Unicode characters that map to precomposed glyphs can be used in many cases, thus avoiding the problem, but where no precomposed character has been encoded, the problem can often be solved by using a specialist Unicode font such as Charis SIL that uses Graphite, OpenType ('gsub'), or AAT technologies for advanced rendering features.

The Unicode Standard has imposed rules intended to guarantee stability.^[121] Depending on the strictness of a rule, a change can be prohibited or allowed. For example, a "name" given to a code point cannot and will not change. But a "script" property is more flexible, by Unicode's own rules. In version 2.0, Unicode changed many code point "names" from version 1. At the same moment, Unicode stated that, thenceforth, an assigned name to a code point would never change. This implies that when mistakes are published, these mistakes cannot be corrected, even if they are trivial (as happened in one instance with the spelling BRAKCET for BRACKET in a character name). In 2006 a list of anomalies in character names was first published, and, as of June 2021, there were 104 characters with identified issues,^[122] for example:

• U+034F͏COMBINING GRAPHEME JOINER: Does not join graphemes.^[122]
• U+2118℘SCRIPT CAPITAL P: This is a small letter. The capital is U+1D4AB𝒫MATHEMATICAL SCRIPT CAPITAL P.^[123]
• U+A015ꀕYI SYLLABLE WU: This is not a Yi syllable, but a Yi iteration mark.
• U+FE18 ︘รูปแบบการนำเสนอสำหรับวงเล็บเลนติคูลาร์สีขาวแนวตั้งด้านขวา :วงเล็บสะกดผิด ^{[ 124 ]} (แก้ไขข้อผิดพลาดในการสะกดโดยใช้ชื่อนามแฝง Unicode )

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