文字コードとは
パソコンで扱う、ひらがなやカタカナ、漢字、アルファベットなどあらゆる文字はどのようにして表示され、また通信されているのでしょうか?
アルファベットについてはキーボードで直接入力することができますが、日本語のように、扱う文字数が千以上の場合は、前項で解説した日本語入力システム(インプットメソッド)によって、複数のキーのタイプで1文字を入力することになります。
すなわち、アメリカで誕生したコンピュータとインターネットの仕組みは、アルファベットと数字、数種の記号の使用しか想定されていないため、その仕組みの中で日本語などを扱うということは、それなりにシステムの拡張や継ぎ足し的な措置を施さなければならないということなのです。
文字に限らずデジタルデータは、アナログデータとデジタルデータ で解説のとおり、0と1の2進数でやり取りされていますので、日本語やアルファベットなどの文字や記号も、数値と対応させたコードに変換してやり取りされています。
つまり、「A」という文字を、例えば「1000001」という具合にコード化して処理するわけです。このように、文字とコードとの対応規則をまとめたものを、
文字コード
と言います。全ての文字は、文字コードというコード体系に置き換えられて、さらに最終的には2進数に変換されてコンピュータで処理されます。
したがって、私たち人間にも言語が多数存在するように、文字コードも多数存在します。日本語の文字コードや中国語の文字コード、ハングル語の文字コードなどです。同じ言語内でも複数の文字コードが存在します。
歴史を遡れば、コンピュータの機種ごとに各メーカーが開発した異なる文字コードが使われていました。やがて、それらのコンピュータが互いに通信し合うようになると、文字コードの乱立により、ある問題が発生するようになったのです。
それは、通信している双方で使用している文字コードが異なれば、意図する文字とは全く異なる文字(または意味不明の文字の羅列、文字化け)が表示されてしまうというある意味では当然の現象です。
こうした問題を解消するために、様々な技術や仕組み、または文字コードの規格の統一や開発などが行われてきました。詳しくは後述しますが、インターネットが爆発的に普及しはじめると、さらに問題は複雑になってきます。
同じ国内の機種間でさえ問題が起きていたのに、言語も国境も越えたグローバルな通信や、世界中のウェブサイトの閲覧などにおいて対応できるはずもなく、文字コードの問題は完全には解決されないまま現在に至っているのです。
このように、文字コードは多くの問題を抱えており、それを理解するというのは多少難解ではあるのですが、それぞれの文字コードを個別に詳しく解説するよりも、歴史的な推移と問題点を明らかにすることで、文字コードというものの基礎的な理解が得られると思います。
それでは、早速文字コードの歴史から解説して行きたいと思いますが、その前にもう一度、文字コードの「定義」を説明しておきましょう。
文字コードというものを理解するのは、実はかなり難解なので、この入口の部分である文字コードの「定義」をあいまいに理解していると、迷路から抜け出せなくなるというくらい大切なことです。
「文字コード」という用語は、様々な場面で用いられており、以降に解説する用語とひとくくりにされて使われるることが多い用語なので、誤解を招きやすく理解するのが難しい用語です。
したがって、文字コードとは「文字とコードとの対応規則をまとめたもの」と解説したとおり、
「文字に割り当てた数値」というような単純な意味ではない
と理解しておくことです。この意味で用いられることもありますが、基本的な理解としては、文字と数値をどのように対応させるかを定義したもので、私的には「ルールブック」と定義した方がしっくりきます。ただ単純に数値としての「コード」を指す用語ではないと理解しておくべきだと思います。
したがって、ルールブックである「文字コード」には、「何」を「どのようにうして」といった内容が決められているわけです。
まず、文字コードを定めるときには、どのような種類の文字をどれだけ扱うのかということを決めておかなければなりません。例えば、その文字コードが日本語なら、「ひらがな」と「漢字」を使うなどといったことです。
ただ、「ひらがな」は全て扱うのが当然ですが、「漢字」になると全てというのも困難です。なぜなら、全ての漢字とは、どこからどこまでなのかの定義がないからです。一般の社会生活で漢字を使用する際の目安として示されている「常用漢字」のように扱う文字を決めておかなければならないのです。
つまり、その文字コードで扱う文字を全て集めて、その上でコードを割り当てないと文字コードという言わば一つのパッケージに成り得ないので、「この文字コードで扱う文字は、この文字群です」というように、扱う文字を集めてまとめることが必要になります。
このように集められた文字の集合に、数値を割り当てて表のように整理したものを、
文字コードセット(文字集合)
と言います。数値を割り当てられる前の文字の集合を「文字集合」、文字集合に数値を割り当てたものを「符号化文字集合」として区別することもありますが、それほど厳密に使い分ける必要はないと思います。
たいていの文字コードセットは、集合と同時に数値が割り当てられて、「符号化文字集合」として表に整理されますので、これらは同じ意味で用いても問題ないでしょう。
さて、この文字コードセットにも様々な規格や種類があります。文字コードセットは、日本語入力システムのMS-IMEで確認することができます。
詳しくは後述しますが、下図のように、UnicodeやシフトJISといった文字コードによって独自の文字コードセットが作られていたり、または使い分けられています。文字コードセットには、「JIS X 0208」などがあります。(詳しくは後述します)
そして、文字コードセットによって、文字と対応する数値の組み合わせが決まるのですが、日本語のコードの場合には、その数値がそのままの形でコンピュータに使用されることはほとんどなく、目的や処理の方式によって、この数値が様々な方式で変換されて処理されます。
このように、データを目的に応じた形式(通常はビット列)に変換することを、
符号化(エンコード)
と言います。符号化は、文字コード(ルールブック)にしたがって行うため、当然文字コードによって異なります。これが原因で文字が読み取れなかったり、文字化けなどの原因となるのですが、この符号化(エンコード)の方式のことを、
符号化(エンコード)方式
と言います。日本語の符号化方式は一般に「JIS(ジス)」、「Shift_JIS(シフトJIS)」、「EUC(イーユーシー)」などがあります。符号化方式は、文字コードセットで定義された数値をどのように符号化するかのルールを決めたものです。したがって、同じ文字コードセットでも符号化方式によって異なる形式に符号化されることもあります。
一方、後述するASCII(アスキー)のような単純な文字コードでは、文字コードセットで定義された数値(文字と数値を対応させた単純な整数値)を、さらにエンコードする必要はなく、そのまま使うことができるので、ASCIIは「文字コードセット」の意味でも用いられます。
このように、厳密には文字コードセットのことを文字コードとしてひとくくりに表現する場合もあります。(ASCIIについては、電子メールの拡張規格 でも解説しています)
また、文字コードと符号化方式は同じ名称であることが多く、こちらも同じ意味で用いられる場合があります。したがって、厳密にこれらの用語が使い分けられているわけではありません。
例えば、これも後述しますが「ISO-2022-JP(通称JISコード)」という文字コードは、符号化方式も「ISO-2022-JP」となります。このあたりが文字コードというものの理解を困難にしている部分でもあります。
しかし、「文字コード」とは、どのような文字コードセット(符号化文字集合)を用い、それをどのような符号化方式で符号化(ビット化)するのかを定義したルールブックという解釈をしておけば、文字コードというものが一番理解しやすいと思います。
さて、それでは文字コードの歴史を解説して行きたいと思います。文字コードの歴史は、コンピュータの歴史といっても決して大げさではありません。コンピュータへ命令を与えるのに、文字の入力は必須だからです。
まず、文字コードを作るという最初の段階において問題となるのが、
1文字を何ビットで表すのか
ということです。まだコンピュータが普及する前、文字コードが誕生した当初は、5ビットの文字コードだったそうです。5ビットということは、25=32文字しか表現することができません。つまり、アルファベット26文字がやっとというわけです。
しかしこれでは、0~10までの数字を含めると36文字となってしまい、アルファベットしか扱えなかったため、この文字コードのある任意のコードを「切り替え用」として定義し、そのコードに「表の切り替え」つまり、文字コードセットを切り替える という意味を持たせたることにしました。
コンピュータは、そのコードでは文字を表示するのではなく、数字の文字コードセットからアルファベットの文字コードセット、または逆へという風に切り替えるためのトリガーとして認識し、アルファベットと数字の2枚の文字コードセットを使い分けることを考え出したのです。こうした役割を持つコードのことを、
エスケープシーケンス
と言います。これは、後述しますが現在でも電子メールで用いられている方法です。この「切り替え」コードを用いることによって、5ビットコードでも、32×2=64文字(実際には56文字)を扱うことが可能になりました。
つまり、同じコード番号でも、文字コードセットを切り替えることによって、異なる文字を表示させることができるというわけです。
ただし、コンピュータが広く普及し始めると、文字コードは、統一した規格が誕生するでもなく、なんとコンピュータメーカーがそれぞれ独自に文字コードを開発して、製品に搭載するという状況になってしまいました。
これが今現在でも、「機種依存文字」などのように問題として残っています。そして、これらのコンピュータが互いに通信し合うようになったので、いよいよ重要課題となったのです。
環境依存文字は、電子メールの書式 でも解説していますが、文字コードセットの空き領域に、各メーカーが独自に定義した文字のことで、通信で双方が同じ文字コード体系を用いても、機種やOSの違いによって、異なる文字が表示されたり表示されなかったりします。
もっとも、同じ文字コードで通信しないと、意図する文字とは全く異なる文字(または意味不明の文字化け)が表示されてしまいます。
こうした文字コードの違いによる通信の問題解決のために考え出された文字コードが、
ASCII(アスキー)コード
です。ASCIIコードは、アメリカ国内での通信用の文字コード(ひいてはインターネットの標準コード)として規格されました。電子メールの MIME と同様に、コンピュータ内部での文字コードは独自のものを使用し、
通信時はASCIIコードに変換して送信する
というルールを策定しました。このルールによって、文字コードが乱立していて、誰がどんな文字コードを使用しているかわからないという状況の中でも、各自がそれぞれ、ASCIIへの変換プログラムと、ASCIIからの復号プログラムを用意しておけば、通信が成り立つようになったのです。
ASCIIコードは、以後開発される文字コードに大きな影響を与えるコードとなり、ほとんどの文字コードは、ASCIIとの互換性を考慮して開発されるようになりました。(互換性について詳しくは、互換性/バージョンとは を参照してください)
現在では、インターネットの代表的な文字コードであるASCIIコードは、1文字を7ビットで表す7ビットコードです。1文字を7ビットで表すということは、27=128文字を表現することができます。
7ビットコードは、下表(ASCIIコード)のとおり、横軸が上3ビット、縦軸が下4ビットの計7ビットで1文字を表現します。例えば「A」という文字は、縦軸「100」、横軸「0001」なので「1000001」と7ビットの文字列で表現します。(16進数では「0x41」)
16進数の値を表現する時には、10進数等との区別をつけるため、先頭に「0x」を付けて表現します。2進数の場合も、先頭に「0b」を付けて表現することがあります。(2進数・16進数については、2進数と10進数と16進数 を参照してください)
0b | 000 | 001 | 010 | 011 | 100 | 101 | 110 | 111 | |
0b | 0x | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
0000 | 0 | 制御文字群 | SP | 0 | @ | P | ` | p | |
0001 | 1 | ! | 1 | A | Q | a | q | ||
0010 | 2 | " | 2 | B | R | b | r | ||
0011 | 3 | # | 3 | C | S | c | s | ||
0100 | 4 | $ | 4 | D | T | d | t | ||
0101 | 5 | % | 5 | E | U | e | u | ||
0110 | 6 | & | 6 | F | V | f | v | ||
0111 | 7 | ' | 7 | G | W | g | w | ||
1000 | 8 | ( | 8 | H | X | h | x | ||
1001 | 9 | ) | 9 | I | Y | i | y | ||
1010 | A | * | : | J | Z | j | z | ||
1011 | B | + | ; | K | [ | k | { | ||
1100 | C | , | < | L | \ | l | | | ||
1101 | D | - | = | M | ] | m | } | ||
1110 | E | . | > | N | ^ | n | ~ | ||
1111 | F | / | ? | O | _ | o | DEL |
※ 1011100(0x5C)に位置する文字「\」は環境依存文字であり、お使いの機種によっては正しく表示されないかもしれませんが、「バックスラッシュ」です。日本では円記号「\」とする場合があります。
7ビットコードといっても、実際には128文字分全てを文字に当てることはできません。コンピュータに「改行」や「処理中止」などの制御命令を与える制御コードとして32文字分使っていますので、ここからさらにSP(スペース)とDEL(デリート:削除)を除いて、実際に扱うことのできる文字数は、94文字になります。
当時としては、7ビットというのは革新的な大きさで、「切り替え」コードによって文字コードセットを使い分ける必要もなく、そもそも米国でのアルファベットと数字、記号の使用しか想定されていないので、十分なビット数でした。
しかし、アルファベット26文字と数字、記号などしか使わない英語圏のユーザーなら128文字でも十分ですが、これでは、ひらがなやカタカナ、さらに漢字を使う私たち日本人には到底足りません。漢字だけでも軽く千を超えるからです。
実際、コンピュータは、1文字に8ビットを使用する(コンピュータが扱うデータの最少単位は8ビットを1単位とする1バイト)ことができ、28=256文字を扱うことができます。しかし、それでも全然足りません。
ASCIIだけで事足りるアメリカと異なり、私たち日本人は、文字コードという問題とより身近でつき合わなくてはならないのです。では、今度は「日本語」の文字コードの歴史をみていきましょう。
日本の文字コードの中でも、特に漢字をコード化するのは困難を極めました。コード化以前に、実際に使われる漢字を定義することもままならず、漢字の一覧作り、すなわち「文字コードセット」の整備から始めて、ようやく規格として1978年に、
JIS漢字コード
という文字コードセット(漢字コードとありますが符号化文字集合の規格で、「情報交換用符号化漢字集合」と定義されています)が日本工業規格(JIS)によって定められました。正式名称は「JIS C6226」ですが、その後、1980年代に改正を経て、1990年代に現在でも使われている、
JIS X 0208(ジス エックス ゼロニセロハチ)
が制定されました。JIS X 0208は、ASCIIをもとに拡張した「2バイト」のコード体系(JIS X 0208は正確には文字コードセット)になります。
ASCIIコードでは、横軸3ビットで縦軸4ビットの計7ビットでしたが、JIS X 0208は、横軸7ビットで縦軸も7ビット使います。もっとも1バイトは8ビットなので、1ビット分余りますが、最上位のビットは都合によって流動的に0や1にします。
例えば、ある文字が、横軸「0000001」で縦軸「0000010」だった場合、それぞれ「X0000001」「X0000010」となります。「X」は流動的に0もしくは1が当てられます。それぞれ1バイトずつ使い、1文字を表すのに2バイトを使用します。
なぜこのようにしたかというと、電子メールの書式 で解説のとおり、電子メールが7ビットにしか対応していないなどの理由で残りの1ビット分を空けているのです。
つまり、8ビットの最初のビットは無視されても構わないように7ビットの範囲を使用するということで、通信し合うことを念頭に策定された文字コードになります。
なぜ、正確には文字コードセットであるJIS X 0208を文字コードと表現するかというと、JIS X 0208を文字コードセットとして使う文字コードが多数存在する標準的な文字コードセットだからです。
このように7ビットルールに対応させるため、JIS X 0208は、7ビットのビット列を2つ使って文字コードセットを作っています。そのため、14ビットコードとは呼ばれず「7ビット×2」の文字コードと呼ばれます。
したがって、前述のとおり、ASCIIを拡張した2バイトの文字コードであり、例えば「X0000001」「X0000010」のように表現します。このコード値は、ASCIIのコード値と重なる部分がある(つまり同じコード値にASCII文字が割り当てられている)ため、ASCIIとの切り替えが必要になります。
電子メールで日本語を扱う場合は、前述したエスケープシーケンスという切り替えコードを用いて、文字コードセットを切り替えて使うことで、7ビットルールに適応しています。
この2バイトコードによって、8836文字(7ビットコードで実際に文字に使用できるのは94文字であり、94×94=8836文字)を扱うことができるようになりました。この種の文字コード(1文字に2バイト以上を使うコード)を「マルチバイトコード」と言います。
このように、コンピュータおよびインターネットはアメリカ主導で発展してきたため、現在でも、1バイト(7ビットもしくは8ビット)を基本単位として扱うことが前提です。その中で日本語のように多くの文字を必要とする言語は、1文字を表わすのに2バイト以上を要するため、どうにかしてそれに適応しなければならないのです。
このようなマルチバイトコードと、ASCIIなどの7ビットコードを、インターネットの世界でどのように共存させるかを定めた規格が存在し、それを、
ISO-2022(アイエスオー ニマルニーニー)
と言います。ISO-2022には、多くの文字コードセットが定義(登録)されていて、実際に文字を扱う場合には、まずどの文字コードセットを利用するかを決め、その文字コードセットのコードに対応した文字を選択します。
そして、その文字コードセットにない文字が必要となった時は、それを含む文字コードセットに切り換えるというものです。
ただしこれは、「ISO(アイエスオー)」という国際的な標準化機関が定めた「文字コードの扱いに関する規格」であり、実際のコードと文字の対応(実際にどの文字コードセットを用いどのように符号化するか)までは定めたものではありません。
つまり、ガイドライン的なもので、これに則した実際のコード体系が国や言語ごとにそれぞれ決められています。日本語のコード体系は、
ISO-2022-JP(通称、JISコード)
と呼ばれています。このJISコード(ISO-2022-JP)では、JIS X 0208やASCIIなどの文字コードセットがエスケープシーケンスによって切り替えて使われます。JISコード(ISO-2022-JP)は、電子メールの「本文」で用いることがルールになっています。
このように、日本でもASCIIと同じく通信用の文字コードとして、JIS X 0208などの文字コードセットが整備され、電子メールの世界では、JISコード(ISO-2022-JP)が今現在も用いられています。
さて、これまで解説してきたJIS X 0208のような、文字コードセットの切り替えが必要になるマルチバイトコードは、通信し合うことを念頭に策定された文字コードであり、実は、コンピュータ内部で使うことは想定していませんでした。
なぜなら、日本もアメリカと同様に、コンピュータ内部ではメーカーがそれぞれ独自に開発して、製品に搭載した文字コードを使用していたからです。
しかし、インターネットの爆発的な普及にともなって、こうした通信用の文字コードも普及してくると、今度はこの通信用の文字コードに変換しやすいコンピュータ内部用の文字コードが求められるようになりました。
JISコードなどの通信用の文字コードをコンピュータ内部で用いるには、文字コードセットを切り替えなければならないため、コンピュータ内部の処理はその分増えて速度が落ちます。したがって、
文字コードセットを切り替えなくてもいいように工夫された文字コード
で、尚且つ、通信用のJISコードとの互換性も考慮された文字コードが必要になったのです。こうした要望から誕生したのが、
Shift_JIS(シフト ジス)コード
です。Shift_JISコードは、2バイトの文字コードです。詳しい解説は割愛しますが、Shift_JISは、JISコードとは異なり、文字コードセットは1つでコードが重ならないため、エスケースシーケンスによる文字コードセットの切り替えは必要ありません。
また、簡単な処理で通信時に用いるJISコード(JIS X 0208)へ変換できる設計になっています。このため、「Shift(シフト)= ずらす」という名前がつけられています。
しかし、コンピュータの内部コードにShift_JISを採用するパソコンが普及するにつれて、Shift_JISコードのままで通信するケースもでてきました。
また、UNIX(ユニックス:OSの種類)の内部コードとして使われていた文字コード「EUC(イーユーシー)」も、Shift_JISと同様に通信の場面でも使われるようになった文字コードです。
これらの内部コードが通信でも用いられるようになると、当然、先述したように7ビットのコード体系ではないため、最上位ビットが削られてしまって文字化けが起こったり、ISO-2022に則していないために、誤作動を起こしてしまったりという問題があります。
このように、英語圏以外の2バイト文字を使用する私たちには、「文字コード」というのは鬼門のような存在です。
複雑にシステムの増築や改築をした結果、複数の文字セットの切り替え、7ビットコードしか伝送できないシステムのための様々な符号化方法、内部コードが通信にも用いられるなど、文字コード体系は複雑な仕組みになってしまっています。また、
インターネットの世界では扱う文字コードが決まっていない
というのが現実です。電子メールの世界では、ISO-2022-JPを使用するのがルール(マナーに近い)ですが、Shift_JISを用いることが禁止なわけではなく、8ビットコードに対応したサーバを経由し、送信相手もShift_JISを用いれば、問題なく通信し合うことができます。
ウェブページにおいては、まさにバラバラで、ブラウザの機能で文字コードを判別し、そのウェブページが読める文字コードに自動変換するのが一般的です。
OSの性能や技術の進歩のおかげで、文字コードが混在してもスムーズに通信できたり、ブラウザの高性能化でウェブページが閲覧できる環境になっていると言えます。
しかし、文字コードが原因で発生する問題が全て解消できるわけではありませんし、処理に無駄が多いことも事実です。それならばいっそ、こうした問題解決のために、
世界中の全ての文字を網羅した一つの文字コード体系を作成する
という構想を立ち上げ、多重言語の文字コードセットの作成が行われました。つまり、異なる文字に同じコードが重なるということなく、世界中の全ての文字に独立した番号を与えるという壮大なプロジェクトです。
こうして誕生した文字コード体系を、
Unicode(ユニコード)
と言います。当初はコンピュータの内部コードとして採用されましたが、通信用の外部コードとしても世界統一の文字コードとして今後広く普及していくことが予測されます。が、こと文字コードにおいて、そうすんなり行くはずはありません。
Unicode(ユニコード)は、当初、またもや漢字などを扱わないアメリカ等が主導して開発されたため、2バイト(16ビット)コードとして策定されました。
しかし、2バイト(最大65536文字)では、世界中の全ての文字を含めるには全然足りないことがはっきりしたために、このコードにおいても複雑なシステムの増築や改築が必要になったのです。
本末転倒ですが、世界中の文字をこの限られたスペースに詰めこむために、形の似ている文字は一つにまとめることにされ、文字統合が行われました。
例えば、漢字を扱う言語は中国語、日本語、韓国語などがありますが、各国で用いられている漢字コードから重複するものや意味、構造が同じものをまとめて「漢字統合」を行い2万字程度に減らされてしまった経緯があります。(当然かなりの批判があります)
このように、すべての文字の収録を目的に作成が行われたUnicodeも、当初の16ビットでいいだろうという目論見が元凶となり、この文字コードも紆余曲折するハメになりました。
その結果、Unicodeは、部分的に3バイト以上を使用する体系に変化し、現在では、Unicode全体は4バイト(正確には31ビット)で定義されています。
31ビットという広大なビット列を使えば、おそらく全世界のすべての文字を収録できる文字セットを作成することができます。(231=2147483648で、約21億語扱うことができる)
ただし、31ビットのまま使われることは滅多にありません。既存のマルチバイトコード(8ビットや16ビットコード)と併用できるように、8ビット単位または16ビット単位に変換(エンコード)して使われます。
8ビット単位への符号化方式が「UTF-8(ユーティーエフ ハチ)」
16ビット単位への符号化方式が「UTF-16(ユーティーエフ ジュウロク)」
と言います。UTF-8は、ASCII文字を8ビットのまったく同じ文字コードに変換し、残りの日本語文字などを8ビット×2、×3、×4、×5、×6のビット列に変換します。
したがって、ASCIIと互換性があるので、通信双方でASCIIとUTF-8を使っていても文字化けせず正しく表示されます。(もっとも、Unicodeは多くの文字に対応しているため、相手側のパソコンがUTF-8で実装している文字に対応していない場合は文字化けしたりします)
UTF-16は、16ビットもしくは、16ビット×2のビット列に変換します。ちなみに当サイトの文字コードは「UTF-8」を使用して作成しています。
さて、Unicodeは、前述のとおり内部コードとして開発されました。なぜなら、外部の通信は、ISO 2022のような規格があり、各国で文字コードセットを切り替える文字コードの拡張方式でなんとか通信を行うことはできるからです。
しかし、内部コードまで文字コードセットを切り替えるような方式を用いると処理作業が増え、速度が遅くなるし、なにより、米国企業のコンピュータの供給側からすると、各国の文字コードに対応するだけで膨大なコストがかかるためです。
そこで、世界で一つの文字コードが存在してくれると、いちいち国ごとにシステムを拡張したりせずに済むうえ、文字化けやシステム障害等の心配もありませんし、コンピュータに限らず、あらゆるソフトウェアの開発コストも安くなります。
したがって、Unicodeがコンピュータの内部コードとして標準搭載され、スタンダードになるにつれて、通信用の外部コードにおいても世界で使用される文字コードの主流は、Unicodeに移行していくことになると思います。
もっとも、よりスムーズで無駄(文字コードセットの切り替え等)のない通信を確立するために、今後、7ビットコードにしか対応できない古いサーバシステム等の対応が必要です。
しかし、IPv6への移行がスムーズに進まないのと同様に、ユーザーが複雑な「文字コード」における被害をそれほど被らない、または認識していない現状で、文字コードがはたしてスムーズに統一されるかは疑問があります。
さて、このように「文字コード」とは、単に文字に対応させた数値という単純なものではありません。実際に自分の意思を伝える「言葉」であり、インターネットで世界がつながった現在では、各国の「言葉」に対応しなければなりません。
その各国でバラバラの文字コードが用いられていたり、アメリカに代表される英語圏の文字の使用しか想定されていないシステムなど、その対応は複雑を極め、コストもかかる悩みの種なのです。
そのため、「文字コード」というものを理解しようとすると歴史も学ばなければならず、かなりの労力がいります。しかし、とても大切な知識ですので他サイトも参考に十分学習してください。
※本項の作成にあたり、参考サイト を参考にさせていただきました。内容が酷似することを避け、無断転載等には十分配慮しているつもりですが、至らない点についてはご容赦いただけると幸いです。
更新履歴
- 2009年10月2日
- ページを公開。
- 2009年10月2日
- ページをXHTML1.0とCSS2.1で、Web標準化。レイアウト変更。
- 2014年5月23日
- 内容修正。
- 2018年2月5日
- ページをSSL化によりHTTPSに対応。
参考文献・ウェブサイト
当ページの作成にあたり、以下の文献およびウェブサイトを参考にさせていただきました。
- 文字コードの発展経緯から役割と仕組みを学ぶ
- http://itpro.nikkeibp.co.jp/article/COLUMN/20061122/254616/
- 文字コード問題を考える
- http://www.horagai.com/www/moji/moji000.htm
- 文字コード入門
- http://www.shuiren.org/chuden/teach/code/index-j.html
- 管理人のつぶやき
- Twitterのフォローお願いします!