文字コードの符号化文字集合と文字符号化方式について

総合スコア28660

2019/08/12 12:45

全て理解しているわけではありませんが、、、 > 例えば UTF-8 の場合は、そのような工夫 UTF-8は英語圏の人たちが、アルファベット以外オマケだよ、って発想を感じます。英数字のみならば、今までとほぼ同じデータ量で通信ができる。あと、UTF-8の場合、 > 文字列の中の十番目の文字が文字列の何バイト目にあるのかはあり得ません。確か数バイトで同期可能。これが、UTF-8の一つの売り文句。 UTF-16で、 > 文字の種類が増えてそれでは符号化しきれなくなり、必ず二バイトとは限らなくなったので、これは、当初からの話。ただし、16bitで主な文字はカバーできるだろうってのが、当初の目論見。なお、 > 互換性が無くなるので、は、UTF-32だけでなく、UTF-16も同様。今だったら、ともかく、Unicode策定時は、32bitは無駄が多すぎると考えられた模様。 5Cの件は、厳密な論拠を提示できないですが、ちょっと違和感あり。日本だけみれば、そうですが、世界のコードを見るとちょっと違う感じ。そもそも 0x5Cでエスケープは、 C言語等のプログラム上の問題。ちょっと違う気がする。

2019/08/12 12:58

数バイトで同期可能というのがどういうことかよくわかりませんが、十番目の文字が何バイト目から何バイト目のデータに当たるかは最初から見ていかないとわからないのではありませんか？ Unicode は 1.0 の時点で 16 ビット固定長だったはずです。そのために CJK 問題があります。 https://ja.wikipedia.org/wiki/Unicode > 1980年代の当初の構想では、Unicodeは16ビット固定長で、216 = 65,536 個の符号位置に必要な全ての文字を収録する、というもくろみであった。しかし、Unicode 1.0公表後、拡張可能な空き領域2万字分を巡り、各国から文字追加要求が起こった。「互換性がなくなるので」は UTF-32 の特徴であり、それは UTF-16 の特徴でないことを意味しません。 5C の件はマルチバイトを扱う上でずっと問題になっていたことなので、考慮されていることは間違いないと思います。むしろ、考慮されていなければびっくりします。

2019/08/13 01:48

