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

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

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

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

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

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

我們特別希望：

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

對(duì)于我們的下一個(gè)嘗試，讓我們嘗試 “ text_general” 字段類型：

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

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

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

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