東京大学教養学部
全学ゼミ「インターネットテクノロジー入門」
講義ノート (1998年1月9日)

文字コード

豊田英司
toyoda@ms.u-tokyo.ac.jp
東京大学大学院数理科学研究科

はじめに

計算機が文字を扱うときは、文字を整数に対応させて表現していることが多い。 この文字と対応する整数 (あるいは対応づけ) を 文字コード(character code) という。

インターネットなどで英語や日本語のローマ字表記を使うならば 文字コードについては ASCII だけを知っていれば十分であるが、 日本語漢字仮名混じり文を表現するためにはいろいろな文字コードが使われている。 本講はこれらの文字コードたちの成り立ちと望ましい使い方を理解することを 目的とする。


文字集合と符号化方式(符号拡張法)

コンピュータでは 8ビット (1オクテット) を単位 (1バイト―これは8ビットとは限らない) として入出力などの処理をすることが多い。 またシリアル通信などでは 7ビット単位の入出力を行うこともある。

後述する ASCII は 7ビット整数で表現できるので、 ASCII だけか同程度に少数の文字を使うならば 文字コードをそのまま入出力に使って差し支えない。 つまりファイルなどにある1バイトの数値が そのまま文字に対応すると考えて差し支えない。

しかし多数の文字を扱う場合には 7ビットや 8ビットでは おさまりきらないので、 各バイトの数値を直接文字に対応させるのではなく 何らかの工夫 (変換) を用いる。 これを符号化 encoding という (encoding は一般的な語で文字処理以外の文脈でも使うので注意)。 以下の議論では符号化の具体的な方法を文字集合と並行して紹介するが、 文字集合と符号化の区別に注意して読まれたい。

7ビットの文字集合 (ASCII と ISO 646)

ほとんどのコンピュータでは ASCII または ASCII のスーパーセットの 文字コードを用いている。

ASCII

ASCII code table

ASCII は American Standard Code for Information Interchange の略で、 ANSI X 3.4-1968 という ANSI 規格 (JIS に相当するもの) である。 たいていの UNIX では man ascii とするとコード表を得ることができる (ただし ISO 646 的文字化け等で役に立たない可能性はあるが...) 。

ASCII は 0/0 (0列0行 という意味; 図の左上の NUL) から 7/15 (右下の DEL) までの 128 個の符号を用いている。 これらは 16 進数 (以下プログラム言語 C にならい 0x をつけて示す) で 0x00 から 0xFF までの 7ビット整数とみなすこともできる。 16進表記は列と行の番号を16進数字で書けばよい。

このうち図の赤の部分 (0/0 から 1/15 と 7/15) は 普通にいう文字ではなく 改行やタブなどの特別な意味を与えられており、 制御文字 (control character) と呼ばれている。 また制御文字ではない部分 (図の緑の部分) を 図形文字 (graphic character) という。 2/0 にある間隔 (space) は元来 ASCII では制御文字としていたが 図形文字とすることもある。

ISO 646

ISO 646 BCP

世界各国では ASCII と大体が共通でいくつかの図形文字が異なる 7ビットの文字集合が使われている。 日本では JIS X 0201 のラテン文字集合 がこれにあたる。 これらの多くは ISO 646 という国際規格に従っている。

ISO 646 は ASCII の図形文字にあたる部分を規定するもので、 図のように世界共通でなければならない部分 (invariant set) と選択できる部分が決められている。 また ASCII にあたるものが国際基準版 (International Reference Version) となっている。

文字集合 \ 符号位置 2/3 2/4 4/0 5/11 5/12 5/13 5/14 6/0 7/11 7/12 7/13 7/14
ANSI X3.4-1968 (ASCII, ISO646国際基準版) # $ @ [ ] ^ ` { | }
JIS X 0201-1997 ラテン文字 (JIS C 6220-1969 ローマ字) # $ @ [ ] ^ ` { | }
BS 4730 (英国) £ $ @ [ ] ^ ` { | }
NF Z 62-010-1982
(フランス)
# $ á ° ç § ^ μ é ù è ¨
DIN 66 003 (ドイツ) # $ § Ä Ö Ü ^ ` ä ö ü ß
SEN 85 02 00 Annex C
(スウェーデン)
# ¤ É Ä Ö Å Ü é ä ö å ü
IBM Spanish # $ ¡ Ñ Ç ¿ ` ´ ñ ç ¨

