一旦在 Solr 架構(gòu)中定義了一個字段類型，并指定了要應(yīng)用于它的分析步驟，則應(yīng)該對其進(jìn)行測試，以確保它的行為按照預(yù)期的方式進(jìn)行。

幸運(yùn)的是，Solr 管理界面中有一個非常方便的頁面，可以讓您做到這一點。您可以調(diào)用分析器的任何文本字段，提供示例輸入，并顯示結(jié)果的令牌流。

例如，讓我們看一下 bin/solr -e techproducts 示例配置中可用的一些 “文本” 字段類型，并使用分析屏幕（http://localhost:8983/solr/#/techproducts/analysis）來比較在索引時為 “運(yùn)行分析器” 的語句生成的令牌如何匹配查詢 “運(yùn)行我的分析儀” 文本

我們可以從 “ text_ws” 開始 - 可用的最簡化的文本字段類型之一：

通過查看每個術(shù)語的開始和結(jié)束位置，我們可以看到這個字段類型所做的唯一的事情是在空白處標(biāo)記文本。注意在這個圖像中，術(shù)語 “Running” 具有0的起始位置和7的結(jié)束位置，而 “an” 具有8的起始位置和10的結(jié)束位置，并且“分析器”從11開始并結(jié)束于19。如果條款之間的空白也包括在內(nèi)，則數(shù)字為21；因為它是19，我們知道空白已經(jīng)從這個查詢中刪除。

還要注意，索引術(shù)語和查詢術(shù)語仍然非常不同。“Running” 不匹配 “run”，“Analyzer” 不匹配 “analyzer”（對電腦），顯然 “an” 和 “my” 是完全不同的話。如果我們的目標(biāo)是允許諸如 “運(yùn)行我的分析器” 這樣的查詢與 “運(yùn)行分析器” 等索引文本相匹配，那么我們顯然需要選擇一個與索引和查詢時間文本分析不同的字段類型，這樣可以對輸入進(jìn)行更多處理。

我們特別希望：

• 不區(qū)分大小寫，所以 “Analyzer” 和 “analyzer” 相匹配。
  
• 詞干，所以像 “Run” 和 “Running” 這樣的詞被認(rèn)為是等同的詞語。
  
• 停止單詞修剪，所以 “an” 和 “my” 這樣的小單詞不會影響查詢。

對于我們的下一個嘗試，讓我們嘗試 “ text_general” 字段類型：

通過啟用詳細(xì)輸出，我們可以看到新分析器的每個階段在將它們傳遞到下一個階段之前如何修改它們所接收到的令牌。當(dāng)我們向下滾動到最后的輸出時，我們可以看到，從 “LCF” 階段開始，我們開始從每個輸入字符串獲得 “analyzer” 的匹配，如果你用鼠標(biāo)懸停，你會看到是 “ LowerCaseFilter”：

“text_general” 字段類型被設(shè)計為通常對任何語言都有用，而且它肯定使我們更接近我們的目標(biāo)，而不是從我們第一個例子中的 "text_ws" 來解決區(qū)分大小寫的問題。這還不是我們正在尋找的東西，因為我們沒有看到正在應(yīng)用的詞干或停用詞規(guī)則。所以現(xiàn)在讓我們試試 “text_en” 字段類型： 

現(xiàn)在我們可以看到分析器的 "SF" (StopFilter) 階段解決了消除停止單詞 ("an") 的問題，當(dāng)我們向下滾動時，我們也看到 “PSF”（PorterStemFilter）階段應(yīng)用適合我們英語的詞干規(guī)則語言輸入，這樣我們的“索引分析器”產(chǎn)生的術(shù)語和我們的“查詢分析器”產(chǎn)生的術(shù)語就與我們期望的方式相匹配。

在這一點上，我們可以繼續(xù)嘗試更多的輸入，驗證我們的分析器在我們期望它們匹配時產(chǎn)生匹配的令牌，當(dāng)我們不期望它們匹配時驗證不同的令牌，因為我們重復(fù)和調(diào)整了我們的字段類型配置。