2019年6月29日土曜日

NotesHTTPRequest の get メソッドで Type mismatch(後編)

前のエントリでは NotesHTTPRequest の get メソッドを実行し、その戻り値を NotesJSONNavigator クラスへ直接セットしたとき Type mismatch とメッセージが表示されることがあり、そうなる場合の可能性として
  • Content-Type が application/json ではなく text/plain であること
を指摘しました。

その点について、今回は node.js を使って検証してみようと思います。

node.js とは JavaScript の実行環境です。非常に簡単に web アプリを実装できます(レベル感はそれぞれと思いますが)。
私は自宅の Windows 10 に node.js をインストールしており、近い将来 AppDev pack について学習する準備を整えようとしていて、一冊の node.js の入門書を終えたところです。

ですので node.js とその周辺技術についてはほぼほぼ初心者であることを予めお伝えします。また express のインストールなど詳細は省きます。ボロがでますので。

今回、検証用に用意した node.js  側のアプリ app.js のコードは次のとおりです。
const app = require('express')();
const http = require('http').Server(app);

http.listen(3000, () => console.log('Server started'))

app.get('/', function(req, res) {
    var content = [{
        "short": "下丸子図書館 ",
        "address": "東京都大田区下丸子二丁目18番11号",
    }];

    // パターン1:JSONを文字列に変換
    res.json(content);

    // パターン2:Content-Type が application/json
    //res.writeHead(200, {'Content-Type': 'application/json; charset=utf-8'});
    //res.write(JSON.stringify(content));
    //res.end()

    // パターン3:Content-Type が text/plain
    //res.writeHead(200, {'Content-Type': 'text/plain; charset=utf-8'});
    //res.write(JSON.stringify(content));
    //res.end()
})

自宅のパソコンに Notes クライアントと node.js を同居させています。
app.js の実行中に、localhost のポート 3000 番にアクセスすると JSON (あるいはそれっぽいもの)を返します。

JSON のデータは変数 content にある JSON 文字列を元に3パターン用意しています。パターンの切替は、コードの行頭にある // の削除、あるいは行頭へ // を追加しています。
  1. JSONを文字列に変換して返す
  2. JSONを文字列に変換して Content-Type に application/json を指定して返す
  3. JSONを文字列に変換して Content-Type に text/plain を指定して返す


そしてNotesクライアントで実行するエージェントは、前回使用したコードの "url =" の部分を "http://localhost:3000" に書き換えたものになります。


さて結論から言うと、この3つのパターンのうち3番目だけ Type mismatch が発生しました。

パターン1 には Content-Type を指定していませんが、Notes クライアントでレスポンスヘッダーを見ると application/json になっていました。

つまり、パターン1とパターン2のように、レスポンスヘッダーの Content-Type が application/json の場合、Type mismatch とならなかったことがわかりました。

なお文字列中の改行については、パターン2とパターン3で JSON.stringify(content, null, 2) として改行を含んだ文字列にしましたがが、結果に変化はみられませんでした。

もし、NotesHTTPRequest の get メソッドで Type mismatch となった場合、レスポンスヘッダーにある Content-Type を確認してみてはいかがでしょうか。

NotesHTTPRequest の get メソッドで Type mismatch(前編)

10.0.1 の FP2 で拡張された NotesHTTPRequest のプロパティと NotesJSONNavigator を試しました。

概要は、次の Technical Blog Post にあります。
Limitations of NotesHTTPRequest and NotesJSONNavigator with future considerations

FP2 では NotesHTTPRequest に新たに2つのプロパティ(PreferUTF8 と PreferJSONNavigator)を含むのだとか。

ありがたいことに、私が使用する Community 版にも FP2 が提供されていますので適用してみたところ、Designer でコードをタイピングしたときに追加されたプロパティも表示されることを確認できました。


これらのプロパティについて2019年6月末時点では Knowledecenter を検索してもヒットしませんし、上の画像のように説明もほぼありません。 詳しいことは分かりませんが、さっそく試してみることにします。

先の Technical Blog Post には、FP2より前とFP2のコードが紹介されており、 NotesHTTPRequest の戻り値から直接 NotesJSONNavigator クラスのインスタンスを作るには、事前に PreferJSONNavigator プロパティに 1 をセットしておく、と読めます。

そこで、次の鬼わかの記事でも利用している郵便番号検索サイトで試してみました。

連載 Domino V10 アプリ開発 #鬼わか 解説
第 6 回「NotesからREST APIを呼んで郵便番号検索をしてみよう #鬼わか 解説」

