漢字変換ミスで、たまに長音記号がかな文字以外の後に置かれる事例を見かけたので、それをLanguageToolのルールにして取り込んでもらいました。 現状ある日本語のルールをざっと見たのですが、うまい具合に表現する方法が思い浮かばなかったので、思い切ってメーリングリストで聞いてみました。 メイン開発者のDanielさんは親切で反応も早い方で、「正規表現でUnicodeの範囲を使えばできる」という方法を示してくれました。また、過去にも日本語のルールを書いているSilvanさんからは、JavaにおけるUnicodeのクラス表現(\p{IsXxx})を紹介してくれました。 これらを踏まえ、以下のようなルールをpull requestとして書き、無事masterにマージしてもらえました。 カタカナとひらがな以外が長音記号の前にあるとき、LanguageToolは警告を出します。 この機会に、Doc-ja Wikiの”LanguageTool使い方メモ“も若干修正しました。自前のgrammar.xmlを指定して起動する方法と、ソースコード上で変更をしたときにルールのテストをする方法について新た説明を加えています。 LanguageToolのリリースバージョンは現在2.9ですが、次期バージョン3.0ではgrammar.xmlの書式も変わっているため、いずれWiki内の説明もそちらに合わせて修正したいところです。
Category: 自由ソフトウェア
ownCloudのDBマイグレーション失敗とリカバー
ふとしたことから、手元のsid環境を更新したのですが、その時にownCloudが5.0.25から7.0.2へと大きく変わってしまいました。ownCloudはアップブレード機能を持っている(web, occコマンド)のですが、それが途中でこけてしまったので、対処方法をblogに残しておきます。 5.0.25から7.0.2へ移行 自分はsid環境を、lxcコンテナの一つに持っています。その中でownCloudも運用しています。最初に導入したときのバージョンは5.0.25だったのですが、この記事を書いている辞典では7.0.2が最新です。5->6のメジャーアップグレードをはさめばうまくいったのかもしれませんが、自分のケースではデータベースの移行がうまくゆきませんでした。バックエンドにはSQLite3を使っています。 oc_lucene_statusでのエラー アップグレード時に発生したエラーログの一部を以下に示します。 oc_lucene_statusというテーブルの移行に失敗しています。このテーブルはLuceneによる全文検索用のものと思われますが、自分自身が全文検索を使ったことがこれまでなかったので、単純にテーブルの削除と再作成をすればよいだろうと推測し、まずはバックアップを取ったうえでdropしてみました。 単純にdropをしただけでは、当然テーブルがなくなるだけなので、やはりアップグレードに失敗します。その時のエラーは以下の通りです。 データベースのテーブルの定義はXMLで書かれています。ソースコードのapps/search_lucene/appinfo/database.xmlが該当するファイルです。これを見て適当に見よう見まねでテーブルを作ってみたところ、うまくゆきませんでした。 これはまずいと思い、バックアップしておいた方のデータベース上でのテーブル構造を参照してみました。 この結果を参考に、新しい方のデータベースで同じテーブルを作成し(表示されているSQLをそのまま実行する)、再度アップグレードを試みたところ成功しました。 無事アップグレードに成功し、今では普通に利用できています。
caffから受け取った署名を自分の鍵へ取り込む(gpg import)
ずいぶん間が開いてしまいましたが、GnuPG key signの作業をする(signing-party/caff)の続きです。前回は自分が相手に対して署名を行い、その結果を送るための手続きについて説明しました。今回はその逆、自分が受け取った相手からの署名を自分の鍵に追加する方法について説明します。 メールをファイルに保存 相手がcaffを使っている場合、pgp鍵のおそらくは各IDごとに1通のメールが届きます。 私の鍵の場合だと、IDとしているメールアドレスは4つあるので、一人当たり4通メールが送られてきます。それらを1つづつファイルとして保存します。 メールの内容は、それぞれのIDに対応する、自身の公開鍵で暗号化されたpgp asciiメッセージです。 メールの復号化 このメールをpgpコマンドで復号化します。 上記コマンド例では、入力されたファイルをmsgというファイル名で復号化しています。復号化した内容は、caffの標準テンプレートであれば以下のようになります。 署名の取り込み この復号化されたファイルには、添付ファイルとして鍵への署名があります。本文中にも説明がありますが、gpg –importコマンドを実行することで署名を自分の鍵に取り込むことができます。 これを、届いたメールの数だけ実施します。さすがに毎回passphreaseを入力するのはしんどいので、gpg-agent等を使うと楽になります。gpg-agentはバージョン2系からついてきます。1.4系にはありません。エージェントの使い方はssh-agentとよく似ているので、そちらに慣れている人であれば楽に使えるでしょう。 私は以下のようなワンライナーで一括処理をするようにしています。 公開キーサーバー上の鍵の更新 最後に、公開キーサーバーへ新しい(電子署名の増えた)鍵を送信して更新します。これは普段から公開キーサーバーに鍵を登録している人だけがすればよい作業なので、運用によっては不要な作業です。 以上で作業は終わりです。
KAKASIのコードについて
ここしばらくKAKASIのソースをいじっています。いい加減あたらしいバージョンをリリースして、しばらくは他のことをやりたいのですが、次に戻ってきたときいろいろと忘れそうなので、記録として残しておこうと思います。 そもそもKAKASIとは何か オリジナルのKAKASIはたかはしもとのぶさんによって作成されたソフトウェアです。漢字、カタカナ、ひらがな、ローマ字を相互に変換する機能をもっています。SKKの辞書を用いて、 オリジナルのKAKASIに、単語を分割する「分かち書き」機能をパッチとして作成したのが、馬場さんです。馬場さんはこの機能を利用して、freeWAISやNamazuなどの全文検索ソフトウェアで日本語を扱えるようにしました。 自分もNamazuの開発にかかわる中で、パッチとしてKAKASIの機能をメンテナンスするのはしんどい、KAKASIのリリース自体長らく行われていない、といった理由で、Namazuの開発の一環としてKAKASIの開発を継承することをたかはしさんに打診し、受け入れられて今に至ります。 最近の作業 KAKASIのバージョンは長いこと2.3.4でリリースが止まっていました。2006年ごろ自分がリリースをしようとした痕跡があるのですが、その後Debian方面でlibtext-kakasi-perlのテストが通らなくなった等いろいろな要因で「これはリリースしないといけない」と思い、ようやく出せたのが2014/1/18です。このリリースで一番大きい変化はUTF-8のサポートです。といっても、iconvに依存しています。KAKASI本体がISO-2022-JP, EUC-JP, SJIS(cp932)の変換機能を持っているのですが、UTF-8対応のためにテーブルを持つのもどうかな、と思いiconvを使うようにして実装しました。 これでひとまず解決か、と思いきやperlモジュールでテストが通らない問題が直っていませんでした。何が起きていたかというと、分かち書きオプション-wを付加したときに、先頭に余計な空白を出力するために、期待されていた出力とは異なっていたのです。 このバグはDebianパッケージの自動ビルドで発覚しました。開発者がアップロードしたアーキテクチャ以外(mips, arm等)のパッケージは、自動的にビルドサーバーによってパッケージが作成されます。その時make testまで実行するので、ライブラリの変化によってバグが顕著化されました。 これを直すために作業を進めていたところ、さらに複数のバグが発覚し、それらの対応も必要になり、今に至ります。 KAKASIの基本データ構造Character kakasi.hで様々なデータ構造が定義されていますが、文字を格納する基本となる型Character(実体はstruct character)が入出力の基本となります。 typedef struct character { char type; unsigned char c1, c2; } Character; typeは文字の種別を表し、0～5, 127の値をとります。値の定義は同様にkakasi.hで行われています /* character set */ #define ASCII 0 #define JISROMAN 1 #define GRAPHIC 2 #define KATAKANA 3 #define JIS78 4 #define JIS83 5 #define OTHER… Continue reading KAKASIのコードについて
HTMLタグを含むpoファイルからプレーンテキストにまで加工して形態素解析にかけてみてtypo等を見つける (Doc-ja Advent Calendar 2013)
これはDoc-ja Advent Calendar 2013 5日目の記事です。 www.gnu.orgでは、現在GNU website Japanese Translation Teamにてチーム体制でwebの翻訳を進めています。実態はほとんどgniibeさん一人で、私は今のところ翻訳チェックぐらいしかできていませんが… gnu.orgのwebはメッセージの中にHTMLタグも含んだ状態で、poファイルによって管理されています。レビューをする上では、なかなか扱いにくい形式です。 そこで、私は一度poから日本語訳文のテキストを生成し、もう少し見やすくした状態でレビューをしています。この記事では、その方法を紹介します さらに、結果を形態素解析にかければ、若干typo等が見つけやすくなります 今時の形態素解析器はできるだけ細かく分解する方向の実装・辞書が多いので、KAKASIなどを使った方がよいかもしれません。
GNUプロジェクトについて知るワークショップ参加
先の「GNUプロジェクトについて知るワークショップ」に参加してきました。私は「自由ソフトウェアによるライブストリーミング」という内容の発表をしました。 当日gniibeさんに指摘を受けたのですが、この発表ではストリーミングに用いるデバイスは民生品の利用を前提としています。 業務用のデバイスではDRMなどがかからないもの多くあり、不自由なテクノロジーに縛られないストリーミングが可能なはずです。
Software Freedom Day 2012
Software Freedom Day 2012にFSIJとして参加しました。 私はその中で「自由なデータ」について話をしました。しかし、「データ」というのは枠が広すぎて、十分にまとめきれなかったのが残念です。発表資料をsfd2012freedata.odpとして公開しておきます(slideshareにも置きました)。 発表のときは日本語コンピューティングを軸にした内容にしてみましたが、言語に依存しないけどドメスティックなもの、例えば地図などもあります。OpenStreetMapの活動には頭が下がります。 個人的にはスペルチェッカ、文法チェッカをどうにかしたいと昔から思っているのですが、自然言語処理の知識を体系的に学んでいないと難しそうです。
川崎でSoftware Freedom Day 2012イベント
来る9/15に川崎の専修大学 サテライトキャンパスにてSoftware Freedom Day連動イベントをやります。概要はFSIJの案内ページをご覧ください。 私は「自由なデータ」について、議論できればと思っています。以前から自由に使えるデータに関しては自分も関心があり、Flashでプレゼンテーション資料を作るという試みもしていました。その時に、自由に流用できるパーツ的なものがないことを残念に思い、せめて自分が作ったパーツぐらいは、と公開しています。まあでも、Flash自体がこのまま入滅しそうな情勢になってしまいましたね。 Flashで資料を作っていた当時はまだOpenOffice.orgもなく、Unix系技術者のプレゼンテーションはたいていMagic Pointが使われていました。Magic Point自体はそんなに悪いソフトウェアでもないのですが、利用感覚としてはLaTeXに近く、サクサクとテキストベースでソースをかける反面、凝ったレイアウトを作るのはちょっと大変でした。 OpenOffice.org以降はImpressを使えばよいので楽になりましたが、商用ソフトにあるような豊富なクリップアート、ステンシルなどがないのが残念です。 最近はプレゼンテーションを作るのにGoogle Presentationを使うことが増えています。しかしWebアプリは自由ソフトウェアでないのが難点です。SFDでは、アウトラインだけGoogle Presentationで書いています。あとでLibreOffice Impressにて整形することになりそうです。