コンピュータの 中では、字は ぜんぶ 数字です。「文字化け」の 4つの 字は、日本で むかしから 使われた 方式の 1つでは、8つの 数字に なります。べつの 方式では、こんどは 12の 数字に なります［9］。

国語の じてんと 英語えいごの じてんで、同じ ページを ひらいても、書いて ある ことは ちがいます。文字化けは、これと にて います。同じ 数字を ちがう 表で ひくと、ちがう 字に なります。ただし ほんとうは、コンピュータは 本を めくらずに、数字と 字を むすぶ 決まりを 使って います。

この ことばは 日本から 英語えいごにも 入って、mojibake と 書かれます［9］。

「文字化け」の4文字を、日本語で使われてきた3つの方式で数字にすると、次のようになります。数字は16進数（0〜9とA〜F）で書いています。私が、Pythonの標準の文字コード変換で計算しました。

• Shift_JIS：95 B6 8E 9A 89 BB 82 AF（8バイト）
• EUC-JP：CA B8 BB FA B2 BD A4 B1（8バイト）
• UTF-8：E6 96 87 E5 AD 97 E5 8C 96 E3 81 91（12バイト）

同じ4文字なのに、方式によって数字の並びも長さも違います。UTF-8の12バイトをShift_JISの表で読むと、「譁�蟄怜喧縺�」のようになります［9］。末尾のほうの記号は、環境によって見え方が変わります。文字が壊れたのではなく、数字は元のまま、読む表だけが取りちがえられています［5］。

「mojibake」は、日本語から英語に入ったことばです。開発者の久保喜之さんは、英語で説明するより「Mojibake」を英語として広めるほうが早かった、と説明しています［9］。一人の説明なので、定説とは言えません。

では、なぜ表が何種類もできたのでしょう。いちばん最初の表から見ていきます。

文字化けは、どんな数字の食いちがいから起きるのか。それを見るために、「文字化け」の4文字をバイト列にすると、方式ごとに次のようになる（16進数。筆者がPythonの標準コーデックで計算した）。

• Shift_JIS：95 B6 8E 9A 89 BB 82 AF（8バイト）
• EUC-JP：CA B8 BB FA B2 BD A4 B1（8バイト）
• UTF-8：E6 96 87 E5 AD 97 E5 8C 96 E3 81 91（12バイト）

このように、同じ4文字が、方式によって8バイトにも12バイトにもなり、並びも別物だ［9］。だから、UTF-8のバイト列をShift_JISで読むと「譁�蟄怜喧縺�」のようになる［9］（末尾付近の記号は環境で見え方が変わる）。バイト列そのものは元のままで、読む表だけが取りちがえられている。フォントがなくて別の字形が出る場合にも似た症状は出るが、原因は別だ［5］。

「mojibake」は日本語から英語に入った語で、開発者の久保喜之によれば、英語で説明するより「Mojibake」を英語として定着させるほうが早かったためという［9］。一人の説明であり、定説とは書かない。

では、なぜ日本語の表が複数できたのか。最初の規格から順に見ていく。

1963ねんに、アメリカで ASCII（アスキー）と いう 表が 決まりました［1］。字は 128しゅるいです。A は 65ばん、のように、1つの 字に 1つの 番号が ついて います。

番号は、0か 1の ならびが 7つで あらわします。これを 7ビットと いいます［2］。8ビットの コンピュータでは、あまった 8つ目の ビットを、通信つうしんの まちがい さがしに 使う ことが ありました［1］。

この 表には、英語えいごの 字と 数字と 記号が 入って います。ひらがなや 漢字は 入って いません。

ASCIIは、1963年6月17日に、米国規格協会（ASA、のちのANSI）が決めた表です［1］。128文字を、7ビットの2進数で表します。2を7回かけると128になります。初版は1963年に出版されました［2］。

最初に広く使われたのは、AT&Tの電信網と、テレタイプ Model 33という機械でした［2］。

7ビットだと、8ビットで1文字を扱うコンピュータでは、余った8ビット目を通信の誤り検出（パリティ）に使うことができました［1］。これは後の使い方の説明で、7ビットにした理由そのものとは書きません。

この128文字には、英語の文字・数字・記号は入っていますが、日本語の文字は入っていません。日本ではどうしたのでしょうか。

