SharePoint Server 2007を使用して、従業員がネットワークファイル共有を検索できるようにしていますが、ファイル名のアンダースコアは、ファイルのインデックス作成時にWordの区切り文字として扱われないようです。
その結果、chocolateを検索すると次のようになります。
(もちろん、これは単純化された例です。実際には、2番目のファイルのcontentには、「chocolate」という単語が含まれている可能性があります。しかし、問題自体は十分に現実的です。企業環境での一般的なシナリオは、ユーザーが探しているファイルの部分的な名前を知っていて、検索結果の上部に一致するファイル名が表示されることを期待しているためです。ファイル名のアンダースコアは、社内で広く使用されている規則です)。
アンダースコアは、ファイルの内容でもWordの区切り文字として扱われませんが、これは私たちにとってはそれほど問題ではありません。この問題の根本的な原因は、SharePointが使用するWordブレーカー(つまり、IWorkBreakerインターフェイスを実装する言語固有のDLL)の動作におそらく関連しています。 、まだ確認していませんが。
この問題の回避策を知っている人はいますか? Search Server 2008 Express(同じテクノロジに基づく)でもテストしましたが、影響も受けます。 SharePoint2010で問題が修正されたかどうかはわかりません。
Wordブレーカーが、ドキュメントの内容とファイル名の両方のアンダースコアの処理を決定することを確認しました。ワードブレーカーは、レジストリで言語ごとに構成されます。
ワードブレーカーはActiveXコントロールとして実装されており、理論的には独自に作成できるはずです(Microsoft Platform SDK for Windows XPには例 "lrsample"が含まれています)が、私にはありませんマイクロソフトが提供する多くのWordブレーカーはすべてアンダースコアをWordの一部として扱っているようですが、アンダースコアで壊れるものを見つけました:簡略化された中国語用のWordブレーカーのバージョン2(chsbrkr .dll-1,677,824バイト)。この動作は、Search Server 2008ExpressおよびおそらくSharePoint2007で提供されるSimplifiedChineseWordブレーカーのバージョン3とは異なることに注意してください。
したがって、必要な検索動作を取得するために、次のWordブレーカーを使用するようにSharePointSearchを構成しました。
"WBDLLPathOverride" = "C:\PROGRA~1\MI54E7~1\12.0\Bin\ChsBrkr2.dll"
(パスが異なる場合があります)および"WBreakerClass" = "{9717fc70-c1bc-11d0-9692-00a0c908146e}"
net stop osearch
を実行してからnet start osearch
を実行します)。アンダースコアを単語区切りとして扱うことを除けば、chsbrkr.dllとデフォルトの英語の単語区切り記号の間に他の重要な違いがあるかどうかはわかりませんが、これまでのところ、問題は発生していません。カスタムWordブレーカーを特定の管理プロパティ(この場合はPath)に適用する方法があれば素晴らしいのですが、これが可能かどうかはわかりません。データベースのMSSManagedPropertiesテーブルに「WordBreakerOverride」という有望な名前の列がありますが、その目的がわかりません。
注: SharePoint 2010では、管理プロパティにSplitStringCharactersと呼ばれる追加の設定があるようです。これにより、この回避策が廃止される可能性があります。