PDIC/Unicode 開発メモ

★英辞郎第9版発売中! 2016/6/7発売

■Download

PDIC/Unicode Ver.5.10.43 試作版 2017.5.16

※エラー発生時のエラーレポートについて
・最新版で行うようにしてください。最新版で修正されている場合があります。
・同じエラーを何度送っても解決には役立ちません(一度だけで十分です)
・早く解決したい場合は下記連絡先などにご連絡ください
・再現手順を記入されない方がほとんどですが、その場合、解決は非常に難しいです
・特定の見出し語の検索でエラーが必ず発生する場合は辞書が壊れている可能性があります。辞書チェックを行ってください

全文インクリメンタルサーチソフト - PDICとは関係ありませんが、公開中。ソースコードの検索などに便利。英辞郎のような巨大テキストファイルをサクサク検索

■DokoPop! Ver.2.0

★お知らせ - 正式版を公開しました。→こちらから

■PDIC/Unicode 5.10予定

エラー時のレポート機能【済】

これまではエラー発生時簡単なメッセージが出るだけでしたが、詳細なレポートを作成・送信する機能を追加してあります。(Ver.5.10.6より)

簡易HTMLの強化

ポップアップ検索ウィンドウの強化 【実装中】

チェコ語の変化形への対応 【開発中】

こちらに試用版の辞書が公開されています。活用形の多いチェコ語ですが、ポップアップ検索などで多くの単語がヒットするようになっています。

ファイルリンク

ポップアップ検索の強化・改善

全文検索機能の強化 【済】

検索機能の強化

内蔵ブラウザによるHTMLインライン表示

辞書ファイルにURL、著作権情報などの埋め込み

辞書ファイルには拡張ヘッダー部があり、ここに任意の様々なデータを埋め込むことができるようになって います。

ネット共有辞書の強化

クリップボード履歴の拡張

その他

FAQ

■PDIC for Android!

Android版情報はこちらへ

■会議室/Mailing List

PDICの仕様に関する議論・要望など。

PDIC Development」メーリングリスト

PDIC 開発会議室

どちらでもお好きなほうで。


以下、検討課題

英語版の正式リリース

英語版はこちら

アラビア語など、右→左言語対応(自動ON/OFF)

Unicode アラビア語フォント
Windows でアラビア語

ポップアップ検索の改善

RichHistory

蛍光ペン機能

表示改善

履歴情報の共有

→単純にファイルで共有する程度にとどめる

その他

Unicode の正規化
- 現状、正規化を必要とするケースは非常に少ない
- 正規化を伴う検索は遅くなる
- 多くの場合無駄な処理となるためオプション扱いにする必要がある。ユーザーにはわかりにくいオプションであり、必要なオプションであるかどうかほとんどの人は判断できな い。
- 検索時に正規化するのではなく辞書作成時に正規化すれば、検索も早くなる
ということで検索時にはUnicodeの正規化は不要、という結論です。
ただし、ポップアップ検索では対象となるテキストが必ずしも正規化されていないため、正規化したテキストでの検索などの工夫が必要ではないかと考えていま す。

■実験

関連語検索の超高速化

機能

・見出し語に含まれる単語をインクリメンタルサーチで検索
・関連語検索で見出し語に含まれる単語を瞬時に検索
注意:キーワード部のカスタマイズは様々な問題が発生します。ここにあるのは将来 的な機能を検討するための実験です。

しくみ

Unicode版ではキーワード部が新設されましたが、それを使って今回の機能を実現しています。
キーワード部は、Tools - 設定 - 動作環境 - 登録語編集で「キーワード欄を表示する」をチェックすると、登録語編集のDLGに出てきます。
このキーワード部をカスタマイズすることで実現しています。

インストール手順

