KWIC Finder リニューアルの進捗状況

前回KWIC Finderのリニューアルについて公表したが、2ヶ月経過してかなり具体的に進んでいる。リリースは年内を目標にしている。
ファイル検索ソフトには、ファイルシステムの中からどこに保存したかわからないファイルを探し出すもの(Everything等)と、ファイルの場所自体は分かっていてファイルの内容を検索するGrep系に大別できると思う。KWIC FinderはGrep系になるが、Grep系では最強の検索ソフトを目指している。

新バージョンの機能と特徴

新バージョンの特長は以下の通りで、操作性がかなり向上している。

• VisualStudioのように各ペインを自由にドッキングできる。
• 検索やテキストビューの表示がUnicode対応になった
• ネットワークのパス ( \\ネットワーク名) の検索が可能になった。以前はネットワークドライブの割り当てを行ない、Z: などのドライブ表記にしないと検索できなかった。
• 画像のプレビューにプラグインなしで対応した。（以前はGIFやPNGを表示するにはsusieプラグインを使用する必要があった）
• zipフォルダの表示、およびZip内のファイル検索にネイティブ対応した。以前は統合アーカイバプロジェクトのDLLが必要だった。ただしzip以外の圧縮形式には対応していない。
• KWICコンコーダンスの表示を、従来のKWIC Finder風のtree形式と、一般的なリスト形式の2種類で表示できるようになった。リスト形式の場合、見出しのクリックでソートができる。
• 正規表現は外部DLLではなくC# の標準の正規表現を使用できるようにした。
• 検索時に論理演算子AND OR NEAR ANDNOTが使用できる(旧版からサポートしている)
• ワイルドカード文字(*)で前方一致、後方一致、部分一致ができる(旧版からサポートしている)
• 全文検索インデックスのエンジンは、Hyper Estraierを使用。(旧版でサポートしていたGoogle Desktopは今日では使えないので、削除した。)
• 設定項目やメニューは大幅に整理してわかりやすくした。
• 起動オプション等は従来通りなので、Wordや秀丸のマクロから起動できる。
• dpi aware
• 64bit版サポート予定
• 英語/日本語UI
• xdoc2txtでサポートしているMicrosoft Office文書、Open Office文書、PDF、一太郎等の検索が可能。

画面例

ファイルエクスプローラ画面。選択したファイルの内容を右下画面にプレビューできる。

検索例。検索結果のKWICコンコーダンスをリスト形式表示している。ヘッダをクリックするとソートできるので、検索に一致した後続文字列で並び替えることもできる。zipの内部ファイルを検索している点にご注目。

検索結果を、同じくツリー形式表示したもので、従来のKWIC Finderと同じ表示形式。左側のペインはタブで検索条件ペインに切り替えている。

htmlをブラウザで表示した例。左側の検索条件ペインは画面の好きな位置にドッキング配置できる。

既存ユーザのアップグレードについて

バージョンアップではなく新開発になるので、既存のユーザには、優待価格でのアップグレードを予定している。

KWIC Finderリニューアルに着手

ここ数年、かつて2000年代に作成したアプリの書き換えを進めており、EBWin4に続いて昨年はEBStudio2をリリースした。残る大物アプリがファイル検索ソフトのKWIC Finderである。
KWIC Finder
KWIC Finderは基本的にファイルブラウザ+GREP検索+KWIC索引のアプリで、OfficeやPDF文書をプラグインなしで検索できることから長く利用されてきた。だが近年Windowsの利用環境の変化により、不便に感じることが多くなってきた。作者が考える致命的な問題点は次の2つである：

1. Unicodeに未対応
2. NASのネットワークフォルダに未対応

KWIC Finderからテキスト抽出フィルタの機能を独立させたxdoc2txt については、すでにUnicode対応を行ったver2.0をリリースしている。いよいよ本体のKWIC Finderに手をつけようかと考えている。
KWIC FinderのソースはVisual C++6.0なので、現在のVisual Studio では再コンパイルも難しく、C#で全面的に書き直すこととしたい。

KWIC Finderリニューアルの目標：

• KWIC Finderの基本的な機能は踏襲する
• 内部Unicode対応
• 64bit版のサポート
• ネットワークファイル対応の強化
• Office文書やPDFはxdoc2txtを使用して抽出する。テキストファイルはネイティブ対応。
• 高DPI対応
• Hyper Estraierによる全文検索
• ePub対応

