入力メソッド (Input Method Editor, IME) は、キーボードのキー数を超える文字体系を持つ言語で文字入力を実現するソフトウェアです。日本語、中国語、韓国語など、数千から数万の文字を持つ言語では、限られたキー数のキーボードから直接すべての文字を入力することは不可能であり、IME が読みや部首などの入力を目的の文字に変換する役割を担います。同じ IME という枠に入っていても変換の性質は言語ごとに異なります。韓国語のハングルは 24 個の字母をキーボードから打つと音節の形に自動で組み上がるため、日本語のように候補の一覧から選んで確定する操作を伴いません。

日本語 IME の基本的な仕組みは、ローマ字入力またはかな入力で読みを入力し、変換キーで漢字かな交じり文に変換するというものです。変換候補の表示、選択、確定という一連の操作フローが日本語入力の基本です。多くの日本語 IME は予測変換を備えており、数文字入力した段階で文脈に応じた候補を提示します。入力した読みを外部のサーバーへ送って候補を受け取る仕組み (クラウド辞書・クラウド変換) を持つものもあり、新語や固有名詞が端末側の辞書更新を待たずに候補へ出てきます。ただしこの仕組みでは入力した内容が端末の外へ出るため、機密情報を扱う端末では機能ごと無効にする運用も取られます。

主要な日本語 IME には、Windows の Microsoft IME、macOS の日本語入力 (旧ことえり)、Google 日本語入力、ATOK などがあります。Microsoft IME は Windows に標準で組み込まれているため、追加の導入なしに使える既定の選択肢になります。Google 日本語入力は Web 上のテキストから語彙を収集している点を特徴として掲げており、新語や固有名詞が候補に出やすい傾向があります。ATOK はジャストシステムが開発する有料 IME で、文脈を踏まえた変換と分野別の辞書が売りです。中国語圏では読みをラテン文字で打つ拼音入力 (ピンイン入力) が主流で、Sogou 入力法 (搜狗输入法) や Baidu 入力法 (百度输入法) が広く使われています。どれを使うかで変換結果が変わるため、入力欄の不具合を報告として受けたときは、OS とブラウザに加えて IME の種類も確認する対象に入れておくと再現の手がかりになります。

Web アプリケーション開発では、IME の変換中 (composition) イベントの処理が重要な課題です。IME で文字を入力している最中は「未確定文字列」がテキストフィールドに表示されますが、この状態で input イベントや keydown イベントを処理すると、変換確定前の中間状態が処理されてしまいます。compositionstart で変換開始を検知し、compositionend で変換確定を検知して、その間のイベント処理を抑制するのが標準的なパターンです。キーイベント単位で判定する場合は KeyboardEvent の isComposing プロパティを使います。これは、そのイベントが compositionstart から compositionend までの変換中に発生したかどうかを真偽値で返します。とくに落とし穴になるのが変換を確定する Enter です。Enter で送信するフォームや検索ボックスでは、変換を確定するつもりで押した Enter が送信まで実行してしまい、未確定のまま中途半端な文字列が送られます。Enter を処理する前に変換中かどうかを確認し、変換中なら送信しない分岐を入れておく必要があります。

IME に関するよくある問題として、リアルタイム検索やオートコンプリート機能での二重入力があります。ユーザーが「東京」と入力しようとして「とうきょう」と打つ過程で、未確定の「と」「とう」「とうき」…が逐次検索クエリとして送信されてしまうケースです。isComposing プロパティや composition イベントを適切にハンドリングすることで、この問題を回避できます。送信の起点を「変換が確定したとき」に寄せるだけでも、無駄な通信と的外れな候補表示はかなり減ります。

文字数カウントとの関連では、IME の変換中に表示される未確定文字列をどう扱うかが設計上のポイントになります。リアルタイムで文字数を表示するカウンターでは、未確定文字列を含めてカウントするか、確定後の文字列のみをカウントするかで挙動が変わります。多くの文字数カウントツールは確定後の文字列を対象としますが、入力中のフィードバックとして未確定文字列も含めたカウントを表示する実装もあります。判断の分かれ目は、その数値を何に使うかです。入力量の目安として見せるだけなら未確定文字列を含めても差し支えありませんが、上限を超えた入力を止めたり送信を拒否したりする用途では、確定後の文字列で判定しないと誤って弾きます。たとえば「東京」(2 文字) を入力する途中の読みは「とうきょう」(5 文字) なので、確定後なら収まる入力が変換中に上限へ達してしまいます。カウンターの数値が変換の途中でせわしなく増減するのも、未確定文字列を数えていることによる挙動です。