試したエージェントのコードは次のとおりです。
Option Public
Option Declare

Dim ss As NotesSession
Sub Initialize
 Dim jsonNav As NotesJSONNavigator
 Dim url$
 Set ss = New NotesSession
 url = "http://zipcloud.ibsnet.co.jp/api/search?zipcode=8480001"
 Set jsonNav = getJSON(url)
End Sub
Function getJSON(url$) As NotesJSONNavigator
 Dim http As NotesHTTPRequest
 Set http = ss.CreateHTTPRequest()

 http.Preferjsonnavigator = True
 Set getJSON = http.Get(url)
End Function

エージェントを実行すると、下から2行目で Type mismatch と出ます。


上のデバッグ・ウィンドウをよく見ると、レスポンスコードが 200 となっているので、検索結果は戻ってきているようです。ただし NotesJSONNavigator のインスタンスが作れていません。

ひょっとして body が JSON 形式じゃないのかも?

と考え、 notes.ini へ次の1行を追加して、console.log に記録されるデバッグ情報をみてみることにしました。

DEBUG_NOTESHTTPREQUEST=1 

すると、気になる点が2つありました。まず、レスポンスヘッダーの Content-Type が application/json ではなく text/plain でした。

LSXBE HTTP debug information type: HTTP Response header:
Content-Type: text/plain;charset=utf-8

もうひとつは data に改行が含まれていることです。

LSXBE HTTP debug information type: HTTP Response header:  
 Content-Type: text/plain;charset=utf-8
 
