Kengo's blog

Technical articles about original projects, JVM, Static Analysis and TypeScript.

テキスト変換Webサービス概要

先週作成したテキスト変換ツールについて、その概要を簡単にまとめておきます。
f:id:eller:20081116091314p:image


このツールの目的は「かなフォントの入力を支援する」ことにあります。似ている既存ツールとしてはMac向けに「カナブン」というツールがあるようです。さすがはデザイナーに愛されるMac、というところでしょうか。
この手のツールで大切なのは「いかにデータを大量かつ新鮮に持つか」というところです。実際プログラム自体は全く複雑でなく*1、その本質は文字列を変換する「関数」に近いと言えるでしょう。
今回Webアプリとして再作成した理由もここにあり、「ユーザが情報更新を意識する必要がなく常に新鮮な情報を提供できる」ためです。またプラットフォームによらず動作できるのも、カナブンとは大きく異なる所です。

DB設計

HSPで作成した前作ではデータをファイルで管理していました*2が、今作ではDBで管理しています。自作ファイル形式では仕様の拡張などがうまくできませんでしたが、DBならばテーブルを増やすことでそこそこ柔軟に対応できるのではと期待しています。
もちろん必要となるデータをあらかじめ洗い出した上でテーブルを用意してはいます。現段階で考えているテーブルは以下の4つです。

テーブル名 概要
フォントデータ フォントの名前やフォントの種類(TrueType・OpenTypeなど)を記録するテーブル。将来的にはライセンスの種類も記録し、画像作成など「ライセンスによっては使えない機能」の制限を可能にする。
作者データ 作者名や配布元URLを記録するテーブル。
変換パターンヘッダデータ 「GrayGraphics共通変換パターン」「濁音・半濁音利用変換パターン」など、変換パターンの名前や特徴を記録するテーブル。フォントデータが登録されていないデータでも「このパターンで変換して」とユーザが指定することで変換が可能となる。
変換パターンデータ 「『あ』を『3』に変換する」など、実際の変換条件を記録したテーブル。変換パターンの種類×入力文字(50音+濁音・半濁音)の数だけレコードが存在する。

文字列変換の実装方法

変換はあらかじめ記録しておいた変換パターンを用いて行っています。変換パターンは基本的にフォントによって異なりますが、同じ作者が作成したフォントなど複数のフォントで同じ変換パターンを適用できるケースも多くあります。
そこで「フォントデータ」テーブルの他に「変換パターンデータ」テーブルを作成し、パターンデータテーブルの外部キーとなる「変換パターンID」を各フォントデータに設定することでデータの重複を排除しました。


変換方法にはあらかじめマップをサーブレット内に作成・保持しておく方法や毎回SQLを投げる方法など様々な方法が考えられますが、パフォーマンス測定に基づくアルゴリズム最適化はサービス稼動後の課題としてあまり深く考えてはいません。現在は検証のためにDBが頻繁に編集されることを考慮し、リクエストごとにマップを作成する方法を選択・実装しています。

	// 実装イメージ
	Map<String, String> map = new HashMap();
	StringBuilder stringBuilder = new StringBuilder();

	for (int i = 0, max = input.length(); i < max; ++i) {
		String key = input.substring(i, i + 1);
		if (map.containsKey(key)) {
			// マップにある場合はそれを利用
			stringBuilder.append(map.get(key));
		} else {
			// マップにない場合はSQLを投げる
			// 省略:PreparedStatementに対するパラメータ設定
			resultSet = preparedStatement.executeQuery();
			if (resultSet.next()) {
				// 省略:resultSetから変換結果を取得
				stringBuilder.append(result);
				map.put(key, result);
			}
		}
	}

変換パターンはとても単純なもので、以下のような表で表すことができます。入力文字に対して出力文字列としているのは、1文字が2文字以上になる可能性がある*3ためです。

パターンヘッダID パターンID 入力文字 出力文字列
1 1 3
1 2 e

リリースまでの流れ

リリースまでの流れは以下の通りです。レコードの追加はそこそこ時間がかかるでしょうから、年内の公開は難しいと考えています。サーバの選定もレンタルにするのか自宅に用意するのかから検討し、学習の種としたいところです。

  1. インタフェース改善
  2. DBレコードの追加
  3. サーバ準備
  4. 公開

*1:今作っているものはJavaのクラス数が10未満

*2:当時は[http://sprocket.babyblue.jp/:title=SQLele]に代表されるようなHSPでDBを扱う手段を知りませんでした

*3:例えば「が」を「か」と「濁点」に分けることがある