UTF-8の同期の件は、各バイトの先頭bitを見る事で判定できます。Wikipedia([https://ja.wikipedia.org/wiki/UTF-8])見ると表がありますが、先頭が 10xxxxxx ならば、途中のバイトである事が分かるので、読み捨てれば、良い事になります。 Unicodeの歴史を見る場合、ISO/IEC 10646 も無視できません。参照されている Wikipediaにも、ISO/IEC 10646 は 32bit版が策定(1990 Draft)とあります。その後、Unicodeとの整合とあります。私の理解としては、" Unicode: アメリカの民間企業中心に策定された Code系" なので、16bitメインにしようとしたかと思っています。なお、Unicode ≒ ISO10646 です。以前、調べた時にも混乱する事が多かったですが、要注意。なお、5Cの件は、色々な意見はあるでしょうが、今回の符号化とは関係ないと思います。あるとすれば、0x5Cに割り当てられている円記号は、Unicode表ではどこに対応させるかだけです。(これはこれで、面倒) また、Shift-JIS固有の問題で日本語環境の MS-DOS/Windows限定です。 (Shift-JISは、当初、正式のJIS規格では無かったし)

2019/08/13 01:57

読み捨てるという話とはまた別ですよ。最初から(途中を飛ばしても)読んでいかないと何文字目かはわからないので、char のように配列として使うことができません。配列より結合リストに近いものになります。十文字目のデータはこのアドレスにあるというのが、パースしなければわかりません。また、私の言っている 5C の問題は円記号と関わるグリフの問題ではなく、5C に代表される特殊記号を 2 バイト目に使わない工夫のことです。

2019/08/13 02:03

UTF-8の文字数が何文字か先頭から、読まないと分からない件は同意。バイト列として、処理した場合の破損の件と思っていました。 > 5C に代表される特殊記号をこれは、Shft-JIS固有の問題なので、Unicode策定時に本当に考えられたのか? という事です。(日本人が本気で関与した?)

2019/08/13 02:13

シフト JIS で発生している問題と同じ問題を国際的な符号化で発生させるわけにはいかないので、日本人が関わる関わらないは無関係に、当然考慮していると思います。

2019/08/13 02:14

既存の符号化の研究をせず新しい符号化を作ろうとするということは、まずありません。

2019/08/13 02:15

再度確認のため言いますが、この話は円記号の問題とは無関係です。

2019/08/13 02:36

私の認識では、Unicode策定当初、漢字など、アジア圏のコードはオマケ扱いと聞いています。(多分、ここから、違うでしょう) それ以上についは、話が本来の文字集合/符号化と外れている気がしますので、止めます。

2019/08/13 14:19

長文の回答ありがとうございます。とても勉強になりました。

行動規範の内容に同意します

参照サイト
https://blog.shibayu36.org/entry/2015/09/14/102100
見てみました。
割とよく書かれているのではないかと思います。
(ネタ本、あまり好きじゃ無かったりするのですが)

文字集合で定めたコードポイントを、そのまま扱って(符号化方式でエンコードしない)文字を表示する方が分かりやすく効率が良いと思いました。

簡単には、文字集合で定めたコードポイントそのままでは、使えない場合があるという事です。符号化と言っても今、多くの人は、PC内部のコードと思う人も多いでしょうが、当初は通信を行うための符号化ですね。
通信経路によって、全てのコードが使えるとは限らないので、符号化となります。今の多くは 8bit = 1byteとして通信していますが、7bit=1byteも有ったりします。(そのため、通信系では、8bit = 1octet とする事も) その一方、今のPCの内部処理は、64bitだったり、、と。

それで、通信経路とかに依存しないコードポイント(文字集合)を決め、実際の使用は、符号化して使うという事になります。そして、符号化は、通信経路に最適にすべき、、でしょうが、過去との互換性などが絡み、、となります。

こんな感じでしょうか。

投稿2019/08/13 02:28

総合スコア6383

2019/08/13 14:23

回答ありがとうございます。 >簡単には、文字集合で定めたコードポイントそのままでは、使えない場合があるという事です。なるほどですね。勉強になりました

行動規範の内容に同意します

ベストアンサー

文字集合で定めたコードポイントを、そのまま扱って(符号化方式でエンコードしない)文字を表示する方が

分かりやすく効率が良いと思いました。

それがされていないのは、1つには不可能だからです(後述)。別の解として、Unicodeを使い、UTF-32というのが1つの解ですが、何をするにも4バイト必要で、効率が悪いので今のところほとんど使われていません。

Unicodeでない符号化文字集合は、他の符号化文字集合と符号の重複があります。
例えば、JIS-X0208（いわゆる全角のJIS第一水準と第二水準）のあは、16進で24 22ですが、これはJIS-X0201（半角英数仮名）での$"という2文字と全く同じです。つまり、24 22というデータがあった場合に、JIS-X0208のあなのか、JIS-X0201の$"なのかはこの2バイトだけを見ても決められないと言うことです。
JIS規格内だけでこれなので、他国の符号化文字集合とも当然重複があります。これをなんとかするのが、ISO-2022というISO規格で、世界各国の複数の符号化文字集合を切り替えながら使う方式を定めています。

これにしたがって、JIS-X0208とJIS-X0201を1ないし2バイトで表現する方式がEUC-JPです。また、JIS-X0208とJIS-X0201（仮名以外）とUS-ASCIIの3種類をエスケープシーケンスで切り替えながら表現する方式がISO-2022-JPです。
（シフトJISはISO-2022を無視して作られた方式です）

「こういう切り替えとか面倒くさいよね、2バイトの符号化文字集合を新規で作って上手に割り当てれば全世界の文字を表せるのでは？で、そのまま（あなたのいうように）符号化文字集合をコードとして使おう」という考えで出来たのがUnicodeの元です。途中で「2バイトではやっぱり足りない」と分かって4バイトになっています。（最初から4バイトなら日中韓の漢字統合は不要だったんじゃ無いかと思いますが）

そうは言っても、US-ASCIIと互換性がないと普及しにくいということで作られたのがUnicodeのUTF-8表現です。これが出来たので、多分UTF-32は普及しないと思います。

投稿2019/08/12 09:32

総合スコア84555

2019/08/12 12:45

ほとんど余談に近いですが、 > 最初から4バイトなら日中韓の漢字統合は不要当初、日本は(一部の方を除き)、積極的に関与して無かった。しかし中国は違って、積極的に関与し、漢字フォント等多くを提供したと聞きます。非公式な話としては、大中華思想の元、漢字圏は、全て中国文化なので、中国が管理するものだとか(推測、誇張を含む)。実際に、Unicodeの漢字デザイン(例示フォント)の多くが中国漢字なのはそのため。(こちらは事実)

2019/08/12 13:08

https://moji-memo.hatenablog.jp/entry/20130808/1375949975 Unicode に先んじて今昔文字鏡という有名なフォント・コード体系がありましたが、日本はそれを Unicode に持っていっています。積極的に関与していなかったというのはどういう意味でしょう？日本の漢字だけではなく、五体字類から甲骨文字・ヒエログリフ・楔形文字に至るまでありとあらゆる文字が入っていました。

2019/08/13 01:22

リンク先を見ると、2001年からの歴史ですね。私が言いたいのは、それ以前の話。10年以上前でしたが、Unicodeを調べた事があり、一部の研究者等は結構、頑張ったが、日本政府(JIS関係者とか)は、Unicodeに懐疑的で、積極的に関与しなかったと記述を結構見ました。今では、(日本由来の)絵文字等も入っていますが、CJK統合漢字が入った頃の話です。また、"今昔文字鏡"は、Wiki([https://ja.wikipedia.org/wiki/%E4%BB%8A%E6%98%94%E6%96%87%E5%AD%97%E9%8F%A1])で見る限り、一民間企業が、1990年代後半に開発したもので、それに対し、中国は、GBK(GB18030に先行する規格 - 未制定)で、1990年代前半に Unicodeを意識しています。

2019/08/13 01:51

日本政府というのは内閣のことですか？もう一つよくわかりません。私の聞いていた話では、日本も頑張ったが押し切られたということでしたが、私のソースもあやふやですね。 TRON コードを推し進めようとしていたために UTF-16(ユニコードではなく)を積極的に導入しようとしなかったという話とはまた別でしょうか？もしその話であれば、TRON コードはユニコードと対立するものではないし、アメリカに潰されたということだったと思います。

2019/08/13 02:11

私が聞いた(見た)のは日本(一部関係者 Unix系が多かった)も頑張ったが (JIS関係等の公的機関の後押しも無く)押し切られたということ、という事です。 TRONも関係あったかも知れませんが、こちらは不明。ただ、当時のJISに関与する人たちは、Unicodeに懐疑的だったと言われています。(そんなもの、出来ないだろう、と) で、Unix系の多くは、Shift-JISで無かったりするので、5C関係あるのと? となります。

2019/08/13 02:22

JIS は国内のことなので無関係ですし、政府の代表でもありませんし、元々後押しできるような立場にはないと思います。あくまでもユニコードの策定に関わったスタッフが関係者ですが、これが積極的に関わっていないというのは少し信じがたく思います。 5C の話は向こうでお願いします。この件については、かなり主旨を誤解されています。グリフの話は私はしていません。Unix も無関係ですね。

2019/08/13 02:41

一点だけ、 > JIS は国内のことなので無関係です ISO-10646も考慮してください。また、国際規格の場合、国の関与は大きく、実際に中国は積極的に関与したと聞く。勝手で申し訳ありません、他の方のコメント欄ではこの辺で止めたいと思います。

2019/08/13 02:51

そのソースも回答に上げていただければと思います。

2019/08/13 02:57

Unicodeの動きも、ISO10646の原案が否決されてUnicodeとの統合案が出る前と後とでは大分風向きが違う気がします。「ユニコード戦記」も多分それ以降の話ですよね。当初は、「多バイト文字をよく知らない米国企業がなんかやってる。2バイト？日本の漢字だけで何万文字あると思ってるんだ？」という受け取り方をする人が多かったと思います。

2019/08/13 03:28

こんなの見つけました。 http://ie.u-ryukyu.ac.jp/~kono/fj/fj.kanji/618.html

2019/08/13 03:39

otn さん、ありがとうございます。貴重な資料ですね。面白いです。

2019/08/13 08:19

otnさん、懐かしいものを見つけましたね。ヘッダ(Path)がバケツリレー(正式名は?)を示していたりして。リアルタイムだったか、後付けかは忘れましたが、見た記憶有ります。リアルタイムだったとしても、当時は"関わるな"って雰囲気が強かった。

2019/08/13 08:29

「fj.kanji unicode」でググったのですが、これくらいしか見当たらずでした。 Google Groupにも1980年代の記事は無いし。

2019/08/13 10:26

ちょっと情報無いかと思ったら、懐かしい記事がありましたので。 (小形克宏の「文字の海、ビットの舟」第1部第2回)[https://internet.watch.impress.co.jp/www/column/ogata/part1_2.htm] 途中から、Unicodeの話になります。このシリーズ全編、当時、興味深く読ませてもらいました。質問の趣旨とはちょっと外れるかと思いますが、参考までに。

2019/08/13 14:20

回答ありがとうございます。為になる情報ありがとうございました

行動規範の内容に同意します

一言でいうと、「話が逆」ですかね…。

素朴に文字コードを1個作った場合、「文字集合で定めたコードポイントを、そのまま扱って(符号化方式でエンコードしない)文字を表示する」ようなものができます。
で、その場合、文字集合・符号化方式という概念は生まれません。必要ないので。

でも世の中は複雑なので、様々な文字コードが作られます。
ここで、

新たに全く別の(例えば日本語に対して韓国語とかの)文字コードを作りたくなったとき、既存の文字コードの仕組みを変えずに流用すると楽です。
既存の文字コードが何か都合が悪くて(例えばステートフルだと面倒とか、バイト数と文字幅が揃ってたほうがいいとか)新しいものを作るとき、収録する文字のレパートリーは変える必要がありません。

そうしていくつもの文字コードが作られるとき、変わらない部分と変わる部分があることに気づきます。
1で変わらない部分が「符号化方式」、2で変わらない部分が「文字集合」です。
この概念があることで、「符号化方式EUCで、文字集合の違いでEUC-JPとEUC-KRがある」とか「文字集合JISに対して符号化方式の違いでISO-2022-JP・EUC-JP・Shift_JISがある」とか言えるようになります。

投稿2019/08/12 14:00

ikadzuchi

総合スコア3047