過去の桐井戸端ＢＢＳ　（桐ver.５）
6520 文字コードの選択（桐Ver5） 沢田和明 2000/06/19-22:23
　幅田さん、みなさん　こんばんわ
　この掲示板を閲覧することを楽しみにしている者です。
　
●桐Ver5を使う上で、以前から疑問に思っていたことがあります。
　それは、文字コードの設定についてです。
　桐というより、ＦＥＰとかＩＭＥとかの問題でしょうが、日本語のデータを
扱うことの本質のような気もしており、ぜひ質問させてください。

●私は、なんとなく感覚として次のように理解しています。

　９０年代はじめ頃のパソコンはＪＩＳコードが主流だった．．．？
　（ＰＣ−９８用ＤＯＳソフトが全盛の頃でしょうか）
　　↓
　ウィンドウズを使うようになって、いつのころからかシフトＪＩＳが標準とされてきたような．．．？
　　↓
　そして電子メールでは文字コードは自動判別されるらしいし、
ついにユーザーが意識しなくてよい時代になりつつある．．．

　これって勘違いかもしれませんけど。
　
●で、ここから質問です。
　現在私は、Ｗｉｎ９５上で桐５＋松茸を使っているのですが、設定はＪＩＳコードが良いと思いこんでいます。
　これで構わないのでしょうか？
　たとえば、一太郎８にコンバートする、ＣＳＶ経由でエクセル９７で処理する、
等の場合に、問題は発生しないと言い切れるのでしょうか？

●さらに言うと、私がＪＩＳにしているのは、以前ＪＩＳコードで入力した数年前のデータの一部が、
今からシフトＪＩＳにしてしまったら、もしかして画面上・印刷で表示されないのではないだろうか、
と危惧していることもあります。

　※以前、ＰＣ−９８の桐ファイルの記号「Ｎｏ．」がＡＴ互換機では表示され
なくてすべて文字の「Ｎ」「ｏ」「．」に入力し直したことがあります。
　これは機種間の問題でしょうが、そのときの煩雑さが思い出されてしまって。

●このあたり、書籍を読んでもいまひとつ理解できなくて、そのまま現在に至ってしまっています。
　何か障害が発生したという訳ではないのですが、なんとなく確証がほしいな、
胸のモヤモヤをすっきりさせたいなと思って質問させていただきます。
　よくご存じの方がありましたら、ぜひご教示ください。
　よろしくお願いします。

6522 Re:文字コード Ogo 2000/06/20-01:25
記事番号6520へのコメント

>　９０年代はじめ頃のパソコンはＪＩＳコードが主流だった．．．？
>　（ＰＣ−９８用ＤＯＳソフトが全盛の頃でしょうか）
>　　↓
>　ウィンドウズを使うようになって、いつのころからかシフトＪＩＳが標準と
>されてきたような．．．？
>　　↓
>　そして電子メールでは文字コードは自動判別されるらしいし、ついにユーザ
>ーが意識しなくてよい時代になりつつある．．．

上記は全くの誤解です。

MS-DOS(Win 95)/Macintosh 系 では外部データ交換には SHIFT-JIS を使うのが標準です
（今までも、これからも）。
内部でどのような形でデータを持つかはアプリケーションの設計に依存します
（最近になって、内部データ格納コードをユニコードで持つものが出て来た）。
ちなみにアプリケーション内部でどのような形でデータを保持していようとも
データ交換には関係ありませんので、ユーザーがその違いを意識する必要はありません。

DOS 松茸を使っていると、起動時パラメーターの指定により、「区点コード」「JIS」「SHIFT-JIS」の中から
使用文字種を選択できるように誤解しやすいのですが、これは全く意味が違います。
アレはあくまでも「読み仮名不明の文字をコード入力する際に、
自分に取って都合の良い文字コード」を指定しているだけです。
松茸も桐も内部文字コードは（多分）SHIFT-JIS でしょう。
ユーザーに選択の余地はありません。

>　※以前、ＰＣ−９８の桐ファイルの記号「Ｎｏ．」がＡＴ互換機では表示され
>なくてすべて文字の「Ｎ」「ｏ」「．」に入力し直したことがあります。
>　これは機種間の問題でしょうが、そのときの煩雑さが思い出されてしまって。

これは、ＰＣ−９８の桐ファイルの記号「Ｎｏ．」が外字であることが原因です。
外字に関しては互換性がとれなくて当然。
NEC-98 で 桐 V5 & 松茸 の環境で当然と思って使っている外字も、
（同一環境でさえも）外字ファイルの中身を入れ替えると全く違った内容になってしまいます。
NEC-98 と DOS/V では外字に使える文字コードが違うので、互換できないことは
桐５のリファレンスにも明記していることで仕方ありません（でも、Ｋ３が本気で取り組めば
絶対に解決可能なんですけどね、 NEC-98 では ASCII 文字をわざわざ２バイト半角文字で
表示するようなことをしているのだから、同じことをすればいい筈）。