日本語の文字化けの話は、日本語が1文字も入っていない表から始まる。1963年6月17日、米国規格協会（ASA、のちのANSI）がASCII（ASA X3.4-1963）を制定した［1］。128文字を7ビットの2進数で表す規格で、初版は1963年に出版された。最初の広い商用実装は、AT&Tの電信網とテレタイプ Model 33だった［2］。

7ビットだと、1バイト（8ビット）には1ビット余る。8ビットで1文字を扱う機器では、その余った8ビット目を通信の誤り検出（パリティ）に使える［1］。ただし、これは二次資料が挙げる後年の使い方で、7ビットに決めた理由とは断定しない。

128文字は英語の文字・数字・記号で、ひらがなも漢字も含まない。では、文字を「番号の表」にするこの考えは、日本語ではどう広がったのか。

1969ねんに、日本でも ASCIIに にた 表が 決まりました［3］。ほとんど 同じですが、92ばんの 字だけ ちがいます。ASCIIでは バックスラッシュ（ななめの 線）です。日本の 表では、円記号です［3］。

半角の カタカナも 入って いました［3］。

同じ 番号で 字が ちがう。文字化けの ちいさな たねは、この ときから すでに ありました。

1969年6月1日に、日本でもASCIIに近い表が決まりました。当時の規格番号はJIS C 6220で、いまはJIS X 0201と呼ばれます［3］。

ほとんどの番号はASCIIと同じです。ただし、0x5C（10進数で92）は、バックスラッシュではなく円記号です。0x7Eも、チルダではなく、文字の上に引く横線（オーバーライン）になっています。この表には、半角カタカナも入っていました［3］。

同じ92番が、ASCIIではバックスラッシュ、日本の表では円記号です。読む表がちがうと字が変わる、という文字化けの原理は、すでにこの時点で小さく出ています。

ASCIIが日本に入ると、表はどう変わったのか。日本のJIS X 0201は1969年6月1日に制定された（当時の規格番号はJIS C 6220）［3］。ASCIIに近いが、0x5C（10進で92）はバックスラッシュでなく円記号、0x7Eはチルダでなくオーバライン（文字の上の横線）になる。半角カタカナも含む［3］。

つまり、同じ0x5Cが、ASCIIではバックスラッシュ、JISでは円記号だ。バイトを読む表がちがえば字が変わるという文字化けの原理の、小さな実例が、この時点で規格の中にある。

ところが、この表は1バイトの文字だけを扱う。では、漢字はどうするのか。別の仕組みが要った。

漢字は たくさん あるので、1つの 数字では 足りません。そこで、2つの 数字で 1つの 字を あらわす 表が、1978ねんに できました。いまの 名前は JIS X 0208 です［4］。

いまの 表には、6879こ の 字が のって います［4］。

この 表の 字を 数字に する やり方が、3つ 出て きました。メール向けの ISO-2022-JP、UNIXと いう コンピュータ向けの EUC-JP、パソコン向けの Shift_JIS です［4］［5］。

字の 表は 同じでも、数字の ならびは ちがいます。だから、書いた ときと ちがう 表で よむと、文字化けが おきます。

漢字は数が多いので、1バイト（256通りまで）では足りません。そこで、2バイトで1文字を表す文字集合が、1978年にJIS C 6226として決まりました。いまの名前はJIS X 0208です［4］。

現行の規格は6879字（漢字6355字と、それ以外の524字）です。1983年、1990年、1997年に改正されています［4］。6879字は改正後の数で、1978年の最初の字数ではありません。

この文字集合を数字にする書き方は、3つ並び立ちました。メールや掲示板向けのISO-2022-JP、UNIX系のEUC-JP、パソコン向けのShift_JISです［4］［5］。

同じ文字集合でも、数字の並びは違います。「文字化け」で比べると、ISO-2022-JPの本体部分は 4A 38 3B 7A 32 3D 24 31、EUC-JPは CA B8 BB FA B2 BD A4 B1 です。EUC-JPの各数字は、ISO-2022-JPの同じ位置の数字に、16進数の80（10進数で128）を足した数になっています。私が計算して気づきました。Shift_JISの 95 B6 8E 9A… は、ISO-2022-JPともEUC-JPとも別の並びです。

Shift_JISは、なぜそんな並びにしたのでしょうか。

