Webアプリ文字変換の実装方法｜フロントエンド・バックエンド連携

Web アプリ 文字変換と入力モードを区別する

Web アプリ 文字変換では、すでに入力された文字列を別の表現へ写す処理を設計します。一方、IMEの入力モード切り替えは、これから入力する文字の候補や種類を変えます。保存済みの文やフォーム値を扱うなら、変換ルールと対象データを定義します。利用者の入力方式まで制御しようとすると、OS、ブラウザー、IMEごとの差が加わり、同じ結果を保証しにくくなります。

Web アプリ 文字変換の設計では、まず入力値の用途を分類してください。氏名や住所の検索用キー、商品コード、自由記述、表示専用の文章では、許される変化が違います。たとえば商品コードで英数字の幅を統一しても、自由記述中の丸数字や単位記号まで変えてよいとは限りません。「全角を半角にする」という依頼を、変換対象の文字クラスと対象外の文字まで落とし込むと、実装とレビューが具体的になります。

Web アプリ 文字変換のフロントエンドはプレビューを担当する

Web アプリ 文字変換をブラウザー側でプレビューすると、利用者は送信前に変化を確認できます。短い入力は通信を待たずに更新できますが、その値だけで登録完了と見なしてはいけません。開発者ツールからリクエストを変更したり、別のクライアントからAPIを呼び出したりできるためです。クライアント処理を省略されてもサーバー側で同じルールが働く構成にします。

Web アプリ 文字変換のプレビューには、JavaScriptのString.prototype.normalize()を利用できます。このメソッドは指定したUnicode正規化形式で文字列を返します。次の例では入力欄の値をNFKCで表示し、HTML文字列として解釈させません。textContentを使うことで、入力文字列にタグのような文字が含まれていても画面上のテキストとして扱えます。

const input = document.querySelector("#sourceText");
const preview = document.querySelector("#previewText");

function updatePreview() {
  const source = input.value;
  preview.textContent = source.normalize("NFKC");
}

input.addEventListener("input", updatePreview);

Web アプリ 文字変換のフォームでは、このプレビューを確定値として直接保存せず、送信時に元の入力と選択したモードをAPIへ渡します。応答が返るまでは「処理中」、成功時には確定結果、通信や入力エラー時には再試行できる説明を表示します。複数の入力欄で変換するなら、画面ごとに異なる処理を複製するより、共通モジュールにまとめる方が仕様変更を追いやすくなります。

Web アプリ 文字変換では、変換前後の差を示す機能も役立ちます。長文やフォームの登録前に、変更された文字を確認できる表示を設けると、利用者が意図しない変換に気付きやすくなります。差分表示は補助情報として用い、変換の正しさを利用者の目視だけに委ねないようにします。

Web アプリ 文字変換のバックエンドでルールと入力を検証する

Web アプリ 文字変換のAPIでは、入力の型、文字数、許可する変換モードをサーバーで検証します。ブラウザーの必須入力や文字数制限は操作性のために残しつつ、サーバーでも同じ制限を適用してください。本文サイズの上限をHTTPパーサーにも設定すると、アプリケーションの処理へ渡す前に過大なJSONを拒否できます。利用者へ返すエラーは入力を直せる内容にし、内部スタックトレースや不要な入力原文は含めません。

Web アプリ 文字変換APIの例では、NFKCだけを許可し、文字列以外、未知のモード、長すぎる入力を拒否します。ここではコードポイント数を数えますが、製品の「文字数」が書記素クラスタ数やバイト数を意味する場合は、要件に応じた計測方法を選んでください。入力サイズ制限と業務上の文字数制限は別の防御として設定します。

app.use(express.json({ limit: "16kb" }));

app.post("/api/text/normalize", (req, res) => {
  const body = req.body ?? {};
  const { text, mode } = body;

  if (typeof text !== "string") {
    return res.status(400).json({ code: "invalid_text" });
  }
  if (mode !== "nfkc") {
    return res.status(400).json({ code: "unsupported_mode" });
  }
  if (Array.from(text).length > 5000) {
    return res.status(413).json({ code: "text_too_long" });
  }

  const normalized = text.normalize("NFKC");
  return res.json({
    text: normalized,
    mode,
    changed: normalized !== text
  });
});

Web アプリ 文字変換APIでは、JSON構文エラーや本文サイズ超過も統一したJSONエラー形式で返すミドルウェアを用意します。認証、レート制御、ログへの入力記録はAPIのリスクに合わせて判断し、自由記述を無条件にログへ出さないでください。変換結果をHTMLへ表示する側では、通常の出力エスケープを維持します。変換は入力検証や出力エスケープの代わりにはなりません。