現在のKWIC Fiderから削除する機能：

• susieプラグイン対応は削除。代表的な画像フォーマットはネイティブ対応する。
• Google Desktop等、現在は使われなくなった機能の削除。

開発を始めた証拠に、最初のスクリーンショットを掲載しておこう。最終的なUIはかなり変わると思う。

期間は半年から1年ぐらいを考えているが、自分で満足のいくものができたタイミングでリリースしたい。

青空文庫がSSL/TLS1.0を無効化?

5/31頃からAndroid4.4(kitkat)で読書尚友での青空文庫のダウンロードができなくなったという報告を受けた。現象としてはAndroid5.0以上は問題なくダウンロードでき、4.4以下が全てダメらしい。調べたところ、どうやら青空文庫のaozora.gr.jpのサーバーがSSL/TLS1.0を無効化した為ではないかという推論に達した。
青空文庫のSSL化については、以前から告知されており、4/1以降は https: のURLでないとアクセスができなくなっている。
2018年03月31日 青空文庫のSSL化対応についてのお知らせ
https://www.aozora.gr.jp/soramoyou/soramoyouindex.html#000497
だがTLS1.0の無効化については告知がない。たぶんサーバー管理会社の方針でおこなったものではないかと思う。
SSL/TLS1.0の脆弱性は以前から指摘されており、無効化の期限が切られている。
脆弱なSSLおよびTLSからの移行期限の変更について | NTTデータ先端技術株式会社
SSL/TLS 1.0 はいつまでに無効化しなければならないか？ | NTTデータ先端技術株式会社
大手のサーバーは軒並み2018年6月をめどにTLS1.0を無効化する見込みで、青空文庫も追従することは仕方ないかもしれない。
問題は既存のアプリへの影響で、iOSはiOS5以降TLS1.1/1.2に対応しているが、Androidの場合はTLS1.1/1.2に標準で対応するのは5.0(Lollipop)以降である。
実は4.1〜4.4はTLS1.1/1.2が既定で無効化されているだけなので、アプリ側の対応でTLSを有効にすれば回避できる。
この辺の事情については次が参考になる。
Android4系端末のTLS1.1&1.2対応について
https://qiita.com/ntsk/items/9f31fc7b44c04ea45e0b

具体的な実装は下記の通りで、OkHttpClientを使っている場合は比較的簡単に対応できる。
Android 4系(API16-19)のTLS1.1, 1.2対応 - 怠惰を求めて勤勉に行き着く
support enabling TLSv1.2 on Android 4.1-4.4. #2372
https://github.com/square/okhttp/issues/2372

AndroidでHTTP通信の方法について

AndroidでHTTP通信を行う方法には変遷がある。
最初はHttpClientが標準だったが、Android5.1から非推奨になり、現在はHttpURLConnectionが標準ということになっている。
一時期Volleyが流行った時期があったが、HTTPClientに依存しているために現在は非推奨になってしまった。
HttpURLConnectionにも標準ではリダイレクトに対応していないという問題があって、リダイレクトさせるには自分で色々実装が必要になる。
[Android]URLConnectionでリダイレクトにも対応してみた | T.Muroiのblog
サードパーティー製でOkHttpClientというのがあり、こちらはリダイレクトにも対応していて活発に更新されているので、今はOkHttpClientを使っているアプリが多いと思う。
読書尚友ではHttpURLConnectionを使っていたが、kitkat以下の場合はOkHttpClientを使って上記の方法でTLSを有効にすることで、なんとかAndroid4.1-4.4でも青空文庫からダウンロードできるようにした。

Android4.0.3以下については、どうあがいても青空文庫サーバーから直接ダウンロードすることはできない。実際、端末のブラウザから青空文庫ホームページを見ることすらできない。

