UTF-32

雖然每一個碼位使用固定長定的字節看似方便，它並不如其它Unicode編碼使用得廣泛。它更容易進行截斷操作，但這方面並不比UTF-8及UTF-16強多少，因為後兩者也只要在要截斷的位置向前或向後至多搜索2-4個字符即可。

程序想直接定位到第n個字符且不去考察前n-1個字符的情形其實很少見。也就是説，雖然UTF-32遍歷字符時候每一個字符都可以方便地下標+1，但是實際上在UTF-8和UTF-16中可以用一個記錄已經遍歷過的總字符寬度加上當前字符的寬度的整數來代替，二者效率其實差不多。其他一些情形，例如打算直接讀取第n個字符而不打算去考察之前的字符，例如一些哈希操作和高速搜索算法，實際上並不需要n非常精確。以截斷為例，用UTF-8或UTF-16也很簡單，此時只需要調整指針的位置到最接近的字符邊界處即可，這是一個固定時間的操作。

UTF-32也不會讓計算所顯示字符串的寬度更簡單。因為即使用定寬字體，一個顯示字符的位置也可能會存在多於一個編碼字符（如結合字符）或一個編碼字符對應多於一個顯示字符的位置（如CJK表意符）。如果文本編輯器僅侷限於從左到右且無結合字符，那麼用UTF-32會有一定優勢。但是這樣的文本編輯器既然也不太可能支持非基本平面的字符，那麼為什麼不用UTF-16呢？

原本ISO 10646標準定義了一個32位元的編碼形式，稱作UCS-4，使用通用字符集（UCS）的每一個字符，會在0到十六進制的7FFFFFFF這樣的字碼空間中，被表示成一個的32位元的碼值。

UCS-4足以用來表示所有的Unicode的字碼空間，其最大的碼位為十六進制的10FFFF，所以其空間約有百萬個碼位。有些人認為保留如此大的字碼空間卻只為了對應這很小的碼集是浪費的所以一個新的編碼UTF-32被提出來了。UTF-32 是一個 UCS-4 的子集，使用32-位元的碼值，只在0到10FFFF的字碼空間。

UTF-32 原本是 UCS-4 的子集，但JTC1/SC2/WG2聲明，所有未來對字符的指定都將會限制在BMP及其14個補充平面，並移除先前在 E0 到 FF 平面的 60 到 7F 羣的私用空間。

於是就現狀而言，除了 UTF-32 標準包含額外的 Unicode 意涵，UCS-4 和 UTF-32 大體是相同的。

（英文）The Unicode Standard 4.1，第三章 - 在§3.10, D43-D4中正式定義 UTF-32（英文）Unicode Standard Annex #19 - Unicode 3.x 中正式定義的 UTF-32（2001 年三月；最後更新於 2002 年三月）（英文）註冊新字集：UTF-32, UTF-32BE, UTF-32LE - IANA 字符集新增 UTF-32的宣言（2002 年四月）