先に要点
- Shift_JIS は日本語 Windows や古い業務システムで長く使われてきた文字コードです。
- 今の標準寄りは UTF-8 ですが、CSV を Excel で開く運用、古い基幹システム、外部取引先との受け渡しでは Shift_JIS がまだ出てきます。
- UTF-8 と Shift_JIS が混ざると文字化けや取り込み失敗が起きやすいです。
- 今の実務では 新規開発の基準は UTF-8 にしつつ、受け渡し相手が Shift_JIS 前提なら出力だけ合わせる、という考え方が現実的です。
Shift_JIS って古い文字コードでしょ と思っていても、CSV ダウンロード、Excel、古い業務システム、取引先とのファイル連携では今でも普通に出会います。
逆に UTF-8 に全部そろえれば解決 と言い切れないのが実務のややこしいところです。
このページでは、Shift_JIS とは何かを入り口にしつつ、なぜまだ残っているのか、どこで事故が起きるのか、今はどう付き合うべきかを整理します。
先に全体像をつかみたいなら UTF-8とは?文字コードを初心者向けにどう理解すればいいのか、文字化け全般から見たいなら 文字化けとは?防止方法、復元方法は? もつながります。
Shift_JISとは何か
Shift_JIS は、日本語を扱うために広く使われてきた文字コードのひとつです。
特に日本語版 Windows、古いアプリ、古い業務ソフト、業務向け CSV などで長く使われてきました。
今の感覚だと UTF-8 を前提にする場面が多いですが、Shift_JIS は 昔の遺産 というだけではありません。
今も動いているシステムと、人が実際に使っている運用の中に残っている ので、実務ではまだ無視できません。
UTF-8と何が違うのか
大きな違いは、使える文字の広さ と 今の標準との相性 です。
Shift_JISの特徴
- 日本語環境で長く使われてきた
- 古い Windows や古い業務ソフトとの相性がよいことがある
- 使えない文字や、環境差が出やすい文字がある
- グローバル前提の Web や API では基準にしづらい
UTF-8の特徴
- 現在の Web、API、アプリ開発で標準寄り
- 日本語だけでなく多言語や記号も扱いやすい
- OS や言語をまたぐ連携に向いている
charset=utf-8など周辺仕様とも整合しやすい
つまり、新しく作る側の基準は UTF-8 です。
ただし、相手側が Shift_JIS を前提にしているなら、そこに合わせた出力や変換が必要になります。
なぜ今でも実務で出てくるのか
もう古いなら消えそうなのに、なぜまだ残っているのか という疑問はもっともです。
理由は、技術そのものより 周辺の人と運用が Shift_JIS 前提で動いている からです。
1. Excel前提のCSV運用が多い
日本の業務では、CSV をシステム連携というより Excel で開いて確認するファイル として使うことがまだ多いです。
このとき、利用者側の手順が ダブルクリックで開く に寄っていると、UTF-8 CSV が期待どおり読まれず、Shift_JIS 前提の方がトラブルが少ないことがあります。
2. 古い業務システムが現役
基幹システム、会計システム、販売管理、EDI まわりなどでは、長く動いている仕組みがそのまま使われています。
こうしたシステムはファイル入出力の前提まで含めて固定されていることが多く、文字コードだけを簡単には変えられません。
3. 取引先との受け渡し仕様が固定されている
社内で UTF-8 に統一していても、外部の指定が CSV は Shift_JIS でください なら合わせるしかありません。
実務では 理想の標準 より 相手が読めること が優先される場面があります。
Shift_JISで起きやすい困りごと
Shift_JIS 自体が絶対に悪いわけではありません。
困りごとの多くは、UTF-8 前提の世界と混ざること で起きます。
1. UTF-8をShift_JISとして読んで文字化けする
典型例です。UTF-8 で保存した CSV やテキストを、Shift_JIS 前提のツールで開くと文字が崩れます。
これはファイルが壊れたというより、読む側の前提がズレた 状態です。
2. Shift_JISで表しにくい文字がある
UTF-8 なら素直に扱える文字でも、Shift_JIS では表せない、別字になる、環境によって見え方が変わる、という問題があります。
人名、地名、記号、機種依存文字まわりで特に出やすいです。
3. WebやAPIの基準と相性が悪い
Web では Content-Typeとは?Webで charset=utf-8 を付ける理由 のように UTF-8 前提で組むのが自然です。
JSON、HTTP、各種ライブラリ、クラウドサービスも UTF-8 寄りなので、Shift_JIS を中心に置くと毎回変換の境界が生まれます。
4. 開発者と利用者で前提がズレやすい
開発側は 全部 UTF-8 でいきたい、利用者側は Excel でそのまま開きたい、取引先は Shift_JIS 指定。
このズレがあると、実装は正しくても運用で事故ります。
今の実務ではどう付き合うべきか
ここは白黒ではなく、役割分担で考えるのがいちばん安定します。
原則はUTF-8を基準にする
新規開発、Web、API、DB、ログ、アプリ内部処理は、まず UTF-8 基準でそろえるのがよいです。
複数環境をまたぐ連携や将来の保守を考えると、その方が無理がありません。
受け渡しの出口だけShift_JISにする
利用者や連携先の都合で Shift_JIS が必要なら、内部まで Shift_JIS に寄せるのではなく、出力時だけ変換する 方が安全です。
こうすると、アプリ内部の基準を崩さずに、相手の事情にも合わせられます。
仕様書に文字コードを明記する
CSV を出します だけでは足りません。
実務では次のあたりまで決めておくと事故が減ります。
- 文字コードは UTF-8 か Shift_JIS か
- BOM は付けるか
- 区切り文字はカンマかタブか
- 改行コードは何か
- 想定する開き方は Excel 直開きか、取り込みか
じゃあShift_JISはもう使わない方がいいのか
結論は、新規の基準としては積極的に選ばない、でも 現場の受け渡しではまだ普通に使う です。
たとえば次のように考えると整理しやすいです。
Shift_JISを選ぶ理由がある場面
- 受け手が日本語版 Excel をそのまま開く前提
- 既存システムの受け入れ仕様が Shift_JIS 固定
- 取引先から文字コード指定が来ている
UTF-8を選ぶべき場面
まとめ
Shift_JIS は、日本語の業務現場で長く使われてきた文字コードです。
今の標準寄りは UTF-8 ですが、CSV、Excel、古い業務システム、外部連携ではまだ現役です。
大事なのは 古いから全部捨てる でも 慣れているから全部 Shift_JIS でもなく、
- 内部の基準は UTF-8
- 必要な受け渡しだけ Shift_JIS に合わせる
- 文字コードを仕様として明記する
という整理で考えることです。
そうすると、文字化けを減らしつつ、現場の実情にも合わせやすくなります。
このあと一緒に読みたい
参考リンク
- Unicode Standard, East Asia section: JIS, Shift_JIS and Unicode
- Microsoft Support: Opening CSV UTF-8 files correctly in Excel
- WHATWG: Encoding Standard