TLS1.0の無効化がすすむと、古いAndroid端末は実用的には使えなくなると思う。Yahoo! JAPANも6/1以降TLS1.0/1.1のサポートを順次終了するとアナウンスしており、「見られるホームページがほとんどない」という事態になるはずだ。
読書尚友の有償版では別のサーバーからの一括ダウンロードができるので、現在までに公開されている作品については一括ダウンロードで読むことが可能である。
だが作品一覧のデータの取得ができないので、新規作品を読めない。作品一覧をミラーサーバに置くとかすれば対応できる可能性があるが、今後メンテしていけるかどうかが不透明だ。
miniSDKVersionを16(4.1Jelly Bean)にして、4.0.3以下は切り捨てることも考えないといけないかもしれない。4.0.3以下の端末で読書尚友を利用しているユーザがまだ2%くらいいるので、悩ましいところだ。

青空文庫のSSL対応

読書尚友で青空文庫の作品一覧の更新ができなくなったので慌てて調べたところ、4/1からSSL対応され、URLが https: に変わったためだった。
2018年03月31日 青空文庫のSSL化対応についてのお知らせ
https://www.aozora.gr.jp/soramoyou/soramoyouindex.html#000497
すぐに修正したが、メンテナンスされていない青空文庫関連アプリだと脱落するものもありそうだ。多くの青空文庫ビューアで使用されている青空プロバイダもエラーになってしまっている。
青空文庫OPDSも今の所3/31で更新が止まっている。こちらはたぶん対応してくださると思うけど。

EBWin4 64bit版

要望を頂いている訳ではないが、EBWin4の64bit版を実験的にビルドしてみた。
WindowsのクライアントOSではVistaから64bit版が提供されるようになり、現在ではインストールベースで64bitが32bit版を上回っている。32bitOSでは物理メモリが3GBが上限だが、64bitなら物理メモリの上限まで使用できる。
ちなみにmac OSもHigh Sheirraが32bitアプリが動作する最後のOSと告知されており、iOSもiOS11から32bitはもはや実行できない。Windowsアプリもいずれは64bit対応が必須になるだろう。
EBMacやEBPocketはすでに64bit化が済んでおり、EBWin4もそろそろ64bitネイティブ化する時期だと思う。

Visual Studio で64bitアプリを作成する

既存の32bitアプリを64bit化する手順は、

• 構成マネージャからプラットフォームに<新規作成>でx64を追加する
• ソリューション構成に<新規作成>でRelease(x64)を作成し、コピー元に32bit版のReleaseを指定する。プラットフォームをx64にする
• アプリからリンクするdllを全て64bit版にする。EBWin4の場合、zlibとsqlite3が外部DLLなので、各ホームページから64bit版をダウンロードする。
• .Net Frameworkでは32bitと64bitの違いは吸収されるが、C#のプロジェクトのプラットフォームはx86ではなくx64を指定しないといけない。
• WindowsインストーラのTargetPlatform をx64とし、Default Locationの指定を ProgramFiles64Folder とする

本当に64bitで動いているかどうかは、タスクマネージャで確認できる。
1日くらいの作業で64bit化できたが、私の通常の使用環境だと32bitとの違いは全然感じない。数十個の辞書をグループ化して検索するような極端なケースでは、多少恩恵があるかもしれない。
次の目標はEBStudio2の64bit化になるが、これは4GB超の巨大辞書を作るときに必要になると思う。
P.S.
EBStudio2の64bit版も2/27にリリースしました。特に問題はないように見えます。

iPhoneX 全画面対応

iPhone Xが発売されて数カ月が立つが、iPhone Xはこれまでと違う独特のアスペクトレシオを持ち、アプリもそれなりの対応が必要になる。
当方の開発環境はこれまでMac OS X 10.11 El Capitan および Xcode 8だったが、iPhone Xの対応はXcode 9以降となる。さらにXcode9の動作環境はmacos X Sierra以降なので、iPhone Xエミュレータを試すには開発環境をアップグレードしないといけない。
開発環境を更新するのはリスキーなので、VMWare Fusionでmacos X Sierra環境を作り、その上でXcode9のiPhone Xエミュレータを動かしてEBPocket for iOSの動作確認を行い、対応できたものと思って安心していた。（→iPhone X の解像度の問題 - hishidaのblog）
ところがiPhone Xの実機で全画面で動作させるには、Xcode9でビルドおよび提出が必要であり、Xcode8以前でビルドしたアプリをiPhone Xで実行すると上下に黒い枠が表示されることがわかった。
いずれはXcode9以上でないとアプリの提出が認められなくなるので、重い腰を上げてXcode9対応を行うことにした。