PDICはどのバージョンでもoK。
Perlが必要。Perlのインストールし、 ppmを使って次のモジュールをインストール。
ppm install Text-CSV_XS
※ほかにも必要なモジュールがあれば同様にインストール。
mk_mkey.zipをダウンロードして適当なフォルダーに展開。mk_mkey.plとい うファイルができる。

作成手順

1. CSVファイルの作成
File - 辞書設定<詳細>で使用辞書一覧から実験したい辞書を選択し、右クリックで「辞書の変換」を選択
変換先辞書を適当に入力(仮にここではtest.csv)、変換先ファイル形式を「CSV形式」
「登録項目」ボタンを押し、「検索キー」をチェック
OKボタンを押して変換。
2. キーワード部のカスタマイズ
perl mk_mkey.pl test.csv test.txt
と実行する。(数分程度かかる)
3. 作成したファイルをPDIC辞書に戻す
File - 辞書設定<詳細>から使用辞書一覧で右クリック、「既存辞書の追加」を選択
ファイル名に、先ほど作成した test.txt を指定し、あとは表示に従ってPDIC辞書に変換。
(英辞郎を使用した場合は数十分以上かかります)

使い方

すでに辞書が登録されたはずですので、いつもの通りに使えます。
例えば、WORD欄で "effort" と入力するとeffortを含む見出し語が瞬時に出てきます。
そこでさらに関連語検索をすると同様に出てきます。
ポイントは、今まで時間のかかっていた「見出し語の全文検索が瞬時に出てくる」ことです。
英辞郎はすでに大量の見出し語があるため、例えば take と入力すると大量の見出し語がヒットし、逆に見にくくなってしまいます。
GENE95PDEJ2005といっ た比較的小さい辞書のほうが、良好な結果が得られるかもしれません。(まだ実験していません)

考察

現段階ではとりあえずこんなこともできます、という程度なので実用レベルになるかどうかはこれから確認 していきます。
今回はすでに存在する見出し語から、単純に半角スペースを区切り文字として単語を切り出してキーワード部を作成しましたが、
・単語の切り出し精度を上げる
・見出し語だけでなく、訳語部も対象にすれば訳語部も高速化
といった可能性があります。(これらはPerlのscriptを書き換えれば簡単に可能)

辞書サイズ

英辞郎118の英和辞書から作成したところ、ファイルサイズが360MB、登録語数5,671,538 語、辞書使用率16% (辞書は最適化済み)。
15年以上前に考えた辞書形式をベースにしているとはいえ、5百万語登録してもまだ使用率が16%っていうのは我ながら凄い。(笑)
(勿論、インクリメンタルサーチは超高速のまま)
従ってこの機能を実現出来てしまうと登録語数の制限に引っかかってしまいますが、別の辞書形式もすでに用意してありますので、そちらでやるかもしれませ ん。その場合、現在ある標準の辞書形式を変更するのではなく、高速に検索するための別に用意した辞書という感じです。(下記の技術情報参照)

感想

巨大な辞書からマイナーな熟語などを探すときはこういう機能は便利なんですよね。なぜなら速いですか ら。
しかし多くの場合は、そんなマイナーな熟語を検索することなんてほとんどないですから(日本人が英語を勉強をする場合)。
もちろん、不要というわけではありませんが、比較的マイナーと思われる語句に対して、上記のようなことをやらないといけません。
これをPDICの標準機能とするには敷居が高いですよね。。
もちろん、今すぐにでも出来ますよ。問題はそれが本当に欲しいかどうかです。
私の今までの経験では、全文検索をしないといけないと思うような単語・熟語は全文検索してもほとんど出ることはありません。
やはりこういった機能は90%以上、いや、単純に速くして欲しいと思っている人にとっては99%以上が無駄だと思うんですけどね。。

■技術情報

[TechInfo] 辞書の仕様書

むか〜しの辞書形式も一緒に記述していたため混沌としてきました。→Unicode専用に書き直してい たのですが・・・誰か書き直してください。(笑)
辞書の仕様ページ