Web アプリ 文字変換で保存方式を考えるとき、検索の表記ゆれ対策だけが目的なら、原文を上書きせず、必要な場合に限り正規化済みの検索キーを別に持つ方法があります。原文と正規化値を両方保存するときは、個人情報の扱い、用途、保持期間、参照権限を検討してください。データの目的を分ければ、将来ルールを変更しても元データから再計算できる可能性が残ります。

Web アプリ 文字変換でNFKCを使う範囲を決める

Web アプリ 文字変換にNFKCを使う場合は、互換文字を正規化する形式である点を理解します。全角英数字が通常のASCII表記へ変わる例がある一方、半角カタカナ、丸数字、単位記号なども変化することがあります。そのため「全角を半角へ変換するAPI」と同じ意味で扱わず、どの表現を等価と見なすかを項目や検索目的ごとに決めます。

Web アプリ 文字変換の対象を英数字と全角スペースだけにするなら、範囲を明示できます。JavaScriptでは全角ASCII範囲から半角ASCII範囲へ一定値を引き、全角スペースを半角スペースへ写せます。この方式では半角カタカナや丸数字は変更されません。対象が増えたときは対応表とテストを更新し、曖昧な文字を暗黙に処理しないようにします。

function toHalfWidthAscii(value) {
  return value
    .replace(/[\uFF01-\uFF5E]/g, (char) =>
      String.fromCharCode(char.charCodeAt(0) - 0xFEE0)
    )
    .replace(/\u3000/g, " ");
}

toHalfWidthAscii("ＡＢＣ　１２３"); // "ABC 123"

Web アプリ 文字変換で、検証前に正規化するのか、原文を受け付けて検索用の値だけ正規化するのかは項目の仕様で決めます。どの方式でも、クライアントだけの検証をセキュリティ境界にせず、サーバーが受け取った値を許可リスト、長さ、形式などで検証します。正規化後の値を別のルールで再解釈する処理があるなら、その順序も仕様とテストに含めます。

Web アプリ 文字変換APIの契約を決める

Web アプリ 文字変換APIは、入力、モード、成功時の出力、失敗時の形式を先に決めると、フロントエンドとバックエンドを並行して実装しやすくなります。例えばリクエストにtextとmodeを含め、成功時に変換後のtext、適用したモード、値が変わったかを返します。利用者の画面に必要なデータだけを返し、内部処理の詳細をレスポンスへ漏らさないようにします。

Web アプリ 文字変換の出力を実際に確かめたい場合は、既存の全角半角変換ツールを使えます。複数言語での実装差はPython・JavaScript・C#の文字列処理比較、Javaのサーバー処理はJavaの全角半角変換実装も参考になります。

Web アプリ 文字変換の境界値を含むテストを用意する

Web アプリ 文字変換では、正常な全角英数字だけでなく、変換対象と対象外が隣り合う入力をテストします。NFKCを選ぶなら、互換文字が変わることも期待値に含めます。仕様が「この範囲だけ変える」であれば、それ以外が元のまま残ることを確認します。同じ入力を繰り返し処理したときの結果、空文字、改行を含むテキストも確認すると、画面とAPIの差が見つかりやすくなります。

Web アプリ 文字変換をフロントエンドとバックエンドで別々に実装する場合は、同じ入出力例を共有テストデータにします。APIの単体テストでは許可モード、入力上限、型エラー、成功時のレスポンスを確認します。画面側では入力中のプレビュー、通信中の二重送信、成功後の差分、失敗後の再試行を確認します。同じ仕様からテストを作れば、片方だけが更新された状態を検出できます。

Web アプリ 文字変換の仕様を変えるときは、移行方法も考えます。既に正規化済みの値を再変換すると結果が変わる場合、保存済みデータを一括更新する前に影響範囲とロールバック方法を用意します。原文と検索用キーを分けておけば、再計算や新旧ルールの比較をしやすくなります。ただし、監査や復元に不要な原文を無期限に保存する理由にはならないため、データ保持方針も併せて決めてください。

Web アプリ 文字変換についてよくある質問

Web アプリ 文字変換はフロントエンドだけで完結できますか？

プレビューには使えますが、保存や検索に利用する確定値はサーバーでも同じルールで処理・検証します。ブラウザーの処理は書き換えられるため、APIが受け取った値をそのまま信頼しないでください。

Web アプリ 文字変換でNFKCをすべての入力に適用してよいですか？

一律適用は避け、項目ごとに対象と期待値を決めます。半角カタカナや互換文字も変化し得るため、URL、コード、認証情報などは通常の文章とは別に扱います。

Web アプリ 文字変換の前に、元の文字列も保存すべきですか？

原文表示や差分確認が必要な場合に限って検討します。原文には個人情報が含まれる可能性があるため、目的、保存期間、参照権限を決め、不要なら保存しません。