0と1の意味は誰が決めるのか？同じデータが文字にも画像にもなる仕組み

Sat, 08 Aug 2026 00:00:00 +0000

コンピューターが扱うデータは、すべて0と1の並びです。しかし0と1の並びそのものには、意味がありません。同じ 01000001 が、あるプログラムでは文字の「A」になり、別のプログラムでは数値の65になり、また別のプログラムでは画像の点の明るさになります。意味を決めているのはデータではなく、それを読む側のルールです。この記事では、モールス信号を手がかりに、この仕組みを見ていきます。

はじめに

電気信号の記事で、ケーブルを流れる電気の高低が0と1に置きかえられることを学びました。コンピューターが扱うデータは、文字も画像も音声も、最終的にはすべて0と1の並びです。

では、0と1の並びを見ただけで、それが文字なのか画像なのかを判断できるでしょうか。

答えは「できない」です。0と1の並びそのものには、意味が含まれていないからです。意味を与えているのは、そのデータを読む側が持っているルールです。

今回はこの仕組みを、モールス信号を手がかりに見ていきます。

モールス信号で考える

モールス信号は、短い音「・」と長い音「－」の組み合わせで文字を表す通信方法です。無線通信の初期から使われてきました。

このモールス信号には、英語などで使う 国際モールス と、日本語で使う 和文モールス があります。

同じ信号が別の文字になる

2つの方式を比べると、同じ信号がまったく別の文字を表していることが分かります。

信号	国際モールス	和文モールス
・－	A	イ
－・	N	タ

図：同じ信号でも、読むルールが違えば意味が変わる

「・－」という信号を受け取ったとき、それを「A」と読むか「イ」と読むかは、信号からは判断できません。受け手がどちらのルールで読むかによって決まります。

読むルールを伝える合図

では、受け手はどうやって正しいルールを選ぶのでしょうか。

和文モールスには、そのための合図があります。和文の通信を始めるときは「ホレ」、終えるときは「ラタ」という符号を送ります。

合図	符号	意味
ホレ	－・・－－－	ここから和文で送る
ラタ	・・・－・	和文の通報を終える

「ホレ」はホ（－・・）とレ（－－－）を、「ラタ」はラ（・・・）とタ（－・）を、文字の区切りを入れずに続けて送ります。ふつうの文字と区別し、1つの合図として受け取ってもらうためです。なお「ラタ」は、無線局運用規則でも和文の通報を終えるときに送る符号として定められています。

この合図は、伝えたい内容そのものではありません。「これから送る信号を、どのルールで読めばよいか」を知らせるための情報です。この発想は、後で見るようにコンピューターの世界でもそのまま使われています。

コンピューターのデータも同じ

コンピューターの世界でも、モールス信号と同じことが起きています。

01000001 は何を表すか

01000001 という8ビットのデータがあるとします。

2進数の各桁は、右から順に1・2・4・8・16・32・64・128を表します。01000001 では64の桁と1の桁が1なので、10進数に直すと64＋1＝65です。

この65という値が何を意味するかは、読むプログラムによって変わります。

文字として読む と「A」になります。文字コードの規格では、65番に「A」が割り当てられているためです。
数値として読む と、そのまま65です。
画像の点として読む と、明るさを0〜255で表す方式なら、やや暗い灰色の点になります。

用語/英単語	意味	イメージ・補足
文字コード / Character Encoding	encoding＝符号化; 文字とビット列の対応を定めたルール	文字ごとに背番号を決めた対応表

図：同じ「01000001」が、何にでもなる

意味を決めるのは読む側

同じ 01000001 が、文字にも数値にも画像にもなります。データ自体は何も変わっていません。変わったのは、読む側が使ったルールだけです。

つまりコンピューターのデータは、「このルールで読む」という前提とセットになって初めて意味を持ちます。

ルールがずれると何が起きるか

読む側が、書いた側と違うルールを使うと、データは正しく読めません。

文字化け

身近な例が 文字化け です。

同じ「あ」という文字でも、文字コードによって割り当てられるデータが異なります。16進数での表し方はMACアドレスの記事で紹介しました。

文字コード	「あ」を表すデータ（16進数）
UTF-8	E3 81 82
Shift_JIS	82 A0