[TechInfo] ファイル経由によるDDEコマンド

FirePop!とのプロセス間通信として使用されています。
詳細はこちらへ

.ndファイルの仕様 - ネット共有辞書用の作業ファイル

見出語部 - LastWordId (10桁の整数)
訳語部 - 登録用見出語
用例部 - status \t 新しい見出語
発音記号部 - LastId
単語レベル - コマンド番号

拡張ヘッダーに記録される内容

.tsファイルの仕様 (Web辞書検索機能用のタイムスタンプ辞書)

見出し語 - そのまま見出し語
訳語 - time()関数と同じ時刻系(GMT)の数値(文字列) - 2038年問題有り。その頃はPDICなんて無くなっているでしょう。。

nkf

文字コード判別&文字コード変換。
NKFをDLLで使用するつもりですが、本家(?)に あるDLL wrapperは、かなり酷い作りになっているので作り直しました。

download nkfu-2.0.9.zip - 仮リリース・作成途中

C++Builder5がある場合は、nkfudll.bprを開いてbuild。
無ければ、nkfudll.cをメインファイルにして、必要なファイルをリンクしてできあがり。(要UNICODE define)
DLL consumerは、nkfu.h をincludeして利用してください。(nkf.hやnkf32.hではありません)

注意事項としては、APIが返してきたポインターを後生大事に保存してはいけません。
(今時そんなコード書く人はいないと思いますが)

DLLテストプログラム nkf-dlltest.zip - これもまだ作成中

Web辞書検索

Web辞書検索・ダウンロード
Web辞書検索モジュールの開発方法

[TechInfo] 高速な正規表現検索モジュールは?

PDICでは従来regex++をDLL化したものを利用していましたが、bregonig.dllに載せかえたところ数倍速い事に驚き!
現在re2を実装中。。。→Windowsでは正常に動かない??

要件:
・Unicode対応であること
・Windows対応済み、あるいは対応が容易であること
・動作が安定していること
・PDICが必要とする正規表現に対応していること
・ライセンス的に問題が無いこと

高速検索用のインデックス辞書

こういうのはありそうでなかなか無い。汎用的な全文検索エンジンは重すぎてダメ。ということで作ってみ ました。
基本動作・特徴は、
・検索語をMD5(の簡略・高速版)でハッシュ値を取り、それを検索キーとする。(検索キーは8バイト)
・それをB-treeもどきで検索。(8バイトの固定キーなので非常に高速)
・検索キーがヒットするとそのキーに対応したデータを取得
・データは複数有り、見出し語の一部が登録されている
・複数のデータから検索語と一致するものを抽出し、それを本体の辞書から検索して本当に一致する見出し語を選択
・登録可能な検索キーの数は論理的には8バイト、つまり64bit=とんでもない数まで登録可能ですが、実際はファイルサイズやOSのファイルシステムの 制限で決まります。(WindowsではMemoryMappedFileを使っているためあまり大きくできない)
・ですが、1つのファイルに格納しきれない場合は複数のファイルに分散して格納するため、実質検索キーの登録数は64bitの制限になるはず(検討中)
・データの数(見出し語の数)は約6万件に制限。(それ以上ヒットする見出し語があってもあまり意味はないでしょう)

とてもわかりにくい構造になっているので、簡単に言うと、インデックス辞書の検索は、B-treeなので理論上は O(n)=log nになりますが、固定長のキーとしているため、実質O(1)のオーダーと見なして問題ないはずです。むしろこのインデックス辞書での検索より、ヒットした見出し語の検索の ほうで時間がかかります。つまり、現在のPDICの辞書の検索処理が支配的ではないかと思います。(Profilingをまだしていません)

