青空文庫が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日がかりの仕事になる。対応にはまだしばらく時間がかかる模様。

EBStudio リニューアル計画(6) EBStudio2 for Mac

EBStudio2のWindows版は12/1にリリースし、Vectorによる販売、および優待アップグレードも始まっています。
EBStudio2
お待ちかね？のEBStudio2 for Macも、本日より公式HPにて配布を開始。Windows版とライセンスキーは共通なので、Windows版を購入された方はMac版もフル機能が使用できます。
Mac版のEPWING辞書圧縮ユーティリティEBShrink for Macも同梱しており、EBMac と組み合わせれば、Mac OS XだけでEPWINGの辞書作成、辞書の圧縮、閲覧まで完結させることができます。
今後の予定では、任意のXMLからの変換を可能にするという作業が残っています。つまりXMLのどの要素を見出しやキーワード、装飾に使用するかというセマンティックを定義できるようにするということ。
ここまでできればEBStudio2のリニューアル計画は終わりになりますが、ちょっと疲れているので、あとは休み休み進めたいと思います。

lingvo辞書の要望について

EBPocket/EBWin4もlingvo辞書の要望をいただいていますが、こちらはちょっと手強そうなので、サポートが可能かどうかは今のところはっきりしません。lingvoはロシアのABBYY社の辞書フォーマットで、ソース形式のDSL形式とコンパイル形式のLSD形式があります。LSD形式は非公開ですが、LSDからDSLへの逆コンパイラが公開されているのと、DSL形式にネイティブ対応しているGoldendictのソースが参照できる(ただしGPLなので流用不可)ので、これらを参考にすれば、原理的には対応は可能。問題は解析と開発にかかる時間コストが妥当かどうかですね。
解析資料を誰かが文書化していて、StarDictやMDictと同程度の開発時間で対応できそうなら脈がありますが、今の所分かっている資料では、解析にかかる時間が大きすぎて、私が個人的に割ける時間が限られていることを考えると、厳しいと言わざるをえません。
妥協案としては、DSL形式だけサポートして、初回起動時にインデックスを自前で作るという手がありますが、ストアで売られているlingvoの辞書はLSDだけなので、ユーザの希望とは違うと思います。

EBStudio リニューアル計画(5) 今後の予定

すでにHPで告知済みですが、EBStudio2のリリースについて、次のように決めさせていただきました。

• EBStudio 1.70 は2017/11/30をもって販売終了。
• EBStudio2は2017年12月に販売開始(予価1000円+税)。
• 既存のユーザの方は、優待アップグレードを実施(500円)。
• EBStudio2の開発意向発表を行った2017年9月以降に購入された方は、希望者は無償アップグレード
• Mac OS X版は来年リリース。ライセンスキーはWindows版と共通とする。
• 「ライセンスキーを入力しない場合は前方一致検索だけ作成できる」という仕様は以前と同じ。

無償アップグレードを期待しておられた方には大変申し訳ありませんが、旧ソースからのリファクタリングに多大な時間を要しており、新アプリを開発するぐらいの作業量がかかっているので、ご理解いただければ幸いです。

なお、旧　EBStudioとの互換性に関しては、次の大型辞書での変換で確認しており、各種変換ツールキットで変換したEBStudio用HTMLは、ほぼ変換できると考えています。

• マイぺディア
• 世界大百科事典
• 小学館スーパーニッポニカ2003
• 大辞泉
• 岩波仏教辞典
• グランドコンサイス(DTONIC)
• LDOCE4
• Collins COBUILD
• 学研Super日本語大辞典