SortKey 類別
本文提供此 API 參考文件的補充備註。
區分文化特性的兩個字串比較取決於字串中具有數種排序權數類別的每個字元，包括腳本、字母、大小寫和讀音符號權數。 排序索引鍵可作為特定字串之這些權數的存放庫。
方法 CompareInfo.GetSortKey 會傳回 類別的 SortKey 實例，反映指定字串中字元的文化特性敏感對應。 物件的值 SortKey 是其索引鍵數據，由 屬性傳 KeyData 回。 此索引鍵數據是由一系列位元組所組成，這些位元組會編碼字串、特定文化特性的排序規則，以及使用者指定的比較選項。 使用排序索引鍵的比較包含每個排序索引鍵中對應索引鍵數據的位比較。 例如，如果您藉由呼叫 GetSortKey(String, CompareOptions) 值為 CompareOptions.IgnoreCase的 方法來建立排序索引鍵，則使用排序索引鍵的字串比較作業不區分大小寫。
建立字串的排序索引鍵之後，您可以呼叫靜態 SortKey.Compare 方法來比較排序索引鍵。 這個方法會執行簡單的位元組位元組比較，因此比 String.Compare 或 CompareInfo.Compare 方法快得多。
注意
您可以下載 排序權數表格，這是一組文本檔，其中包含 Windows 作業系統排序和比較作業中使用的字元權數資訊、 預設 Unicode 定序元素數據表、Linux 和 macOS 的排序權數數據表。
效能考量
執行字串比較時， Compare 和 CompareInfo.Compare 方法會產生相同的結果，但會以不同的案例為目標。
概括而言， CompareInfo.Compare 方法會產生每個字串的排序索引鍵、執行比較，然後捨棄排序索引鍵並傳回比較的結果。 不過， CompareInfo.Compare 方法實際上不會產生整個排序索引鍵來執行比較。 相反地，方法會為每個字串中的每個文字項目產生索引鍵數據（也就是基底字元、代理字組或結合字元序列）。 然後，方法會比較對應文字元素的索引鍵數據。 一旦判斷比較的最終結果，作業就會終止。 會計算排序索引鍵資訊，但不會 SortKey 建立物件。 如果兩個字串都比較一次，則此策略在效能方面是經濟的，但如果相同字串比較多次，就會變得昂貴。
在執行比較之前，方法 Compare 需要為每個字串產生 SortKey 物件。 由於花費時間和記憶體來產生 SortKey 物件，此策略在第一次比較時的效能成本很高。 不過，如果多次比較相同的排序索引鍵，就會變得經濟。
例如，假設您撰寫的應用程式會搜尋資料庫數據表中字串型索引數據行符合指定搜尋字串的數據列。 數據表包含數千個數據列，並將搜尋字串與每個數據列中的索引進行比較需要很長的時間。 因此，當應用程式儲存數據列及其索引數據行時，也會產生索引的排序索引鍵，並將其儲存在專用於改善搜尋效能的數據行中。 當應用程式搜尋目標數據列時，它會比較搜尋字串的排序索引鍵與索引字串的排序索引鍵，而不是比較搜尋字串與索引字元串。
安全性考量
方法CompareInfo.GetSortKey(String, CompareOptions)會根據指定的字串和值，CompareOptions以及與基礎CompareInfo對象相關聯的文化特性，傳回SortKey具有 值的物件。 如果安全性決策取決於字串比較或大小寫變更，您應該使用 CompareInfo.GetSortKey(String, CompareOptions) 不因文化特性而異的方法，以確保不論操作系統的文化特性設定為何，作業的行為都是一致的。
使用下列步驟來取得排序索引鍵：
從屬性擷 CultureInfo.InvariantCulture 取非變異文化特性。
CompareInfo從 CultureInfo.CompareInfo 屬性擷取不因文化特性而異的物件。
使用物件的值 SortKey 相當於使用指定的LCMAP_SORTKEY值呼叫 Windows LCMapString 方法。 不過，針對 SortKey 物件，英文字符的排序索引鍵位於韓文字符的排序索引鍵之前。
SortKey 物件可以串行化，但只能讓物件跨越 AppDomain 物件。 如果應用程式串行化 SortKey 物件，當有新版本的 .NET 時，應用程式必須重新產生所有排序索引鍵。
如需排序索引鍵的詳細資訊，請參閱 Unicode 聯盟網站上的 Unicode 技術標準 #10「Unicode 定序演算法」。