ISO 646 に従う各種の文字集合の異同。 シフト JIS では表現できない文字は ISO 8879 の実体参照を用いたが うまく見えない場合には文字集合名称のところからリンクしておいた 京大の安岡さんの文字表を参照されたい。

しかし同じ符号位置を国ごとに別の文字に割り当てていると 情報交換が国内で閉じているうちは問題ないが、 何も考えないで国際的に情報交換すると 米国で「#」のはずが英国では「£」に、 「\」のはずが日本では「¥」に化けてしまう といった問題が発生する。

7ビットの空間を使いながらこの問題を解決するためには 文書のなかで文字集合を切り替える必要がある (これは後述する ISO 2022 の符号化によって可能) が、 必要な文字数が 256 以下ならば、 切り替えが不要になるので 8ビットの空間をそのまま用いることができる。

ISO 6429

ASCII の制御文字にあたる部分は国際規格 ISO 6429 で規定されている。 日本での翻訳規格は JIS X 0211 である。 これらの規格では (ASCII の項でみた制御文字にあたる) C0 制御文字集合のほかに C1 制御文字集合をも規定している。

8ビットを前提とした文字集合

8 ビットの整数では 0 から 0xFF (255) までの値が表現できるので、 ASCII を使うと 0x80 から 0xFF までは空き地になる。 ここを使うことを前提にすると特別な符号化の工夫をしなくても 200 字程度の大きさの文字集合を作ることができる。

JIS X 0201 ― 英数字とカタカナ

JIS X 0201 code table

ISO 646 の日本版である JIS X 0201 は ISO 646 の項で紹介したラテン文字だけではなく カタカナの文字集合を規定している。 ラテン文字とカタカナを同時に用いる際は以下のようにする:

8 ビットの場合
ラテン文字の部分は ASCII と同じでカタカナは 10/1 から 13/15 に割り当てる。 ある1バイトを解釈するときはその最上位ビット (Most Significant Bit; MSB) を見ればラテン文字集合かカタカナ集合かが判定できる。
7 ビットの場合
制御文字 SI と SO を用いてラテン文字とカタカナを切り替える。 バイト列を解釈するとき、SO が現れた後の 2/0−7/14 はカタカナ、 SI が現れた後の 2/0−7/14 はラテン文字と解釈する。
この SI/SO による制御は JIS X 0202 (ISO 2022) の一部で、 JIS X 0201 だけでなく広く用いられている。

ISO 8859 ― 欧州の国際化

欧州諸国で必要となるが、ASCII にはない文字を集めたもの (正確に言うと ISO 8859 の各面は 2/1−7/14 に ASCII と同じ文字をも含んでいる)。 さきほどの JIS X 0201 と同じように 8 ビットの空間を使って ASCII で使っていない 10/1−15/14 に入れて使うように作られている。 ISO 8859/1 から ISO 8859/10 まで 10 の文字集合があって、 それぞれ最大 96 個の文字が含まれている:

西欧で使う非 ASCII 文字はすべて ISO-8859/1 (Latin 1 ともいう) に含まれている。

ASCII + ISO 8859/1 は欧米では広く用いられている。 たとえば Windows 95 の米国・西欧版の文字コード (Windows 方言では ANSI 文字セット) や 日本語版の欧文フォントは ASCII + ISO 8859/1 に若干の文字を追加したものである。 UNIX 機械でも運がよければ man iso_8859_1 のようなコマンドで Latin 1 の説明を読むことができるかもしれない。 また HTML でも ASCII + ISO 8859/1 が使えるとされている。

パソコンの機種依存する8ビット文字集合

パソコンには未定義域や制御文字の領域に 勝手に (他の規格などによらず、機種依存して) 文字を割り当てたフォントが搭載されていることがある。 文字コードに関する規格は「情報交換用」であり、 これらに特有な文字を一つのパソコンで用いているかぎりは 本来は悪くないのではあるが、 ファイルにそのような文字を含められるならば、 不注意によって情報交換に用いて混乱を起こしてしまう可能性は 非常に高いので注意が必要である。

