- 浏览: 1012999 次
- 性别:
- 来自: 福州
最新评论
-
guanxin2012:
大神,您好。非常感谢您贡献了IKExpression。我们现在 ...
分享开源表达式解析器IK-Expression2.0 -
qqgigas:
LZ,public boolean createUser(LD ...
Sun Directory Server/LDAP学习笔记(二)——API说明及代码样例 -
gao_shengxian:
Hibernate: update T_GX_TEST set ...
优雅Java编程 之 使用Hibernate存储Oracle Spatial对象 -
a78113534:
感谢大神,在安卓里面调用成功了。
发布IK Expression开源表达式解析器 V2.1.0 -
majiedota:
加油
来自开源支持者的第一笔捐赠
新版本改进:
IK Analyzer 2012特性
分词效果示例
IK Analyzer 2012版本支持 细粒度切分 和 智能切分,以下是两种切分方式的演示样例。
文本原文1:
IKAnalyzer是一个开源的,基于java语言开发的轻量级的中文分词工具包。从2006年12月推出1.0版开始, IKAnalyzer已经推出了3个大版本。
智能分词结果:
ikanalyzer | 是 | 一个 | 开源 | 的 | 基于 | java | 语言 | 开发 | 的 | 轻量级 | 的 | 中文 | 分词 | 工具包 | 从 | 2006年 | 12月 | 推出 | 1.0版 | 开始 | ikanalyzer | 已经 | 推 | 出了 | 3个 | 大 | 版本
最细粒度分词结果:
ikanalyzer | 是 | 一个 | 一 | 个 | 开源 | 的 | 基于 | java | 语言 | 开发 | 的 | 轻量级 | 量级 | 的 | 中文 | 分词 | 工具包 | 工具 | 包 | 从 | 2006 | 年 | 12 | 月 | 推出 | 1.0 | 版 | 开始 | ikanalyzer | 已经 | 推出 | 出了 | 3 | 个 | 大 | 版本
文本原文2:
张三说的确实在理
智能分词结果:
张三 | 说的 | 确实 | 在理
最细粒度分词结果:
张三 | 三 | 说的 | 的确 | 的 | 确实 | 实在 | 在理
文本原文3
公路局正在治理解放大道路面积水问题
智能分词结果:
公路局 | 正在 | 治理 | 解放 | 大道 | 路面 | 积水 | 问题
最细粒度分词结果:
公路局 | 公路 | 路局 | 正在 | 治理 | 理解 | 解放 | 放大 | 大道 | 道路 | 路面 | 面积 | 积水 | 问题
文本原文4
据路透社报道,印度尼西亚社会事务部一官员星期二(29日)表示,日惹市附近当地时间27日晨5时53分发生的里氏6.2级地震已经造成至少5427人死亡,20000余人受伤,近20万人无家可归。
智能分词结果:
据 | 路透社 | 报道 | 印度尼西亚 | 社会 | 事务部 | 一 | 官员 | 星期二 | 29日 | 表示 | 日 | 惹 | 市 | 附近 | 当地时间 | 27日 | 晨 | 5时 | 53分 | 发生 | 的 | 里氏 | 6.2级 | 地震 | 已经 | 造成 | 至少 | 5427人 | 死亡 | 20000 | 余人 | 受伤 | 近 | 20 | 万人 | 无家可归
最细粒度分词结果:
据 | 路透社 | 路透 | 社 | 报道 | 印度尼西亚 | 印度 | 尼 | 西亚 | 社会事务 | 社会 | 事务部 | 事务 | 部 | 一 | 官员 | 星期二 | 星期 | 二 | 29 | 日 | 表示 | 日 | 惹 | 市 | 附近 | 当地时间 | 当地 | 时间 | 27 | 日 | 晨 | 5 | 时 | 53 | 分发 | 分 | 发生 | 发 | 生 | 的 | 里氏 | 6.2 | 级 | 地震 | 已经 | 造成 | 至少 | 5427 | 人 | 死亡 | 20000 | 余人 | 受伤 | 近 | 20 | 万人 | 万 | 人 | 无家可归
GoogleCode下载:
http://code.google.com/p/ik-analyzer/downloads/list
新的正向切分技术已经能达到双向切分的标准,而且正向切分速度最快,当然是用正向切分了
double check lock的问题很早之前已经解决了,问题产生的原因是对象的初始化是在主内存中完成,即堆内存,而编译器对代码进行优化,导致未完全初始化的对象引用被其他线程获取到。
在2001年,JVM1.2已经发布好久了.JMM(Java Memory Model)已经已经发布了新的规范,分配空间,初始化,调用构造方法只会在线程的工作存储区完成,在没有向主存储区复制赋值时,其它线程绝对不可能见到这个过程.而这个字段复制到主存区的过程,更不会有分配空间后没有初始化或没有调用构造方法的可能.在JAVA中,一切都是按引用的值复制的.向主存储区同步其实就是把线程工作存储区的这个已经构造好的对象有压缩堆地址值COPY给主存储区的那个变量.这个过程对于其它线程,要么是resource为 null,要么是完整的对象.绝对不会把一个已经分配空间却没有构造好的对象让其它线程可见.
你这个需要在修改IK的词典结构,可以修改DictSegment这个类,把你的词性添加上去,并在分词的结果Lexeme中记录就可以了
我不明白为啥你需要重启solr才生效?!IK的词典是立刻生效的
提醒您,solr/lucene索引一旦建立后,加了新词就必须重新索引了,这个是solr/lucene的索引机制造成的。
IK需要载入27w的词典,词典加分词的内存消耗将近50M,这个分词器从设计理念上讲,并不适用于手机应用,因为从一开始就定位了“用空间换时间”来提高分词效率的思路。
多谢您的及时回复,非常感谢~
IK需要载入27w的词典,词典加分词的内存消耗将近50M,这个分词器从设计理念上讲,并不适用于手机应用,因为从一开始就定位了“用空间换时间”来提高分词效率的思路。
- 支持分词歧义处理
- 支持数量词合并
- 词典支持中英文混合词语,如:Hold住
IK Analyzer 2012特性
- 采用了特有的“正向迭代最细粒度切分算法“,支持细粒度和智能分词两种切分模式;
- 在系统环境:Core2 i7 3.4G双核,4G内存,window 7 64位, Sun JDK 1.6_29 64位 普通pc环境测试,IK2012具有160万字/秒(3000KB/S)的高速处理能力。
- 2012版本的智能分词模式支持简单的分词排歧义处理和数量词合并输出。
- 采用了多子处理器分析模式,支持:英文字母、数字、中文词汇等分词处理,兼容韩文、日文字符
- 优化的词典存储,更小的内存占用。支持用户词典扩展定义。特别的,在2012版本,词典支持中文,英文,数字混合词语。
分词效果示例
IK Analyzer 2012版本支持 细粒度切分 和 智能切分,以下是两种切分方式的演示样例。
文本原文1:
IKAnalyzer是一个开源的,基于java语言开发的轻量级的中文分词工具包。从2006年12月推出1.0版开始, IKAnalyzer已经推出了3个大版本。
智能分词结果:
ikanalyzer | 是 | 一个 | 开源 | 的 | 基于 | java | 语言 | 开发 | 的 | 轻量级 | 的 | 中文 | 分词 | 工具包 | 从 | 2006年 | 12月 | 推出 | 1.0版 | 开始 | ikanalyzer | 已经 | 推 | 出了 | 3个 | 大 | 版本
最细粒度分词结果:
ikanalyzer | 是 | 一个 | 一 | 个 | 开源 | 的 | 基于 | java | 语言 | 开发 | 的 | 轻量级 | 量级 | 的 | 中文 | 分词 | 工具包 | 工具 | 包 | 从 | 2006 | 年 | 12 | 月 | 推出 | 1.0 | 版 | 开始 | ikanalyzer | 已经 | 推出 | 出了 | 3 | 个 | 大 | 版本
文本原文2:
张三说的确实在理
智能分词结果:
张三 | 说的 | 确实 | 在理
最细粒度分词结果:
张三 | 三 | 说的 | 的确 | 的 | 确实 | 实在 | 在理
文本原文3
公路局正在治理解放大道路面积水问题
智能分词结果:
公路局 | 正在 | 治理 | 解放 | 大道 | 路面 | 积水 | 问题
最细粒度分词结果:
公路局 | 公路 | 路局 | 正在 | 治理 | 理解 | 解放 | 放大 | 大道 | 道路 | 路面 | 面积 | 积水 | 问题
文本原文4
据路透社报道,印度尼西亚社会事务部一官员星期二(29日)表示,日惹市附近当地时间27日晨5时53分发生的里氏6.2级地震已经造成至少5427人死亡,20000余人受伤,近20万人无家可归。
智能分词结果:
据 | 路透社 | 报道 | 印度尼西亚 | 社会 | 事务部 | 一 | 官员 | 星期二 | 29日 | 表示 | 日 | 惹 | 市 | 附近 | 当地时间 | 27日 | 晨 | 5时 | 53分 | 发生 | 的 | 里氏 | 6.2级 | 地震 | 已经 | 造成 | 至少 | 5427人 | 死亡 | 20000 | 余人 | 受伤 | 近 | 20 | 万人 | 无家可归
最细粒度分词结果:
据 | 路透社 | 路透 | 社 | 报道 | 印度尼西亚 | 印度 | 尼 | 西亚 | 社会事务 | 社会 | 事务部 | 事务 | 部 | 一 | 官员 | 星期二 | 星期 | 二 | 29 | 日 | 表示 | 日 | 惹 | 市 | 附近 | 当地时间 | 当地 | 时间 | 27 | 日 | 晨 | 5 | 时 | 53 | 分发 | 分 | 发生 | 发 | 生 | 的 | 里氏 | 6.2 | 级 | 地震 | 已经 | 造成 | 至少 | 5427 | 人 | 死亡 | 20000 | 余人 | 受伤 | 近 | 20 | 万人 | 万 | 人 | 无家可归
GoogleCode下载:
http://code.google.com/p/ik-analyzer/downloads/list
评论
59 楼
lection.yu
2012-07-09
请问楼主,经过您测试得出的160万字/秒的数据,是指智能分词还是最细力度分词。
58 楼
lection.yu
2012-07-04
每次看到高人的作品,我都心生敬仰和崇拜。希望自己也能写出这样优秀的作品。
57 楼
linliangyi2007
2012-06-29
bohaiwaiwai 写道
林兄,你好。我刚接触中文分词没多久。就算了解部分吧,但是现在我有个疑问想请教您:
是这样的,中文分词不有 正向切分 ,逆向切分 ,最少切分 和双切分 几类,而它们从准确度上是 正向 《 逆向 《 双向(运用了最小切分) ,所以我的疑问是,为什么ik和mmseg4j等主流分词技术都是用的正向,而不是正确度较高的?请林兄赐教。
是这样的,中文分词不有 正向切分 ,逆向切分 ,最少切分 和双切分 几类,而它们从准确度上是 正向 《 逆向 《 双向(运用了最小切分) ,所以我的疑问是,为什么ik和mmseg4j等主流分词技术都是用的正向,而不是正确度较高的?请林兄赐教。
bohaiwaiwai 写道
林兄,你好。我刚接触中文分词没多久。就算了解部分吧,但是现在我有个疑问想请教您:
是这样的,中文分词不有 正向切分 ,逆向切分 ,最少切分 和双切分 几类,而它们从准确度上是 正向 《 逆向 《 双向(运用了最小切分) ,所以我的疑问是,为什么ik和mmseg4j等主流分词技术都是用的正向,而不是正确度较高的?请林兄赐教。
是这样的,中文分词不有 正向切分 ,逆向切分 ,最少切分 和双切分 几类,而它们从准确度上是 正向 《 逆向 《 双向(运用了最小切分) ,所以我的疑问是,为什么ik和mmseg4j等主流分词技术都是用的正向,而不是正确度较高的?请林兄赐教。
新的正向切分技术已经能达到双向切分的标准,而且正向切分速度最快,当然是用正向切分了
56 楼
bohaiwaiwai
2012-06-27
林兄,你好。我刚接触中文分词没多久。就算了解部分吧,但是现在我有个疑问想请教您:
是这样的,中文分词不有 正向切分 ,逆向切分 ,最少切分 和双切分 几类,而它们从准确度上是 正向 《 逆向 《 双向(运用了最小切分) ,所以我的疑问是,为什么ik和mmseg4j等主流分词技术都是用的正向,而不是正确度较高的?请林兄赐教。
是这样的,中文分词不有 正向切分 ,逆向切分 ,最少切分 和双切分 几类,而它们从准确度上是 正向 《 逆向 《 双向(运用了最小切分) ,所以我的疑问是,为什么ik和mmseg4j等主流分词技术都是用的正向,而不是正确度较高的?请林兄赐教。
55 楼
quicko
2012-06-10
老兄你好,IK有没这个样的功能,我自定义A,B,C 3个字典,分词结束后,我可以知道这个词是在哪个字典里面的?像这样的功能怎么实现,请给个思路,谢谢了...
54 楼
linliangyi2007
2012-05-31
XinYiTian 写道
博主,程序中几个单例的地方用到了double lock check,例如:
public static Dictionary initial(Configuration cfg){
if(singleton == null){
synchronized(Dictionary.class){
if(singleton == null){
singleton = new Dictionary(cfg);
return singleton;
}
}
}
return singleton;
}
private DictSegment[] getChildrenArray(){
if(this.childrenArray == null){
synchronized(this){
if(this.childrenArray == null){
this.childrenArray = new DictSegment[ARRAY_LENGTH_LIMIT];
}
}
}
return this.childrenArray;
}
private Map<Character , DictSegment> getChildrenMap(){
if(this.childrenMap == null){
synchronized(this){
if(this.childrenMap == null){
this.childrenMap = new HashMap<Character , DictSegment>(ARRAY_LENGTH_LIMIT * 2,0.8f);
}
}
}
return this.childrenMap;
}
double lock check已经被证实在java中是错误的做法,希望楼主修正,详情可以google: java double lock check
public static Dictionary initial(Configuration cfg){
if(singleton == null){
synchronized(Dictionary.class){
if(singleton == null){
singleton = new Dictionary(cfg);
return singleton;
}
}
}
return singleton;
}
private DictSegment[] getChildrenArray(){
if(this.childrenArray == null){
synchronized(this){
if(this.childrenArray == null){
this.childrenArray = new DictSegment[ARRAY_LENGTH_LIMIT];
}
}
}
return this.childrenArray;
}
private Map<Character , DictSegment> getChildrenMap(){
if(this.childrenMap == null){
synchronized(this){
if(this.childrenMap == null){
this.childrenMap = new HashMap<Character , DictSegment>(ARRAY_LENGTH_LIMIT * 2,0.8f);
}
}
}
return this.childrenMap;
}
double lock check已经被证实在java中是错误的做法,希望楼主修正,详情可以google: java double lock check
double check lock的问题很早之前已经解决了,问题产生的原因是对象的初始化是在主内存中完成,即堆内存,而编译器对代码进行优化,导致未完全初始化的对象引用被其他线程获取到。
在2001年,JVM1.2已经发布好久了.JMM(Java Memory Model)已经已经发布了新的规范,分配空间,初始化,调用构造方法只会在线程的工作存储区完成,在没有向主存储区复制赋值时,其它线程绝对不可能见到这个过程.而这个字段复制到主存区的过程,更不会有分配空间后没有初始化或没有调用构造方法的可能.在JAVA中,一切都是按引用的值复制的.向主存储区同步其实就是把线程工作存储区的这个已经构造好的对象有压缩堆地址值COPY给主存储区的那个变量.这个过程对于其它线程,要么是resource为 null,要么是完整的对象.绝对不会把一个已经分配空间却没有构造好的对象让其它线程可见.
53 楼
XinYiTian
2012-05-30
博主,程序中几个单例的地方用到了double lock check,例如:
public static Dictionary initial(Configuration cfg){
if(singleton == null){
synchronized(Dictionary.class){
if(singleton == null){
singleton = new Dictionary(cfg);
return singleton;
}
}
}
return singleton;
}
private DictSegment[] getChildrenArray(){
if(this.childrenArray == null){
synchronized(this){
if(this.childrenArray == null){
this.childrenArray = new DictSegment[ARRAY_LENGTH_LIMIT];
}
}
}
return this.childrenArray;
}
private Map<Character , DictSegment> getChildrenMap(){
if(this.childrenMap == null){
synchronized(this){
if(this.childrenMap == null){
this.childrenMap = new HashMap<Character , DictSegment>(ARRAY_LENGTH_LIMIT * 2,0.8f);
}
}
}
return this.childrenMap;
}
double lock check已经被证实在java中是错误的做法,希望楼主修正,详情可以google: java double lock check
public static Dictionary initial(Configuration cfg){
if(singleton == null){
synchronized(Dictionary.class){
if(singleton == null){
singleton = new Dictionary(cfg);
return singleton;
}
}
}
return singleton;
}
private DictSegment[] getChildrenArray(){
if(this.childrenArray == null){
synchronized(this){
if(this.childrenArray == null){
this.childrenArray = new DictSegment[ARRAY_LENGTH_LIMIT];
}
}
}
return this.childrenArray;
}
private Map<Character , DictSegment> getChildrenMap(){
if(this.childrenMap == null){
synchronized(this){
if(this.childrenMap == null){
this.childrenMap = new HashMap<Character , DictSegment>(ARRAY_LENGTH_LIMIT * 2,0.8f);
}
}
}
return this.childrenMap;
}
double lock check已经被证实在java中是错误的做法,希望楼主修正,详情可以google: java double lock check
52 楼
confident_f
2012-05-30
博主,你好,我现在想用这个工具做敏感词的过滤,建立一个敏感词库,直接将文章中的敏感词都高亮出来,请教一下,这个可以怎么实现?另外,能否详细说明一下ik基于词库分词的算法吗?不胜感激
51 楼
codeutil
2012-05-27
http://code.google.com/p/ik-analyzer/
http://linliangyi2007.javaeye.com/
需要更新成
http://linliangyi2007.iteye.com/ 了:)
http://linliangyi2007.javaeye.com/
需要更新成
http://linliangyi2007.iteye.com/ 了:)
50 楼
java_bbs
2012-05-22
IKAnalyzer 2012版本不兼容JDK1.5版本的问题,希望博主能解决一下,修复这个问题应该比较简单的,谢谢,报错信息如下:
java.lang.NoSuchMethodError: java.util.Arrays.binarySearch([Ljava/lang/Object;IILjava/lang/Object;)I
at org.wltea.analyzer.dic.DictSegment.lookforSegment(DictSegment.java:229)
at org.wltea.analyzer.dic.DictSegment.fillSegment(DictSegment.java:199)
at org.wltea.analyzer.dic.DictSegment.fillSegment(DictSegment.java:170)
at org.wltea.analyzer.dic.Dictionary.loadMainDict(Dictionary.java:209)
at org.wltea.analyzer.dic.Dictionary.<init>(Dictionary.java:69)
at org.wltea.analyzer.dic.Dictionary.initial(Dictionary.java:86)
at org.wltea.analyzer.core.IKSegmenter.init(IKSegmenter.java:85)
at org.wltea.analyzer.core.IKSegmenter.<init>(IKSegmenter.java:65)
at org.wltea.analyzer.lucene.IKTokenizer.<init>(IKTokenizer.java:63)
at org.wltea.analyzer.lucene.IKAnalyzer.tokenStream(IKAnalyzer.java:71)
java.lang.NoSuchMethodError: java.util.Arrays.binarySearch([Ljava/lang/Object;IILjava/lang/Object;)I
at org.wltea.analyzer.dic.DictSegment.lookforSegment(DictSegment.java:229)
at org.wltea.analyzer.dic.DictSegment.fillSegment(DictSegment.java:199)
at org.wltea.analyzer.dic.DictSegment.fillSegment(DictSegment.java:170)
at org.wltea.analyzer.dic.Dictionary.loadMainDict(Dictionary.java:209)
at org.wltea.analyzer.dic.Dictionary.<init>(Dictionary.java:69)
at org.wltea.analyzer.dic.Dictionary.initial(Dictionary.java:86)
at org.wltea.analyzer.core.IKSegmenter.init(IKSegmenter.java:85)
at org.wltea.analyzer.core.IKSegmenter.<init>(IKSegmenter.java:65)
at org.wltea.analyzer.lucene.IKTokenizer.<init>(IKTokenizer.java:63)
at org.wltea.analyzer.lucene.IKAnalyzer.tokenStream(IKAnalyzer.java:71)
49 楼
linliangyi2007
2012-05-22
nggno1 写道
博主您好!
刚下载使用了您的开源分词插件,感觉非常好用,感谢您的工作于分享!
使用中有以下需求,不知道在现行版本中如何实现,希望博主能给予指导:
1 我希望定义定义不同种类的词典,以便在分词结束后进行分类知识库检索,例如:
a 网络用语 b 专业术语 c 日常用语 d 基础语言 并设置优先级(即搜索词典的先后顺序)
并在取得分词的同时,获取该词的类型。
比如:
IKSegmenter ik = new IKSegmenter(reader, true);
ik.next();
返回的值中存在(6-9 : 有木有 : CN_WORD: N)其中N表示网络用语。
这样的需求现有API是否能够实现?
如不能,求博主给出代码修改方向,如何实现。
不尽感激,期待您的回复。
刚下载使用了您的开源分词插件,感觉非常好用,感谢您的工作于分享!
使用中有以下需求,不知道在现行版本中如何实现,希望博主能给予指导:
1 我希望定义定义不同种类的词典,以便在分词结束后进行分类知识库检索,例如:
a 网络用语 b 专业术语 c 日常用语 d 基础语言 并设置优先级(即搜索词典的先后顺序)
并在取得分词的同时,获取该词的类型。
比如:
IKSegmenter ik = new IKSegmenter(reader, true);
ik.next();
返回的值中存在(6-9 : 有木有 : CN_WORD: N)其中N表示网络用语。
这样的需求现有API是否能够实现?
如不能,求博主给出代码修改方向,如何实现。
不尽感激,期待您的回复。
你这个需要在修改IK的词典结构,可以修改DictSegment这个类,把你的词性添加上去,并在分词的结果Lexeme中记录就可以了
48 楼
linliangyi2007
2012-05-22
melodyf 写道
想请问一下,我现在是使用solrj进行查询、修改等相关操作,又需要用到IK的自定义词典。但是每次添加完都需要重新启动solr才能生效,有没有办法不重新启动?
我不明白为啥你需要重启solr才生效?!IK的词典是立刻生效的
提醒您,solr/lucene索引一旦建立后,加了新词就必须重新索引了,这个是solr/lucene的索引机制造成的。
47 楼
nggno1
2012-05-21
博主您好!
刚下载使用了您的开源分词插件,感觉非常好用,感谢您的工作于分享!
使用中有以下需求,不知道在现行版本中如何实现,希望博主能给予指导:
1 我希望定义定义不同种类的词典,以便在分词结束后进行分类知识库检索,例如:
a 网络用语 b 专业术语 c 日常用语 d 基础语言 并设置优先级(即搜索词典的先后顺序)
并在取得分词的同时,获取该词的类型。
比如:
IKSegmenter ik = new IKSegmenter(reader, true);
ik.next();
返回的值中存在(6-9 : 有木有 : CN_WORD: N)其中N表示网络用语。
这样的需求现有API是否能够实现?
如不能,求博主给出代码修改方向,如何实现。
不尽感激,期待您的回复。
刚下载使用了您的开源分词插件,感觉非常好用,感谢您的工作于分享!
使用中有以下需求,不知道在现行版本中如何实现,希望博主能给予指导:
1 我希望定义定义不同种类的词典,以便在分词结束后进行分类知识库检索,例如:
a 网络用语 b 专业术语 c 日常用语 d 基础语言 并设置优先级(即搜索词典的先后顺序)
并在取得分词的同时,获取该词的类型。
比如:
IKSegmenter ik = new IKSegmenter(reader, true);
ik.next();
返回的值中存在(6-9 : 有木有 : CN_WORD: N)其中N表示网络用语。
这样的需求现有API是否能够实现?
如不能,求博主给出代码修改方向,如何实现。
不尽感激,期待您的回复。
46 楼
melodyf
2012-05-21
想请问一下,我现在是使用solrj进行查询、修改等相关操作,又需要用到IK的自定义词典。但是每次添加完都需要重新启动solr才能生效,有没有办法不重新启动?
45 楼
happyczx
2012-05-20
感谢您的IK Analyzer,非常不错的一款中文分词库!
但最近将IKAnalyzer 2012_u5版本应用于JDK1.5时发现一个小问题,因为Arrays.binarySearch(Object[], int, int, Object)方法只在JDK1.6及以上版本支持,所以在JDK1.5环境下会报错,报错信息如下:
java.lang.NoSuchMethodError: java.util.Arrays.binarySearch([Ljava/lang/Object;IILjava/lang/Object;)I
at org.wltea.analyzer.dic.DictSegment.lookforSegment(DictSegment.java:229)
at org.wltea.analyzer.dic.DictSegment.fillSegment(DictSegment.java:199)
at org.wltea.analyzer.dic.DictSegment.fillSegment(DictSegment.java:170)
at org.wltea.analyzer.dic.Dictionary.loadMainDict(Dictionary.java:209)
at org.wltea.analyzer.dic.Dictionary.<init>(Dictionary.java:69)
at org.wltea.analyzer.dic.Dictionary.initial(Dictionary.java:86)
at org.wltea.analyzer.core.IKSegmenter.init(IKSegmenter.java:85)
at org.wltea.analyzer.core.IKSegmenter.<init>(IKSegmenter.java:65)
at org.wltea.analyzer.lucene.IKTokenizer.<init>(IKTokenizer.java:63)
at org.wltea.analyzer.lucene.IKAnalyzer.tokenStream(IKAnalyzer.java:71)
但最近将IKAnalyzer 2012_u5版本应用于JDK1.5时发现一个小问题,因为Arrays.binarySearch(Object[], int, int, Object)方法只在JDK1.6及以上版本支持,所以在JDK1.5环境下会报错,报错信息如下:
java.lang.NoSuchMethodError: java.util.Arrays.binarySearch([Ljava/lang/Object;IILjava/lang/Object;)I
at org.wltea.analyzer.dic.DictSegment.lookforSegment(DictSegment.java:229)
at org.wltea.analyzer.dic.DictSegment.fillSegment(DictSegment.java:199)
at org.wltea.analyzer.dic.DictSegment.fillSegment(DictSegment.java:170)
at org.wltea.analyzer.dic.Dictionary.loadMainDict(Dictionary.java:209)
at org.wltea.analyzer.dic.Dictionary.<init>(Dictionary.java:69)
at org.wltea.analyzer.dic.Dictionary.initial(Dictionary.java:86)
at org.wltea.analyzer.core.IKSegmenter.init(IKSegmenter.java:85)
at org.wltea.analyzer.core.IKSegmenter.<init>(IKSegmenter.java:65)
at org.wltea.analyzer.lucene.IKTokenizer.<init>(IKTokenizer.java:63)
at org.wltea.analyzer.lucene.IKAnalyzer.tokenStream(IKAnalyzer.java:71)
44 楼
青春的、脚步
2012-05-18
Hold住
43 楼
tianjing725
2012-05-14
linliangyi2007 写道
tianjing725 写道
你好,非常感谢你的IK开源中文分词。
我将代码移植到Android中,但是,
D/dalvikvm(18677): GC_CONCURRENT freed 233K, 51% free 2783K/5639K, external 598K/1041K, paused 1ms+1ms
D/dalvikvm(18677): GC_CONCURRENT freed 298K, 50% free 3037K/5959K, external
在 TokenStream stream = (TokenStream) ikAnalyzer.tokenStream("", reader);的内存消耗太大,因为都是以调jar的形式,想询问一下产生的原因。
我将代码移植到Android中,但是,
D/dalvikvm(18677): GC_CONCURRENT freed 233K, 51% free 2783K/5639K, external 598K/1041K, paused 1ms+1ms
D/dalvikvm(18677): GC_CONCURRENT freed 298K, 50% free 3037K/5959K, external
在 TokenStream stream = (TokenStream) ikAnalyzer.tokenStream("", reader);的内存消耗太大,因为都是以调jar的形式,想询问一下产生的原因。
IK需要载入27w的词典,词典加分词的内存消耗将近50M,这个分词器从设计理念上讲,并不适用于手机应用,因为从一开始就定位了“用空间换时间”来提高分词效率的思路。
多谢您的及时回复,非常感谢~
42 楼
linliangyi2007
2012-05-11
tianjing725 写道
你好,非常感谢你的IK开源中文分词。
我将代码移植到Android中,但是,
D/dalvikvm(18677): GC_CONCURRENT freed 233K, 51% free 2783K/5639K, external 598K/1041K, paused 1ms+1ms
D/dalvikvm(18677): GC_CONCURRENT freed 298K, 50% free 3037K/5959K, external
在 TokenStream stream = (TokenStream) ikAnalyzer.tokenStream("", reader);的内存消耗太大,因为都是以调jar的形式,想询问一下产生的原因。
我将代码移植到Android中,但是,
D/dalvikvm(18677): GC_CONCURRENT freed 233K, 51% free 2783K/5639K, external 598K/1041K, paused 1ms+1ms
D/dalvikvm(18677): GC_CONCURRENT freed 298K, 50% free 3037K/5959K, external
在 TokenStream stream = (TokenStream) ikAnalyzer.tokenStream("", reader);的内存消耗太大,因为都是以调jar的形式,想询问一下产生的原因。
IK需要载入27w的词典,词典加分词的内存消耗将近50M,这个分词器从设计理念上讲,并不适用于手机应用,因为从一开始就定位了“用空间换时间”来提高分词效率的思路。
41 楼
tianjing725
2012-05-10
你好,非常感谢你的IK开源中文分词。
我将代码移植到Android中,但是,
D/dalvikvm(18677): GC_CONCURRENT freed 233K, 51% free 2783K/5639K, external 598K/1041K, paused 1ms+1ms
D/dalvikvm(18677): GC_CONCURRENT freed 298K, 50% free 3037K/5959K, external 221K/733K, paused 1ms+2ms
D/dalvikvm(18677): GC_CONCURRENT freed 321K, 48% free 3270K/6215K, external 221K/733K, paused 1ms+2ms
D/dalvikvm(18677): GC_CONCURRENT freed 294K, 46% free 3490K/6407K, external 221K/733K, paused 2ms+3ms
D/dalvikvm(18677): GC_CONCURRENT freed 319K, 45% free 3721K/6663K, external 221K/733K, paused 1ms+2ms
D/dalvikvm(18677): GC_CONCURRENT freed 334K, 43% free 3962K/6919K, external 221K/733K, paused 1ms+3ms
D/dalvikvm(18677): GC_CONCURRENT freed 343K, 42% free 4208K/7175K, external 221K/733K, paused 1ms+5ms
D/dalvikvm(18677): GC_CONCURRENT freed 387K, 41% free 4485K/7495K, external 221K/733K, paused 1ms+3ms
D/dalvikvm(18677): GC_CONCURRENT freed 445K, 39% free 4810K/7879K, external 221K/733K, paused 2ms+2ms
D/dalvikvm(18677): GC_CONCURRENT freed 510K, 38% free 5194K/8327K, external 221K/733K, paused 2ms+3ms
D/dalvikvm(18677): GC_CONCURRENT freed 597K, 37% free 5618K/8839K, external 221K/733K, paused 1ms+2ms
D/dalvikvm(18677): GC_CONCURRENT freed 689K, 36% free 6102K/9415K, external 221K/733K, paused 1ms+2ms
D/dalvikvm(18677): GC_CONCURRENT freed 788K, 34% free 6643K/10055K, external 221K/733K, paused 1ms+2ms
D/dalvikvm(18677): GC_CONCURRENT freed 884K, 33% free 7252K/10759K, external 221K/733K, paused 1ms+3ms
D/dalvikvm(18677): GC_CONCURRENT freed 1010K, 32% free 7958K/11591K, external 221K/733K, paused 2ms+3ms
D/dalvikvm(18677): GC_CONCURRENT freed 1123K, 31% free 8740K/12487K, external 221K/733K, paused 1ms+2ms
D/dalvikvm(18677): GC_CONCURRENT freed 1229K, 29% free 9595K/13447K, external 221K/733K, paused 2ms+3ms
D/dalvikvm(18677): GC_CONCURRENT freed 1212K, 27% free 10444K/14279K, external 221K/733K, paused 1ms+4ms
D/dalvikvm(18677): GC_CONCURRENT freed 1248K, 26% free 11290K/15175K, external 221K/733K, paused 1ms+7ms
D/dalvikvm(18677): GC_CONCURRENT freed 1204K, 25% free 12122K/16007K, external 221K/733K, paused 2ms+3ms
D/dalvikvm(18677): GC_CONCURRENT freed 1182K, 24% free 12944K/16839K, external 221K/733K, paused 1ms+2ms
D/dalvikvm(18677): GC_CONCURRENT freed 1170K, 23% free 13760K/17671K, external 221K/733K, paused 2ms+2ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1111K, 22% free 14549K/18439K, external 221K/733K, paused 124ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1154K, 21% free 15322K/19271K, external 221K/733K, paused 135ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1129K, 20% free 16084K/20039K, external 221K/733K, paused 138ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1104K, 19% free 16860K/20807K, external 221K/733K, paused 143ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1084K, 19% free 17627K/21575K, external 221K/733K, paused 149ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1075K, 18% free 18389K/22343K, external 221K/733K, paused 155ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1080K, 18% free 19145K/23111K, external 221K/733K, paused 166ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1091K, 17% free 19892K/23879K, external 221K/733K, paused 171ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1044K, 17% free 20613K/24583K, external 221K/733K, paused 186ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1013K, 16% free 21330K/25287K, external 221K/733K, paused 179ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1039K, 16% free 22070K/26055K, external 221K/733K, paused 208ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1020K, 15% free 22791K/26759K, external 221K/733K, paused 191ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1018K, 15% free 23484K/27463K, external 221K/733K, paused 194ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1025K, 15% free 24181K/28167K, external 221K/733K, paused 200ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1007K, 14% free 24900K/28871K, external 221K/733K, paused 223ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 990K, 14% free 25600K/29575K, external 221K/733K, paused 219ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1005K, 14% free 26297K/30279K, external 221K/733K, paused 222ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1004K, 13% free 26997K/30983K, external 221K/733K, paused 229ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1015K, 13% free 27691K/31687K, external 221K/733K, paused 229ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1014K, 13% free 28393K/32391K, external 221K/733K, paused 240ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1015K, 13% free 29095K/33095K, external 221K/733K, paused 240ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 988K, 12% free 29802K/33799K, external 221K/733K, paused 248ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 992K, 12% free 30502K/34503K, external 221K/733K, paused 254ms
在 TokenStream stream = (TokenStream) ikAnalyzer.tokenStream("", reader);的内存消耗太大,因为都是以调jar的形式,想询问一下产生的原因。
我将代码移植到Android中,但是,
D/dalvikvm(18677): GC_CONCURRENT freed 233K, 51% free 2783K/5639K, external 598K/1041K, paused 1ms+1ms
D/dalvikvm(18677): GC_CONCURRENT freed 298K, 50% free 3037K/5959K, external 221K/733K, paused 1ms+2ms
D/dalvikvm(18677): GC_CONCURRENT freed 321K, 48% free 3270K/6215K, external 221K/733K, paused 1ms+2ms
D/dalvikvm(18677): GC_CONCURRENT freed 294K, 46% free 3490K/6407K, external 221K/733K, paused 2ms+3ms
D/dalvikvm(18677): GC_CONCURRENT freed 319K, 45% free 3721K/6663K, external 221K/733K, paused 1ms+2ms
D/dalvikvm(18677): GC_CONCURRENT freed 334K, 43% free 3962K/6919K, external 221K/733K, paused 1ms+3ms
D/dalvikvm(18677): GC_CONCURRENT freed 343K, 42% free 4208K/7175K, external 221K/733K, paused 1ms+5ms
D/dalvikvm(18677): GC_CONCURRENT freed 387K, 41% free 4485K/7495K, external 221K/733K, paused 1ms+3ms
D/dalvikvm(18677): GC_CONCURRENT freed 445K, 39% free 4810K/7879K, external 221K/733K, paused 2ms+2ms
D/dalvikvm(18677): GC_CONCURRENT freed 510K, 38% free 5194K/8327K, external 221K/733K, paused 2ms+3ms
D/dalvikvm(18677): GC_CONCURRENT freed 597K, 37% free 5618K/8839K, external 221K/733K, paused 1ms+2ms
D/dalvikvm(18677): GC_CONCURRENT freed 689K, 36% free 6102K/9415K, external 221K/733K, paused 1ms+2ms
D/dalvikvm(18677): GC_CONCURRENT freed 788K, 34% free 6643K/10055K, external 221K/733K, paused 1ms+2ms
D/dalvikvm(18677): GC_CONCURRENT freed 884K, 33% free 7252K/10759K, external 221K/733K, paused 1ms+3ms
D/dalvikvm(18677): GC_CONCURRENT freed 1010K, 32% free 7958K/11591K, external 221K/733K, paused 2ms+3ms
D/dalvikvm(18677): GC_CONCURRENT freed 1123K, 31% free 8740K/12487K, external 221K/733K, paused 1ms+2ms
D/dalvikvm(18677): GC_CONCURRENT freed 1229K, 29% free 9595K/13447K, external 221K/733K, paused 2ms+3ms
D/dalvikvm(18677): GC_CONCURRENT freed 1212K, 27% free 10444K/14279K, external 221K/733K, paused 1ms+4ms
D/dalvikvm(18677): GC_CONCURRENT freed 1248K, 26% free 11290K/15175K, external 221K/733K, paused 1ms+7ms
D/dalvikvm(18677): GC_CONCURRENT freed 1204K, 25% free 12122K/16007K, external 221K/733K, paused 2ms+3ms
D/dalvikvm(18677): GC_CONCURRENT freed 1182K, 24% free 12944K/16839K, external 221K/733K, paused 1ms+2ms
D/dalvikvm(18677): GC_CONCURRENT freed 1170K, 23% free 13760K/17671K, external 221K/733K, paused 2ms+2ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1111K, 22% free 14549K/18439K, external 221K/733K, paused 124ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1154K, 21% free 15322K/19271K, external 221K/733K, paused 135ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1129K, 20% free 16084K/20039K, external 221K/733K, paused 138ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1104K, 19% free 16860K/20807K, external 221K/733K, paused 143ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1084K, 19% free 17627K/21575K, external 221K/733K, paused 149ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1075K, 18% free 18389K/22343K, external 221K/733K, paused 155ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1080K, 18% free 19145K/23111K, external 221K/733K, paused 166ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1091K, 17% free 19892K/23879K, external 221K/733K, paused 171ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1044K, 17% free 20613K/24583K, external 221K/733K, paused 186ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1013K, 16% free 21330K/25287K, external 221K/733K, paused 179ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1039K, 16% free 22070K/26055K, external 221K/733K, paused 208ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1020K, 15% free 22791K/26759K, external 221K/733K, paused 191ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1018K, 15% free 23484K/27463K, external 221K/733K, paused 194ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1025K, 15% free 24181K/28167K, external 221K/733K, paused 200ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1007K, 14% free 24900K/28871K, external 221K/733K, paused 223ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 990K, 14% free 25600K/29575K, external 221K/733K, paused 219ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1005K, 14% free 26297K/30279K, external 221K/733K, paused 222ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1004K, 13% free 26997K/30983K, external 221K/733K, paused 229ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1015K, 13% free 27691K/31687K, external 221K/733K, paused 229ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1014K, 13% free 28393K/32391K, external 221K/733K, paused 240ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 1015K, 13% free 29095K/33095K, external 221K/733K, paused 240ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 988K, 12% free 29802K/33799K, external 221K/733K, paused 248ms
D/dalvikvm(18677): GC_FOR_MALLOC freed 992K, 12% free 30502K/34503K, external 221K/733K, paused 254ms
在 TokenStream stream = (TokenStream) ikAnalyzer.tokenStream("", reader);的内存消耗太大,因为都是以调jar的形式,想询问一下产生的原因。
40 楼
chick56
2012-05-09
解决了. 果然是这样, 谢谢.
一般中文应该是长词的意思比短词更具体, 所以长词应该优先匹配吧.
这种短词匹配不上的情况应该没什么影响吧. 呵呵.
一般中文应该是长词的意思比短词更具体, 所以长词应该优先匹配吧.
这种短词匹配不上的情况应该没什么影响吧. 呵呵.
发表评论
-
来自开源支持者的第一笔捐赠
2013-01-09 21:15 57812013年1月9号,一个平凡而又不平常的日子! IK中文分词 ... -
发布 IK Analyzer 2012 FF 版本
2012-10-23 17:50 25081首先感谢大家对IK分词器的关注。 最近一段时间正式公司事务最 ... -
CSDN发生严重用户账号泄密事件
2011-12-21 19:21 2566之前有在CSDN注册过的兄弟们,注意了。。。 如果你的邮箱, ... -
一个隐形的java int溢出
2011-08-30 09:44 7560故事的背景: 笔者最近在做一个类SNS的项目,其中 ... -
雷军 :互联网创业的葵花宝典
2011-05-04 10:35 3596博主评: 这片博客很短 ... -
Luci-mint站内搜索实测
2011-04-02 16:18 4141关于Luci-mint 服务器硬 ... -
发布 IK Analyzer 3.2.8 for Lucene3.X
2011-03-04 17:49 14255IK Analyzer 3.2.8版本修订 ... -
TIPS - XML CDATA中的非法字符处理
2011-02-17 15:03 3305XML解析过程中,常遇见CDATA中存在非法字符,尤其在火星文 ... -
对Cassandra的初体验
2010-10-13 17:58 9137作为“云计算”时代的架构设计人员而言,不懂K-V库会被 ... -
Spring + iBatis 的多库横向切分简易解决思路
2010-10-11 13:43 93561.引言 笔者最近在做一个互联网的“类SNS”应用,应用 ... -
发布 IK Analyzer 3.2.5 稳定版 for Lucene3.0
2010-09-08 14:43 5823新版本IKAnnlyzer3.2.8已发布! 地址: http ... -
关于Lucene3.0.1 QueryParser的一个错误
2010-05-21 21:33 2129表达式1: 引用 id:"1231231" ... -
发布 IK Analyzer 3.2.3 稳定版 for Lucene3.0
2010-05-15 14:13 6719IK Analyzer 3.2.3版本修订 在3.2.0版 ... -
windows平台上的nginx使用
2010-01-28 17:13 3406转载自:http://nginx.org/en/docs/wi ... -
发布IKAnnlyzer3.2.0稳定版 for Lucene3.0
2009-12-07 09:27 9580最新3.2.5版本已经推出,http://linliangyi ... -
在Tomcat下以JNDI方式发布JbossCache
2009-12-04 10:57 3831前言: 看过JbossCache的开发手册,发现在Jb ... -
Spring AOP小例子
2009-11-16 10:35 3405PS: 要注明一下,这个是转载滴,之前漏了说鸟,汗死 这里给 ... -
ActiveMQ 5.X 与 Tomcat 集成一(JNDI部署)
2009-11-10 15:15 5650原文地址:http://activemq.apache.org ... -
发布IKAnalyzer中文分词器V3.1.6GA
2009-11-08 23:10 11858IKAnalyzer3.2.0稳定版已经发布,支持Lucene ... -
设计模式感悟
2009-11-07 17:57 3696最近又把以前学习的模式过了一遍,感觉模式不是学出来的,是悟出来 ...
相关推荐
2. IKAnalyzer2012.jar(主jar包) 3. IKAnalyzer.cfg.xml(分词器扩展配置文件) 4. stopword.dic(停止词典) 5. LICENSE.TXT ; NOTICE.TXT (apache版权申明) 它的安装部署十分简单,将 IKAnalyzer2012.jar ...
标题中的"IKAnalyzer2012FF_hf1.zip"指的是IK Analyzer的2012年最终版(Final)的高频率更新1(Hot Fix 1)。IK Analyzer是一款开源的、基于Java语言开发的轻量级中文分词器,主要用于Java环境下对中文文本的分词...
IKAnalyzer2012_u6中文分词器jar包 IKAnalyzer2012_u6中文分词器jar包 IKAnalyzer2012_u6中文分词器jar包 IKAnalyzer2012_u6中文分词器jar包 IKAnalyzer2012_u6中文分词器jar包
"2012FF_hf1.7z" 是IK Analyzer的一个特定版本,可能包含了优化和改进,适应了2012年及之后的技术需求。 在Solr中,分词器扮演着至关重要的角色。它们负责将输入的中文文本分解成一系列的词汇单元,这些单元通常被...
IKAnalyzer2012_u6中文分词器以及手册正式版 Mode LastWriteTime Length Name ---- ------------- ------ ---- d----- 2017/10/29 1:41 doc -a---- 2017/10/29 1:41 414 IKAnalyzer.cfg.xml -a---- 2017/10/29 1...
IKAnalyzer2012.jar 中文分词包
IKanalyzer2012是一款基于Java语言的开源中文分词器,主要用于处理中文文本的分词任务。在中文搜索引擎和自然语言处理领域,分词是基础且关键的一环,因为中文没有明显的空格来区分词汇,需要通过特定的算法进行切分...
使用IK分词器,应为该集群使用到的solr版本为4.10.3-cdh5.7.5,所以使用的 IK 包为IKAnalyzer2012FF_u1.jar,如果是3x的solr,使用IKAnalyzer2012_u6.jar solr-4.10.3下载地址:...
IKAnalyzer2012FF_u1.jar 是一款广泛应用于Java环境中的中文分词库,尤其在搜索引擎和文本分析领域有着重要的应用。这个jar包包含了IK Analyzer的最新版本,即2012FF_u1更新版,它是一款开源的、高性能的中文分词...
IKAnalyzer2012是一个专为中文处理设计的开源分词工具,主要应用于搜索引擎、文本分析和信息检索等领域。这个工具包的核心是IKAnalyzer2012.jar文件,它包含了IK Analyzer的所有功能和实现,是一个Java编写的库,...
标题提到的 "IK Analyzer 2012FF_hf1" 和 "IKAnalyzer2012_u6" 都是该分词器的不同版本。 IK Analyzer 2012FF_hf1 是2012年发布的HotFix 1更新版,"FF" 可能代表 "Final Fix",意味着这是对之前版本的最终修复,而 ...
IKAnalyzer2012_u6是一款基于Java语言开发的全文检索分析器,主要应用于中文信息处理,如搜索引擎、文本挖掘等场景。这个版本是u6更新,意味着它是IKAnalyzer的一个升级版,修复了前一版本可能存在的问题,并可能...
解决lucene4.0与IKAnalyzer的冲突。解决Exception in thread "main" java.lang.VerifyError: class org.wltea.analyzer.lucene.IKAnalyzer overrides final method ...本资源包含了IKAnalyzer2012_FF_hf1.jar及源码
这个“IKAnalyzer2012.jar.zip”压缩包包含了IKAnalyzer的两个不同版本的jar包,分别是IKAnalyzer2012.jar和IKAnalyzer2012FF_u1.jar。 1. **IKAnalyzer简介** - IKAnalyzer是由国人开发的一款高性能的中文分词...
2012FF_hf1 版本是IK Analyzer的一个特定版本,HF1代表Hot Fix 1,即该版本是对2012FF版本的小幅修正版。 IK Analyzer 2012FF_hf1 版本在原有的基础上进行了性能优化和错误修复,确保了其在处理中文文本时的准确性...
IK Analyzer 2012 IKAnalyzer2012_u3 IK Analyzer 2012 IKAnalyzer2012_u3 IK Analyzer 2012 IKAnalyzer2012_u3
ikanalyzer2012ff_u1 是一个专为Solr 4.10.3版本设计的IK分词器插件。在中文信息检索和文本分析领域,分词器扮演着至关重要的角色,它能够将连续的汉字序列切分成具有语义意义的词语单元,便于后续的索引和查询操作...
从 2006年 12 月推出 1.0 版开始,IKAnalyzer 已经推出了 4 个大版本。最初,它是以开源项目Luence为应用主体的,结合词典分词和文法分析算法的中文分词组件。从 3.0 版本开始,IK 发展为面向 Java 的公用分词组件,...