UTF-32

UTF-32 (或 UCS-4)是一種將Unicode字元編碼的協定，對每一個Unicode碼位使用恰好32位元。其它的Unicode transformation formats則使用不定長度編碼。因為UTF-32對每個字元都使用4位元組，就空間而言，是非常沒有效率的。特別地，非基本多文種平面的字元在大部分檔案中通常很罕見，以致於它們通常被認為不存在占用空間大小的討論，使得UTF-32通常會是其它編碼的二到四倍。雖然每一個碼位使用固定長定的位元組看似方便，它並不如其它Unicode編碼使用得廣泛。

基本介紹

• 外文名：UTF-32
• 別稱： UCS-4
• 全稱：Unicode transformation formats
• 隸屬：Unicode編碼

簡介

雖然每一個碼位使用固定長定的位元組看似方便，它並不如其它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 年四月）