IBM PC または互換機 では ASCII をベースとした 文字集合 を用いている。 米国以外の環境ではそれぞれ ISO 646 の各国版などをベースとした 文字集合を用いており、 この区別を MS-DOS ではコードページ (Windows では OEM コードページ) と呼んでいる。

NEC PC-9800 シリーズ では JIS X 0201 のラテン文字・片仮名用の8ビット文字集合をベースとした 文字集合 (図は右半面だけを示す)を用いている。 ただし日本語 MS-DOS では機種依存する文字が シフトJIS の1 バイト目にあたるためデフォルトでは表示できず、 問題が表面化しない。

多バイト文字集合

日本語の漢字かな交じり文や中国語などを表記するためには 最低でも数千の文字を必要とする。 またハングルは少数の構成要素から合成されるが、 組み合わせ方が複雑なので合成結果を1文字としてフォントを 用意したほうが便利である。 これらの文字は1バイトでは表現できないので2バイトを使って表現される。

符号化法として ISO 2022 を使うことを前提とした 日本・中国・韓国・台湾の国家規格では ASCII 図形文字に相当する符号 (2/1−7/14) が 2 つで1文字を 表わすようになっており、94×94 = 8836 文字が表現できる。 (台湾で使われる事実上の標準である Big5 はこれらと異なり シフトJIS と日本語 EUC の中間のような構造を持つ)。

また(少なくとも)日本では 94×94 文字集合の符号位置を示すのに 区点番号というものも用いられる。 これは1バイト目は 2/1, 2/2, ... 7/14 をそれぞれ 1区、2区、... 94区、 2バイト目は 2/1, 2/2, ... 7/14 をそれぞれ 1点、2点、... 94点と称するもので、 たとえば読点「、」(2/1 2/2, 0x2122) は 1区2点 である、 または区点番号は 0102 である、というように使う。 区点番号は各バイトの16進表現から 32 (0x20) をひいて10進表記したものに相当する。

JIS X 0208 ― いわゆる JIS 漢字

正式名称は 「7ビットおよび8ビットの2バイト情報交換用符号化漢字集合」。 文字表は 京大の安岡さんの作られたもの を参照。 これに含まれているのは

である。 漢字だけしか含まれていないわけではないが、 俗にこれらをまとめて「JIS 漢字」と呼ぶことがある。

JIS X 0208 には ASCII・JIS X 0201 と共通する文字 (「A」と「A」、「$」と「$」など) が含まれている。 しかし両者をサポートする伝統的な固定幅表示装置では 両者が同じ文字であることを考慮せずにこれらを区別し、 JIS X 0208 の文字を ASCII・JIS X 0201 の文字の倍の幅で表示する ので、これらは俗に「全角文字」「半角文字」と呼んで区別されている。

しかし規格は文字の幅など規定していないし、 これらは同じ名称をもつ同じ文字なのだから、 異なる文字のように考えたり処理したりするのも間違っている。 これはそもそも同じ図形文字に2通りの表現 (重複符号化) が可能なのが 間違っているのである。

重複符号化を起こさないために、 JIS X 0208-1997 では ISO 646 系の文字集合と同時に利用するときは いわゆる全角英数字を使ってはならないとしており、 またシフトJIS (シフト符号化表現) でも いわゆる半角片仮名を使ってはならないことになっている。 ただし「これまでの慣習的利用との互換を目的とする場合に限って」 いわゆる半角片仮名と全角英数字に別の名称を与えて区別することを認めている。

JIS X 0208 は現行規格(1997年)までに以下のような改正を経ている:

JIS C 6226-1978
最初の規格
JIS X 0208-1983
罫線素片32字、特殊文字39文字、漢字4字を追加。 漢字の22対を入れ替え(「籠」「篭」など)、4字を字形を簡略化したうえ 元の字形を第2水準に追加し(「遙」「遥」など)、 300字の字形を変更した(「鴎」など)ため深刻な互換性の問題が生じた
JIS X 0208-1990
2つの漢字(「凛」「煕」)を追加。 また 300 の字形が変更されたがこの影響はあまり深刻ではない。
JIS X 0208-1997
文字の追加・削除や字体変更を行わず、 文字同定(包摂)基準や文字選定根拠を明確化した。 シフトJIS や junet コードによる符号化を付属書として追加
基本的には JIS X 0208-1997 に適合するためには 追加された文字を表示できなければならない。