LSXBE HTTP debug information type: HTTP Response data:  
 "message": null,
 "results": [
  {
   "address1": "o¢ET│Ct£i",
   "address2": "o-eoccUciOce",
   "address3": "Oiuμ│oOnUto-UciμRi",
   "kana1": "´¢-´¢A´\×´¢-´\O",
   "kana2": "´¢-´\A´\y´¢-",
   "kana3": "´\E´\a´\E´\e´\C´\u´¢≪´¢│´¢-´\×´¢!´¢│´\e´\×´¢-",

ひょっとするとこれらが type mismatch の原因なのかも。


そこで、郵便番号検索とは別のサービス、カーリルさんの図書館APIを試してみることに。
上のコードの "url = " で渡す値を次のように書き換えます。

"http://api.calil.jp/library?appkey=[あなたのアプリキー]&city=大田区&format=json&callback="
※実際のコードへ設定する場合、アプリキーと、"大田区"の文字列はURLエンコードが必要です

実行してみたところ、エラーにならず NotesJSONNavigator クラスのインスタンスが作成できました。


このときのデバッグ情報は、レスポンスヘッダーの Content-Type は application/json であることに加え、data は 2つにわかれてはいるものの改行は含まれていないように見えました。

LSXBE HTTP debug information type: HTTP Response header:  
 Content-Type: application/json; charset=utf-8

LSXBE HTTP debug information type: HTTP Response data:  
[{"category": "MEDIUM", "city": "Onoto-Oi-", "short": "ocioccO!EOo│μocUn- ", "tel": "03-3759-2454", "pref": "μO-o--Ua¢", "faid": null, "geocode": "139.6880403,35.5658561", "systemid": "Tokyo_Ota", "address": "μO-o--Ua¢Onoto-Oi-ocioccO!Eo-iocuto≪18to¬11OAA
LSXBE HTTP debug information type: HTTP Response data:  
to¬14OAA Onoμu≪TncOEeμu¢T-!OaoOa-LuzOnoμu≪Oaa", "libid": "109666", "libkey": "OaNμu-o-oOo│μocUn-", "post": "143-0016", "url_pc": "http://www.lib.city.ota.tokyo.jp/", "systemname": "μO-o--Ua¢Onoto-Oi-", "isil": "JP-1000983", "formal": "Onoto-Oi-t-iOaNμu-o-

これだけでは断定できませんが、可能性のひとつかもしれません。

次のエントリでは、 node.js を使って検証してみようと思います。

2019年6月14日金曜日

NRPC 通信を記録してアプリの遅さを見てみた

昨日は会社帰りに「のの会」へ参加しました。

今回の目玉は、アクセル社の岡本さんが参加された、欧州で主催されたNotes/Domino関係のイベント engage のフィードバックです。

DMA と V11 の話題が盛りだくさんでした。

個人的に気になったポイントを挙げるとすれば次のとおりです。
・画面遷移の順序をフレームに指定できる拡張
・スマートフォンでビューの列を非表示にできる拡張
・標準テンプレートのDMA対応
・DAOSの2次ストレージとして Amazon S3 等のサービスを利用可能に


なお、来週開催の テクてくLotus技術者夜会も engage のフィードバックがあります。


さて、今回の「のの会」での私の発表ですが、その内容についてはアイキャッチ画像にある「ザ・ビュー」というテーマとは少し外れたものになってしまいました...

Notes クライアントから Domino サーバーへのNRPC通信した記録を取得して、NRPCコマンドごとに要する時間をみる方法についてご紹介しました。

Slideshareへアップした資料をリンクしておきます。
この資料では、主にビュー参照のパフォーマンス改善について触れていますので、どうかお許しくださいませ。

会場では、実際に「遅さ」を体感するデモを行い、その時に取得できる NRPC のログから経過時間の長いNRPCコマンドを探りました。

PCに Domino と Notes を同居させているためネットワーク通信にかかる時間はほぼ無いのですが、それでも遅さを感じることができるデモでした。

もしご自身のNotesデータベースが遅いと感じたときに試してみてはいかがでしょうか。

2019年6月6日木曜日

10.0.1 FP2 で可能になったこと

5月のおわりに Notes/Domino 10.0.1 の FP2 がリリースされました。


詳細は リリースノート や FixList をご覧いただくとして、このリリースには日本人にとって必要とはいえないまでも重要な修正がいくつか含まれています。

ひとつは新元号「令和」への対応です。
Notes/Domino の新元号対応

9.0.1 では既に対応済みでしたが 10.0.1 は令和になって約1ヶ月ものあいだ新元号に対応できていなかったわけです。FP2 でようやく「令和」を表示できるようになりました。しかしながら上のガイドによると 10.0.1 で和暦を表示するには少し注意点もあるようです。

なお、私のように趣味で Community Edition を使っている環境では「Notes 10.0.1 の日本語版」や「Domino 10.0.1 Language Pack 日本語版」をダウンロードする術が無く...FP2 だけでは新元号「令和」を表示することができません。


さて、次は DQL への対応です。

FixList を "DQL" で検索してみたところ、FP2 では11の修正があったようです。

実はこれまでの DQL にはクエリーの日本語を正しく処理できない不具合がありました。そしてこの不具合は FP2 で修正予定と聞いていたのです。
そして FP2 リリースと聞いて FixList を確認したのですがそれらしい記載がないため延期かと勝手にあきらめていたのですが、いざ FP2 を適用してみたら不具合は解消していたのです!

なにはともあれ日本語が検索できるようになったということで、日本における DQL の歴史はやっとスタート地点に立ったわけです。(少々大袈裟ですね...)

なお、DQL Explorer でも日本語が検索できました。



ところで DQL といえば、ほかにもに気になっていたことがありました。

それは LotusScript で NotesDominoQuery クラスを使って大量の文書あるいはビューエントリをスキャンする際の制限を緩和するために指定するプロパティ( MaxScanDocsMaxScanEntries )が Integer 型だったことです。デフォルトが20万のところ、Integer 型では 3万あまりしか指定できず、これでは緩和どころかさらに制限する向きにしか使えません。これが FP2 では Long 型に修正され、21億あたりまで拡張できるようになりました。こちらはオンラインヘルプも Integer から Long に変更されていました。


このほか(まだ未確認ですが) NotesHTTPRequest と NotesJSONNavigator がパワーアップしているようですし、CORS のサポートなどあるようです。

もう少し遊んでみたいと思っています。

2019年6月1日土曜日

ZIPファイルも全文検索にヒットしました。ところが...

先日のノーツコンソーシアムの「ザ・ノーツ研究会」では、V10の新機能について検証するというテーマで、各チームに分かれ取り組みました。

そこで私が検証に取り組んだ機能が成功しないまま時間切れとなり、少々悔しい思いをしました。

そこで今回は、自宅で再検証した結果について書こうと思います。

成功しなかった機能とは、
zipファイルが全文検索できる
というものです。

ところで Notes/Domino の V10 で変わったことのひとつに、全文索引に添付ファイルを含める際に使われる、添付ファイルからテキストを抽出する仕組み(Conversion Filter)があります。

9.0.1 までは Conversion Filter に KeyView を使用していましたが、V10 ではこれが使えなくなりました。
KeyView に代わる Conversion Filter として V10 では Apache Tika 1.18 が使用されます。

余談ですが、世の中の文書検索システムで用いられている Conversion Filter (Converter) にはいろいろあるようです。
  • KeyView (HP/Autonomy)
  • Apache Tika (Open Source)
  • Outside In (Oracle)
  • IFilter (Microsoft)
などなど

さて、オンラインヘルプには Tika は .zip や .tar といったコンテナファイルを含むさまざまな形式を検索する、とあります。


Conversion Filter を使用して添付ファイル内のテキストを検索するには、全文索引を作成する画面でオプション「添付ファイルを索引する」を有効にしたうえで、さらに「詳細検索」を選択します。
英語版では "Using conversion filters on supported files" を選択します

今回検索のテストに使用したデータベースには、本文が異なる3つの文書を登録しています。
1) 文字列をリッチテキストフィールドに直書き
2) 1の文字列を転記した、UTF-8でエンコードしたテキストファイル
3) 2のファイルが入った .zip ファイル
全文検索前の状態

まずは Domino の設定を何も変更せず、検索バーへ "domino" とタイプして全文検索してみます。
設定なしで全文検索、.zip 以外の2文書がヒット

すると、1と2の文書がヒットしましたが .zip ファイルはヒットしません。

オンラインヘルプによると、デフォルトでは Tika 1.18 でサポートされているすべてのファイル形式のうち、次のものを除いて全文索引されているとのこと。
.au, .bqy, .cca, .dbd, .dll, .exe, .gif, .gz, .img, .jar, .jpg, .mov, .mp3,.mpg,
 .msi,.nsf, .ntf, .p7m, .p7s,.pag, .pdb, .png, .rar, .sys, .tar, .tif, .wav, .wpl, .z, .zip. 

.zip はサポートされてはいるものの、デフォルトでは全文索引に含まないファイル形式となっています。

こういった .zip などの「サポートされているがデフォルトで除かれているファイル形式」のうち *.zip と *.jar を手っ取り早く索引に含める場合、notes.ini に次のパラメータを追加します。
FT_USE_ATTACHMENT_WHITE_LIST=1
これを設定することにより、次のファイル形式を一度に全文索引に含めることが可能となります。
*.123,*.ami,*.ap,*.as,*.aw,*.dca,*.doc*,*.dwg,*.emf,*.emz,*.fff,*.fft,*.flg,*
.fm,*.htm*,*.hwp,*.jar,*.jtd,*.jtt,*.lwp,*.mime,*.oas,*.odp,*.ods,*.odt,*.pdf*,*.pic,
*.ppt*,*.pst,*.qpw,*.r13,*.r14,*.rtf,*.sam,*.shw,*.swp,*.vsd*,*.wk4,*.wks,*.wmf,*.wp*,
*.wri,*.xlr,*.xls*,*.xml,*.xy*",*.zip

今回は検索のテストに使用しているデータベースがサーバーにあるため、サーバーの notes.ini へ追加しました。
※notes.ini へ追加した後(要否は不明ですが)念のためDominoを再起動しています

次のコマンドを投入して全文索引を(更新ではなく)再構築します。

load updall -X FTSearchTest.nsf

2019/05/29 11:52:04   Index update process started:  -X FTSearchTest.nsf
2019/05/29 11:52:04   Updating views in C:\IBM\Domino\data\FTSearchTest.nsf
2019/05/29 11:52:04   Full text indexing documents in C:\IBM\Domino\data\FTSearchTest.nsf
2019/05/29 11:52:05   3 documents (12705 bytes) indexed in C:\IBM\Domino\data\FTSearchTest.nsf
2019/05/29 11:52:05   Index update process shutdown


では改めて検索バーに "domino" とタイプして検索します。

.zip ファイルを含む3件すべてが検索にヒットしました。
ひとまず「.zip ファイルの全文検索」の検証は大成功です。

研究会の検証時にうまく動かなかった原因は、おそらく notes.ini に追加したパラメータが反映していない状態だったのではないか...と推測しています。
今回の検証では、パラメータを変更したあとに Domino を再起動しました。


ところで日本語の検索はどうなのでしょうか。

試しに"エコシステム" とタイプして検索します。
.txt の日本語はヒットしない

今度は .zip ファイルがヒットして .txt ファイルがヒットしなくなりました。

そう言えば先に示した「FT_USE_ATTACHMENT_WHITE_LIST=1 を追加すると検索可能になるファイル形式」のリストに .txt が無いことが少々気になります。

とは言え、英語が検索できるということは .txt ファイルもきちんと索引されていると理解してよいと思うのですが、日本語が検索できないとはこれ如何に。

そこで、さらに次のファイルを追加して、全文索引を再構築してみました。
4) 2のテキストファイルの内容をPDFへ出力したもの
5) 4のファイルが入った .zip ファイル
pdfファイルとそれをzipファイルに入れたものを追加

