LASSIC Media らしくメディア
文字コードとは？文字化けの原因と対策を解説
LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発・検証を受託
メールの本文が「??????」の連続になっていたり、CSVファイルをExcelで開いたら住所欄が意味不明な記号に変わっていたりする現象に、業務の中で一度は遭遇したことがあるのではないでしょうか。このような文字化けは偶然のトラブルではなく、コンピュータが文字をどのように数値へ対応づけているか、その「文字コード」の扱いに起因して起こるものです。原因を切り分けられないまま場当たり的に再送信や再入力を繰り返していると、同じトラブルが形を変えて再発しやすくなります。
本記事では、文字コードの基本的な仕組みから、ASCII・Shift_JIS・EUC-JP・UTF-8・Unicodeといった主要な文字コードの関係と違い、文字化けが発生する具体的な仕組み、そして実務で取り得る対策までを整理するものです。特定製品の比較機能やDNSの仕組みには立ち入らず、情シス・開発担当者が押さえておきたい「文字コードそのものの理解」に焦点を当てて解説します。
この記事のポイント
- 文字コードとは、文字と数値（バイト列）を対応づける規則であり、コンピュータは文字を直接扱っているわけではありません。
- 文字化けは、文字を符号化したときの規則と、それを読み込む側が想定している規則が一致しないときに起こります。
- 実務ではUTF-8への統一とエンコード宣言の明示が基本の対策になり、CSV・DB・API連携ではあわせて改行コードや文字集合の範囲も確認しておく必要があります。
文字コードとは何か
文字コードとは、文字と数値（バイト列）を対応づける規則のことです。私たちが画面上で目にしている「あ」や「A」といった文字は、コンピュータの内部では特定の数値として保持されており、その数値を画面表示用の文字に変換する際の対応表が文字コードにあたります。
コンピュータが扱えるのは数値だけ
コンピュータの記憶装置や通信経路は、突き詰めれば0と1の並びであるビット列しか保持できません。文字を保存したり送受信したりするためには、あらかじめ「どの数値をどの文字に対応させるか」を決めておく必要があります。例えば数値65をアルファベットの「A」に対応させる、といった具合です。この対応関係のルール一式が文字コードであり、送り手と受け手の双方が同じ対応表を使って初めて、文字は正しく再現されます。
符号化方式（エンコーディング）という仕組み
文字を数値に変換する処理を「符号化（エンコード）」、逆に数値から文字へ戻す処理を「復号（デコード）」と呼びます。この符号化・復号のルールをまとめて符号化方式、あるいはエンコーディングと言います。文字コードという言葉は、狭い意味では「どの文字にどの数値を割り当てるか」という文字集合そのものを指す場合と、広い意味では符号化方式まで含めて指す場合があり、文脈によって指す範囲が異なる点には注意が必要でしょう。実務上は、両者を厳密に区別せず「UTF-8」「Shift_JIS」といった符号化方式の名称で会話が進むことがほとんどです。
主要な文字コードの種類と違い
現在広く使われている文字コードには、成り立ちや対応できる文字の範囲が異なるいくつかの種類があります。代表的なものを整理します。
ASCII（アスキー）
ASCIIは、アルファベット・数字・基本的な記号だけを1バイト（7ビット）で表現する、もっとも基礎的な文字コードです。日本語のようなアジア圏の文字は含まれておらず、対応できる文字数は128種類にとどまります。多くの後発の文字コードは、ASCIIの範囲との互換性を保つ設計になっているものです。
Shift_JISとEUC-JP（日本語向けの文字コード）
日本語を扱うために、ASCIIを拡張する形でいくつかの文字コードが個別に開発されてきました。Shift_JISはWindows環境を中心に広く使われてきた符号化方式であり、EUC-JPは主にUnix系システムで使われてきた符号化方式です。どちらも日本語の文字集合であるJIS X 0208をもとにしていますが、同じ文字に割り当てるバイト列の規則が異なるため、Shift_JISで符号化されたデータをEUC-JPとして読み込む、あるいはその逆を行うと、文字化けが発生します。両者は似て非なる規格として扱う必要があるでしょう。
UnicodeとUTF-8・UTF-16
Unicodeは、世界中の文字を一つの体系にまとめて番号（コードポイント）を割り当てる、いわば「世界共通の文字の台帳」にあたる規格です。Unicode自体は文字と番号の対応を定めたものであり、その番号をどのようなバイト列に変換するかは、UTF-8・UTF-16・UTF-32といった別の符号化方式が担っています。中でもUTF-8は、ASCIIの範囲をそのまま1バイトで表現しつつ、日本語を含む多バイト文字は2〜4バイトで可変長に表現する方式であり、Web標準として広く採用されている符号化方式です。
| 文字コード | 対応する文字の範囲 | 1文字あたりのバイト数 | 主な利用場面 |
|---|---|---|---|
| ASCII | 英数字・基本記号のみ | 1バイト固定 | プログラムの識別子・古い通信プロトコル |
| Shift_JIS | 日本語（JIS X 0208中心） | 1〜2バイト | Windows環境の古いシステム・一部の業務ファイル |
| EUC-JP | 日本語（JIS X 0208中心） | 1〜2バイト | Unix系システム・レガシーなサーバー環境 |
| UTF-8 | Unicodeの全文字 | 1〜4バイト（可変長） | Webサイト・API・現行システムの標準 |
| UTF-16 | Unicodeの全文字 | 2または4バイト | Windows内部処理・一部プログラミング言語の内部表現 |
文字化けが起きる仕組み
文字化けは、突き詰めると「符号化したときの対応表」と「復号するときの対応表」が一致していないことによって起こります。具体的にどのような場面で不一致が生まれるのか、順に見ていきましょう。
符号化方式の宣言と実際のデータが食い違う
Webページやメールには、本文がどの符号化方式で書かれているかを示す宣言（HTMLのcharset指定や、メールヘッダーのContent-Typeなど）が付与されます。ところが、実際のファイルはShift_JISで保存されているのに宣言だけがUTF-8になっている、あるいは宣言そのものが抜けているといったケースも珍しくないものです。受け手のブラウザやメールソフトは宣言を信じて復号を試みるため、宣言と実データが食い違っていると、文字化けとして表面化します。
文字コード変換時の情報欠落と機種依存文字
ある符号化方式から別の符号化方式へデータを変換する際、変換先の文字集合に存在しない文字があると、その文字は変換できずに欠落したり、代替の記号に置き換えられたりします。特に丸囲み数字やローマ数字、一部の環境依存の記号（いわゆる機種依存文字・環境依存文字）は、Shift_JISの独自拡張領域に含まれる一方でUnicode側での対応が環境によって異なるため、システム間でのデータ連携時にトラブルの原因になりやすい文字群です。
BOM（バイトオーダーマーク）の扱い
UTF-8やUTF-16のファイルの先頭には、そのファイルがUnicode系の符号化方式であることを示す数バイトの目印（BOM）が付与される場合があります。BOMの有無は文字コードの判定を助ける一方、BOM付きのファイルを想定していないプログラムで読み込むと、先頭に見えない不要な文字が混入したものとして扱われ、CSVの1行目の項目名がずれる、比較処理が一致しないといった不具合につながることがあるでしょう。
実務での対策
文字化けを未然に防ぎ、発生した際にも速やかに切り分けるためには、次のような対策が有効です。
文字コードをUTF-8に統一する
新規に構築するシステムやWebサイトでは、文字コードをUTF-8へ統一しておくことが基本の対策になります。UTF-8はUnicodeの全文字を表現でき、Shift_JISやEUC-JPと比べて多言語対応や他システムとの連携でも扱いやすい符号化方式です。既存システムがShift_JISやEUC-JPを使っている場合でも、周辺システムとの連携部分から段階的にUTF-8へ寄せていく方針が現実的でしょう。
HTML・メール・APIでエンコードを明示する
HTMLでは<meta charset="utf-8">のように文書の先頭で符号化方式を明示し、メール送信やAPIレスポンスでもヘッダーに符号化方式を明記しておくことが大切です。宣言を省略すると、受け手側の環境やソフトウェアの初期設定に依存した推測処理に委ねられ、環境が変わった途端に文字化けが再発する不安定な状態になりやすくなります。
データベース・API・CSV連携時の注意点
システム間でデータをやり取りする際は、次の観点を確認しておくと、文字化けの発生を抑えやすいでしょう。
- データベースの文字コード設定（サーバー・データベース・テーブル・接続の各レベル）がすべてUTF-8系に揃っているか
- CSVファイルの文字コードとBOMの有無を、送信側・受信側で事前にすり合わせているか
- APIのリクエスト・レスポンスヘッダーに符号化方式が明記されているか
- 外部ベンダーから受領するファイルの文字コードが、社内システムの想定と一致しているか
- 機種依存文字を含む項目（氏名・住所など）について、変換時の扱いをあらかじめ決めているか
文字化けが発生した場合の調査手順
実際に文字化けが発生した場合は、次の順序で切り分けていくと原因を特定しやすくなります。
- 文字化けしたファイルやデータを、複数の文字コードで開き直して元の文字が再現されるものを探す
- 送信側・保存側で実際にどの符号化方式で出力しているかを、宣言ではなく実データから確認する
- 途中経路（メールサーバー・変換バッチ・外部連携API）で符号化方式の変換処理が挟まっていないかを確認する
- BOMの有無や改行コードの違いなど、符号化方式以外の要因が混在していないかもあわせて確認する
原因の切り分けに時間がかかる場合は、発生した箇所（表示側・保存側・連携先）を一つずつ固定しながら再現条件を絞り込んでいく進め方が、遠回りのようでいて結果的に早く解決につながることが多いものです。
まとめ：文字コードは「対応表の一致」で捉える
本記事では、文字コードの基本的な仕組みと、ASCII・Shift_JIS・EUC-JP・UTF-8・Unicodeといった主要な文字コードの関係、そして文字化けが起きる仕組みと実務での対策を整理しました。文字化けは、符号化する側と復号する側で使っている対応表が一致していないときに起こる、原理としてはシンプルな現象です。
UTF-8への統一とエンコード宣言の明示を基本としつつ、データベースやCSV・API連携ではBOMや機種依存文字といった細部まで確認しておくことが、システム間のデータ連携を安定させる土台になります。
よくある質問
文字コードと文字エンコーディングは同じ意味ですか。
文脈によって使い分けられることがある言葉です。厳密には、文字コードは文字と番号の対応を定めた文字集合を指し、文字エンコーディングはその番号をバイト列へ変換する符号化方式を指しますが、実務ではあまり区別せずに「文字コード」という言葉が符号化方式まで含めて使われる場面がよく見られます。
UTF-8に統一すれば文字化けは起きなくなりますか。
送信側・受信側の双方がUTF-8で正しく符号化・復号している限り、文字化けの主要な原因の一つは解消されます。ただし、古いシステムからのデータ変換時に文字が欠落する場合や、BOMの有無・改行コードの違いなど別の要因が絡む場合もあるため、UTF-8への統一だけで全ての文字化けを防げるとは限りません。
Shift_JISとEUC-JPは、どちらか一方に統一すべきですか。
新規のシステムであれば、どちらか一方というよりUTF-8への統一を検討する方が現実的です。Shift_JISとEUC-JPはいずれも古くから使われてきた日本語向けの文字コードですが、対応できる文字の範囲や多言語対応の面でUTF-8に比べて制約があり、現行の標準としてはUTF-8が選ばれることが多くなっています。
機種依存文字とは具体的にどのような文字ですか。
丸囲みの数字、ローマ数字、単位記号など、特定のパソコン環境向けにShift_JISの独自拡張領域へ割り当てられた文字を指します。Unicode側での扱いが環境やソフトウェアによって異なる場合があり、システム間でデータをやり取りする際に文字化けや変換エラーの原因になりやすい文字群として知られています。
CSVファイルの文字化けはどこから確認すればよいですか。
まずCSVを出力したシステム側が実際にどの符号化方式で保存しているかを確認し、次に受け取る側のソフトウェア（Excelなど）がどの符号化方式で読み込もうとしているかを確認する流れが基本です。あわせてBOMの有無も、出力元と読み込み先で認識が揃っているかを確認しておく必要があります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：MDN Web Docs「Character encoding（文字エンコーディング）」用語集（https://developer.mozilla.org/ja/docs/Glossary/Character_encoding）
- *2 出典：MDN Web Docs「UTF-8」用語集（https://developer.mozilla.org/ja/docs/Glossary/UTF-8）
- *3 出典：W3C国際化ガイド「HTMLで文字エンコーディングを指定する」（https://www.w3.org/International/questions/qa-html-encoding-declarations.ja ）