UTF-8で書かれた文章をShift_JISのルールで読むと、E3 81 82 という並びが別の文字の組み合わせとして解釈されます。データは正しく届いているのに、画面には読めない文字が並びます。

画像をテキストとして開く

画像ファイルをメモ帳などのテキストエディタで開くと、意味不明な記号が大量に表示されます。これも同じ現象です。画像のルールで書かれたデータを、文字のルールで読もうとしているために起こります。

読むルールを伝える仕組み

モールス信号に「ホレ」という合図があったように、コンピューターにも「このデータをどう読むか」を伝える仕組みがあります。

ファイルの拡張子

.txt や .png といった拡張子は、そのファイルをどのルールで読むべきかを示す目印です。OSは拡張子を見て、ファイルを開くアプリを選びます。

ただし拡張子はファイル名の一部にすぎないため、自由に書き換えられます。画像ファイルの拡張子を .txt に変えても、中身は画像のままです。

ファイルの先頭の目印

より確実な手がかりとして、多くのファイル形式は先頭に決まったデータを置いています。これを マジックナンバー といいます。

ファイル形式	先頭のデータ（16進数）
PNG画像	89 50 4E 47（後半の3バイトは文字の「PNG」）
PDF	25 50 44 46（文字の「%PDF」）

用語/英単語	意味	イメージ・補足
マジックナンバー / Magic Number	ファイルの先頭に置かれ、ファイル形式を示す決まったデータ	書類の表紙に書かれた「種類」の欄

通信での伝え方

通信でも同じ仕組みが使われています。プロトコルの記事で紹介したように、HTTPでは次のようなヘッダーでデータの種類を伝えます。

Content-Type: text/html; charset=UTF-8

「このデータはHTMLで、文字はUTF-8で書かれている」という意味です。受け取ったブラウザは、この情報をもとに正しいルールでデータを読みます。モールス信号の「ホレ」と同じ役割です。

通信では層ごとに読むルールが違う

通信の場面では、1つのデータを複数の機器やソフトウェアが順番に読んでいきます。そしてそれぞれが、自分の担当する部分を自分のルールで読みます。

TCP/IPモデルの記事で学んだように、送られるデータには層ごとにヘッダーが付けられています。受け取る側では、次のように読む分担が決まっています。

読む側	読む部分	判断すること
NIC	MACヘッダー	自分宛てのデータか
OS	IPヘッダー	自分のIPアドレス宛てか
OS	TCPヘッダー	どのアプリに渡すか
ブラウザ	データ部分	HTMLとしてどう表示するか

図：層ごとに、読む場所とルールが違う

どの部分を、どのルールで読むか。これを取り決めているのがプロトコルです。Ethernetのルールを知っているNICだけがMACヘッダーを正しく読め、HTTPのルールを知っているブラウザだけがデータ部分を正しく解釈できます。

まとめ

コンピューターが扱う0と1の並びそのものには意味がなく、意味を与えているのは読む側のルールです。モールス信号の「・－」が国際モールスでは「A」、和文モールスでは「イ」になるように、同じ 01000001 も文字として読めば「A」、数値として読めば65、画像として読めば暗い灰色の点になります。書いた側と読む側のルールがずれると、文字化けのように正しく読めなくなります。そのため拡張子やマジックナンバー、HTTPのContent-Typeといった「どのルールで読むか」を伝える仕組みが用意されています。通信では、NIC・OS・ブラウザがそれぞれ担当する部分を自分のルールで読んでおり、その分担を定めているのがプロトコルです。

用語表

用語	意味
2進数	0と1だけで数を表す方法。コンピューターのデータはすべて2進数で表される
文字コード	文字とビット列の対応を定めたルール。UTF-8やShift_JISなど
文字化け	書かれたときと異なる文字コードで読んだために、文字が正しく表示されない現象
拡張子	ファイル名の末尾に付ける目印。ファイルの種類を示す
マジックナンバー	ファイルの先頭に置かれ、ファイル形式を示す決まったデータ
Content-Type	HTTPでデータの種類や文字コードを伝えるヘッダー

文字化け on ネットワーク入門講座