JIS X 0212 ― 補助漢字

1990 年に制定されたもので、 補助漢字という。 漢字部分は文字同定基準が示されておらず、 しかも後述するシフトJIS で使えないためあまり使われていない。 JIS 第3水準という俗称もあるが、 別のものが第3水準と呼ばれることになるらしいので この呼び方はあまり勧められない。

JIS X 0213 (仮称)

上記のほかに 「第3水準・第4水準」と称するもの が開発中である。 こちらは シフトJIS で使えるように考慮しているらしい。

JIS X 0208 への勝手な拡張

国外の複数バイト文字集合

ISO 2022 の符号拡張法

ISO 2022 は複数の文字集合を共存させるための 非常に多様な拡張法を規定している。 詳細が知りたい向きは

などを参照されたいが、基本的には ということになる。

GL and GR regions invocation/designation illustration

文字を切り替えるに際しては

  1. 2/1--7/14 (ASCII の図形文字にあたる部分)を GL 領域という。 8 ビットシステムでは 10/1−15/14 を GR 領域という。 (本当は ISO 2022:1986 には GL, GR という語は出てこないが JIS の 他の規格などで広く使われているし、なにより便利なので以下こう呼ぶ)
  2. これら GR, GL 領域は呼び出し制御 SI, SO, SS2, SS3, LS0, LS1, LS2, LS3 (という名前の 1−2 バイトの制御コードが決められている) で中間バッファ G0, G1, G2, G3 に対応づけられる
  3. エスケープ文字 ESC ではじまる指示シーケンスによって G0−G3 に ASCII などの具体的な文字集合が指示される
という 2 段階の手順を使ってバイト符号と文字を対応づけている。 なお指示シーケンスの具体的な形とその指示する文字集合の対応は ISO 2022 自体には書かれておらず、 ISO 2375 によって登録事務局をしている ECMA (欧州計算機製造業者協会) という団体が管理している。

ISO 2022 はこのほかにもいろいろな符号拡張法が規定されているが、 とてもすべて完全に実装できるようなものではないので 目的に応じて ISO 2022 の適切な部分集合を用いる。 後述する 日本語EUC や junet code はこのような部分集合と解釈することができる。

日本語3大符号化方式: junet, 日本語EUC, シフトJIS

日本の UNIX, MS-DOS, Macintosh などでは通常、文字集合としては が用いられている。 しかしその符号化方式はさまざまであるところに問題が発生する。 日本語の符号化方式をよく漢字コードという。

junet コード

いまではもう少なくなりつつあるが、 伝統的な電子メール配送系では 1 バイトのうち 7 ビットの部分しか 利用できないようにしている。 そこで、junet コードと呼ばれる ISO-2022-JP ( RFC 1468 で規定されている) は ISO 2022 の 7 ビット系を使う。 これは主に email やネットニュースで使われている。

junet コードのことを俗に JIS コードと呼ぶことがあるが、 EUC も ISO 2022 (JIS X 0202) にのっとっているし、 シフトJIS も JIS X 0208-1997 の付属書に登場し、 さらにいうなら Unicode さえ JIS になっているのだから、 junet コードを JIS コードというのは意味をなさない。 7ビット JIS という言い方があるが、 まあこれならば意味が通じないことはないだろう。

junet code illustration

文字集合を切り替える際には G0−G3 の呼び出しを変えるのではなく、 以下のような指示シーケンスで G0 に各種文字集合を指示することで 切り替えている。

