FessのCSV・JSON取り込みで件数不足と文字化けの原因を探す

CSVやJSONの取り込みが完了しても、検索文書が少ない、あるいは本文が文字化けしていることがあります。データストアプラグインに、これまで気付きにくかった入力の問題をログへ出す修正がマージされました。

CSVの置換文字と閉じ忘れた引用符

CSVデータストアのfile_encodingの初期値はUTF-8です。指定した文字コードで解釈できないバイトがあると、デコーダーはU+FFFDという置換文字へ置き換えて取り込みを続けます。修正後は、該当レコード数、最初の行、ファイル、文字コード、設定名をWARNで知らせます。セルの内容はログへ出しません。

たとえば元ファイルがWindows-31Jなら、その文字コードであることを確認した上でデータストアのパラメーターを指定します。

file_encoding=Windows-31J

これは設定例です。実際の文字コードがUTF-8のファイルへ一律に指定しないでください。ファイル内に本物のU+FFFDが含まれている場合も警告対象となるため、警告だけで文字コード違いと断定できません。

引用符を閉じ忘れたCSVでは、後続の複数行が一つのフィールドとして読まれ、文書数が減ることがあります。修正後はファイル終端の引用状態を確認し、WARNに加えて「ファイル:行」の失敗URLを登録します。引用符を扱う初期値はquote_disabled=falseで、trueにした場合はこの検出を行いません。すべてのCSV構文誤りを検出する仕組みではありません。

JSONのroot_pathを実データと照合する

JSONデータストアのroot_pathは初期値では未指定です。ネストした配列を選ぶ場合は、JSON Pointerで指定します。

root_path=/data/items
{"data":{"items":[{"id":"1"},{"id":"2"}]}}

この例でitemzと誤記すると、従来は文書0件で何も知らせず終わっていました。修正後は、空ではないJSONのどこにも指定箇所がないとき、ソースごとにWARNを出します。JSON本文は出力しません。初期値のformat=autoよりroot_pathが優先されます。

正しく空配列に一致した場合と、入力文書そのものが空の場合は警告しません。複数ソースの一部にだけ項目がない運用もあるため、この警告は失敗URLを作りません。

警告は入力データを直す手掛かり

どちらの修正も、取り込まれる文書の結果を自動補正するものではありません。ログと失敗URLで箇所を絞り、文字コード、引用符、JSON構造を直してから再クロールします。既存文書の修復や欠落した行の再登録は別途確認が必要です。

関連PR

FessのLDAP連携でRoleのOU判定と日本語グループ名を確認する

LDAP連携を更新するときは、ログインできるかだけでなく、どのグループ・ロールを受け取ったかも確認したいところです。FessのPR #3690・#3691はマージ済みで、ネストしたグループの検索とOUの判定を修正します。

OU名の前方一致に依存しない

これまではDNの文字列にou=roleが含まれると、グループをロールとして扱っていました。修正後はDNを解析し、いずれかのOUがRoleまたはRolesと完全一致する場合にロールと判断します。大文字小文字は区別しません。OU=Roles-RequestsやOU=RoleOwnersは対象にならず、不正なDNはグループとして扱います。

authentication.admin.rolesの初期値はadminです。たとえばadminという名前が同じでも、グループと管理ロールでは意味が異なります。従来の部分一致に依存したディレクトリー構成では、更新後に必要なロールが付かなくなるため、Role・RolesのOUへ配置するか、権限マッピングを見直します。

ldap.role.search.user.enabled・ldap.role.search.group.enabled・ldap.role.search.role.enabledの初期値はいずれもtrueです。既存の有効・無効フラグは引き続き適用され、この修正のための新しいスイッチはありません。

エスケープ付きDNとネストしたグループ

memberOfから得たDNをldap.group.filterへ埋め込むとき、LDAPフィルターの値としてエスケープするようになります。カンマを含むCNなどでは、DNとしてのエスケープと検索フィルターとしてのエスケープが別に必要だからです。既存DNを手作業で二重エスケープする手順ではありません。

更新時は通常のグループに加え、カンマなどを含む名称とネストしたグループを使い、ログイン後に期待した検索対象が見えることを確認します。従来取得できていなかった上位グループが取得される場合もあるため、付与する権限も併せて確認します。

日本語・絵文字を含む名前は別の修正案

PR #3698は、管理画面やLDAPログインがURL-safe Base64で保存したグループ・ロールIDを、ユーザー情報の読み取り側でも同じ形式として扱う提案です。標準Base64の+・/も読み取れる形に変換してからデコードします。

関連PR

FessのファイルクロールでCSVとHTMLの文字化けを減らす

ファイルやSMBから取得したShift_JIS・EUC-JPのCSVや、文字コードを宣言していないHTMLが、検索結果で文字化けする問題への修正がマージされました。HTTPヘッダーのcharset対応とは別に、抽出時にファイルのバイト列から文字コードを推定する変更です。

UTF-8という初期値をヒントとして扱う

ファイル系クライアントは、通常UTF-8をcharsetとして報告します。従来のCSV抽出はこれを実際の文字コードとして使い、宣言のないHTMLもUTF-8へフォールバックしていました。テキストファイルを扱うTikaでは推定が働いていても、CSVやHTMLでは同じ結果にならなかった理由です。

修正後のCSV抽出では、BOMがなければ指定charsetをヒントに、先頭16 KiBから文字コードを推定します。HTMLでもBOMや文字コード宣言がないときに推定を行います。BOMとHTMLのmeta charsetは引き続き優先されます。XML抽出の既定動作は変わりません。

対象ファイルで小さく再クロールする

利用には修正を含むCrawlerライブラリーを組み込んだFessが必要です。設定を一つ追加して旧版の推定機能を有効にする変更ではありません。

まず問題のCSV・HTMLについて実際の文字コードとBOM・meta指定を確認し、少数のファイルで再クロールしてタイトルと本文を照合します。すでに文字化けした検索文書は、修正版を配置しただけでは書き換わらないため、本文を再取得する必要があります。

推定にも限界がある

短い日本語テキストなど、情報が不足する場合は指定charsetのヒントに依存します。ASCIIだけの検査データでは推定値を返さず、呼び出し側のcharsetを維持します。常に正解を選ぶ機能ではありません。

ファイル系クライアントのcharsetはURLエンコードやキャッシュ表示にも使われるため、今回その初期値は変更していません。Markdown抽出も対象外です。データストアのCSV取り込みで指定するfile_encodingとは別の経路なので、そちらの文字化けにはデータストア側の設定確認が必要です。

関連PR