とらりもん - 情報のデジタル表現: (4) テキスト型式 Diff
- Added parts are displayed like this.
- Deleted parts are displayed
like this.
テキスト形式では、データを文字の並び, すなわち「文字列」で表現する。文字なので, 「123」のような数値だけでなく"Hello!"のような単語や文章も表現できる。ところが, その実体は, 数値の羅列である。どういうことかというと, あらかじめ, 各文字には「背番号」が振られてあり, 文字列はその「背番号」の羅列として表現されるのだ。すると, 当然ながら, どの文字にどの数値（背番号）が対応するかという「対応表」が大事になってくる。その対応表を「文字コード」と呼ぶ。
!文字コード
文字コードは, 世界のIT研究者や技術者が相談しあって, 共通のものがいくつか提案されている。
最も大事な文字コードは, 「アスキーコード」である:
*アスキーコード(ascii character code)： 半角の英数字・記号等。各文字につき1バイトで表現される。漢字は入っていない。
アスキーコードは歴史が古く, コンピュータで漢字やひらがなが使えなかった頃（そんな頃もあったのです!)から使われてきた。というか, コンピュータの歴史の初期の頃は, アルファベットと数字だけを使うのでも大きな進歩だったのである。アルファベットの大文字と小文字, そして0から9までの数字, さらに, コンマ「,」やドット「.」, コロン「:」, ダブルクオート「"」などの記号(文字)をぜんぶあわせても100種類にもならないので, 1バイト(0から255, もしくは0x00〜0xFF)で十分に表現できる。なので, アスキーコードでは, 「1文字を1バイトの数値で表現する」という取り決めになった。
ところが, コンピュータが発達すると, 日本や中国では漢字を使いたいし, 韓国ではハングル文字を使いたいし, ...というように, 各国で独自に使われている文字もコンピュータで使いたくなったのである。そういうのは種類が膨大である。漢字だけでも（というか主に漢字のせいだが）, 何千, 何万種類もある。それらをそれぞれ1バイトで表現するのは無理である（1バイトで表現できるのは256種類まで!)。そこで, それらを2バイト以上の数値で表現する文字コードがいくつか開発された：
*EUC： 漢字・かなを含めた、日本語文字と全角英数字記号の表現のひとつ。2000年頃までのUnixで主流。各文字につき2バイトで表現される。
*Shift-JIS(SJIS)EUC： 漢字・かなを含めた、日本語文字と全角英数字記号の表現のひとつ。Windowsで主流。各文字につき2バイトで表現される。
*[[UTF-8|http://ja.wikipedia.org/wiki/UTF-8]]: 日本語・中国語・アラビア語・韓国語など、世界の多くの言語の文字を統一的に表現する文字コード。現在のUnixで主流。各文字につき2バイト以上6バイトまでの数値で表現される。
EUC, SJIS, UTF-8の間には互換性が無い。だから, 例えばEUCで書かれた文書をUTF-8として表示すると, 「文字化け」を起こす。逆に言えば, 「文字化け」の原因の多くは, 書かれた文書の文字コードと, 表示しようとしているソフトの文字コードの食い違いが原因である。
ただし, これらの文字コードの多くは, （半角の）アルファベットや数字, コンマなどの記号は, 原則的にアスキーコードをそのまま使う。つまり, アスキーコードの拡張という形になっている。従って、（半角の）アルファベットや数字, コンマなどの記号だけで書かれたテキストデータなら, 実質的に文字化けの心配は不要である（なので, 大事なコメントや情報は英語で書こう!）。
* アスキーコードの例："a"=97, "b"=98, "1"=49, "2"=50, "$"=36, " "=32
* EUCの例： "山"=46011=0xBBB3
* SJISの例： "山"=21134=0x8E52
* UTF-8の例： "山"=0xE5B1B1
さて, 実際にテキストデータを使っていて, 文字化けに出会ったらどうしたらいいだろうか? とりあえずUnix (Linux)のコンソールでテキストデータのファイル"data.txt"をcatコマンドなどで表示したら文字化けした! というような場合は, nkfというコマンドが助けてくれる:
$ nkf -w data.txt
もしくは,
$ cat data.txt | nkf -w
(-wはUTF-8への変換。EUCへの変換は-e。Shift-JISへの変換なら-s)
!改行コード
テキストデータには, もうひとつ厄介なことがある。同じ文字コードを使っていても、OSによって、改行コード(行の切れ目、つまり段落やパラグラフの終端を表すコード)は, OSによって異なることがあるのだ。実際、Windows, Macintosh, Unixのそれぞれで、改行コードは以下のようにバラバラに決められている：
Windows: 13 10 (0x0D0A)
Mac: 13 (0x0D)
Unix: 10 (0x0A)
このため、例えばUnixで作られたテキストファイルをMacintoshやWindowsで表示しようとすると、うまく改行がされないことがある。
従って、異なるシステム間でテキストデータをやりとりするときは、文字コードと改行コードを正しく認識し、随時、適切な形式に変換しなければならない。たとえば、一般に、衛星データの多くはUNIXで処理されているので、衛星データに付随してくるテキスト形式のファイルをWindowsで処理しようとすると、問題になることがある。
改行コードは、UNIXのコンソールの上で、以下のようにすれば変換することができる：
$ perl -pe 's/\r\n/\n/' winfile > unixfile
$ perl -pe 's/\r/\n/g' macfile > unixfile
$ perl -pe 's/\n/\r\n/' unixfile > winfile
参考ページ: http://www.rsch.tuis.ac.jp/~mizutani/online/with-pc/textline.html
!特殊なテキスト形式 ... CSV形式
表形式のデータを表現するために、「[[CSV形式|https://ja.wikipedia.org/wiki/Comma-Separated_Values]]」という特殊なテキスト形式がある。特殊といっても、表の列の区切りをカンマで表す、という約束があるだけだが。
!文字コード
文字コードは, 世界のIT研究者や技術者が相談しあって, 共通のものがいくつか提案されている。
最も大事な文字コードは, 「アスキーコード」である:
*アスキーコード(ascii character code)： 半角の英数字・記号等。各文字につき1バイトで表現される。漢字は入っていない。
アスキーコードは歴史が古く, コンピュータで漢字やひらがなが使えなかった頃（そんな頃もあったのです!)から使われてきた。というか, コンピュータの歴史の初期の頃は, アルファベットと数字だけを使うのでも大きな進歩だったのである。アルファベットの大文字と小文字, そして0から9までの数字, さらに, コンマ「,」やドット「.」, コロン「:」, ダブルクオート「"」などの記号(文字)をぜんぶあわせても100種類にもならないので, 1バイト(0から255, もしくは0x00〜0xFF)で十分に表現できる。なので, アスキーコードでは, 「1文字を1バイトの数値で表現する」という取り決めになった。
ところが, コンピュータが発達すると, 日本や中国では漢字を使いたいし, 韓国ではハングル文字を使いたいし, ...というように, 各国で独自に使われている文字もコンピュータで使いたくなったのである。そういうのは種類が膨大である。漢字だけでも（というか主に漢字のせいだが）, 何千, 何万種類もある。それらをそれぞれ1バイトで表現するのは無理である（1バイトで表現できるのは256種類まで!)。そこで, それらを2バイト以上の数値で表現する文字コードがいくつか開発された：
*EUC： 漢字・かなを含めた、日本語文字と全角英数字記号の表現のひとつ。2000年頃までのUnixで主流。各文字につき2バイトで表現される。
*Shift-JIS(SJIS)EUC： 漢字・かなを含めた、日本語文字と全角英数字記号の表現のひとつ。Windowsで主流。各文字につき2バイトで表現される。
*[[UTF-8|http://ja.wikipedia.org/wiki/UTF-8]]: 日本語・中国語・アラビア語・韓国語など、世界の多くの言語の文字を統一的に表現する文字コード。現在のUnixで主流。各文字につき2バイト以上6バイトまでの数値で表現される。
EUC, SJIS, UTF-8の間には互換性が無い。だから, 例えばEUCで書かれた文書をUTF-8として表示すると, 「文字化け」を起こす。逆に言えば, 「文字化け」の原因の多くは, 書かれた文書の文字コードと, 表示しようとしているソフトの文字コードの食い違いが原因である。
ただし, これらの文字コードの多くは, （半角の）アルファベットや数字, コンマなどの記号は, 原則的にアスキーコードをそのまま使う。つまり, アスキーコードの拡張という形になっている。従って、（半角の）アルファベットや数字, コンマなどの記号だけで書かれたテキストデータなら, 実質的に文字化けの心配は不要である（なので, 大事なコメントや情報は英語で書こう!）。
* アスキーコードの例："a"=97, "b"=98, "1"=49, "2"=50, "$"=36, " "=32
* EUCの例： "山"=46011=0xBBB3
* SJISの例： "山"=21134=0x8E52
* UTF-8の例： "山"=0xE5B1B1
さて, 実際にテキストデータを使っていて, 文字化けに出会ったらどうしたらいいだろうか? とりあえずUnix (Linux)のコンソールでテキストデータのファイル"data.txt"をcatコマンドなどで表示したら文字化けした! というような場合は, nkfというコマンドが助けてくれる:
$ nkf -w data.txt
もしくは,
$ cat data.txt | nkf -w
(-wはUTF-8への変換。EUCへの変換は-e。Shift-JISへの変換なら-s)
!改行コード
テキストデータには, もうひとつ厄介なことがある。同じ文字コードを使っていても、OSによって、改行コード(行の切れ目、つまり段落やパラグラフの終端を表すコード)は, OSによって異なることがあるのだ。実際、Windows, Macintosh, Unixのそれぞれで、改行コードは以下のようにバラバラに決められている：
Windows: 13 10 (0x0D0A)
Mac: 13 (0x0D)
Unix: 10 (0x0A)
このため、例えばUnixで作られたテキストファイルをMacintoshやWindowsで表示しようとすると、うまく改行がされないことがある。
従って、異なるシステム間でテキストデータをやりとりするときは、文字コードと改行コードを正しく認識し、随時、適切な形式に変換しなければならない。たとえば、一般に、衛星データの多くはUNIXで処理されているので、衛星データに付随してくるテキスト形式のファイルをWindowsで処理しようとすると、問題になることがある。
改行コードは、UNIXのコンソールの上で、以下のようにすれば変換することができる：
$ perl -pe 's/\r\n/\n/' winfile > unixfile
$ perl -pe 's/\r/\n/g' macfile > unixfile
$ perl -pe 's/\n/\r\n/' unixfile > winfile
参考ページ: http://www.rsch.tuis.ac.jp/~mizutani/online/with-pc/textline.html
!特殊なテキスト形式 ... CSV形式
表形式のデータを表現するために、「[[CSV形式|https://ja.wikipedia.org/wiki/Comma-Separated_Values]]」という特殊なテキスト形式がある。特殊といっても、表の列の区切りをカンマで表す、という約束があるだけだが。