SQL Server 2005/2008 UTF-8 排序規則/字元集
UTF-8我在 SQL Server 2005/2008中找不到直接設置相關的選項Collations/Charsets，這與在其他 SQL 引擎中設置的可能相同，但在 SQL Server 2005/2008 中只有拉丁語和 SQL 排序規則。是否有一些選項可以在 Win2008 作業系統上的 SQL Server 引擎（兩個版本）2005/2008 中強制/安裝這些排序規則/字元集
不，沒有。SQL Server 不支持 UTF-8。
如果需要 unicode 數據，則需要將列定義為 nvarchar/nchar。注意，內部 SQL Server 將其儲存為 UCS-2。
請注意，這已在 Connect 上向 MS提出請求，並且有一篇較舊的知識庫文章。還有這個部落格上的一些資訊
從 SQL Server 2019（目前處於測試版/“社區技術預覽版”）開始，通過一系列新的 UTF-8 排序規則提供對 UTF-8 的原生支持。***但是，*能夠使用 UTF-8 並不意味著您應該這樣做。使用 UTF-8 有明顯的缺點，例如：
- 只有前 128 個程式碼點是 1 個字節（即標準的 7 位 ASCII 集）
- 接下來的近 2000 個程式碼點是 2 個字節，因此與 UTF-16 相比沒有節省空間/
NVARCHAR- BMP 中剩餘的 63k 個程式碼點（即 U+0800 - U+FFFF 範圍）都是 3 個字節，因此比 UTF-16 / 中的相同字元大
NVARCHAR1 個字節。- 只是說一下：補充字元在兩種編碼中都是 4 個字節，所以沒有空間差異
- 雖然使用 UTF-8 可以節省空間，但這樣做很有可能會影響性能。
真正歸結為：UTF-8 是一種儲存格式設計，可讓 8 位系統（通常圍繞 ASCII 和 ASCII 擴展——程式碼頁設計）使用 Unicode 而不會破壞任何東西或需要對現有系統進行任何修改文件以保持執行。UTF-8 非常適合文件系統和網路，但儲存在SQL Server 中的數據兩者都不是。恰好大部分（或完全）在標準 ASCII 範圍內的數據在儲存為 UTF-16 / 時需要比相同數據更少的空間這一事實
NVARCHAR是一個副作用。當然，這是一個可以證明是有用的副作用，但這個決定需要由既了解數據又了解該決定的後果/缺點的人做出。這是不是一般用途的功能。此外，UTF-8（在 SQL Server 中）的主要案例是已經使用 UTF-8 的應用程式碼，可能已經使用另一個支持它的 RDBMS，並且不希望或沒有能力更新應用程式碼/數據庫架構使用
NVARCHAR數據類型（用於表、變數、參數等），或在字元串文字前加上大寫“N”。目標與 UTF-8 存在的原因相同：使應用程式碼能夠使用 Unicode，而不改變整體結構或呈現現有數據無效。如果這描述了您的情況，請使用 UTF-8，但請注意它仍然存在一些錯誤/問題。如果您在不使用
NVARCHAR或大寫“N”前綴字元串文字的情況下沒有明確需要 Unicode 工作，那麼 UTF-8 是一個好處的唯一其他情況是，如果您有很多需要允許的大部分標準 ASCII 數據Unicode 字元，並且您正在使用NVARCHAR(MAX)（這意味著數據壓縮不起作用），並且表會頻繁更新（因此聚集列儲存索引可能不會真正提供幫助）。詳細內容請看我的文章：