Shift_JIS は、日本語テキストを表現するための文字エンコーディングです。1982 年に実装され、MS-DOS や Windows で標準的に使用されてきました。策定にはアスキーやマイクロソフト、三菱電機など複数の企業が関わったと伝えられており、中心になったのはアスキーの技術者とされています。業界での実装が先にあり、JIS の規格として位置づけられたのは 1997 年の JIS X 0208 附属書 1 (シフト符号化表現) です。この順序が、後に述べる実装ごとの差異の遠因になっています。JIS X 0201 (半角英数字・半角カナ) と JIS X 0208 (漢字・全角文字) を組み合わせた可変長エンコーディングで、日本の IT 史において最も影響力のある文字コードの一つです。

Shift_JIS では半角英数字は 1 バイト、日本語 (ひらがな・カタカナ・漢字) は 2 バイトで表現されます。UTF-8 では日本語が 3 バイトになるため、日本語テキストに限ればバイト効率は Shift_JIS の方が優れています。ただし、Shift_JIS の収録文字数は約 7,000 字 (JIS 第一・第二水準) に限られ、Unicode の 14 万字以上と比べると大幅に少なくなります。絵文字や一部の漢字 (JIS 第三・第四水準) は表現できません。

Shift_JIS には「5C 問題」と呼ばれる有名な技術的課題があります。バックスラッシュ (0x5C) が日本語の 2 バイト目に出現する文字 (「表」「能」「ソ」など) があり、C 言語のエスケープ文字と衝突してプログラムが誤動作する原因になります。この問題は「ダメ文字」とも呼ばれ、Shift_JIS を扱うプログラミングでは常に注意が必要でした。事故が起きるのは、文字列を 1 バイトずつ走査して区切りや置換を行う処理です。「表」は 0x95 0x5C、「能」は 0x94 0x5C、「ソ」は 0x83 0x5C という並びなので、2 バイト目だけを見ると円記号やバックスラッシュと区別がつきません。区切り文字にこれらの記号を選んだ時点で破綻するため、Shift_JIS を扱うなら文字単位で境界を判定できるライブラリを通し、自作のバイト単位処理を避けるのが唯一の確実な回避策です。

UTF-8 への移行は世界的にほぼ完了しており、W3Techs の利用状況調査では 2026 年 8 月時点で Web サイトの 99.0% が UTF-8 で配信されています。しかし、日本のビジネス環境では Shift_JIS が依然として必要とされる場面があります。Excel で CSV ファイルを開く際のデフォルトエンコーディングが Shift_JIS であること、銀行や行政のレガシーシステムが Shift_JIS を前提としていること、EDI (電子データ交換) の一部規格が Shift_JIS を指定していることなどが理由です。CSV は拡張子にエンコーディングの情報を持たないため、受け取った側が何のつもりで読むかで結果が変わります。日本語環境の Excel はファイルを直接開くと Shift_JIS 系 (CP932) として解釈するので、UTF-8 で書き出した CSV は先頭に BOM を付けないと日本語が崩れます。逆に BOM を付けると、BOM を想定していないプログラムの取り込みでは先頭の項目名が一致せずに列の対応が崩れます。渡す先が Excel なら CP932 か BOM 付き UTF-8、プログラムなら BOM なし UTF-8 と、出力を用途別に分けておくのが確実です。

Shift_JIS と UTF-8 の変換時に文字化けが発生することがあります。特に「〜」(波ダッシュ、U+301C) と「～」(全角チルダ、U+FF5E) の変換、「−」(全角マイナス) と「－」(マイナス記号) の変換はトラブルの原因になりやすい文字です。Windows の CP932 (Windows-31J) は Shift_JIS の拡張版で、NEC 特殊文字や IBM 拡張文字を含むため、純粋な Shift_JIS との互換性にも注意が必要です。

文字数カウントの観点では、Shift_JIS と UTF-8 で同じテキストのバイト数が異なる点が重要です。日本語 1 文字は Shift_JIS で 2 バイト、UTF-8 で 3 バイトです。データベースのカラムサイズやファイルサイズの見積もりでは、使用するエンコーディングを考慮する必要があります。文字数カウントツールでは、文字数とバイト数を両方表示し、エンコーディングごとのバイト数の違いを可視化することで、ユーザーの実務に役立つ情報を提供できます。