この状態で日本語で検索すると .pdf ファイルはヒットします。
.pdf の日本語はヒットしたが .txt がヒットしない

念のため Notes 9.0.1 FP9 でも .txt の全文検索を試してみたところ、(当然 .zip ファイルはヒットしませんが) .txt にある日本語と英語のどちらも検索にヒットしました。どうやら V10 になって(Conversion Filter が変わって)からの不具合のようです。

では、V10 の notes.ini に追加したパラメータを削除してみるとどうでしょうか。全文索引を再構築して検索してみます。
notes.ini パラメータ無しでは .txt の日本語がヒットする

少々混乱してきましたので、整理してみます。
表の最も右にある列の上から4行目に注目してください。

まずは Notes 9.0.1 FP9 のローカルにあるデータベースでの結果です。 .txt ファイルの日本語は検索にヒットします。
Notes 9.0.1 FP9 の全文検索結果

続いてコミュニティー版 Domino 10.0.1 FP1 で notes.ini パラメータを追加していない状態での結果です。こちらは Notes 9.0.1 FP9 の結果と同じです。
Domino 10.0.1 FP1 notes.ini パラメータ無し

最後にコミュニティー版 Domino 10.0.1 FP1 で notes.ini パラメータ「FT_USE_ATTACHMENT_WHITE_LIST=1」を追加した状態での結果です。
Domino 10.0.1 FP1 notes.ini パラメータ追加
Domino 10.0.1 FP1 では .zip ファイルの全文検索を選択すれば .txt の日本語検索をあきらめなければならないのでしょうか...


