建立全文檢索索引時，您必須針對索引資料行指定資料行層級語言。 指定語言的 斷詞符號和詞幹分析器 會由直欄上的全文檢索查詢使用。 在建立全文檢索索引並選擇資料行語言時，必須考慮一些事項。 這些考量事項與文字如何權杖化，然後由 Full-Text 引擎建立索引有關。
注意
若要指定全文檢索索引直欄的直欄層級語言，請在指定直欄時使用 子 LANGUAGE <language_term> 句。 如需詳細資訊，請參閱 CREATE FULLTEXT INDEX 和 ALTER FULLTEXT INDEX。
Full-Text Search 中的語言支援
本節介紹斷詞工具和詞幹分析器，並討論 Full-Text Search 如何使用資料行層級語言的語言代碼識別碼 （LCID）。
斷詞符和詞幹分析器簡介
SQL Server 包含完整的斷詞器和詞幹分析器系列。 Microsoft 自然語言群組 （NLG） 會實作並支援這些語言元件。
斷詞工具提供下列優點：
加強性
測試顯示斷詞工具在高壓查詢環境中非常穩健。
安全性
預設情況下，斷詞工具會在 SQL Server 中啟用。 強烈建議對斷詞工具和篩選之類的外部元件進行簽署，以改善 SQL Server 的整體安全性和健全性。 您可以設定全文檢索來確認這些元件是否已簽署，方法如下所示：
EXECUTE sp_fulltext_service 'verify_signature';品質
內部測試表明，斷詞器提供比以前的斷詞器更好的語義質量。 這會增加重新叫用精確度。
大部分語言的文字分隔都已包含在 SQL Server 中而且預設為啟用。
如需 SQL Server 包含斷詞工具和詞幹分析器的語言清單，請參閱 sys.fulltext_languages。
Full-Text Search 如何使用資料行層級語言的名稱
建立全文檢索索引時，您必須針對每個資料行指定有效的語言名稱。 如果語言名稱有效，但 sys.fulltext_languages 型錄視圖未傳回，則 Full-Text 搜尋會回復至相同語言系列中最接近的可用語言名稱 （如果有的話）。 否則，Full-Text 搜尋會回復至「中性斷詞器」。 這種尋求的行為可能會影響重新叫用精確度。 因此，在建立全文檢索索引時，我們強烈建議您針對每個資料行指定有效且可用的語言名稱。
注意
系統會針對適用於全文檢索索引的所有資料類型 (例如 char 或 nchar) 使用 LCID。 如果您將 char、 varchar或 text 類型資料行的排序次序設定為與 LCID 所識別之語言不同的語言設定，在全文檢索索引和查詢這些資料行期間，系統仍然會使用 LCID。
斷詞
文字分隔會針對文字分界 (語言特有) 將索引的文字 Token 化。 因此，不同語言之間的斷詞行為便有所差異。 如果您使用一種語言 ， x來索引數種語言 {x、 y和 z}，則某些行為可能會導致非預期的結果。 例如，破折號 （-） 或逗號 （,） 可能是在一種語言中被丟棄但在另一種語言中不會丟棄的斷詞元素。 此外，由於給定的字詞可能會在不同的語言中以不同方式進行詞幹分析，因此有時可能也會發生非預期的詞幹分析行為。 例如，在英文中，文字分界通常是空白字元或某種形式的標點符號。 在其他語言中，例如德語，單詞或字符可能會組合在一起。 因此，您選擇的直欄層級語言應該代表您預期儲存在該直欄列中的語言。
西方語言
針對西語系列語言，如果您不確定哪些語言將儲存在資料行中，或預期會儲存多個語言，一般因應措施是針對資料行中可能儲存的最複雜語言使用斷詞工具。
例如，您可能希望將英語、西班牙語和德語內容存儲在單個列中。 這三種西方語言具有相似的斷詞模式，其中德語模式最為複雜。 因此，在這個情況下，使用德文斷詞工具是不錯的選擇，因為它能夠正確地處理英文和西班牙文的文字。 相較之下，英文斷詞工具可能無法完美地處理德文的文字，因為德文含有複合字。
使用語系中最複雜語言的斷詞器並不能保證語系中每種語言的完美索引。 可能存在最複雜的斷詞工具無法正確處理以另一種語言編寫的文字的極端情況。
非西方語言
對於非西方語言（例如中文、日語、印地語等），基於語言原因，先前的解決方法不一定有效。 若為非西方語言，請考慮採用下列其中一個解決方法：
不同語系的語言
如果資料行可能包含完全不同的語言 (例如，西班牙文和日文)，請考慮將不同語言的內容儲存在個別的資料行中。 這種分隔將允許您對每個列使用特定於語言的斷詞器。 如果您選擇這種解決方案，但是不知道查詢時所使用的查詢語言，可能就必須針對這兩個資料行發出查詢，以便確保查詢會尋找正確的資料列或文件。
二進位內容 (例如 Microsoft Word 文件)
當索引內容是 二進位 類型時，在將文字內容傳送至斷詞工具之前處理文字內容的 Full-Text 搜尋篩選器可能會接受二進位檔中存在的特定語言標籤。 在此情況下，在編製索引時，篩選會針對文件或文件區段發出正確的 LCID。 然後，Full-Text 引擎會呼叫具有該 LCID 之語言的斷詞工具。 不過，建立多語言內容的索引之後，我們建議您確認是否已正確建立內容的索引。
純文字內容
當您的內容是純文字時，您可以將其轉換成 xml 資料類型，並加入語言標記，以便表示對應至每份特定文件或文件區段的語言。 不過，若要讓此解決方法有用，您必須在建立全文檢索索引之前，了解所使用的語言。
詞幹分析
選擇資料行層級語言時的另一個考量是 詞幹處理。 全文檢索查詢中的詞幹是搜尋特定語言中單字的所有詞幹（屈折）形式的過程。 當您使用一般斷詞工具來處理許多語言時，詞幹分析程序只會針對指定給資料行的語言運作，而不會針對資料行中的其他語言運作。 例如，德語詞幹分析器不適用於英語或西班牙語（等等）。 這可能會影響重新叫用，端視您在查詢時選擇的語言而定。
欄類型對 Full-Text 搜尋的影響
選擇語言時的另一個考量與呈現資料的方式有關。 對於未儲存在 varbinary（max） 資料行中的資料，不會執行特殊篩選。 相反地，文字可以其原始格式傳送，而不會受限於文字分隔元件。
此外，斷詞工具主要設計成處理一般撰寫內容。 因此，如果您的文字上有任何類型的標記（例如 HTML），則在索引和搜尋期間可能無法獲得很高的語言準確性。 在此情況下，您有兩個選擇 - 偏好的方法只是將文字資料儲存在 varbinary（max） 資料行中，並指出其文件類型，以便可以過濾它。 如果這不是一個選項，您可以考慮使用中性斷詞器，並在可能的情況下將標記資料（例如 HTML 中的「br」）新增至雜訊單字清單。
注意
當您指定中性語言時，語言型詞幹分析不會發揮作用。
在全文檢索查詢中指定非預設資料行層級語言
根據預設，在 SQL Server 中，Full-Text Search 會使用全文檢索子句中所包含之每個資料行指定的語言來剖析查詢字詞。 若要覆寫此行為，請在查詢時指定非預設語言。 對於已安裝資源的支援語言， LANGUAGE <language_term> 可以使用 CONTAINS、 CONTAINSTABLE、 FREETEXT 或 FREETEXTTABLE 查詢的子句來指定用於查詢詞彙的斷詞、詞幹、同義字及停用詞處理的語言。