3.3ローカライゼーションと国際化

「日本語のはずが文字化けする」「ソートの結果が環境で違う」——原因はたいていロケールか文字コードです。日本語環境の管理者にとっては実害が身近なだけに、仕組みから理解しておくと強いテーマです。

3.3.1ロケールと環境変数

• 国際化（i18n）＝ソフトを多言語対応できる作りにすること／ローカライゼーション（l10n）＝特定の言語・地域に合わせ込むこと。
• ロケール＝言語・地域・文字コードの組（ja_JP.UTF-8 ＝日本語/日本/UTF-8）。現在値の確認＝locale コマンド・利用可能一覧＝locale -a。
• 優先順位＝LC_ALL（全カテゴリを強制上書き）＞ LC_*（LC_TIME・LC_COLLATE 等の個別カテゴリ）＞ LANG（既定値）。
• LANG=C（POSIX ロケール）＝メッセージが英語・ソートがバイト順になる基準環境。スクリプトでコマンド出力を parse するときは LANG=C にして、翻訳による出力差を排除するのが定石。

3.3.2文字コードと iconv

• ASCII＝英数字と記号の7ビット基本セット／ISO-8859＝欧州言語向けの8ビット拡張群／Unicode＝全世界の文字に番号を割り当てる規格で、その代表的な符号化が UTF-8（ASCII 互換・現在の Linux 標準）。
• ISO-2022-JP＝日本語メールで伝統的に使われる7ビット符号化（JIS）。
• iconv＝文字コード変換（iconv -f SHIFT_JIS -t UTF-8 old.csv > new.csv＝-f 変換元・-t 変換先）。対応一覧は iconv -l。

なぜ LANG=C が「スクリプトの保険」になるのかを具体で見ましょう。df -h の出力見出しは、日本語ロケールでは「使用%」、英語では「Use%」——grep や awk での抜き出しがロケール次第で壊れるわけです。スクリプト冒頭（またはコマンド単位で LANG=C df -h）で C ロケールに固定すれば、どのサーバーでも同じ英語出力・同じバイト順ソートが保証されます。もうひとつの実務定番が文字化けファイルの救出です。Windows から届いた Shift_JIS の CSV が Linux（UTF-8 前提）で化けたら、iconv -f SHIFT_JIS -t UTF-8 受領.csv > 変換済.csv で正規化します。優先順位の実験は LC_TIME=C date と LC_ALL=ja_JP.UTF-8 LC_TIME=C date を見比べるのが早く、後者では LC_ALL が LC_TIME を握りつぶして日本語表示になります——「LC_ALL は個別設定をすべて上書きする」を体で覚えられる例です。

3.3.3この節のまとめ

• 優先度 LC_ALL＞LC_*＞LANG・確認は locale（-a）。スクリプトの parse は LANG=C で固定
• UTF-8＝Unicode の符号化（Linux 標準）・メールの伝統は ISO-2022-JP。変換は iconv -f 元 -t 先