UTF-32 ( รูปแบบการแปลงยูนิโค้ด 32 บิต ) บางครั้งเรียกว่า UCS-4 เป็นการ เข้ารหัสความยาวคงที่ที่ใช้ในการเข้ารหัสจุดรหัส ยูนิโค้ด ซึ่งใช้ 32 บิต (สี่ไบต์ ) ต่อจุดรหัส (แต่จำนวนบิตนำหน้าต้องเป็นศูนย์เนื่องจากมีจุดรหัสยูนิโค้ดน้อยกว่า 2³² จุดมาก^จึงต้องการเพียง 21 บิตเท่านั้น) ^{[ 1 ]}ในทางตรงกันข้าม รูปแบบการแปลงยูนิโค้ดอื่นๆ ทั้งหมดเป็นการเข้ารหัสความยาวแปรผัน ค่า 32 บิตแต่ละค่าใน UTF-32 แทนจุดรหัสยูนิโค้ดหนึ่งจุดและเท่ากับค่าตัวเลขของจุดรหัสนั้นอย่างแน่นอน

ข้อได้เปรียบหลักของ UTF-32 คือจุดรหัส Unicode ได้รับการจัดทำดัชนีโดยตรง การค้นหา จุดรหัส ที่ Nในลำดับของจุดรหัสเป็นการ ดำเนินการ แบบคงที่ ในทางตรงกันข้ามรหัสที่มีความยาวแปรผันต้อง ใช้ เวลาเชิงเส้นในการนับ จุดรหัส Nจากจุดเริ่มต้นของสตริง ทำให้ UTF-32 เป็นการทดแทนที่ง่ายในโค้ดที่ใช้จำนวนเต็มที่เพิ่มขึ้นทีละหนึ่งเพื่อตรวจสอบแต่ละตำแหน่งในสตริงดังที่ทำกันโดยทั่วไปสำหรับASCIIโปรแกรมเมอร์มือใหม่มักประเมินประโยชน์ของสิ่งนี้สูงเกินไป^{[ 2 ]}

ข้อเสียหลักของ UTF-32 คือการใช้พื้นที่อย่างไม่มีประสิทธิภาพ โดยใช้สี่ไบต์ต่อจุดรหัส รวมถึง 11 บิตที่เป็นศูนย์เสมอ อักขระที่นอกเหนือจากBMPนั้นค่อนข้างหายากในข้อความส่วนใหญ่ (ยกเว้นในกรณีของข้อความที่มีอีโมจิยอดนิยมบางตัว) และโดยทั่วไปสามารถละเลยได้ในการประมาณขนาด ทำให้ UTF-32 มีขนาดเกือบสองเท่าของUTF-16และอาจมีขนาดใหญ่กว่าUTF-8 ถึงสี่เท่า ขึ้นอยู่กับจำนวนอักขระที่อยู่ในชุดย่อยASCII ^{[ 3 ]}

มาตรฐาน ISO/IEC 10646ดั้งเดิม กำหนด รูปแบบการเข้ารหัส 32 บิตที่เรียกว่าUCS-4ซึ่งแต่ละจุดรหัสในชุดอักขระสากล (UCS) จะถูกแทนด้วยค่า 31 บิตตั้งแต่ 0 ถึง 0x7FFFFFFF (บิตเครื่องหมายไม่ได้ใช้งานและเป็นศูนย์) ในเดือนพฤศจิกายน 2546 Unicode ถูกจำกัดโดย RFC 3629 เพื่อให้ตรงกับข้อจำกัดของ การเข้ารหัส UTF-16โดยห้ามใช้จุดรหัสที่มากกว่า U+10FFFF อย่างชัดเจน (รวมถึงค่าทดแทนสูงและต่ำ U+D800 ถึง U+DFFF ด้วย) ชุดย่อยที่จำกัดนี้กำหนด UTF-32 ^{[ 4 ] [ 1 ]}แม้ว่ามาตรฐาน ISO (ณ ปี 1998 ใน Unicode 2.1) จะ "สงวนไว้สำหรับการใช้งานส่วนตัว" 0xE00000 ถึง 0xFFFFFF และ 0x60000000 ถึง 0x7FFFFFFF ^{[ 5 ]}แต่พื้นที่เหล่านี้ถูกลบออกในเวอร์ชันต่อมา เนื่องจากเอกสารหลักการและขั้นตอนของISO/IEC JTC 1/SC 2 Working Group 2 ระบุว่าการกำหนดรหัสจุดในอนาคตทั้งหมดจะถูกจำกัดอยู่ในช่วง Unicode ดังนั้น UTF-32 จะสามารถแสดงรหัสจุด UCS ทั้งหมดได้ และ UTF-32 กับ UCS-4 นั้นเหมือนกัน^{[ 6 ]}

การกำหนดจำนวนไบต์คงที่ต่อจุดรหัสมีข้อดีในทางทฤษฎี แต่ข้อดีเหล่านั้นก็มีปัญหาในทางปฏิบัติเช่นกัน:

• การตัดทอนทำได้ง่ายขึ้น แต่ก็ไม่ได้ง่ายขึ้นมากนักเมื่อเทียบกับUTF-8และUTF-16 (ซึ่งทั้งสองแบบสามารถค้นหาจุดที่จะตัดทอนย้อนหลังได้โดยดูที่หน่วยรหัส 2–4 หน่วยเป็นอย่างมาก) ^{[ a ]}
• การค้นหา "อักขระ" ตัวที่ Nในสตริง การค้นหา จุดรหัสตัว ที่ Nเป็นปัญหา O(1)ในขณะที่เป็นปัญหา O(n)ในการเข้ารหัสความกว้างแปรผัน อย่างไรก็ตาม สิ่งที่ผู้ใช้อาจเรียกว่า "อักขระ" ยังคงมีความกว้างแปรผัน^{[ 3 ]}ตัวอย่างเช่นลำดับอักขระที่รวมกันáเป็นจุดรหัสสองจุด อีโมจิ👨‍🦲มีสามจุด^{[ 7 ]}และตัวอักษรเชื่อมffมีหนึ่งจุด
• ทราบ "ความกว้าง" ของสตริงได้อย่างรวดเร็ว อย่างไรก็ตามแม้แต่แบบอักษร "ความกว้างคงที่" ก็ยัง มีความกว้างที่แตกต่างกัน บ่อยครั้งที่อักษรจีน ญี่ปุ่น และเกาหลีมีความกว้างเป็นสองเท่า^{[ 2 ]}บวกกับปัญหาที่กล่าวถึงไปแล้วเกี่ยวกับจำนวนจุดรหัสที่ไม่เท่ากับจำนวนอักขระ

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

การใช้งานสตริง UTF-32 บน Windows (ซึ่งwchar_tเป็น 16 บิต) แทบจะไม่มีเลย ส่วนในระบบ Unix นั้น บางครั้งก็มีการใช้งานสตริง UTF-32 ภายในโปรแกรมต่างๆ แต่ก็เกิดขึ้นน้อยมาก เนื่องจากชนิดข้อมูลwchar_tถูกกำหนดให้เป็น 32 บิต

UTF-32 ยังถูกห้ามใช้เป็นการเข้ารหัสอักขระ HTML อีกด้วย^{[ 8 ] [ 9 ]}

Pythonเวอร์ชันไม่เกิน 3.2 สามารถคอมไพล์ให้ใช้สตริง UTF-32 แทนUTF-16ได้ ตั้งแต่เวอร์ชัน 3.3 เป็นต้นไป สตริง Unicode จะถูกจัดเก็บในรูปแบบ UTF-32 หากมีอักขระที่ไม่ใช่BMP อย่างน้อย 1 ตัว ในสตริง แต่ไบต์ศูนย์นำหน้าจะถูกปรับให้เหมาะสม "ขึ้นอยู่กับ [จุดรหัส] ที่มีลำดับ Unicode ที่ใหญ่ที่สุด (1, 2 หรือ 4 ไบต์)" เพื่อให้จุดรหัสทั้งหมดมีขนาดเท่ากัน^{[ 10 ]}

ภาษา การเขียนโปรแกรม Juliaได้เลิกใช้การสนับสนุน UTF-32 ในตัวตั้งแต่เวอร์ชัน 1.0 โดยลดความซับซ้อนของภาษาให้เหลือเพียงสตริง UTF-8 เท่านั้น (โดยถือว่าการเข้ารหัสอื่นๆ ทั้งหมดเป็นของเก่าและย้ายออกจากไลบรารีมาตรฐานไปเป็นแพ็กเกจ^{[ 11 ]} ) ตาม "UTF-8 Everywhere Manifesto" ^{[ 12 ]}

C++11มีชนิดข้อมูลในตัว 2 ชนิดที่ใช้ UTF-32 char32_tชนิดข้อมูลนี้เก็บอักขระ 1 ตัวในรูปแบบ UTF-32 และu32stringชนิดข้อมูลนี้เก็บสตริงของอักขระที่เข้ารหัสแบบ UTF-32 อักขระหรือสตริงลิเทอรัลที่เข้ารหัสแบบ UTF-32 จะถูกทำเครื่องหมายด้วยUก่อนอักขระหรือสตริงลิเทอรัลนั้น^{[ 13 ] [ 14 ]}

#include <string> char32_t UTF32_character = U '🔟' ; // เขียนอีกแบบว่า U'\U0001F51F' std :: u32string UTF32_string = U "UTF–32-encoded string" ; // กำหนดเป็น `const char32_t*´

C#มีUTF32Encodingคลาสที่แสดงอักขระ Unicode เป็นไบต์แทนที่จะเป็นสตริง^{[ 15 ]}

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

UTF-32 มี 2 เวอร์ชันสำหรับ big-endian และ little-endian คือUTF-32-BEและUTF-32- LE

• การเปรียบเทียบการเข้ารหัส Unicode
• ยูทีเอฟ-16

• มาตรฐาน Unicode 5.0.0 บทที่ 3  กำหนดนิยามอย่างเป็นทางการของ UTF-32 ใน § 3.9, D90 (หน้า 40 ในไฟล์ PDF) และ § 3.10, D99-D101 (หน้า 45 ในไฟล์ PDF)
• มาตรฐาน Unicode Annex #19  – กำหนดนิยามอย่างเป็นทางการของ UTF-32 สำหรับ Unicode 3.x (มีนาคม 2001; ปรับปรุงล่าสุด มีนาคม 2002)
• การขึ้นทะเบียนชุดอักขระใหม่: UTF-32, UTF-32BE, UTF-32LE  – การประกาศเพิ่ม UTF-32 เข้าสู่ทะเบียนชุดอักขระของ IANA (เมษายน 2545)