ちなみに、notes.ini へ次のパラメータを追加すると Conversion Filter である Tika がフィルタリングするファイル名をコンソールに表示することができます。
DEBUG_FILTER_TIMING=1
DEBUG_TIKA=1

FT_USE_ATTACHMENT_WHITE_LIST=1」を追加する前は、.txt ファイルと .pdf ファイルがフィルタリングされていました。

load updall -X FTSearchTest.nsf

Index update process started: -X FTSearchTest.nsf
Updating views in C:\IBM\Domino\data\FTSearchTest.nsf
Full text indexing documents in C:\IBM\Domino\data\FTSearchTest.nsf
Tika upload and response took 31 msecs Filtering Attachment 'Sample.txt' in 'C:\IBM\Domino\data\FTSearchTest.nsf' (DocID = 2294), sent size = 3678, returned size = 3706
Tika Attachment Filtering - took 31 msecs Filtering Attachment 'Sample.txt' in 'C:\IBM\Domino\data\FTSearchTest.nsf' (DocID = 2294), size = 3678, occurrences = 1103
Tika upload and response took 203 msecs Filtering Attachment 'Sample.pdf' in 'C:\IBM\Domino\data\FTSearchTest.nsf' (DocID = 2322), sent size = 101058, returned size = 3594
Tika Attachment Filtering - took 203 msecs Filtering Attachment 'Sample.pdf' in 'C:\IBM\Domino\data\FTSearchTest.nsf' (DocID = 2322), size = 101058, occurrences = 1096
5 documents (11159 bytes) indexed in C:\IBM\Domino\data\FTSearchTest.nsf
Index update process shutdown

FT_USE_ATTACHMENT_WHITE_LIST=1」を追加すると、.zip ファイルがフィルタリングされるようになりましたが、.txt がフィルタリングされなくなりました。

load updall -X FTSearchTest.nsf

