人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

文字コードや文字化けについて。

文字コードやエンコード等がよく分かりません。

文字化けについて、例えば、1.txtというテキストファイルがあるとして、そのファイルを作成する時に、SJISを指定して作成したら、そのファイルの文字コードがSJISで作成される。そのファイルをSJIS以外のエンコードを指定されたエディタで開くと、文字化けする。

ということでしょうか?

●質問者: koime_ryokutya
●カテゴリ:コンピュータ インターネット
✍キーワード:SJIS txt エディタ エンコード テキスト
○ 状態 :終了
└ 回答数 : 4/5件

▽最新の回答へ

1 ● 勇者よっしー
●23ポイント

>文字化けについて、例えば、1.txtというテキストファイルがあるとして、そのファイルを作成する時に、SJISを指定して作成したら、そのファイルの文字コードがSJISで作成される。そのファイルをSJIS以外のエンコードを指定されたエディタで開くと、文字化けする。

これは正しいです

---

まず、コンピュータというのものは、内部は全て0か1のデジタルで処理しているという大前提があります。

つまり、文字のデータも0か1の集まりです。

0と1の集まりを文字にしたり、文字を0と1の集まりにする「ルール」が、SJISやJIS、EUCなどの「文字コード」と呼ばれているものです。

---

日本語より先に、英語の文字、つまり半角のABCD……という文字でさえ、コンピュータが出来ていろんな人がいろんなルールで作成してしまった為、ルールが統一されていません。

多くの場合ASCII(JIS)コードというもので扱われますが、メインフレームというコンピュータではEBCDICコードを主に使います。

英語でさえそうなのですから、日本語では更に複雑で難しいルールが複数乱立してしまいました。

---

ある文字コードで書いたテキストファイルを別の文字コードで読み込んでしまうと、間違ったルールのまま翻訳してしまい、結果、ワケの判らない文字や文字でないものが混じり合った滅茶苦茶な翻訳結果になってしまいます。

---

最初に「このテキストファイルの日本語はJISコードです」等と宣言するルールがあれば、文字化け問題など起きなかったかも知れませんが、そういったルールは作られませんでした。

つまり、コンピュータは、そのテキストファイルが何の文字コードを使っているのか判らないまま、データを読み込んで、ある程度読み込んでから推察してコードを決めています。

更に、そのルールは「ルール自体が被っている」ので「このテキストファイルで使用されている文字コードは何か?」の判断は、計算だけでは完全にはできず、コンピュータ任せではできなくなっています。ある程度は出来ますが、100%ではありません。なので、大抵のテキストエディタには、文字コードを人間が指定して読み込む方法が必ず用意されています。


2 ● じゃっくそにっく
●23ポイント

こんにちは。

ご存知かと思いますが、

文字コードごとに、「文字:コード」の対照表が全く違います。

たとえば、

文字コード 日本語の'あ'に対応するコード(16進数)
Shift-JIS 82A0
UTF-8 E38182
JIS 2422
EUC-JP A4A2

といったようにです。

エンコード(エンコーディング)は、対象の何の文字コードとして解釈するか(取り扱いを行うか)になります。

本来想定された文字コードではない、想定されていない文字コードの対照表で「文字:コード」の対照変換(エンコーディング)が行われれば、

当然文字化けを起こします。

元のコードを違う文字コードに合わせるように変換を行う場合は、

phpの場合なら、mb_convert_encoding()というような関数を使います。


UTF-8の場合は、BOMというものもが着いたりしますが、

詳しいことはこちらを参照してください。

文字コード | PHP Labo


3 ● Banias
●22ポイント

例えば、1.txtというテキストファイルがあるとして、そのファイルを作成する時に、SJISを指定して作成したら、そのファイルの文字コードがSJISで作成される。そのファイルをSJIS以外のエンコードを指定されたエディタで開くと、文字化けする。

その通りです。


文字コードに関する入門書的な参考書をご紹介します。

図解でわかる文字コードのすべて―異体字・難漢字からハングル・梵字まで

図解でわかる文字コードのすべて―異体字・難漢字からハングル・梵字まで

  • 作者: 清水 哲郎
  • 出版社/メーカー: 日本実業出版社
  • メディア: 単行本


4 ● a-kuma3
●22ポイント

No.1 の回答が、とてもまとまってるので、その補足だけ。


最初に「このテキストファイルの日本語はJISコードです」等と宣言するルールがあれば、文字化け問題など起きなかったかも知れませんが、そういったルールは作られませんでした。

「じゃあ、宣言するルールを作ろう」と思った人たちもいて、XML というルールを作りました。

テキストファイルの最初の行に、↓のような宣言を入れ、このデータは XML だよ、ということと、文字セットにはこれを使っているよ、というのを明示的に示します。

<?xml version="1.0" encoding="UTF-8" ?>

ただ、それでも文字コードの解釈が正しく行えないケースもあって、文字セットにはどういう文字を使う、ということを決めているのですが、それに正しくしたがってないベンダーもいたりします。

http://www.iana.org/assignments/character-sets


最近の「文字化け」は、化けている、というよりは正しく表示できてない、ということがほとんどですが、昔は、本当に化けちゃう(データが変わってしまう)ことも、よくありました。

まず、コンピュータというのものは、内部は全て0か1のデジタルで処理しているという大前提があります。

つまり、文字のデータも0か1の集まりです。


昔は電話線で、0と1を音に変えて送ってたんですが、電話なので音が飛んだり、変わったりすることがあります。

ひとつの数字が0→1に変わるだけで、別の文字になってしまうので、受け取った側で文字が化けている、ということになります。

送ったデータが正しく遅れているかどうか判別する、とか、データが壊れているようだったら修復する、という技術もずいぶん開発されました。


また、データは、0 or 1の組合せ(ビット)を8個で、ひとまとめにして扱う(バイト)のですが、ASCII を使ってる人達は7個のビットで自分たちの文字が表現できるので、

あまったひとつを別の意味に使ったり、データを中継するときに省いてしまったりすることもありました。

これをやるサーバを中継すると、8ビット使わないと表現できない文字セットを使ってる人達のデータが、きれいに化けてしまいます。


これを回避するために BASE64 のような、任意のデータを ASCII の範囲だけで表現するエンコード方法を作った人達もいます。

関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