ファイルや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とは別の経路なので、そちらの文字化けにはデータストア側の設定確認が必要です。