恐らく英辞郎程度の辞書でN-gramでやってもサクサク動くだろうと思ってます。もちろん、インデックス辞書はそれ なりに巨大になりますが。。
1万語でN-gram=4でやったら100MB余りだったような気がするので、英和辞書だけでやったとしても10GB超かな〜。
間違いなく登録処理で時間がかかるので一般用途ではNGですね〜そもそも英辞郎を対象にしていませんので、あくまで参考実験用です。
理論的には大したことはやっていませんが、こんな特殊なことをやっているのは世界的に見ても非常に少ないはずなので、もしかすると世界最速かもしれま せん。が、実装を完了しないことにはわかりません。。
自分が知らないだけかもしれませんが、巨大データをサクサク検索するエンジンの実装はあまりないのではないでしょうか。Googleはそれをやってい ますが、サーバー側に巨大なデータベースを構築しているからできることです。自分がやろうとしているのは、1台のPCでという話なので。。

WinInetの制約

・同時に複数のスレッドからHTTP requestを発行する場合はINTERNET_FLAG_RELOAD | INTERNET_FLAG_NO_CACHE_WRITE が必要かもしれない。
・同時に同じサーバーへは2つの接続まで。INTERNET_OPTION_MAX_CONNS_PER_SERVER | _MAX_CONNS_PER_1_0_SERVER を使用する。
それよりもWinHTTPを使った方が良いだろう。→WinInet to WInHttp porting
出 典 出典

WInInetとWinHttpは似ているが、ProxyはInternet Explorerの設定を引き継がない、などの問題があり、簡単にはportingできなさそう。

CoInitializeEx

これをまじめに考えないといけませんが、こ こをじっくり読めばわかる。(いくつか表現が誤っているので直したいが)
一言で言えば、初期のCOMはthread unsafeで、それをmulti threadなアプリでも(無理矢理)使えるようにするため、Microsoftがアホなしくみを考えた、です。apartmentは何かというと、threadを管理す る仕組みですね。
STA/MTAがあるおかげで余計な制約が増えてしまい、一体何がいいのかよくわからない。
この仕組みがなければクライアント側のプログラムは賢く作れるのに、まったくどうしようもないです。あの会社は。

それはともかく、では一体どうやるのが最良か?恐らく、
・main threadでCoInitialize()をする(STAで初期化)
・ほかのthreadはCoInitialize()しない、thread管理、排他制御はアプリでやる
が一番簡単じゃないのか?そうすれば
・apartmentは1つですみ、メモリ使用量は最小限
・marshalingをしないのでオーバーヘッドは無し
CoInitializeEx()の中身を知らないので潜在的な問題を抱えるかもしれませんが、今のところ上手く動いている。
そもそもthread unsafeなobjectに対してガンガンmulti threadで使うことを前提にしているあたり、設計思想がまずいと思う。

RTL - アラビア語などの右→左言語

HTML に関して

フリー素材

http://sozai.7gates.net/

■実現予定の機能概要

RichHistory

rich history+bookmark+word test+highlight marking+browser
検索結果表示のブラウザーによる表示の可能性について
利点:
・ブラウザの持つ表現力を利用でき、それを生かした見やすい検索結果の表示ができる
・ブラウザが対応しているデータならどんなものでも表示可能

欠点:
・従来の単語単位の無限スクロールができなくなる(ページ単位のスクロール)
・基本的にマウス操作(キーボード処理を補完する仕組みが別途必要)

履歴情報の機能性向上 - rich history
ポップアップ検索した単語は忘れやすい。検索した単語を含む文の意味が理解できると、検索した単語はそ の時点で忘れている。

そのために考えられる対策:履歴閲覧機能の拡充

 - 履歴情報にdate,action情報を追加(タブ区切り形式)
 - 辞書にない単語はgray表示
 - 辞書にない単語のみを選択

履歴情報の共有機能(世界初?)

