IMEとは

残念ながら、キーボードのキー数はUnicodeのコードポイント全てをカバーするほど多くはありません（桁が3つほど足りませんね）。
そのため様々な文字を入力する必要のある言語では、その入力の際にInput Method Editorと呼ばれるものを挟みます。
例えば日本語では入力した文字列のかなを入力し、それを適切に漢字などに変換するという実装になっています。
例えば、

Microsoft IME
Google日本語入力
ATOK
SKKなど

アプリケーションはキーボードからではなく、IMEのAPIを通して文字列を受け取ることで日本語や韓国語、中国語といった様々な言語を共通の仕組みで扱うことができます。
また、昨今では、このIMEのAPIを挟むことで、手書き文字入力や音声入力といった様々な入力方法に対応してきています。

IME API

IMEのAPIを直接利用する必要がある状況というのは非常に限定されたものです。
基本的には、ディスプレイ上に表示する文字列をOS標準のテキスト入力フィールド以外で編集させようとする場合です。

IMEのAPIは以下に示すように、各プラットフォームがてんでバラバラに提供してくれます。

Windows
- Input Method Manager
- https://msdn.microsoft.com/ja-jp/library/cc448105.aspx
Windows
- Text Services Framework
- https://msdn.microsoft.com/library/ms629032.aspx
Windows Universal Platform
- Windows.UI.Text.Core
- https://msdn.microsoft.com/library/windows.ui.text.core.aspx
GTK+
- GtkIMContext
- https://developer.gnome.org/gtk3/stable/GtkIMContext.html
macOS
- NSTextInputClient
- https://developer.apple.com/reference/appkit/nstextinputclient?language=objc
iOS
- UITextInput
- https://developer.apple.com/reference/uikit/uitextinput
Android
- BaseInputConnection
- https://developer.android.com/reference/android/view/inputmethod/BaseInputConnection.html

クロスプラットフォーム？
なにそれ誰かやってくれるの？
そういう世界です。

また、IMEの自由度は各OSが提供しているこれらのAPIの自由度に大きく依存します。
各プラットフォームの詳細な説明は別の機会に譲ることにして、この記事ではおおよそ全てに共通する部分について書きたいと思います。

未確定文字列の変更

一般的なデフォルトのIMEでは通常、下線のついた文字列として扱われるあれです。
この状態のテキストは基本的にはアプリケーション側で描画する必要があります。
（もちろん、OSが提供するテキスト入力欄はこの処理の一切を請け負ってくれます）

この「未確定文字列」の描画方法には、大きくふたつあります。

未確定文字列を挿入位置の現在のテキストの上から重ねて描画する
未確定文字列を挿入してあたかもテキストの一部であるかのように描画する

の2パターンです。
未確定文字列が変更されるのは新しい未確定文字が追加されたときや、スペースキーを押すなど変換候補を変更した場合です。
もちろんこれ以外のタイミングで変えることはIMEの自由ですし、APIの許す範囲で様々なことができます。

未確定文字列の確定 (commit)

ここで初めてIME上で編集されていた未確定文字列がテキストに挿入されます。
多くの日本語IMEではこれはエンターキーを押したときの挙動に相当します。
特にテキスト編集の挙動にこだわりがないのならば、この未確定文字列の確定をもって編集履歴に追加するのが良いでしょう。

その他

上の「未確定文字列の変更」と「未確定文字列の確定」のふたつがIMEのAPIで一番重要な部分です。
ここをしっかりしておけば、少なくともユーザーが文字列を入力できないということはなくなります。
ただし、IMEのAPIにはそれ以外にもいくつかのAPIがあります。

編集中のテキストの位置・属性の取得

デスクトップアプリの場合、未確定文字列の近くにその未確定文字列の変換候補や、その未確定文字列に基づいた予測変換候補が表示されます。
もちろん、このように変換候補の位置が適切に表示されるためにはIME側から指定された範囲の文字列がどこに描画されているのかという情報を返す必要があります。

ここで縦書きにはつらいのが、指定された文字列が縦書きであるか横書き出るかという情報をIME側に伝えることが不可能なOSもあるということです。
つまりこのような環境では変換候補がきちんと縦書きにはならず、横書きで表示されます。

このような状況はAPIの問題だけではなく、そもそもGoogle日本語入力のようにIME側が縦書きに対応していないという状況も存在します。
（こういう場合、アプリケーション側の対応としては、返す文字列の位置を実際の位置とは異なるものにするというものになります。TATEditorではそういうオプションを用意してあります）

未確定文字列の装飾

未確定文字列の中には、現在変換対象になっている文節とそうではない文節があります。
これらを適切に表示するためには、未確定文字列のどこをどのように装飾するかという情報が必要です。
IMEにはこのための情報を（多寡はあるとしても）アプリケーション側に伝える手段があります。
これを描画するのはもちろんアプリケーション側の責任です。

編集中のテキストへのアクセス

日本語には同音の異義語がたくさんあり、適切な単語を上位に上げるためには前後の文字列に応じて挙動を変える必要があります。
このため、多くのIMEのAPIにはIME側からアプリケーションで編集中のテキストへのアクセスが可能になっています。

ここで面倒なのが、テキストへのアクセス方法はOSごとに異なるため、OSごとに異なる実装をする必要があります。
特に、文字列クラスを自身で実装している場合にはそのつなぎこみに苦労することになるでしょう。

おわりに

今日は、IMEとアプリケーションの間に立つAPIについてざっくりとお話ししました。

APIにはOSごとに強い特徴があります。
というわけで明日からは各OSでのアプリケーション側のIME API実装について簡単に紹介していきます。

IMEを使う（序章）