6523 Re:文字コード（余談） Ogo 2000/06/20-01:26
記事番号6522へのコメント
少し蛇足で文字コードの話を続けます。
これから書くことは、歴史上の順序はおかしいかもしれませんが、
理解しやすいように脚色していると考えて下さい。 (^^;;;
なお、文中で「８ビット目」という表現が出て来た場合、これは１バイトの８ビットコード中の
最上位ビットを意味します。
米国の ASCII コードではこのビットは使われません。

>　そして電子メールでは文字コードは自動判別されるらしいし、ついにユーザ
>ーが意識しなくてよい時代になりつつある．．．

こういう話も理解したいなら、とにかくデータ通信のことを知っておかないと
混乱ばかり増えて理解が前に進みません。

今現在普及している日本語を扱える文字コードとしては
１．「JIS 区点」
２．「（いわゆる）JIS (iso-2022-jp)」
３．「SHIFT-JIS (MS-漢字)」
４．「日本語EUC (EUC-jp)」
５．「ユニコード (UTF-8)」
などがあります。

この中で、本来の意味の JIS コード（文字を特定するという意味の）は
１．「JIS 区点」 のみで、それ以外はコンピューター（データ交換用）用に工夫したものです。

- - - -

ここで、コンピューターの出発点に遡ります。
コンピューターの出自は米国です。この国には文字は A 〜 Z と a 〜 z の
都合５２種類の文字しかありません。
それに数字やよく使う記号（コンマ・ピリオド・クォーティション等、キーボードから直接入力できる半角記号）を
合わせてもたかがしれています。
従って「文字は７ビット（１２８種類）のコードで表現しつくせる」というのがコンピューターの原則です。
コンピューターは８ビット＝１バイトを単位として進化を始めたので、残り１ビット分（１２８種類）あるわけですが、
これは適当に絵文字や絵記号が入っていました。
現在でも著作権を示す (c) や (r) 等を１文字で示す記号は、米語圏ではその中に入っていて、
日本人が WEB でその記号に出くわすと妙なカタカナに文字化けして表示されます。
通信等では送受信されたデータのチェックデジットとして使われるのが一般的でした
（つまり、８ビット目は通信内容と関係ない制御用のデータであるというのが重大な出発点）。

さて、コンピューターの黎明期は日本語を使うことができない状態でしたが、
日本独自の実装として、先ほどの「余白絵文字部分」にカタカナを入れてしまいました
（いわゆる半角カナ文字）。
カタカナに限定することで、英語のフォントと全く同じサイズの「半角カタカナフォント」も
デザイン可能だったのです。

当然ながら、日本人は漢字・カナ・かなの全ての文字を使いたい。
そこで更に、文字コードの拡張を行なうことにしました。
「JIS 区点」の「区」と「点」を単純に１バイトづつ符号化して２バイトの
データで表現するのが基本で、これが「JIS 文字コード」の出発点です。
当然ながら、米国ゆかりのデータ・プログラム（コンパイラを含む）は当然
米国 ASCII 規格（最初に述べた７ビット英数字）に基づいていますので、
これも扱えるようにすることは必然です。これを正常にハンドリングできない
「２バイトコード専用コンピューター」は存在の余地がないのです。

また「JIS 区点」とは「文字の種類と文字コードを１対１で対応させたもの」に過ぎず、
文字の表示デザインを規定していません。
ここで言いたいのは、「JIS コードには、全角／半角などという区分が存在しない」
という事実です。
従って、半角の英数カタカナ等を全角のそれと区別する必要があるならば、
JIS コード以外の区別方法も確保する必要があるのです。

必然的に、米国 ASCII 規格と日本の JIS 規格が両立するための方法がいろいろと考案され、
文字コードの分化が始まりました。
ポイントとなるのは「同じデータとして送られて来る日本語の１バイト目と
２バイト目・そして ASCII 文字と半角カタカナの４種類をどうやって区別するか」です。

6524 Re:文字コード（余談） Ogo 2000/06/20-01:28
記事番号6523へのコメント
- - - -

２．「（いわゆる）JIS (iso-2022-jp)」
実は「JIS 区点」を作る時からこれまでの経緯を踏まえたものであるため、
「区」も「点」を単純に１バイトづつ符号化した場合は７ビットまでしか
使っていません（通信機器・プロトコル・ソフト等の中には８ビット目を全く
無視して通さないものがあるからです）。
で、通信用（データ交換用）の「（いわゆる）JIS (iso-2022-jp)」では、
１バイト文字も２バイト文字も単純に７ビットでデータを送付します。
ミソは、文字コード（全角文字／ASCII/半角カナ等の区別等を意味し、
正確には「文字集合」と呼びます）が変わる区切り目にエスケープシーケンス
（文字として扱われない制御記号）を利用して文字集合の区別コードをその
都度挟み込みます。
この方法の利点はいくつもあり、インターネットではこれを標準にするのが
良いとされています（電子メールでは明らかにこれ「のみ」が推奨です）。
「エスケープシーケンスを使う」という仕様は、テキストのデータ送受では
ほぼ絶対的な特徴となっているため、これで送受されたデータは
文字コード判別を間違える可能性が殆どありません。
また、転送中のデータが一部欠損・破損しても、次のエスケープシーケンス
以降では正常に戻るため、いわゆる「文字化け」が最低限ですみます。
更にこの方法なら、多国語混在の問題も全く簡単に解決可能です。

３．「SHIFT-JIS (MS-漢字)」
しかし、「（いわゆる）JIS (iso-2022-jp)」ではエスケープシーケンス等を
利用する関係上、同一文字数でもデータ量が一定でなく、１バイト単位での
データ処理にもなりません。コンピューター側からすれば非能率なのです。
そこでＭＳがとったのは、「８ビット目が使われている場合は半角カタカナか
２バイト文字の１バイト目である（２バイト目はそうとは限らない）」という方法です。

２バイト文字の定義は、正確には

　１バイト目　01 ≦ 区番号 ≦ 62 の時、( 区番号 − 1 ) ÷ 2 ＋ 129
　　　　　　　63 ≦ 区番号 ≦ 94 の時、( 区番号 − 1 ) ÷ 2 ＋ 193

　２バイト目（区番号が奇数の場合）
　　　　　　　01 ≦ 点番号 ≦ 62 の時、 点番号 ＋ 63
　　　　　　　63 ≦ 点番号 ≦ 94 の時、 点番号 ＋ 64

　２バイト目（区番号が偶数の場合）
　　　　　　　01 ≦ 点番号 ≦ 94 の時、 点番号 ＋ 158

４．「日本語EUC (EUC-jp)」
EUC とは Extended UNIX Code の略で、日本語に関する拡張文字コードが
「日本語EUC (EUC-jp)」です（日本語以外に 韓国語・中国語(簡体字)・
中国語(繁体字)の３種類の EUC がある）。
この文字コードでは、 ASCII 文字以外は全て８ビット目がオンになっています
（１バイト目も２バイト目も）。
半角カタカナは、１バイト目に半角カタカナを意味する判別コードを入れる
決まりになっているため、２バイト文字として扱われます。
JIS X 0212 の補助漢字も利用できるのが特徴です（半角カタカナ同様の
手法で３バイト１文字になる）。
「SHIFT-JIS (MS-漢字)」に比べれば明らかに整合性が上がっています。

５．「ユニコード (UTF-8)」
ユニコードは、全世界の文字を統一的に１つの統一文字コードで表わそう
という規格です。
紆余曲折があって、現在でも規格が固定化されていません。
「同じ文字形であれば言語を区別することなく単一の文字コードにしているため、
異言語の文字列を等価と看做す」ということが、最大の問題点でしょうか。
漢字利用民族に取っては、「文字コードの数の制限故に EUC
の存在する各国語間で字形の似た漢字を、同一文字コード（同一文字）の
異体字として強制されてしまった」という点も大きな問題なのですが。
記号その他の問題もあって、どんどん拡張中。
このコードは JIS コード等は全く斟酌されずに新ルールで文字コードを
割り当てているので、 対照表なしには各種文字コードとの間でコンバートできない。
漢字の文字数が２万程度だったかな、現行の JIS に比べれば圧倒的に多いけど
（日本語には存在しない漢字も多いが）、TRON の「超漢字」の１０万字に
比べれば圧倒的に少ない。その差はどうなっているのやら。
Win 95 以降、ＭＳが徐々にこの文字コードを利用し始めているので、
期待は大きいみたいだが……


6525 Re:文字コード（余談） Ogo 2000/06/20-01:35
記事番号6524へのコメント
そう言えば、最近、インターネットからの直接利用を意識し始めたのでしょう、
ニフティの会議室の冒頭、

「特定の機種やＯＳに依存する文字の使用はしないで下さい。
　ローマ数字や、円の中にある数字などがそうです。」

と表示されるようになりましたね。

これまでは シフト JIS を標準文字コードとして、しかも MS-DOSユーザー以外の参加なんか
殆ど考えられなかった 桐 専用の会議室だから、
こんなことはナンセンスな教条主義に感じるのに……

半角カタカナもマズイのかなぁ。過去ログはどうするんだろう。
泥縄的雰囲気がただようなぁ……

6526 Re:文字コード hidetake 2000/06/20-06:08
記事番号6522へのコメント
＞松茸も桐も内部文字コードは（多分）SHIFT-JIS でしょう。

松茸も桐も、基本的に内部は JIS コードでデータを持っています。
ただし、完全な JIS では無く、内部処理の単純化・高速化のために
半角文字に対しても２バイト文字符号を用いています。(41 → 0041)

従って、全角／半角にかかわりなく１項目の文字数が同一になっており、
このため英数字ばかりのデータの場合、半角文字に対して
１バイト符号を用いているシステムに比べ、記憶効率は悪くなっています。

しかし、そのかわりに JIS を用いる場合の漢字イン・漢字アウトの
エスケープシーケンスを用いずにデータを保持でき内部処理を単純化できるのですね。

しかし、ますます Unicode 対応ソフトが増えるなか、
JIS コードでデータを保持している桐ではその対応のためには、
そうとう大きな改造が必要になってくるのでしょうか...

あと、規格については日本国内の規格が JIS であり、Shift JIS は
文字の集合を含む規格ではなく、単なる文字を表現するための符号を
どう取り扱うかの MS を始めとしたメーカー規則であったのですが、
97JIS において、ようやく JIS の規格として正式に認知されたようです。

あと、JIS 規格とともに、国際規格としての ISO 規格や、
US 及びメーカー主動の世界制覇的発想の Unicode と規格が入り交じり、
本当に難しい世界ですね。

最近の動向について詳しくは
http://www.watch.impress.co.jp/internet/www/column/ogata/
でもどうぞ...


6530 Re:文字コード 沢田和明 2000/06/20-13:26
記事番号6522へのコメント
Ogoさん、こんにちわ　質問させていただいた沢田です。

>上記は全くの誤解です。
やっぱり．．．恥ずかしいです（汗）

>ちなみにアプリケーション内部でどのような形でデータを保持していようとも
>データ交換には関係ありませんので、ユーザーがその違いを意識する必要はあ
>りません。
心強いお言葉。安心しました。

>アレはあくまでも「読み仮名不明の文字
>をコード入力する際に、自分に取って都合の良い文字コード」を指定している
>だけです。
そうだったのですか！
知らないということは不幸なことですね。
私今までは、ここの選択にすっごく悩んだ末に、気合い入れて設定していました。
笑っちゃいますね。

>これは、ＰＣ−９８の桐ファイルの記号「Ｎｏ．」が外字であることが原因です。
>外字に関しては互換性がとれなくて当然。

たいへん、よくわかりました。
外字だけに気をつけていれば、その他は心配ないようですね。
胸をつかえがとれた気がします。
本当にありがとうございました。

6531 Re:文字コード（余談） 沢田和明 2000/06/20-14:00
記事番号6525へのコメント
Ogoさん、こんにちわ　沢田です。

たいへん丁寧で、詳細なレスありがとうございました。
パソコンの歴史にまで踏み込んでいただいた解説は、たいへん勉強になりました。
貴重な時間を割いていただき恐縮です。

こういった複雑な話も、ユーザーが知っているのと知らないのとでは、
桐に限らず、パソコンの使いこなしに相当の差が出てくるような気がします。

私にはちょっと難しいですが、これからも関心をもっていこうと思います。
なんてったって、データが命ですもんね。

本当にありがとうございました。
6532 Re:文字コード 沢田和明 2000/06/20-14:06
記事番号6526へのコメント
hidetakeさん、質問させていただいた沢田です。
コメントありがとうございます。

>従って、全角／半角にかかわりなく１項目の文字数が同一になって
>おり、このため英数字ばかりのデータの場合、半角文字に対して
>１バイト符号を用いているシステムに比べ、記憶効率は悪くなって
>います。
>
>しかし、そのかわりに JIS を用いる場合の漢字イン・漢字アウトの
>エスケープシーケンスを用いずにデータを保持でき内部処理を単純
>化できるのですね。
>

半角も全角も２バイトになったのは、桐Ver５からだったように記憶しています。
当時、半角にしてもデータ量が減らないのはディスクがもったいないな、
と思ったのですが、処理の高速化などのためだったのですね。

私が思いますに、桐は、データ保持の点ではやや冗長かもしれないけれども、
ユーザー側のわかりやすさや使い安さ、それに処理の速さなどを優先しているようで、
そこが「人に優しい」と言えるのかなと思います。

データ量を少なくしようと厳密に考えるデータベースソフトは、
ディスクやメモリに負荷がかからないということですから、
逆に「機械に優しい」ソフトでは？

データ保持については、佐田先生のホームページで「桐での表の正規化」の
話を読ませていただいて非常に感動したことを思い出しました。

やはり、桐はユーザー側にたったソフトなんだな、と改めて思います。

>最近の動向について詳しくは
>http://www.watch.impress.co.jp/internet/www/column/ogata/
>でもどうぞ...

私には難解ですが、この世界を理解できるようチャレンジしてみます。
ありがとうございました。

6533 Re:文字コード hidetake 2000/06/20-14:54
記事番号6532へのコメント
>半角も全角も２バイトになったのは、桐Ver５からだったように記憶してい
>ます。

これは開発当初からです。開発者の酒井さん自身が本を出し、その中に書かれております。
また、松茸や桐だけでなく、松も JIS です。


6537 Re:文字コード Ogo 2000/06/20-18:39
記事番号6526へのコメント
>＞松茸も桐も内部文字コードは（多分）SHIFT-JIS でしょう。
>
>松茸も桐も、基本的に内部は JIS コードでデータを持っています。

はっはっはっは…… (^^;;;;;;

6539 桐と文字コード 佐田　守弘 2000/06/20-19:13
記事番号6520へのコメント
既にOgoさんとhidetakeさんが詳細な解説をされておりますが、私からもコメントさせて頂きます。

●JISコードと区点コード
私はこれは全く同じものと理解しております。JIS(日本工業規格)には漢字のコード表が定められたおり、
末尾にその一覧表が載っております。
この表の読み方は基本的には区点（確か横方向に区、縦方向に点。逆かもしれない）で
二次元座標の様に漢字を指定します。つまり、区がx座標、点がy座標といった形で、区と点の値で文字を指定します。
この区点コードでは区と点の値が10進数ではなかったでしょうか。
そして、同時にJISコードと言われる16進数で表したものがJISコードです。
ただし、区点の値をそのまま16進にしたものであったかは、今は憶えておりません。

●シフトインとシフトアウトコード
従来のASCIIコードの中に漢字コードを入れようとすると、その１バイト目を見ただけで、
漢字コードの先頭バイトなのか、あすきーこーど１バイトなのかの区別が付きません。
なぜなら、その１バイトがどちらでも使われるコードだからです。
そこで、「ここから漢字コードが始まる」「ここで漢字コードはお終い」という意味の
シフトインコード、シフトアウトコードで、その前後を挟みます。
ちなみに、エスケープシーケンスとはＥＳＣコードから始まる一連の文字列に特定の
機能を持たせたものです。

●JISコードの欠点
通常のJISコードで外部出力する方式も、かつてはありました。MS-DOSが一般的になる前の
日本語N-88BASICは、ディスクに出力するコードはJISコードでした。
しかしJISコードには１つ欠点があります。それは、シフトイン、シフトアウトコードが
途中に入るため、文字数の計算や部分列の取り出し、文字列の連結が煩雑になることです。

●シフトJISコード
シフトイン/アウトコードなしに漢字コードを扱う方式として、考え出されたのがシフトJISコードです。
ASCIIコードは元来７ビットコードだったのですが、８ビットコードも使われていました。
８ビット目が1のコード範囲には、確かグラフィック文字と称する記号が割り当て等得ていました。
これは、PC-8000時代のユーザは記憶があるでしょう。
そして、この余り利用価値がないグラフィックコードの範囲を漢字コードとして使う事により、
先頭１バイトだけでASCIIコードかJISコードの先頭バイトかを判断できる様にしました。
その変換式はOgoさんが書かれている通りですが、JISコードとシフトJISコードは、
１対１に対応する別のコードという事になります。
（別のコード体系と言うより、表現の違いと言うべきかも）

●桐の内部コード
通常、アプリが内部的にデータを保存する場合も、シフトJISが普通だと思います。
その理由は１バイト文字と２バイト文字を併用する、文字列処理を行う、の２点にあると思います。
しかし、桐は内部コードにJISコードを使っています。確か松もJISコードだったと思います。
その代わり、これらのソフトでは１バイトコードを扱いません。例えば数字や半角カタカナなど、
１バイトで表せる文字であってもJISコードによる２バイトで表します。
この方式は、１バイトで表すものを２バイト使うので非効率的に見えますが、
全てを２バイトで表すので、文字数の計算や部分列の取り出し、その他の文字列処理
（索引もその１つ）がきわめて簡単になる点にあります。

佐田守弘(KS-00119)

6540 Re:文字コード Ogo 2000/06/20-19:18
記事番号6530へのコメント
>>これは、ＰＣ−９８の桐ファイルの記号「Ｎｏ．」が外字であることが原因です。
>>外字に関しては互換性がとれなくて当然。
>
>たいへん、よくわかりました。
>外字だけに気をつけていれば、その他は心配ないようですね。

それがまた、そうとは断言できないのが難しいところで…… (^^;;;

http://apex.wind.co.jp/tetsuro/izonmoji/

http://news.open-news.com/~jiro/izon.html

を参考に、場合によっては「他環境では認識できない文字」は存在するのです。


更に Win 95/98/2000 でユニコードの文字を曲がりなりにも使えるようになったので
余計話が難しくなりつつあります。
この掲示板で以前にも出ていた「今昔文字鏡（こんじゃくもじきょう）」

http://www.mojikyo.gr.jp/html/index.html

なんて素晴らしい成果も、利用するにはユニコード限定なので、
互換性の取りようがない（ Win 桐なんて、そもそも利用不可能）。
人名・地名などで使われている希少文字を収蔵する点で、これほど素晴らしい
成果は他に存在しないんだけれど（ Tron-OS「超漢字」はこれを取り込んでなければ
殆ど存在できなかったでしょう）。

6543 Re:桐と文字コード Ogo 2000/06/20-20:00
記事番号6539へのコメント
多分に「重箱の隅」ですが、

>●シフトインとシフトアウトコード
>従来のASCIIコードの中に漢字コードを入れようとすると、その１バイト目を見ただけ
>で、漢字コードの先頭バイトなのか、あすきーこーど１バイトなのかの区別が付きませ
>ん。なぜなら、その１バイトがどちらでも使われるコードだからです。
>そこで、「ここから漢字コードが始まる」「ここで漢字コードはお終い」という意味の
>シフトインコード、シフトアウトコードで、その前後を挟みます。

以前はそのような説明がされていましたが、現在ではこの概念は明らかに「間違い」とされています。
エスケープシーケンスを使った文字集合の切り換えは、あくまでも「ここから先がどの文字集合であるか」を
示しているだけなのです。
iso-2022 は漢字のみを対象としているのではなく、また、新 JIS, 旧 JIS の文字集合や
中国語・韓国語・JIS X0212-1990 の補助漢字さえも切り換え対象として規格化されているのですから、
「漢字イン」「漢字アウト」という概念ではとても追い付きません。


>JISコードとシフトJISコードは、１対１に対応する別のコードという事になります。

ＭＳの勝手な実装により、シフトJIS に存在して JISコード に存在しない文字が
あることはご承知の通り（ちなみに i-mode もシフトJIS を使っていますが、
独自の絵記号を多数勝手に実装しており、顰蹙の対象です）。
EUC, シフトJIS 相互でも、変換不能な（相手先文字コードには存在しない）文字が存在します。
ホームページを作成する時に、この「特定の文字コードにしか存在しない文字」をページの
先頭近くにコメントとして埋め込むことで、文字コードの自動認識を失敗する確率が減るという
「不思議なおまじない」が一部の人々の間で知られています。

6546 Re:桐と文字コード hidetake 2000/06/20-21:21
記事番号6543へのコメント
う〜む、細かく書けばきりが無くなるようでし...

ISO と JIS は最終的には違うわけだし、文字集合の問題と
文字符号化の問題を混乱させてもいけないでしょうし...

あと、質問ですが、これらの規格をまとめて明確に現した本って今は何があるのでしょうか？

私が持っているものは、1991年ものの JISハンドブックで
もうそろそろ新しい物を手に入れた方が良いと思いますが、
JIS も ISO も Unicode も含めて、取りあえず日本語の
部分だけで良いので、字形まで含めた規格表が欲しいと
思っております。

しかし、1991年当時で 4,700円もしたけど、最近は複雑に
なっただろうから値段も相当高くなっているのかな？
なお手持ちのものは符号・記号だけでなく、用語やデータ
コードも含めた「用語・コード編」です。

何か良いものがあったら紹介してください。　_o_

なお、show さんお薦めの加藤氏の本は買おうと思って
おりますけど...


6547 Re:桐と文字コード hidetake 2000/06/20-21:42
記事番号6539へのコメント
>　通常のJISコードで外部出力する方式も、かつてはありました。

JIS コード(というか細く言えば iso-2022-jp )はインターネットの世界では現役です。

K3 のページも SV のページも show さんや k16 さんのページも、
その他規格を大切にされる方は皆さん JIS で記述されています。
メーカでもプラットフォームに依存しない NEC や Fujitsu もちゃんと JIS です。
（でも IBM は... やっぱ外来者か...）


6550 Re:文字コード（余談） hidetake 2000/06/20-23:59
記事番号6524へのコメント
＞５．「ユニコード (UTF-8)」

やっぱ、Unicode ＝ UTF-8 と言うのは違和感があるなぁ〜
インターネットの世界では UTF-8 が使われるのかも知れませんが、
エディタとかで Unicode を指定して書くと UCS-2が使われると思います。

HTML編集ソフトで UTF-8 を指定して書くと、まさしく漢字は 24bit で記述されるし、
テキストエディタで Unicode を指定して書くと UCS-2 として 16bit で書かれます...

それに、Windows で Unicode としてコードを表示させると、
今のところ 16bit でコードも表示されます。


6551 Re:桐と文字コード hidetake 2000/06/21-06:53
記事番号6543へのコメント
>ページの先頭近くにコメントとして埋め込むことで、文字コードの自動認
>識を失敗する確率が減るという「不思議なおまじない」が一部の人々の間
>で知られています。

iモードの半角カナ問題はわかるのですが、折角の機会ですから後学のために教えてください。 _o_

通常文字コードは、WWWサーバ側で MIME ヘッダの中で charset パラメタを用いて指定する方法が
取られると思います。
また、この手法は取れない場合は仕方なく、HTML 文書の中で META タグを用いて
情報を指定する方法もありますが、これら方法が効かないと言うことですか？

あるいは、iモードではこれらの指定を行ってはいけないとか、
転送量が増えるのを嫌い通常は使わないと言うことですか？


6552 Re:桐と文字コード Ogo 2000/06/21-07:17
記事番号6551へのコメント

>通常文字コードは、WWWサーバ側で MIME ヘッダの中で charset パラメタ
>を用いて指定する方法が取られると思います。

それが正しいのです。
ただし、ブラウザの種類によって（特に古いブラウザでは）この実装が
あやしいものがいくつもあるのです。

ネスケでも、2.0 の頃は charset=iso-2022-jp はともかく、
Shift_JIS や EUC-JP と書くとブラウザは混乱します。
当時は charset=x-sjis や x-euc-jpが使われていたからです。

ただし、こんな古い記述をすると、Lynx 等のブラウザは却って文字化け
するという困ったことなのです。

ＭＳインターネットエクスプローラー 3.0 に至っては、charset の記述を
見つけると却って文字化けする場合があるそうですし
（ページの先頭から1024 bytes目に日本語（2バイト文字）がかかっているか否かも問題
だったりするらしいです）。

>一バイトがコード0xE?、第二バイトがコード0xFDないし0xFEの文字は必ず
>EUCである。例えば「顰蹊迸缸糺磊」などがそれに当たる。

<!--糺の神-->
<!--これは文字コードの判別を助けるまじないです-->

EUC でページを書く時は上記のような記述をヘッダ部分に入れるそうです。

>次に、第一バイトがコード0x82、第二バイトがコード0x9Eから0xF1までの
>文字はSJISである。これは全角平仮名に当たる。

<!--すじとふし-->
<!--これは文字コードの判別を助けるまじないです-->

SHIFT-JIS で書く時の例が上記です。

>あるいは、iモードではこれらの指定を行ってはいけないとか、転送量が
>増えるのを嫌い通常は使わないと言うことですか？

これは iモードでの話ではないのです。
一般の WEBページの話なのです。

6553 Re:桐と文字コード Ogo 2000/06/21-08:07
記事番号6546へのコメント

>ISO と JIS は最終的には違うわけだし、文字集合の問題と
>文字符号化の問題を混乱させてもいけないでしょうし...

hidetake さんはもちろん知っているでしょうが、「JIS」という規格は
単一の物ではなく、JIS X ****-???? という名称が正式で、
「X」は「情報分野の規格」を意味し、**** が
規格の種類を、???? が最終改定年度を示します。

通常、文字集合の規格と言えば JIS X 0208-???? が「JIS
第１水準」「JIS第２水準」というものの定義です。
最新は JIS X 0208-1997 かな。 -1978 が続に言う「旧JIS」で、
-1983 以降は改定内容は非常に少ない。

その他に、１バイト文字の規格（ ASCII を基に、日本独自の
「\」などや半角カタカナを入れた文字集合）としては
JIS X 0201-???? が使われます（???? の最新は -1997か）。

また、JIS第２水準までの文字では少なすぎて困るということで
追加で補足された漢字群（通称「JIS補助漢字」）は
JIS X 0212-???? です（最新は -1990 か）。

で、現在「JIS第３水準」「JIS第４水準」が規格化の最中で
JIS X 0213-???? として公開されます（しかしこの規格には
様々な問題点があり、補助漢字同様、実装でポシャル可能性もあり得ます）。

で、ここからが本題になるのですが、通信（データ交換）の
世界で「（いわゆる）JIS」とか「（７ビット）JIS」と呼ば
れるものは文字集合の概念ではありません。
これはデータ符号化のための規格で、国際規格で iso-2022
と呼ばれるものの日本語ローカライズ版が iso-2022-jp で、
日本の JIS 規格としては JIS X 0202-???? という名称です。

ブラウザやホームページなどで「JIS」「シフトJIS」「EUC」
と並べられる場合の「JIS」とは常に「iso-2022-jp」です。
これは前の発言で述べたとおり、文字集合の切り換えを行なう場合に、
その境目にエスケープシーケンスを挟み込みます。
例えば以下のようになっています。

米国 １バイト ASCII コード　　　　の始まりには ESC ( B
JIS X 0201（日本語版１バイト文字）の始まりには ESC ( J
JIS X 0208-1978 (旧JIS)　　　　　 の始まりには ESC $ @
JIS X 0208-1983 (新JIS)　　　　　 の始まりには ESC $ B

とても、シフトイン・シフトアウト（漢字イン・漢字アウト）
のような単純なものではありません。

なお、桐・松茸などで「JIS」という場合は、この JIS X 2022
ではありませんね。
そもそも、これらで「JIS」を使う場合は、JIS X 0208 以外を
考慮しておらず、 -???? の 新旧JIS の区別さえもありません。
単に、JIS X 0208 を上位バイトと下位バイトに分けて１６進数で
表示しているだけのものを「JIS」と呼んでいます。

>あと、質問ですが、これらの規格をまとめて明確に現した
>本って今は何があるのでしょうか？

>何か良いものがあったら紹介してください。　_o_

Linux 等で、この辺りがシビアになっている（ WWW サーバーの
実装・運用なども多い）ので、その関係が増えているみたいです。
日本のユーザーは、独自に「日本語化」を推進している人が多いので、
参考文献が必要な度合いも大きいのでしょう。

私自身は SOFTBANK の「Linux/FreeBSD 日本語環境の構築と活用」
ISBN4-7973-0480-4(\2600E)の参考資料部分をよく読んでいます。

http://web.kyoto-inet.or.jp/people/tomoko-y/japanese/index.html

で概要を見ることができます。

また、TRON 文字コードやユニコードも含めて

http://www.horagai.com/www/moji/moji000.htm

も読んでいます。

6554 Re:桐と文字コード hidetake 2000/06/21-08:16
記事番号6552へのコメント
へぇ〜、そんな事もあるのですか知りませんでした。

こう言うこともあるから、やっぱり html は JIS に限るですか...　(^_^)


>ＭＳインターネットエクスプローラー 3.0 に至っては、charset の記述
>を見つけると却って文字化けする場合があるそうですし（ページの先頭
>から1024 bytes目に日本語（2バイト文字）がかかっているか否かも問題
>だったりするらしいです）。

ところで、ここで言う charset はどちらの charset ですか？
MIME? META?


6555 Re:桐と文字コード hidetake 2000/06/21-08:50
記事番号6553へのコメント
どうもありがとうございます。 _o_

こう言うものを理解するためにも JISハンドブックは必携ですよね！

エスケープシーケンスに至っては、理解しようとする気も起こらないぐらい面倒だし複雑だし...
それに、これについては ISO の xxxx を参照しろ(従う)だとか、
単純に１対１の関係でも無いため、理解するのに難儀します。　(;_;)

あと、ほら貝他、インターネットで参照できるものは見たりしますが、
やはりコード一覧とか１面で確認できる紙の資料がないと
やっぱり頭の中では理解できにくいですよね...

書籍については、こんど書店で探してみます。



それから、日本規格協会が出している、今の JISハンドブックの
「情報処理」編はどんなものですか？　またいくらになっているのでしょう？
もしお使いの方がおられたら教えて下さい。


6557 Re:桐と文字コード Ogo 2000/06/21-17:30
記事番号6554へのコメント
>ところで、ここで言う charset はどちらの charset ですか？
>MIME? META?

<META HTTP-EQUIV="Content-Type" CONTENT="text/html;charset=Shift_JIS">

の部分です。

>こう言うこともあるから、やっぱり html は JIS に限る
>ですか...　(^_^)

それが、iso-2022-jp でも文字化けするんですよ。 (^^;

１．他人のページからのリンクの場合。
　　ページ毎に上記 Content-Type のヘッダがない場合、リンク元の
　　ページが euc か Shift-JIS だったら化けることがあります。

２．コンバートミス。
　　iso-2022-jp がデフォルトの OS は存在しないので、どのみち、
　　OS デフォルトで入力して、保存時に文字コードを変換するか、
　　保存したファイルを nkf 等でコンバートするのが普通です。
　　ところが、これを忘れたり、設定ミス（パラメーター入力ミス）
　　で正しく JIS コードになっていないのに、中身を確認をせずに
　　そのままアップロードしているケースがままあります。
　　（ http://www.kojima-cci.or.jp/~fuji/horrible/kanji.html )

　　つまり、META HTTP-EQUIV="Content-Type" の内容と実体の文字
　　コードが異なる場合です。
　　ブラウザは強制的に META HTTP-EQUIV="Content-Type" を優先し、
　　人間がブラウザのメニューで強制的に文字コードを変更指定しよ
　　うとしても全く受け付けません（もちろん、iso-2022-jp と関係
　　なく、 EUC と シフトJIS 間でも起き得るのですが）。

　　このような場合、私は、一旦当該ページをローカルに保存して、
　　テキストエディターで開いていますが……

で、変に iso-2022-jp にコンバートするよう心掛けるよりも、却って
「文字コードは OS デフォルトのままで、META HTTP-EQUIV="Content-Type"
を全ページに間違いなく記述する」方が、ケアレスミスを防ぐための
フェールセーフ（フールプルーフ）になるという記事も見掛けました。

6558 Re:桐と文字コード Ogo 2000/06/21-17:47
記事番号6557へのコメント

>１．他人のページからのリンクの場合。
>　　ページ毎に上記 Content-Type のヘッダがない場合、リンク元の
>　　ページが euc か Shift-JIS だったら化けることがあります。

検索エンジンなどは、UNIX で Perl を使っていることが多いのですが、
その都合で元のページ（CGI）は EUC で記述してあるケースが多いみたいなんですよ。

>　　ところが、これを忘れたり、設定ミス（パラメーター入力ミス）
>　　で正しく JIS コードになっていないのに、中身を確認をせずに
>　　そのままアップロードしているケースがままあります。
>　　（ http://www.kojima-cci.or.jp/~fuji/horrible/kanji.html )

以前は、このページに悪例がテンコ盛りで、大笑いできたんだけど、いつのまにか
下火になってたんですねぇ〜（同一ページの途中で文字コードが変化しているような
ＴＶＣＭで有名な某社のモノが最悪でしたけどね）。

まぁ、半プロ集団と言ってもよい linux.or.jp でもこんなミスを発見したことが
ありますし、ケアレスミスを防ぐのはなかなか難しいものです。

そう言えば、最近は「ホームページ作成は専用ソフトに任せている」人が多くて
（それだけ敷居が低くなったとも言えるが）、
META HTTP-EQUIV="Content-Type" というヘッダの事は何も知らない作者が多いようです
（大手ソフトベンダー製品で、このタグを自動的に入れるホームページ作成ソフトは見たことがない）。

6559 Re:桐と文字コード hidetake 2000/06/21-18:15
記事番号6558へのコメント
＞META HTTP-EQUIV="Content-Type"

MIME の設定と META の設定 charset の食い違いが生じたり、
あるいは proxy を通した関係で、META タグの charset と実際の
コードの食い違いが生じたりするので、本来は MEME の設定を優先させないといけないし、
RFC の本来の規定もそうなっているそうですので、
あまり META タグに頼るべきでは無いのでしょうけど、
プロバイダとの関係ではどうしようも無い事もありますしね...

あと、html の文字コードについては EUC や SJIS が悪いわけでもありませんが、
私の場合は k16 さんが JIS が正しいと書いていたので、
それを素直に守って JIS を基本と致しております。

perl については JIS も SJIS も特定の場面で不具合がでる
可能性があるので、perl で処理する部分は EUC で処理し、
また EUC でデータは保持し、html に出力する際 JIS に戻すのが
正統派のやり方と読んだ覚えがあります。

まぁ〜、私自身も CGI の部分で SJIS を使っている部分もありますが、
そのうちに修行を積んでまともな処理にしたいとは思ってはおりますけど、
さていつになるのか？　(^_^ゞ



>META HTTP-EQUIV="Content-Type" というヘッダの事は何も知らない作者
>が多いようです（大手ソフトベンダー製品で、このタグを自動的に入れる
>ホームページ作成ソフトは見たことがない）。

あれ？　FrontPage98 は自動で入れてくれるけどなあ？
しかし、Shift_JIS は x-sjis になりますけど...

でも、先に書いたように本来は　META タグで書くべきものでは無いのです。
RFC に従えば MIME 設定をすべきだし、
タグはコード変換の障害になるのでやめるべきものです。


6562 Re:桐と文字コード hidetake 2000/06/22-07:26
記事番号6559へのコメント
charset に関して、私が参考にしたオリジナルは
http://www.fxis.co.jp/DMS/sgml/html_correct_charset.html
です。他にも
http://www.yl.is.s.u-tokyo.ac.jp/~oiwa/tsg/buho/article/www_m17n.html
また、XML との関わりは
http://www.y-adagio.com/public/standards/tr_xml_jpf/kaisetsu.htm
にあります。

勉強されたい方はどうぞ...


6563 Re:桐と文字コード hidetake 2000/06/22-07:44
記事番号6562へのコメント
>charset に関して、私が参考にしたオリジナルは

他にこんなのもありました
http://www.asahi-net.or.jp/~jy3k-sm/i_net/charset.html


6595 Re:桐と文字コード Ogo 2000/06/24-00:41
記事番号6559へのコメント
例の Another HTML-lint の解説です。

<HEAD>〜</HEAD> 内の <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="〜"> について

- - - -

現在日本語で書かれているHTMLの多くには、文字コードとして JIS、Shift JIS、EUCが利用されています。
UTF-8 なども見られます。HTMLがどのコードで書かれているのかを明示するために、
このタグを書くようにしましょう。

<META http-equiv="Content-Type" content="text/html; charset=ISO-2022-JP">
<META http-equiv="Content-Type" content="text/html; charset=Shift_JIS">
<META http-equiv="Content-Type" content="text/html; charset=EUC-JP">
<META http-equiv="Content-Type" content="text/html; charset=UTF-8">

これらのどれか適切なものを書けばいいのです。こうしておくと、
よくできたWWWブラウザでは、文字コードのエンコーディング指定が欧米などになっていても、
正しく日本語が表示されます。
Mozillaなどでは、表示するフォントを指定されている文字コードごとに指定できるようになっています。
<META> で文字セットを指定していると、それに対応したフォントで表示してくれます。

また、<META> での文字セットの指定がない場合、文字コードのエンコーディング
指定を日本語(自動判別)にしてあると、Shift JIS と EUC の誤認識をすることも
まれにあるようです。

RFC1866によれば、本来は、この <META> の情報は、HTTPサーバが解釈して適切な
HTTPレスポンスヘッダを生成できるようにするためのものなのです。
つまり、WWWブラウザのためのものではありません。
レスポンスヘッダ中に正しい文字セット指定があれば、WWWブラウザは何の問題もなく
正しく表示できるはずなのです。
が、現在の多くのHTTPサーバはそんな面倒な処理はしないので、なかなかうまくいかないようです。

HTTP1.1 (RFC2068) では、HTTPレスポンスヘッダにCHARSETパラメタを含めることが義務付けられています。
こうなると、HTML中での <META> での文字セットの指定は無用の長物と化します。
<META> による指定と、ビットパタンによる文字セットの推測は、
正しくCHARSETパラメタをHTTPレスポンスヘッダに含めない日本のための過渡的な救済措置なのだそうです。
XMLでは、文書中の指定は無視され、CHARSETパラメタが必須です。
HTML5.0でもそのように改訂される可能性があるそうです。
詳しくは「charsetパラメタの勧め: HTMLにおける文字符号化スキームの明示方法」
( http://www.fxis.co.jp/DMS/sgml/html_correct_charset.html )を参照してください。

これらは、HTTP経由での送受信を前提とした話なので、ローカルなHTMLには適用できません。
ローカルなHTMLでは、CHARSETの指定は <META> で行なって構わないようです。

一部のサーバでは、ファイル名の拡張子による Content Negotiation を導入しています。
これは例えば、

hello.html.ja (日本語版のHTML)
hello.html.en (英語版のHTML)

とあった場合、WWWブラウザの言語の設定によって hello.html という要求に対して
どちらかを自動的に振り分けて送信するものです。
ASAHI-Netでは、さらにこの言語優先機能に加えて実験的にリソースの文字セットの
指定も行なえるようにしています。

HTTPサーバがリソース中の情報を参照してCHARSETを決定するのはたいへんなので、
このやり方はなかなか利に適っています。文字セットは次のように明示することができます。
いずれも hello.html という要求で済みます。

hello.html.ja.jis (ISO-2022-JPで書かれた日本語版のHTML)
hello.html.en.8859-1 (ISO-8859-1で書かれた英語版のHTML)

これによって、サーバはHTTPレスポンスヘッダに適切なCHARSETパラメタを含めるので、
HTML中の <META> による指定は不要です。興味のある人は、ASAHI-Netをうろついたり、
Content Negotiation を参考にしてください。

- - - 以上。

6600 Re:桐と文字コード hidetake 2000/06/24-07:01
記事番号6595へのコメント
そう言えば載ってましたね... (手元の資料にもありました)

k16 さんが意識されたのは 1998/08/30 からのことか...
http://www.asahi-net.or.jp/~rh5k-isn/diary/diary199808.html

あと CGI では、一番最初に PRINT すれば HTTPレスポンスヘッダ
として出力されるとありますが、プロバイダでサポートしていない場合も、
CGI を駆使すれば可能だと言うこと...


6610 Re:桐と文字コード hidetake 2000/06/24-23:13
記事番号6600へのコメント
>あと CGI では、一番最初に PRINT すれば HTTPレスポンスヘッダ
>として出力されるとありますが、プロバイダでサポートしていない
>場合も、CGI を駆使すれば可能だと言うこと...

私のテスト用の CGI で試してみましたが、当然との事とは言え、
ちゃんと最初の行の設定が HTTPレスポンスヘッダ として設定され、
META タグが無くとも文字コードが正しくセットされますね！

6625 Re:文字コード（余談） hidetake 2000/06/26-10:02
記事番号6550へのコメント
>Unicode

Word 2000 って、Unicode も普通のリトルエンディアンな UCS-2 だけで無く、
ビッグエンディアンな UCS-2 も、さらには UTF-8 や UTF-7 の入出力も
可能になっていたのですね！


6626 Re:文字コード（余談） hidetake 2000/06/26-12:10
記事番号6625へのコメント
>Word 2000

ついでに書けば、JIS も SO SI による半角カナも取り扱える JIS、
それにエスケープシーケンスを用いた半角カナを取りか使える JIS、
そして普通の JIS で半角カナは全角カナに変換されるタイプの JIS、
の計３種類のタイプが選ばれるようになっています。



PS.
ここで SO SI が出てきたついでに書くと、Ogo さんや佐田さんが
使われた、シフトイン(SI 0x15h)・シフトアウト(SO 0x14h) という言葉は、
通常７単位の文字集合を切り替える特殊機能キャラクタとして用いられるので、
漢字とは関係ありません。

すなわち、ローマ字文字用図形キャラクタ集合と片仮名用図形用
キャラクタ集合を切り替えるための制御文字(方法)をさすと思います。

と言うことで、エスケープシーケンスとは直接関係ないと言葉であり、
用法だと思います。


6627 Re:文字コード（余談） hidetake 2000/06/26-14:03
記事番号6626へのコメント
＞シフトイン(SI 0x15h)・シフトアウト(SO 0x14h)

恥ずかしい (^_^; 10進と16進を間違えてしまいました。　_o_

SI が 10進数で 15 、16進数で 0x0F で、
SO が 10進数で 14 、16進数で 0x0E です。


戻る