【正文】 個(gè)字符串則匹配成功（識(shí)別出一個(gè)詞）。按照掃描方向的不同，串匹配分詞方法可以分為正向匹配和逆向匹配；按照不同長(zhǎng)度優(yōu)先匹配的情況，可以分為最大（最長(zhǎng)）匹配和最?。ㄗ疃蹋┢ヅ洌话凑帐欠衽c詞性標(biāo)注過程相結(jié)合，又可以分為單純分詞法和分詞與標(biāo)注結(jié)合法。常用的幾種機(jī)械分詞方法如下： 正向最大匹配法（由左 到右的方向） 逆向最大匹配法（由右到左的方向） 分詞器實(shí)現(xiàn) 這個(gè)實(shí)現(xiàn)了機(jī)械分詞中正向最大匹配法的 Lucene 分詞器包括兩個(gè)類， CJKAnalyzer和 CJKTokenizer，他們的源代碼如下： package 。 import 。 import 。 import 。 import 。 import 。 /** * @author solo L * */ public class CJKAnalyzer extends Analyzer {//實(shí)現(xiàn)了 Analyzer 接口，這是 lucene的要求 public final static String[] STOP_WORDS = {}。 private Set stopTable。 public CJKAnalyzer() { stopTable = (STOP_WORDS)。 } @Override public TokenStream tokenStream(String fieldName, Reader reader) { return new StopFilter(new CJKTokenizer(reader), stopTable)。 } } package 。 import 。 import 。 import 。 import 。 import 。 import 。 import 。 import 。 import 。 /** * @author solo L * */ public class CJKTokenizer extends Tokenizer { //這個(gè) TreeMap 用來緩存詞庫 private static TreeMap simWords = null。 private static final int IO_BUFFER_SIZE = 256。 private int bufferIndex = 0。 private int dataLen = 0。 private final char[] ioBuffer = new char[IO_BUFFER_SIZE]。 private String tokenType = word。 public CJKTokenizer(Reader input) { = input。 } //這里是 lucene 分詞器實(shí)現(xiàn)的最關(guān)鍵的地方 public Token next() throws IOException { loadWords()。 StringBuffer currentWord = new StringBuffer()。 while (true) { char c。 ub。 if (bufferIndex = dataLen) { dataLen = (ioBuffer)。 bufferIndex = 0。 } if (dataLen == 1) { if (() == 0) { return null。 } else { break。 } } else { c = ioBuffer[bufferIndex++]。 ub = (c)。 } //通過這個(gè)條件不難看出這里只處理了 CJK_UNIFIED_IDEOGRAPHS， //因此會(huì)丟掉其它的字符，如它會(huì)丟掉 LATIN 字符和數(shù)字 //這也是 該 lucene 分詞器的一個(gè)限制，您可以在此基礎(chǔ)之上完善它， //也很歡迎把您完善的結(jié)果反饋給我 If((c)amp。amp。ub== HS){ tokenType = double。 if (() == 0) { (c)。 } else { //這里實(shí)現(xiàn)了正向最大匹配法 String temp = (() + c).intern()。 if ((temp)) { (c)。 } else { bufferIndex。 break。 } } } } Token token = new Token((), bufferIndex (), bufferIndex, tokenType)。 (0)。 return token。 //裝載詞庫，您必須明白它的邏輯和之所以這樣做的目的，這樣您才能理解正向最大匹配法是如何實(shí)現(xiàn)的 public void loadWords() { if (simWords != null)return。 simWords = new TreeMap()。 try { InputStream words = new FileInputStream()。 BufferedReader in =new BufferedReader(new InputStreamReader(words,UTF8))。 String word = null。 while ((word = ()) != null) { //使得我們可以在詞庫中進(jìn)行必要的注釋 if ((() == 1) amp。amp。 (() 5)) { ((), 1)。 if (() == 3) { if (!((0, 2).intern())) { ((0, 2).intern(), 2)。 } } if (() == 4) { if (!((0, 2).intern())) { ((0, 2).intern(), 2)。 } if (!((0, 3).intern())) { ((0, 3).intern(), 2)。 } } } } ()。 } catch (IOException e) { ()。 } } } 分詞效果 這是我在當(dāng)日的某新聞搞中隨意選的一段話： 此外，巴黎市政府所在地和巴黎兩座體育場(chǎng)會(huì)掛出寫有相同話語的巨幅標(biāo)語，這兩座體育場(chǎng)還安裝了巨大屏幕，以方便巴黎市民和游客觀看決賽。 分詞結(jié)果為： 此外 巴黎 市政府 所在地 和 巴黎 兩座 體育場(chǎng) 會(huì) 掛出 寫有 相同 話語 的 巨幅 標(biāo)語 這 兩座 體育場(chǎng) 還 安裝 了 巨大 屏幕 以 方便 巴黎 市民 和 游客 觀看 決賽 提示 這個(gè) lucene 分詞器還比較脆弱，要想將其用于某類項(xiàng)目中您還需要做一些工作，不過我想這里的 lucene 分詞器會(huì) 成為您很好的起點(diǎn)。 對(duì)于中文來說，全文索引首先還要解決一個(gè)語言分析的問題，對(duì)于英文來說，語句中單詞之間是天然通過空格分開的，但亞洲語言的中日韓文語句中的字是一個(gè)字挨一個(gè)，所有，首先要把語句中按 “ 詞 ” 進(jìn)行索引的話，這個(gè)詞如何切分出來就是一個(gè)很大的問題。 首先，肯定不能用單個(gè)字符作 (sigram)為索引單元，否則查 “ 上海 ” 時(shí)，不能讓含有 “ 海上 ” 也匹配。但一句話： “ 北京天安門 ” ，計(jì)算機(jī)如何按照中文的語言習(xí)慣進(jìn)行切分呢？ “ 北京 天安門 ” 還是 “ 北 京 天安門 ” ？讓計(jì)算機(jī)能夠按照語言習(xí)慣進(jìn)行切分，往往需要機(jī)器有一個(gè) 比較豐富的詞庫才能夠比較準(zhǔn)確的識(shí)別出語句中的單詞。另外一個(gè)解決的辦法是采用自動(dòng)切分算法：將單詞按照 2 元語法 (bigram)方式切分出來，比如： 北京天安門 == 北京 京天 天安 安門 。這樣，在查詢的時(shí)候，無論是查詢 北京 還是查詢 天安門 ，將查詢?cè)~組按同樣的規(guī)則進(jìn)行切分： 北京 ， 天安安門 ，多個(gè)關(guān)鍵詞之間按與 and的關(guān)系組合，同樣能夠正確地映射到相應(yīng)的索引中。這種方式對(duì)于其他亞洲語言：韓文，日文都是通用的。 基于自動(dòng)切分的最大優(yōu)點(diǎn)是沒有詞表維護(hù)成本，實(shí)現(xiàn)簡(jiǎn)單，缺點(diǎn)是索引效率低，但對(duì)于中 小型應(yīng)用來說，基于 2元語法的切分還是夠用的?；?2元切分后的索引一般大小和源文件差不多，而對(duì)于英文，索引文件一般只有原文件的 30%40%不同， 自動(dòng)切分 詞表切分 實(shí)現(xiàn) 實(shí)現(xiàn)非常簡(jiǎn)單 實(shí)現(xiàn)復(fù)雜 查詢 增加了查詢分析的復(fù)雜程度 適于實(shí)現(xiàn)比較復(fù)雜的查詢語法規(guī)則 存儲(chǔ)效率 索引冗余大，索引幾乎和原文一樣大 索引效率高，為原文大小的 30％左右 維護(hù)成本 無詞表維護(hù)成本 詞表維護(hù)成本非常高：中日韓等語言需要分別維護(hù)。 還需要包括詞頻統(tǒng)計(jì)等內(nèi)容 適用領(lǐng)域 嵌入式系統(tǒng)：運(yùn)行環(huán)境資源有限 分布式系統(tǒng)：無詞表同 步問題 對(duì)查詢和存儲(chǔ)效率要求高的專業(yè)搜索引擎 多語言環(huán)境：無詞表維護(hù)成本 Lucene 的索引效率 通常書籍后面常常附關(guān)鍵詞索引表（比如：北京： 12, 34 頁，上海： 3,77 頁 ?? ），它能夠幫助讀者比較快地找到相關(guān)內(nèi)容的頁碼。而數(shù)據(jù)庫索引能夠大大提高查詢的速度原理也是一樣，想像一下通過書后面的索引查找的速度要比一頁一頁地翻內(nèi)容高多少倍 ?? 而索引之所以效率高，另外一個(gè)原因是它是排好序的。對(duì)于檢索系統(tǒng)來說核心是一個(gè)排序問題。 由于數(shù)據(jù)庫索引不是為全文索引設(shè)計(jì)的，因此，使用 like %keyword%時(shí)，數(shù)據(jù)庫索引是不起作用的，在使用 like 查詢時(shí)，搜索過程又變成類似于一頁頁翻書的遍歷過程了，所以對(duì)于含有模糊查詢的數(shù)據(jù)庫服務(wù)來說， LIKE 對(duì)性能的危害是極大的。如果是需要對(duì)多個(gè)關(guān)鍵詞進(jìn)行模糊匹配： like%keyword1% and like %keyword2% ...其效率也就可想而知了。所以建立一個(gè)高效檢索系統(tǒng)的關(guān)鍵是建立一個(gè)類似于科技索引一樣的反向索引機(jī)制，將數(shù)據(jù)源（比如多篇文章）排序順序存儲(chǔ)的同時(shí)，有另外一個(gè)排好序的關(guān)鍵詞列表，用于存儲(chǔ)關(guān)