大文字・小文字変換の「落とし穴」――JavaScriptのロケール対応を極める
フロントエンドの現場で、「`toLowerCase()` を使っておけば大文字小文字の区別なんて余裕だろ」と高を括っていると、いつか必ず足元をすくわれる日が来る。
ユーザー入力の正規化や、検索機能のフィルタリング。一見単純な文字列操作に見えるこの処理が、国際化（i18n）が求められる現代のWebアプリにおいて、どれほど「地雷」になり得るか。今日は、中級エンジニアなら絶対に押さえておくべき「ロケール対応の極意」を伝授しよう。
—
なぜ `toLowerCase()` だけでは不十分なのか
まず、基本の確認だ。`toLowerCase()` や `toUpperCase()` は、Unicodeの標準的なマッピングルールに従って変換を行う。しかし、この「標準」が全ての言語にとって正しいわけではない。
最も有名な例がトルコ語だ。
トルコ語には、ドット付きの「i (İ/i)」と、ドットなしの「ı (I/ı)」という別々の文字が存在する。英語の感覚で「i」を小文字化すると、トルコ語の文脈では意味が崩壊してしまうのだ。
現場で遭遇する「事故」の再現
const text = ‘ISTANBUL’;
// 通常の変換
console.log(text.toLowerCase());
// 結果: “istanbul”
// （トルコ語的には：ドット付きの「i」が残ってしまい、誤った綴りになる）
// トルコ語のルールを適用
console.log(text.toLocaleLowerCase(‘tr-TR’));
// 結果: “ıstanbul”
// （これが正しいトルコ語の変換）
このように、ユーザーのブラウザ環境や入力内容が多言語に渡る場合、`toLocaleLowerCase()` や `toLocaleUpperCase()` を使わなければ、文字列の比較ロジックが破綻する。
—
実務でのベストプラクティス：ロケール指定の鉄則
では、どのように実装すべきか。現場のコードで最もよくあるミスは「引数を省略する」ことだ。
`toLocaleLowerCase()` に引数を渡さない場合、JavaScriptエンジンは「ホスト環境（ブラウザ）のロケール」を勝手に採用する。ユーザーが海外旅行中に現地のネットカフェからアクセスしたらどうなるか？ サーバーサイドのテスト環境が英語ロケールで、手元の開発環境が日本語ロケールだったら？ 環境によって結果が変わるコードは、バグの温床でしかない。
堅牢な実装サンプル
/
- 言語ロケールを意識した安全な文字列変換関数
- 予期せぬ環境依存を避けるため、明示的にロケールを指定する
/
const safeNormalize = (str, locale = ‘en-US’) => {
if (typeof str !== ‘string’) return ”;
// 比較や検索のために正規化する際は、ロケールを固定して変換するのが鉄則
return str.toLocaleLowerCase(locale);
};
const input = ‘DİYARBAKIR’; // トルコ語の都市名
// 検索用インデックスを作るなら、環境に依存しないロケールを指定する
const normalized = safeNormalize(input, ‘tr-TR’);
console.log(normalized); // “diyarbakır” となり、検索ロジックと正しくマッチする
—
ブラウザの裏側で起きていること
少し深掘りしよう。`toLocale…` メソッドを呼ぶと、エンジン内部ではその言語のUnicodeデータテーブルを参照しにいく。
ブラウザは単に文字コードをずらしているわけではない。Unicodeの「SpecialCasing.txt」という巨大なルールセットを参照し、「この言語のこの文字は、こういうケースではこう化ける」という複雑な判定を行っている。
この処理は、単純な `toLowerCase()` よりも計算コストがかかる。だからといって、パフォーマンスを優先して標準メソッドを使うのは、「正しい表示や正しい検索」というユーザー体験を切り捨てることと同義だ。
今日から現場でできること
1. 「不特定多数のユーザーが使うアプリ」なら、必ずロケールを指定する
検索やフィルタリングのキーとして文字列を正規化する場合、`toLocaleLowerCase(‘en-US’)` のように、ベースとなるロケールを一つに決めて運用するのが最も安全だ。
2. ユーザーの言語設定に合わせるべき箇所を見極める
ユーザーの表示名や、UI上の特定の言語表示など、「ユーザーが今使っている言語のルールに準拠すべき箇所」だけ `toLocaleLowerCase(navigator.language)` を使うように使い分けよう。
3. テストコードでエッジケースを網羅する
「トルコ語の『I』」のような、変換前後で文字の形や長さ（！）が変わるケースをテストケースに含めるだけで、あなたのコードの信頼性は一段階上のレベルに到達する。
—
最後に
フロントエンドエンジニアが扱うのは、単なる文字列ではない。それはユーザーのアイデンティティであり、文化そのものだ。
JavaScriptのメソッド一つにしても、その背景にある言語学的な仕様まで一歩踏み込んで実装できるエンジニアは強い。コードは常に「なぜこのメソッドを選んだのか」を説明できるように書いてほしい。
今日から君の書くコードが、どの国で、どんな言語設定のユーザーが使っても正しく動くことを願っている。困ったことがあれば、またいつでも聞いてくれ。
コメント