1.まずMac OS Xを 10.11 El Capitanから10.12 macos X Sierraにアップグレードする。これ自体は特に問題は無い。
2.次にXcode9.2をインストールし、Xcode8時代のプロジェクトをコンパイルしてみると、早速コンパイルエラーの山となった。

• Xcode8以前に作成したxibが全てコンパイルエラーになる。プロパティのbuild for でiOSのバージョンを指定する必要があるらしい。一つ一つ"iOS 7.0 and later"を指定して再コンパイル。
• 10.11以前のXcodeプロジェクトをコンパイルすると、Code signing error が出る。

Command /usr/bin/codesign failed with exit code 1
Code signing fails with error 'resource fork, Finder information, or similar detritus not allowed'

Technical Q&A QA1940: Code signing fails with error 'resource fork, Finder information, or similar detritus not allowed'
上のURLに書かれているように、次のコマンドを実行することで解決。

xattr -cr プロジェクトディレクトリ

3.これで大丈夫と思いきや、iOS11で実行するとUIScrollViewのcontentInsetがずれるという凶悪な問題が発生。
iOS11 で UIScrollView の contentInsetがずれる問題
上記URLとは違う解決方法だが、結局、次の方法でiOS11のcontentInsetの自動調整を抑止し、さらに表示位置をiOSのバージョン毎に調整することで解決。

MainWindow.xibのRootViewControllerで下記設定を行なう
Adjust Scroll View Insets : チェックを外す ←勝手なcontentInsetの自動調整を止める
Under Top Bars : チェックをつける←NavigationBarの高さが変わっても潜り込まずにbarの下に表示される

iOS6からiOS7になるときにもNavigationController Barの下にUITableViewが潜り込むという問題が起きたが、その時の対処が不完全であったことが、iOS11になって表面化したらしい。
やはりお前らのiOS7対応は間違っている(解説編)
ただ今回のやり方が合っているのかどうかはわからない。そのうち「おまえらのiOS11対応は間違っている」と言われるかもしれない。
一時はもうAppStoreに提出できないのではないかと思って悩んだが、最終的には無事Xcode9でiPhone X対応版を提出することができた。

一つの問題点として、Xcode9でビルドすると、TargetOSの下限がiOS8になってしまう。ただしiOSは大多数のユーザが最新のOSに速やかにバージョンアップするので、実際は問題は無いだろう。
iOSはメジャーバージョンアップごとに破壊的修正が入るので、開発者にとっては大変である。

iPhone X の解像度の問題

「EBPocket が iPhone Xに対応していない」というご意見を頂いたので、Xcode 9 のエミュレータで確認したところ、横画面のときに検索一致リストと本文の横幅がイビツになっていることがわかった。次のスクリーンショットのように、本文の方が幅が狭くなっている。本当は横位置の時は本文の幅を広く取りたい。

これはiPhone X だけアスペクトレシオが2:1と縦長であることが原因だ。

デバイス名	画面サイズ	画面解像度	アスペクト比
iPhone X	5.8 inch	2436 x 1125	2:1
iPhone 8 Plus/ 7 Plus/ 6s Plus/ 6 Plus/	5.5 inch	1920 x 1080	16:9
iPhone 8 / 7 /6s / 6	4.7 inch	1334 x 750	16:9
iPhone5/5S/5c/SE	4.0 inch	1136 x 640	16:9
iPhone4/4S	3.5 inch	960 x 640	3:2
iPhone3G/3GS	3.5 inch	480 x 320	3:2

これまでは短辺側の幅が必ず本文の幅だったが、iPhoneXだと横位置の時は、検索一致リスト側を短辺の幅にしないといけない。修正後はこんな感じ。

エミュレータでしか検証していないので不安だが、とりあえず修正版を提出してみた。

P.S.
当方の開発環境は未だにOS X El CapitanおよびXcode8だが、どうやらXcode8でビルドして提出すると、iPhone X の全画面にならず、上下に黒い領域が表示されるらしい。Xcode9 はmacOS Sierra以上の対応なので、Xcode9 で本番用のプログラムをビルドして提出するには、メインのMacbook proをmacOS Sierraか High Sierra にアップデートし、Xcode9をインストールしなければならない。環境を完全にバックアップする必要もあるので、たぶん1日がかりの仕事になる。対応にはまだしばらく時間がかかる模様。