了解編碼

發行項
08/21/2008

更新：2007 年 11 月

在內部中，.NET Framework 會將文字儲存為 Unicode UTF-16。編碼器會將此文字資料轉換成位元組序列。解碼器則會將位元組的序列轉換成這個內部格式。編碼方式會描述編碼器或解碼器的運作規則。例如，UTF8Encoding 類別 (Class) 會描述對於將文字表示為 Unicode UTF-8 的位元組序列，進行編碼或解碼的規則。編碼和解碼也可以包含某些驗證步驟。例如，UnicodeEncoding 類別會檢查所有 Surrogate，以確定它們是由有效的 Surrogate 字組所組成。這兩種類別都繼承自 Encoding 類別。

選擇編碼方式

Unicode 標準會指派字碼指標 (數字) 給每個受支援指令碼中的每個字元。Unicode 轉換格式 (UTF) 是用來編碼該字碼指標的方法。如需 System.Text 中類別所支援 UTF 的詳細資訊，請參閱 .NET Framework 中的 Unicode中的＜使用 Unicode 編碼方式＞。

選取 Encoding 類別

Encoding 類別是很常用的類別。繼承自 Encoding 的支援類別，可讓 .NET 應用程式操作可能會在舊版應用程式中遇到的一般編碼方式，而且您也能實作其他編碼方式。然而，當您有機會選擇編碼方式時，強烈建議您使用 Unicode 編碼方式，通常是 UTF8Encoding 或 UnicodeEncoding (也有支援 UTF32Encoding)。尤其 UTF8Encoding 是比 ASCIIEncoding 更為慣用的編碼方式。如果內容是 ASCII，兩種編碼方式就會完全相同，不過 UTF8Encoding 也能表示每個 Unicode 字元，ASCIIEncoding 則只支援 U+0000 與 U+007F 之間的 Unicode 字元值。由於 ASCIIEncoding 沒有提供錯誤偵測，因此 UTF8Encoding 也具有較佳的安全性。

UTF8Encoding 已調整成其可能的最快速度，因此在速度上應該會超過他任何編碼方式。即使是全部都是 ASCII 的內容，使用 UTF8Encoding 執行的作業也會快過使用 ASCIIEncoding 執行的作業。您應該考慮只對某些舊版應用程式使用 ASCIIEncoding。然而，即使在這種情況下，UTF8Encoding 可能仍為較佳的選擇。在假設的預設設定時會發生下列案例：

如果您的應用程式具有的內容不完全是 ASCII，而且使用 ASCIIEncoding, 編碼該內容，這時每個非 ASCII 字元都會編碼成問號 ("?")。如果應用程式接著解碼這項資料，資訊就會遺失。
如果您的應用程式具有的內容不完全是 ASCII，而且使用 UTF8Encoding 編碼該內容，若是將結果解譯為 ASCII，其內容就會無法辨識。然而，如果應用程式接著解碼這項資料，該資料依然會成功地往返。

選擇後援策略

當應用程式嘗試編碼或解碼字元，但此時沒有任何對應存在時，它就必須實作後援策略 (一種失敗處理機制)。後援策略具有兩種類型：

自動調整後援

當字元在目標編碼/解碼中沒有完全相符的字元時，應用程式可嘗試將這些字元對應到相似的字元。
取代字串後援

如果沒有適當的相似字元，應用程式可指定取代字串。

例如，應用程式可以呼叫 GetEncoding(1252, 0, 0) (請參閱 GetEncoding)。這個呼叫會指定字碼頁 1252 (西歐語言的 Windows 字碼頁)，並將 encoderFallback 和 decoderFallback 指定為零。某些 Unicode 字元的預設行為會是自動調整對應。例如，CIRCLED LATIN CAPITAL LETTER S (U+24C8) 會在編碼之前變更為 LATIN CAPITAL LETTER S (U+0053)，而 SUPERSCRIPT FIVE (U+2075) 則會變更為 DIGIT FIVE (U+0035)。如果應用程式接著從字碼頁 1252 解碼回到 Unicode，字母周圍的圓圈將會遺失，而且 2⁵ 會變成 25。其他轉換甚至可能會更為極端。例如，Unicode INFINITY 符號 (U+221E) 可能會對應至 DIGIT EIGHT (U+0038)。