漢字は、1バイト（256通り）では足りない。そこで、2バイトで1文字を表す文字集合が作られた。1978年制定のJIS C 6226で、現在の名称はJIS X 0208だ［4］。現行規格は6879字（漢字6355字、非漢字524字）で、1983・1990・1997年に改正された［4］。6879字は改正後の現行値で、1978年当初の字数ではない。

ところが、文字集合が1つに決まっても、書き方は1つにならなかった。この文字集合を符号にする方式が3つ並立した。ISO-2022-JP（メール・掲示板向け）、EUC-JP（UNIX系）、Shift_JIS（パソコン）だ［4］［5］。文字集合が同じでも、バイト列は違う。

どれくらい違うのか。1章の「文字化け」で並べると、ISO-2022-JPの本体部分は 4A 38 3B 7A 32 3D 24 31、EUC-JPは CA B8 BB FA B2 BD A4 B1 で、各バイトに80（16進）、つまり10進で128を足した関係になっている（筆者の計算）。一方、Shift_JISの 95 B6 8E 9A 89 BB 82 AF は、ISO-2022-JPともEUC-JPとも別の並びだ。

では、Shift_JISの並びはなぜ別なのか。その来歴を次に見る。

Shift_JISは、1982ねんごろ、アスキーや マイクロソフトなどが 力を あわせて 作った、と いわれます［6］。名前の 「シフト」は、ずらす と いう いみです。JIS X 0208の 字を、あいて いる ところへ ずらして ならべました［6］。

ところが、ふしぎな ことが 起きました。「ソ」や「表」などの 字は、2つ目の 数字が 92ばんです。92ばんは、ASCIIでは バックスラッシュです［6］。

プログラムが、これを とくべつな しるしだと まちがえて、ふぐあいが 出ました［6］。ぜんぶの 漢字では なく、一部の 字だけです。この 字たちを「ダメ文字」と よぶ ことが あります。

Shift_JISは、1982年ごろに、アスキーやマイクロソフトなどの共同作業で作られたとされます［6］。誰が中心だったかは、資料によって語りが異なるので、ここでは書きません。名前の「シフト」は、JIS X 0208の文字集合を分けて、8ビットの空いている場所に「ずらして」置いたことによります［6］。

この並べ方には落とし穴がありました。「ソ」は 83 5C、「表」は 95 5C、「能」は 94 5C で、2バイト目が 5C、つまりASCIIのバックスラッシュと同じ数字なのです（私がPythonで計算しました）。プログラムがこれを、次の文字の意味を変える記号（エスケープ）と読みちがえて、不具合が出ました。一部の文字だけの問題で、「ダメ文字」と呼ばれます［6］。

もう1つ、2バイト目が 0x40〜0x7E というASCIIと重なる範囲にも入ることがあります。文章の途中から読みはじめると、いま読んでいる数字が1文字なのか、2文字の後ろ半分なのか、判断しにくくなります［7］。

次は、メール向けの方式です。こちらは、別の事情から生まれました。

Shift_JISは1982年に、アスキーやマイクロソフトなどの共同作業で作られたとされる。誰が主導したかは古川享の証言に依拠する話で、断定しない［6］。名前の由来は、JIS X 0208の文字集合を分割し、8ビットの符号空間の空き領域に「ずらして配置」したことだ［6］。

この「ずらして配置」した並べ方には、副作用があった。それが「ダメ文字」だ。「ソ」（83 5C）、「表」（95 5C）、「能」（94 5C）、「噂」（89 5C）など、2バイト目が0x5C、つまりASCIIのバックスラッシュと同じ値になる文字がある（Pythonで確認）。プログラムがこれをエスケープ記号と誤読して、不具合が出た［6］。すべての漢字ではなく、一部の文字に限る。

弱点は、これだけではない。もう1つは、2バイト文字の2バイト目が0x40〜0x7EというASCIIの範囲にも現れることだ。途中から読むと、文字の切れ目を判定しにくく、Shift_JISだと確実に検出するのは難しい［7］。

では、メール向けの方式は、なぜ別の設計になったのか。次に見る。

むかしの メールは、7ビットの 数字しか まともに 通さない 道が ありました［8］。でも、日本語の 方式には 8ビットの ものが ありました。

そこで、7ビットだけで 日本語を 書く ISO-2022-JP が 作られました。日本語の 前に とくべつな 3つの 数字（ESC $ B）を おいて「ここから 日本語」と しらせます。おわりに もどす 数字を おきます［8］。

