我们使用SharePoint Server 2007来允许员工searchnetworking文件共享，但似乎文件名中的下划线在索引文件时不被视为字词分隔符。
结果，寻找巧克力将会：
（当然，这是一个简单的例子，实际上第二个文件的内容可能包含单词“巧克力”，而不是文件名，但是问题本身是真实的，因为在公司环境中是用户知道他们正在寻找的文件的部分名称，并期望在search结果的顶部看到匹配的文件名，而在文件名中使用下划线是我们公司内部广泛使用的惯例。
下划线在文件内容中不作为单词分隔符处理，尽pipe这不是我们所关心的问题。 此问题的根本原因可能与SharePoint使用的断字符的行为（即，实现IWorkBreaker接口的特定于语言的DLL）有关，尽pipe我还没有确认这一点。
有谁知道这个问题的解决方法？ 我也使用Search Server 2008 Express（基于相同的技术）进行了testing，并且也受到影响。 我不知道该问题是否在SharePoint 2010中得到解决。
我不认为下划线被视为分隔符，social.technet上的stream量似乎证实了这一点。 如果（既然）是这样的话，你需要一个部分/通配符search来匹配来自'chocolate_cake.doc'的'巧克力'，核心结果web部分将不会这样做。 不过，有一个2007年的Codeplex Web部件就是这么做的。
仅供参考，同一Web部件的2010年版本指出，如果用户input星号，则SharePoint 2010会添加通配符search。
我已经确认，断言器决定了对文档内容和文件名的下划线的处理。 断字符在registry中按照每种语言进行configuration。
Word断路器是作为ActiveX控件实现的，理论上应该可以自己编写（Microsoft Platform SDK for Windows XP包含一个示例“lrsample”），但是我没有手头的工具来执行此操作。 看起来，微软提供的许多破解器都把下划线当作一个单词的一部分，但是我确实发现了一个突破了下划线的单词：简体中文（chsbrkr.dll – 1,677,824字节）的断言器的版本2。 请注意，此行为不同于简体中文分词器（与Search Server 2008 Express一起提供的那个）的版本3，也可能是SharePoint 2007。
所以为了获得我想要的search行为，我已经configurationSharePoint Search来使用这个分词器：
"WBDLLPathOverride" = "C:\PROGRA~1\MI54E7~1\12.0\Bin\ChsBrkr2.dll" （您的path可能不同）和"WBreakerClass" = "{9717fc70-c1bc-11d0-9692-00a0c908146e}" net stop osearch然后net start osearch通过命令行来完成）。 除了将下划线当作单词分隔符之外，我不确定chsbrkr.dll和默认的英语单词分隔符之间是否还有其他明显的区别，但到目前为止，它并没有给我带来任何问题。 如果有一种方法可以将自定义分词器应用于特定的托pipe属性（在这种情况下为path），但是我不知道这是否可行。 在名为“WordBreakerOverride”的数据库的MSSManagedProperties表中有一个很有名的列，但我不知道它的目的是什么。
注意：在SharePoint 2010中，托pipe属性显然有一个名为SplitStringCharacters的附加设置，可能会使此解决方法过时。