本文提供此 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)會根據指定的字串和SortKey值，傳回一個基於這些值的CompareOptions物件，並考慮與基礎CompareInfo對象有關的文化特性。 如果安全性決策取決於字串比較或大小寫變更，您應該使用不區分文化特性的 CompareInfo.GetSortKey(String, CompareOptions) 方法，以確保不論作業系統的文化特性設定為何，作業的行為都是一致的。
使用下列步驟來取得排序索引鍵：
從CultureInfo.InvariantCulture屬性中取得不變文化信息。
從 CompareInfo 屬性中擷取不因文化特性而異的 CultureInfo.CompareInfo 物件。
使用物件的值 SortKey 相當於使用指定的LCMAP_SORTKEY值呼叫 Windows LCMapString 方法。 不過，針對 SortKey 物件，英文字符的排序索引鍵位於韓文字符的排序索引鍵之前。
SortKey 物件可以被序列化，但只能為了使其能夠跨越 AppDomain 物件。 如果應用程式串行化 SortKey 物件，當有新版本的 .NET 時，應用程式必須重新產生所有排序索引鍵。
如需排序索引鍵的詳細資訊，請參閱 Unicode 聯盟網站上的 Unicode 技術標準 #10「Unicode 定序演算法」。