Index update process started: -X FTSearchTest.nsf
Updating views in C:\IBM\Domino\data\FTSearchTest.nsf
Full text indexing documents in C:\IBM\Domino\data\FTSearchTest.nsf
Tika upload and response took 47 msecs Filtering Attachment 'Sample.zip' in 'C:\IBM\Domino\data\FTSearchTest.nsf' (DocID = 2302), sent size = 2078, returned size = 3707
Tika Attachment Filtering - took 47 msecs Filtering Attachment 'Sample.zip' in 'C:\IBM\Domino\data\FTSearchTest.nsf' (DocID = 2302), size = 2078, occurrences = 1106
Tika upload and response took 78 msecs Filtering Attachment 'Sample.pdf' in 'C:\IBM\Domino\data\FTSearchTest.nsf' (DocID = 2322), sent size = 101058, returned size = 3594
Tika Attachment Filtering - took 78 msecs Filtering Attachment 'Sample.pdf' in 'C:\IBM\Domino\data\FTSearchTest.nsf' (DocID = 2322), size = 101058, occurrences = 1096
Tika upload and response took 62 msecs Filtering Attachment 'Sample_pdf.zip' in 'C:\IBM\Domino\data\FTSearchTest.nsf' (DocID = 2326), sent size = 94317, returned size = 3652
Tika Attachment Filtering - took 62 msecs Filtering Attachment 'Sample_pdf.zip' in 'C:\IBM\Domino\data\FTSearchTest.nsf' (DocID = 2326), size = 94317, occurrences = 1105
5 documents (20081 bytes) indexed in C:\IBM\Domino\data\FTSearchTest.nsf
Index update process shutdown

このことから、日本語は .txt ファイルがフィルタリングされれば検索できるようになることがわかります。

もし、.txt ファイルを Tika がフィルタリングする対象として個別に設定することができれば、日本語がヒットするのではないでしょうか。

オンラインヘルプには、フィルタリングするファイル形式を個別に指定する notes.ini パラメータの記載もあります。ただし個別に追加する場合、先に追加した notes.ini パラメータ「FT_USE_ATTACHMENT_WHITE_LIST=1」の代わりに「FT_USE_MY_ATTACHMENT_WHITE_LIST=1」を設定するようです。
FT_USE_MY_ATTACHMENT_WHITE_LIST=1 FT_INDEX_FILTER_ATTACHMENT_TYPES=*.txt,*.pdf,*.zip


では、先に追加したパラメータFT_USE_ATTACHMENT_WHITE_LIST=1を削除して上の2行を追加し、全文索引を再構築してみます。
load updall -X FTSearchTest.nsf

Index update process started:  -X FTSearchTest.nsf
Updating views in C:\IBM\Domino\data\FTSearchTest.nsf
Full text indexing documents in C:\IBM\Domino\data\FTSearchTest.nsf
Tika upload and response took 31 msecs Filtering Attachment 'Sample.txt' in 'C:\IBM\Domino\data\FTSearchTest.nsf' (DocID = 2294), sent size = 3678, returned size = 3706
Tika Attachment Filtering - took 46 msecs Filtering Attachment 'Sample.txt' in 'C:\IBM\Domino\data\FTSearchTest.nsf' (DocID = 2294), size = 3678, occurrences = 1103
Tika upload and response took 15 msecs Filtering Attachment 'Sample.zip' in 'C:\IBM\Domino\data\FTSearchTest.nsf' (DocID = 2302), sent size = 2078, returned size = 3707
Tika Attachment Filtering - took 15 msecs Filtering Attachment 'Sample.zip' in 'C:\IBM\Domino\data\FTSearchTest.nsf' (DocID = 2302), size = 2078, occurrences = 1106
Tika upload and response took 62 msecs Filtering Attachment 'Sample.pdf' in 'C:\IBM\Domino\data\FTSearchTest.nsf' (DocID = 2322), sent size = 101058, returned size = 3594
Tika Attachment Filtering - took 62 msecs Filtering Attachment 'Sample.pdf' in 'C:\IBM\Domino\data\FTSearchTest.nsf' (DocID = 2322), size = 101058, occurrences = 1096
Tika upload and response took 79 msecs Filtering Attachment 'Sample_pdf.zip' in 'C:\IBM\Domino\data\FTSearchTest.nsf' (DocID = 2326), sent size = 94317, returned size = 3652
Tika Attachment Filtering - took 79 msecs Filtering Attachment 'Sample_pdf.zip' in 'C:\IBM\Domino\data\FTSearchTest.nsf' (DocID = 2326), size = 94317, occurrences = 1105
5 documents (18510 bytes) indexed in C:\IBM\Domino\data\FTSearchTest.nsf
Index update process shutdown 

.txt ファイルもフィルタリングされたようですので、日本語で検索してみます。
フィルタ対象を個別指定後の日本語検索の結果


.txt ファイルにある日本語が全文検索にヒットするようになりました。

もし V10 にアップグレードした後に .txt ファイルがヒットしなくなった場合、ファイル形式を個別に指定する方法を試してみてはいかがでしょうか。