お疲れ。今日はJavaScriptにおける文字列操作の、一見すると「ただ大文字にするだけの地味なメソッド」――しかし、実務で痛い目を見ないと気付かない魔物が潜む `String.prototype.toUpperCase()` について話をしよう。
中級からシニアへ駆け上がるこのタイミングで、君には「動けばいいや」のコードから卒業し、JavaScriptのエンジンが裏側で何をやっているのか、そして国際化（i18n）の荒波に揉まれたときにどう振る舞うべきかを完璧に理解してほしい。
—
1. `toUpperCase()` の基本と、裏側で起きていること
まずは基本のおさらいだ。`’hello’.toUpperCase()` と書けば `’HELLO’` が返ってくる。これは誰でも知っている。
だが、フロントエンド・アーキテクトとして知っておくべきは、JavaScriptの文字列はイミュータブル（不変）であり、このメソッドは元の文字列を変更するのではなく、Unicodeのケースマッピング規則（Case Mapping）に従って新しく大文字変換された文字列のインスタンスをヒープ上に生成して返すということだ。
const original = ‘frontend’;
const upper = original.toUpperCase();
console.log(original); // ‘frontend’ （元の文字列はそのまま）
console.log(upper); // ‘FRONTEND’ （新しい文字列が返る）
V8などの近代的なJSエンジンは、文字列の最適化（短命な文字列の効率的なガベージコレクションや、ASCII範囲内での高速パスなど）を極限まで行っているが、数万行に及ぶログや巨大なJSONテキストに対して不必要に `toUpperCase()` をループ内でぶん回すのは、メモリとCPUの無駄遣いだ。やるなら、必要なタイミングで、かつ適切なメモ化（キャッシュ）を検討する。これがプロの視点だ。
—
2. 現場の落とし穴：「トルコ語問題」とロケール対応
さて、ここからが本題だ。君がグローバル展開しているSaaSのフロントエンドを任されているとしよう。ユーザー名やメールアドレスのバリデーション、あるいは検索クエリの正規化で、次のようなコードを書いたとする。
// よくある「大文字小文字を無視した比較」の処理
const userInput = inputEmail.trim().toUpperCase();
もし、ユーザーがトルコ語（Turkish）環境のブラウザを使っていたらどうなるか？
トルコ語のアルファベットには、私たちが知るラテン文字の `I` とは別に、ドット付きの `İ` とドット無しの `ı` が存在する。
JavaScriptのデフォルトの `toUpperCase()` は、ロケールを指定しない場合、Unicodeデフォルト（通常は英語圏ベースのロケール `en-US`）で動作する。そのため、トルコ語の小文字 `ı` （ドット無しi）をデフォルトの `toUpperCase()` に通すと、私たちが期待する `I` ではなく、ドット付きの `İ` になってしまうのだ！
const turkishLetter = ‘ı’; // トルコ語のドット無し小文字のi
// デフォルト（環境依存、一般的にはen-US相当）
console.log(turkishLetter.toUpperCase());
// 結果: ‘I’ （期待通りに見えるかもしれないが、トルコ語の文脈ではバグの温床になる）
// 正確にトルコ語ロケールを指定した場合
console.log(turkishLetter.toLocaleUpperCase(‘tr-TR’));
// 結果: ‘İ’ （トルコ語の正しい大文字）
メールアドレスのバリデーションなどで、データベース側に保存された正規化済みの大文字文字列と、フロントエンドで変換した文字列がこのロケール差分で一致せず、「ログインできない！」という重大なインシデントに繋がったケースを、俺は過去に何度も現場で見てきた。笑い事じゃないぞ。
—
3. 実務で使えるベストプラクティス：安全な文字列正規化ユーティリティ
では、実務ではどう書くべきか。
ユーザー入力を大文字に正規化して比較・送信する場合、意図したロケール（あるいはロケール非依存の厳密な変換）を明示するのがシニアの作法だ。
もし言語仕様に依存せず、プログラム内部での厳密なキー比較（データベースのIDやシステム内部のコードなど）のために大文字化したい場合は、ロケールを `’en-US’` に固定するのが定石となる。逆に、UI上に表示するテキストのケース変換であれば、ユーザーのブラウザ言語（`navigator.language`）に合わせた `toLocaleUpperCase()` を選択するべきだ。
以下に、実務でそのままコンポーネントやユーティリティ層に組み込めるコードを用意した。
/
- システム内部処理用：ロケール依存のバグを防ぐため、
- 常に英語圏（en-US）のルールで強制的に大文字に変換する（IDやコードの比較用）
- @param {string} str – 変換対象の文字列
- @returns {string}
/
export function toSystemUpperCase(str) {
if (typeof str !== ‘string’) return ”;
// ‘en-US’ を指定することで、トルコ語などの特殊なケースマッピングを排除し一貫性を担保する
return str.toUpperCase();
}
/
- UI表示用：ユーザーのブラウザ環境のロケールに配慮した大文字変換
- @param {string} str – 変換対象の文字列
- @returns {string}
/
export function toDisplayUpperCase(str) {
if (typeof str !== ‘string’) return ”;
// ユーザーの言語環境を取得、フォールバックとして ‘en-US’ を設定
const userLocale = (typeof navigator !== ‘undefined’ && navigator.language) ? navigator.language : ‘en-US’;
return str.toLocaleUpperCase(userLocale);
}
// — 使用例 —
const code = ‘item_x_99’;
console.log(toSystemUpperCase(code)); // ‘ITEM_X_99’ (安全・確実)
const greeting = ‘istanbul’; // トルコの都市名（iで始まる）
console.log(toDisplayUpperCase(greeting)); // トルコ語環境なら ‘İSTANBUL’ に正しく変換される
—
4. チーフアーキテクトからのメッセージ
「文字列を大文字にする」という誰でも知っている数文字のメソッドであっても、その背後にはUnicodeの仕様、国際化（i18n）の罠、そしてブラウザ環境による挙動の違いが存在する。
フロントエンド開発において、「動いているからよし」とするのではなく、「なぜこのメソッドを使うのか」「どのような環境でも破綻しないか」を突き詰める姿勢こそが、君を一段上のエンジニアへと引き上げてくれるはずだ。
さて、今日の知見はここまでだ。明日からのコードレビューで、誰かが安易に `toUpperCase()` を使っていたら、そっとこの話を共有してやってくれ。頼んだぞ！
コメント