ESC $ @ JIS X 0208 の 1978 年版 (2バイト漢字)
ESC $ B JIS X 0208 の 1983 年版 (2バイト漢字)
ESC ( B ASCII (ラテン文字)
ESC ( J JIS X 0201 のラテン文字 (1バイト)
junet コードの指示シーケンス。

なお指示シーケンスなどを構成するバイト群は図形文字ではないので、 正式には ESC 2/4 4/0 などと数値で表現するのだが、 いまいち視認性が悪いしおぼえにくいので、 以下では俗に用いる ESC $ @ などというような 「数値を ASCII とみなした形」を書くことにする。

指示シーケンスで 1 バイト文字集合が指示されればその後の 各バイトは 1 バイトづつ該当する文字と解釈され、 JIS X 0208 が指示されればその後の各バイトは2バイトづつ文字とみなされる。

junet コードの利点は、文字の入れ替えなどで微妙に異なる JIS X 0208 の 1978/1983 年版の区別や、ASCII と JIS X 0201 の 区別がつけられることである。 欠点としては、JIS X 0208 の部分と 1バイト文字 の部分が同じ 7ビットなので、 ファイルの途中から読み始める場合などはいったんさかのぼって、 最後の指示シーケンスを探し出さないとどちらの状態なのか判別できない (これを stateful という) ことがあげられる。

たとえば「あ」という文字は JIS X 0208 では 2/4 0/2 であるが、 この部分を誤って ASCII とみなしてしまうと「$A」ということになり、 まったく違う文字になってしまう。 ちなみに通常この種の文字化けをしたテキストは多くの「$」を含む。 これは JIS X 0208 において平仮名の第1バイトが 2/4 だからである。

文字化けの危険を減らすために、junet コードでは

ということにしているが、このようにすることは ISO 2022 には適合しない。

インターネットの RFC としては ISO-2022-JP のほかに 補助漢字を追加した ISO-2022-JP-1 ( RFC 2237 ) や ISO 8859/1 ISO 8859/7、中国の GB2312-1980、韓国の KSC5601-1987 を追加した ISO-2022-JP-2 ( RFC 1554 ) が出ている。

日本語EUC

日本語EUC のことをただ EUC と呼ぶのはよくない。 EUC は Extended Unix Code の略で、1バイトの8ビットを全部使って ISO 2022 の GR 集合や SS2 などを使い、 ASCII とそれ以外の文字を共存させようとする符号化方式のことで、 日本語用だけではなく韓国語版・中国語版なども存在する。 EUC は元来 AT&T で開発されたので AT&T 漢字コードとも呼ばれる。 日本語EUCはこの日本語版である。 日本語・中国語・韓国語に対応している UNIX の多くは内部的には EUC を使っている。

EUC-jp illustration

日本語EUCでは指示シーケンスは暗黙に仮定されており、現れることはない。 そのかわり、G1 は MSB が立っていることにより区別される GR 領域に 呼び出されているものとし、G2 と G3 は呼び出しによって文字集合を切り替える。 具体的には

GL 領域の1バイト
(G0 文字集合として) ASCII (JIS X 0201 ラテン文字と同一視することが多い)
GR 領域の2バイト
(G1 文字集合として) JIS X 0208 (現行版ではなく古い版を使っている実装もある)
SS2 (0x8E) のあと 1 バイト
(G2 文字集合として) JIS X 0201 のカタカナ
SS3 (0x8F) のあと 2 バイト
(G3 文字集合として) JIS X 0212 (補助漢字) を割り当てることがある
となっている。

日本語 EUC の (シフト JIS や junet コードと比べた) 利点は ASCII 以外の図形文字は すべて MSB の立ったバイトで表現されており ASCII とは容易に区別されるため、 ASCII のことしか考えていないソフトでも動作する可能性が高くなることがあげられる。 欠点としては (これはシフトJIS も同じだが) ASCII と JIS X 0201 のラテン文字を同一視したり、 JIS X 0208 の古い版を現行規格と同一視したりする羽目になりがちなので いくつかの文字が混乱を起こすことがあげられる。

なおまっとうな ISO 2022 ならば SS2 や SS3 の後のバイト列は MSB が 0 でなければならない (GL になければならない) ように思えるのだが、 EUC では GR の対応する位置のバイトを用いる。 これは ASCII と混同しないためである。 果たしてこれでも ISO 2022 に適合するのであろうか?

シフトJIS

シフト JIS は 1982 年の開発以来 MS-DOS や Macintosh で用いられており JIS X 0208 と 1バイト文字 を同時に利用する符号化方式の 事実上の標準となっている。 長年まともな定義がなかったが JIS X 0208-1997 付属書2 でこれに相当するものが 規定された。

シフト JIS は JIS X 0201 ラテン文字 (EUC の項と同様に ASCII と同一視することが多い), JIS X 0208, ならびに JIS X 0201 カタカナの共存を図るために 作られた符号化方式であることは EUC と類似しているが、 伝統的な JIS X 0201 の使い方と互換性をもたせるために、 ISO 2022 とは無関係な変換 (シフトというゆえん) をして JIS X 0208 の文字を押し込んでいる。

まず JIS X 0201 のラテン文字と片仮名を 8ビットの GL と GR に 割り当てる。すると空いているところは CR (0x80−0x9F) と JIS X 0201 のカタカナ文字集合の未定義領域 (0xD0−0xFE) である。 シフト JIS はこの部分を「全角文字」の第 1 バイトとし、 これでは 94 通りおさまらないので 続く第2 バイトを 94 の 2倍のとることで 94×94 文字集合をおさめている。

シフトJISの問題は少なくない。

利点といいうるものはあえて言うと、あまりのお行儀の悪さに 漢字コード自動判別プログラムがほぼ判定を誤らないことがあげられる。 というわけで出来損ないの WWW ブラウザに読ませる HTML ファイルは シフトJIS で書くと (まっとうな解決とは思えないが) いちばん楽である。

Unicode

Unicode は「16ビット固定長で世界のすべての文字を表現しよう」 という考えにたって開発された文字集合である (が、もちろん16ビットでは足りない)。 1992 年に出版された Unicode 1.0 は ISO 10646 (JIS X 0221) の基本符号面 としても知られる。 Unicode 2.0 というものが出ているのだが筆者不勉強のため 現状を良く知らない。

Unicode は ISO 2022 で扱うことはできない。 また漢字の配列が JIS X 0208 とは異なるので対応表を見ないと変換できない。 このためわざわざ Unicode テキストを作る意義は今のところあまりない。 ただし Microsoft の Windows 95 では一部の、Windows NT ではほとんどの 内部処理に Unicode を用いており、 Windows 関係のプログラムでは内部表現として使わざるを得なくなっていくだろう。


実際的話題

email/NetNews 本文には junet コード

本文には junet コードを使うということになっている。 したがって JIS X 0201 のカタカナ文字集合 (いわゆる半角カタカナ)を使うことはできない。 EUC やシフトJIS などの MSB に意味がある漢字コードを 送ってしまうと、伝統的な 7ビット しか通さない配送系を通ったときに MSB が脱落してしまい、復旧が困難になる。 本文の MIME エンコーディングは受信者が解読できないことが 多いのでしないほうがよい。

ヘッダには特別の注意を要する。 Subject: などの unstructured (機械が解釈することのない) 部分は junet コードをそのまま用いてもよいが、 From:, Date: や To: などの structured (機械が解釈する) 部分は ASCII でいう @ や < などにあたるコードが出る可能性が あるので junet コードを使ってはいけない。 ここでも ASCII 以外の文字を使う場合は次に説明する MIME を使うべきである。

というわけで何も考えたくなければ「ヘッダは MIME」とすることを いちおうお勧めしておくが、 Subject: に関しては junet コードをそのまま使う 人もまだいるようで、どうするのがいいのかはあまり確定的ではない。

MIME

伝統的な 7ビットしか通さない電子メール配送系を使って、 画像・音声などの各種ファイルや ASCII 以外の文字を送るために 作られた拡張。 RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049 を参照。 これを用いたメールやニュース記事は Mime-Version: ヘッダを 持っているのでそれとわかることになっている。

MIME では ASCII 以外の文字やデータを

Quoted Printable encoding
問題を起こしそうなバイトだけを = と16進2桁で表現する
base 64 encoding
バイト列を長い整数とみなし、64進展開して ASCII 文字に 割り当てる
のどちらかのエンコーディングを施して問題をおこさないようにする ことができる。 email の本文ではこのようなエンコーディングは行わず junet コードを そのまま使う習慣であるが、ヘッダに漢字を入れる場合は junet コードを base 64 エンコーディングすることが多い。 MIME に対応していないメールリーダで From: や Subject: などに =?ISO-2022-JP?B? ではじまる文字列が表示されたらこれである。

UNIX ハウツー

漢字コード変換

日本語のかかれたファイルの符号化方式を変換したいという 需要はときおり発生する。 まず覚えてもらいたいのがフィルタ型の変換ツールである。

nkf
もっともありふれた変換ツール。 バージョン1.5以降ではMIME 解読機能もついてさらにお買い得。
coco
mule のパッケージに入っている変換ツール。 日本語で用いるものだけでなく mule の扱えるすべての文字が変換できる。 文字符号化方式の指定としては *junet* などの mule と 同じ記法を用いる点が特徴的 (かったるいともいうが) である。
kakasi
文字コードの変換だけではなく、 漢字かな変換やかなをローマ字に変換することもできる。 したがって海外遠征で ASCII しか読めなくなったときも これさえ備えておけば telnet だけで日本語のメールが読める。
その他
売り物の OS だと付属のものがあったりすることがある。

また mule, nemacs, jvim などの日本語対応のエディタでも ファイル書き出し時の符号化方式を指定してセーブすることで 変換することができる。 mule または nemacs ならば C-x C-k f としてから符号化方式を指定し、 jvim ならば :set jcode=E などとする。

cat などでファイルを作る

日本語入力用のソフトがなくなっても junet コードならば ファイルを作ることは容易である。

cat > filename
というコマンドで cat に対する標準入力をファイルにすることができるが、 ここで junet コードの指示シーケンスや JIS X 0208 の文字の番号 (に対応する ASCII 文字と思えばよい) をそのまま打ち込んでしまえばよい。 たとえば「あ」は 0x24 0x22 に対応するが、これを ASCII とみなせば 「$ "」であるから、前後に指示シーケンスをつけて ESC $ @ $ " ESC ( B を入力すれば、これは junet コードである。 なお、最後の ASCII に戻す指示シーケンスを忘れると以後の ASCII のつもりの文字がすべて化けるので困ったことになる。 注意が必要である。

ISO 2022 的文字化けの対処

ISO 2022 的な端末を使っているときに、ISO 2022 のファイル断片や バイナリファイルを表示したりすると、 端末の状態が変になって文字化けが生じることがある。

たいていの端末にはリセット用のコマンドがあって正気な状態に戻すことが できるのだが、いつでも使える方法として、前述の cat を用いる方法が使える。 まず単に cat と打ち、以下のような制御コードを 入力して、次に普通の ASCII 文字を打ったときのエコーバックが 正常になるか確かめてみるとよい。。

ESC ( B
G0 に ASCII を指示するエスケープシーケンス。
Ctrl-O
これは制御文字 SI であり、GL 領域が G1 に なっていたらこれを G0 に戻すことができる。
なお UNIX ならば tty ドライバの設定でいくつかの制御文字が直接入力できなく なっていることがあるので注意。

なお kterm の場合 Ctrl-中クリック に続き Do Full Reset でリセットすることができる。


文字の同定について

スペース・空白・間隔

SP をスペースというのは正しいが、空白というのはよくない。 UNIX 系の文化では「空白」を whitespace の訳語として用いるが、 これはスペース・タブ・復帰・改行・鉛直タブの総称である。 ちなみに日本の規格では SP は正式には「間隔」と呼ばれている。

JIS X 0208 の「 」は名称を「和字間隔」といい、 SP とは異なる文字となっているが、間隔の長さが「全角1つぶん」と 決まっているわけではないので「全角スペース」と呼ぶのは不適当である。

オーバーラインとチルド

確かに形状も名称も「違う文字」なのだが、ISO 646 に関しては伝統的に 同一視されている。 だから VM21 以降の PC-9800 や Windows 95 の MS明朝フォントのように、 JIS X 0201 でオーバーラインであるべきところがチルドになってしまっている ものでも JIS X 0201 には適合しうる。


参考文献

WWW のうち、本文中でリンクしたものは特に掲げていない。

書籍

WWW