自動調整策略會根據不同的字碼頁而有所差異，而且它們並未詳細記載。例如，某些字碼頁的全形拉丁字母會對應到更常見的半形拉丁字母。但是其他的字碼頁則不會做此對應。

即使是採用最積極的自動調整策略，都無法想像如何為某些編碼方法的某些字元進行調整。例如，一個中文表意字元在字碼頁 1252 中沒有任何合理的對應。在此情況下，就會使用取代字串。根據預設，這個字串只是單一 QUESTION MARK (U+003F)。

自動調整對應是 Encoding 的預設行為，這種行為會將 Unicode 資料編碼成字碼頁資料，而有些舊版應用程式會依靠這項行為。然而，基於安全性理由，大多數的新應用程式都應該避免自動調整行為。例如，應用程式不應該透過自動調整編碼方式放入定義域名稱。

您的應用程式應使用下列自動調整對應的替代方法：

僅使用 Unicode 編碼方式 (UTF8Encoding、UnicodeEncoding 和 UTF32Encoding) 以避免後援問題。

警告：
雖然 UTF7Encoding 在技術上是屬於 Unicode 編碼方式，但是相較其他編碼方式卻是較不穩固且較不安全。在某些情況下，變更一個位元便可能會徹底改變整個 UTF-7 字串的解譯。在其他情況下，差異極大的 UTF-7 字串可能會編碼成相同的文字。因此，請在可以選擇的情況下避免使用 UTF-7。UTF-8 是比 UTF-7 更為慣用的方法。

雖然 UTF7Encoding 在技術上是屬於 Unicode 編碼方式，但是相較其他編碼方式卻是較不穩固且較不安全。在某些情況下，變更一個位元便可能會徹底改變整個 UTF-7 字串的解譯。在其他情況下，差異極大的 UTF-7 字串可能會編碼成相同的文字。因此，請在可以選擇的情況下避免使用 UTF-7。UTF-8 是比 UTF-7 更為慣用的方法。

請使用會在字元完全沒有對應時擲回例外狀況 (Exception) 的 EncoderExceptionFallback 和 DecoderExceptionFallback (分別擲回 EncoderFallbackException 和 DecoderFallbackException)。
如果字元完全沒有對應時，請永遠使用 EncoderReplacementFallback 和 DecoderReplacementFallback 替代取代字串。這是 ASCIIEncoding 的預設行為。根據預設，這個字串只會是一個問號，不過也有提供方法讓應用程式能夠選擇不同的字串。雖然這通常會是單一字元，但這並非絕對必要。對於將文字轉換成 Unicode 時所使用的 DecoderReplacementFallback，通常會使用的一個字元是 REPLACEMENT CHARACTER (U+FFFD)。
請使用自訂 EncoderFallback 和/或 DecoderFallback 來實作慣用的策略。請參閱後援編碼方式應用程式範例。

關於自動調整編碼 (或解碼) 後援策略的兩個額外注意事項：

自動調整通常是編碼上的問題，而非解碼問題。有極少數字碼頁包含無法成功對應到 Unicode 的字元。這些字元由於沒有經常使用，因此已從 Unicode 省略。
自動調整後援並沒有任何對應的支援具名物件。每個字碼頁的自動調整後援都不相同。如果您的應用程式需要針對單一個 Encoding 物件來回切換自動調整和其他一些後援，請將原始自動調整物件複製到某個變數，然後再指派其他任何後援物件。然後，應用程式就能透過將該值指派回到 Encoding.EncoderFallback 或 Encoding.DecoderFallback，以復原自動調整後援。