8つの 0と1で 字を あらわす 表を、7つしか 通らない 道に おくると、さいごの 1つが きえて、ちがう 字に 見える ことが あった、と いわれます［9］。

けいさんして みます。EUC-JPの「文字化け」の いちばん 上の ビットを けすと、「J8;z2=$1」に なります。日本語が、アルファベットと 記号に 見えます。

日本語のメールを送るために、1993年6月に、RFC 1468という文書でISO-2022-JPが紹介されました。これはインターネットの標準ではなく、情報提供の文書です［8］。

この方式は、ESC $ B（1B 24 42）という3バイトで「ここから日本語」と知らせ、ESC ( B で ASCII に戻します。すべて7ビットなので、7ビットしか確実に扱えないメールの経路を通せました［8］。「文字化け」は、私の計算では 1B 24 42 4A 38 3B 7A 32 3D 24 31 1B 28 42 の14バイトです。

反対に、8ビットのShift_JISやEUC-JPが7ビットしか通さない経路に来ると、いちばん上のビットが落ちて、化ける原因になったといわれます［9］。

数字だけ計算してみます。EUC-JPの「文字化け」CA B8 BB FA B2 BD A4 B1 の最上位ビットを落とすと、4A 38 3B 7A 32 3D 24 31 になります。ASCIIで読めば「J8;z2=$1」です。これは私の計算で、実際の経路でどうなったかまでは確かめていません。

答えは、メールの経路にある。RFC 1468（1993年6月）は、メールで日本語を送るためのISO-2022-JPを説明する、情報提供の文書だ（インターネット標準ではない）［8］。ESC $ B（1B 24 42）のあとが日本語の文字、ESC ( B で ASCII に戻る。すべて7ビットで表せるので、7ビットしか確実に扱えないメール経路を通せた［8］。

実際に「文字化け」をISO-2022-JPにすると、1B 24 42 4A 38 3B 7A 32 3D 24 31 1B 28 42 の14バイトになる（筆者の計算）。

では、7ビットにしなかった方式はどうなるのか。逆に、7ビットしか通らない旧式のメール経路に、8ビットのShift_JISやEUC-JPが来ると、最上位ビットが落ちて化ける原因になったという［9］。最上位ビットがどのような経路で消えるのか、その細かい仕組みまでは確認できていない（資料の要約の範囲でしか見ていない）。

仮に、EUC-JPの CA B8 BB FA B2 BD A4 B1 の最上位ビットを落としたとすると、4A 38 3B 7A 32 3D 24 31、ASCIIで読むと「J8;z2=$1」になる。日本語が英数字と記号に見えるわけだ。これも筆者の計算であって、実際の経路の挙動そのものではない。

世界の 字に 1つずつ 番号を つける 考えが、1991ねんに Unicode（ユニコード）として 出ました［10］。その 番号を 数字に する やり方の 1つが、UTF-8 です。

1992ねんの 9がつごろ、ケン・トンプソンと ロブ・パイクが、ごはんを 食べる みせで、紙の ランチョンマットの 上に UTF-8を かきました、と パイクは 書いて います［11］。

UTF-8では、ASCIIの 字は そのまま 1つの 数字です。ASCIIの 数字は、ASCIIの 字だけを あらわします。92ばんは、バックスラッシュだけです［12］。しかも、文章の とちゅうから 読んでも、字の さかいめが わかります［12］。

いまは、文字コードの わかる ウェブサイトの 99.1パーセントが、UTF-8 です［14］。

Unicode 1.0は、1991年10月に出ました。世界の文字に1つずつ番号を振る考え方です［10］。その番号を数字の並びにする方法の1つが、UTF-8です。

UTF-8は、1992年9月ごろ、ニュージャージー州の食堂で、紙のランチョンマットの上で設計されたと、ロブ・パイクが書いています。設計はパイクの目の前で行われました。当時の案（ISO 10646のUTF）が、二人とも気に入らなかったからだそうです［11］。

UTF-8には、Shift_JISの弱点を避ける作りがあります。ASCIIの範囲は1バイトのままで、ASCIIと同じ値のバイトは、ASCIIの文字だけを表します［12］。バックスラッシュの 5C が、日本語の文字の途中に混ざることがありません。「ソ」は E3 82 BD、「表」は E8 A1 A8、「能」は E8 83 BD です（私が計算しました）。

もう1つ、任意の位置から読みはじめても、切れ目が分かります。文字の2バイト目以降は、必ず「10」から始まる並びで、それ以外で始まるバイトが文字の先頭です［12］。

WHATWGのEncoding Standardは、新しいプロトコルや形式にはUTF-8を必須とし、Shift_JIS・EUC-JP・ISO-2022-JPは、既存の内容を読むための互換として定義するだけだ、と述べます［13］。W3Techsの調査（2026年9月）では、文字コードが分かるサイトの99.1％がUTF-8で、EUC-JPは0.1％、Shift_JISは0.1％未満です［14］。全サイトの割合ではなく、文字コードがわかるサイトの中での割合です。

表が増えすぎたなら、世界の文字を1つの表にすればよい。その考えが、Unicode 1.0として1991年10月に出た［10］。世界の文字に1つずつ番号を振る考えで、その番号をバイト列にする方式の1つがUTF-8だ。

では、UTF-8はどこで生まれたのか。1992年9月ごろの夜、米ニュージャージー州の食堂で、ランチョンマットの上で設計された、とロブ・パイクは書く。設計は彼の目の前で行われ、当時のISO 10646のUTFがPlan 9に合わず、二人はそれを嫌っていたという［11］。日付を「9月2日」とする資料もあるが、原文は「9月ごろ」だ。

この設計は、Shift_JISの弱点を避ける作りになっている。特徴は2つある。ASCIIの範囲は1バイトのままで、ASCIIの値のバイトはASCIIの文字だけを表す。もう1つは、文字の2バイト目以降が必ず「10xxxxxx」で始まる構造で、それ以外で始まるバイトが先頭だから、途中から読んでも切れ目が分かる［12］。

実際、「ソ」はUTF-8で E3 82 BD、「表」は E8 A1 A8、「能」は E8 83 BD で、どれも5Cを含まない（Pythonで確認）。Shift_JISの83 5Cと比べると、5章の落とし穴を避ける設計になっている。

その結果、今はどうなっているのか。WHATWGのEncoding Standardは、新しいプロトコルや形式にUTF-8を必須とし、Shift_JIS・EUC-JP・ISO-2022-JPは、既存の内容を読むための互換のためだけに定義する［13］。W3Techsの調査（2026年9月）で、文字コードが分かるサイトの99.1％がUTF-8、EUC-JPは0.1％、Shift_JISは0.1％未満だ［14］。「全サイト」ではなく「文字コードが分かるサイト」の中の割合で、速報値は更新されて変わる。

ローマ字で、じぶんの 名前を 書きます。A を 1、B を 2、C を 3…と じゅんばんに、Z を 26まで 数字に して みましょう。たとえば、CAT（ねこ）は 3、1、20 です。

つぎに、友だちの 表は「A を 0」です。3は D、1は B、20は U です。CAT が「DBU」に なりました。表が 1つ ずれた だけで、文字化けです。

じぶんの 名前でも やって みましょう。友だちに 数字だけを わたして、ずらした 表で 読んで もらうと、どう 見えるでしょうか。

ローマ字で自分の名前を書き、A=1、B=2、C=3…と順に数字にしてみてください。たとえば CAT は 3、1、20 です。

この数字を、友だちに「A=0」の表で読んでもらいます。3は D、1は B、20は U ですから、「DBU」になります。表が1つずれただけで、文字化けの完成です。名前で試すと、どう化けるでしょうか。

原典を読むなら、ロブ・パイクによるUTF-8の史話がおすすめです。英語ですが、短い文章です［11］。

表のずれによる化けは、紙と鉛筆で再現できる。ローマ字の名前をA=1、B=2、C=3…と数字にし、相手にA=0の表で読んでもらう。CAT（3, 1, 20）は、D, B, U で「DBU」になる。ずれの大きさを変えると、どう変わるかも見られる。

原典に当たるなら、ロブ・パイクによるUTF-8の史話［11］、ISO-2022-JPの原文であるRFC 1468［8］、UTF-8のRFC 3629［12］、WHATWGのEncoding Standard［13］が、いずれも英語で公開されている。

Shift_JIS・EUC-JP・UTF-8の3つで、自分の名前をバイト列にしたら何バイトになるか、数えてみるのも手だ。