普段は自分のPCでPDICを使ってwebサイトやWordドキュメントや色んな文書を検索して読む。
PDICでマークした暗記必須単語や、検索履歴を学習サイトに情報をアップ。
それを元にした単語テストや、関連するテストをwebサイトで実施。PDICでやるよりずっとユーザーフレンドリーで学習が出来る。
webサイト側では学習に使っている単語をキーワードにして広告を出すなり、何か面白い情報を出せば楽しく学習が出来る。

要件
・辞書情報の共有はグループ単位で設定。グループには自由参加、承認必要など設定が可能
・登録された情報は登録ユーザーであれば自由にweb上で閲覧可能
・その人専用の辞書共有アカウントも可能
・1つの共有辞書ファイルで複数のサーバーと共有

利点:
・リアルタイムで他人と履歴を共有できる(何のため?)
・・・あまり利点が無さそうなので却下

現在のステータス:
散在している自分の検索履歴を一つにまとめられるのはいいと思う。が、必ずしもそれが必要だとは思わない。
他人と履歴を共有、というのもある程度条件がないとあまり意味がないだろう。(昔のブックマーク公開が流行ったのと同じで最初だけ)
ということで、保留気味。

「検索ランキングに参加しますか?」でOKした人は履歴内容をサーバーにアップ。ランキング見たって何も面白くな い。。
それより、それぞれの検索語に対してどういうWebサイトで検索したとか、検索に付随する情報のほうが面白いけど、それは難しいな。。
検索履歴はとても有益な情報なのに、有効に利用する方法が見つからない。。(現状単語テストだけ)

蛍光ペン機能(世界初?)→辞書に対してではなく、ポップアップ検索ウィンドウで実現。でいいかな?

Wired Markerなんていうブラウザ用に似たようなソフト有り。
教科書、ノートなどで誰もが経験しているあれです。PDICでも蛍光ペンで重要なところをマーキングす る機能を追加したいと思います。(辞書ソフトでは世界初?)
実現方法は簡単で、PDICの簡易HTML機能を使い、テキストにHTMLを埋め込むだけです。

・辞書毎にマーキング情報を保存
・辞書とは別ファイルにマーキング情報を保存
・マーキング情報は、テキストの位置と文字列パターンそのもの
・辞書からデータ取得時、位置とパターンが一致していればそこへマーキングする。一致していなければパターンを検索。一致するパターンがあればそれを マーキング、情報を補正。なければ無効マーキング(削除はしない)

上記方法による利点:
・辞書がアップデートしても追従できる
・マルチ辞書でも対応可能
・対象辞書が読み取り専用でも対応可能
・マーキング検索が高速

現在のステータス:
そもそも自分は蛍光ペンなど使うことはほとんどしなかった。機能的には面白いが、マークするマメさが無い人間が作ってもあまりいいものはできないだろ うし、結局使わないだろう。。
ということで保留気味。

辞書設定ファイルの仕様改善

同一辞書グループにインストールできるように

・UpgradeKeyはカンマ区切りで複数保存可能
・インストール先を各辞書設定ファイルごとに選べる(そうしないと危険)
・万が一pdsetup.iniがすでにあった場合→UpgradeKeyをみて確認→異なる場合変更せよmsg

次の理由から却下

・辞書グループ共通の設定で不一致が発生し、混乱を与えやすい。(フォント設定、言語プロセッサID不一致などなど)
・現状のレジストリ構成では対応でき無さそう。
・PDIが普及して使われ方によって対応を考えることにする

言語プロセッサ(世界 初?)

現状のPDICでは英語に特化した作りになっていますが、この仕組みにより様々な言語の検索が適切に、 便利に行えるようになります。

言語プロセッサ(別ページを用意)

辞書編集Undo機能

辞書ファイル名+.undo というファイルを作成。
PDIC上で行った一連の編集作業(ネット共有辞書からの更新も含む)を保存し、過去へ戻れる。
万が一辞書破壊が発生しても、履歴に残っている情報なら戻せる。
履歴を閲覧し、特定の単語だけ過去に戻せる。

■課題


連絡先: