Q&A
回答ありがとうございます。
>簡単には、文字集合で定めたコードポイントそのままでは、使えない場合があるという事です。
なるほどですね。勉強になりました
お世話になります。
文字コードについて調べている中で疑問に思ったことがあるので質問させていただきます。
文字コードには、符号化文字集合と文字符号化方式の構成要素がありますが、
なぜ文字集合で定めた値を直接使用せずに、さらに符号化方式で定めた値に変換して文字を表示するのでしょうか？
文字集合で定めたコードポイントを、そのまま扱って(符号化方式でエンコードしない)文字を表示する方が
分かりやすく効率が良いと思いました。
参照サイト：https://blog.shibayu36.org/entry/2015/09/14/102100
以上、よろしくお願いします。
回答6件
0
シフト JIS の表問題をご存じですか？
シフト JIS で「表」という文字は 95 5C という二バイトになります。ところが、5C 一つだけだと、バックスラッシュを表します。そこで、文字列を頭から読んでいってバックスラッシュでエスケープするような方法の場合、ここにバックスラッシュがあると誤認してしまいます。
たとえばソースコードに "表" と書いた場合、二番目のダブルクォーテーションマークが「表」の二バイト目の 5C によってエスケープされてしまって、引用符が閉じていないというエラーになります。
これを回避するためには、二バイト目の 5C がバックスラッシュではないと認識するために、コンパイラがシフト JIS に対応しなければいけません。シフト JIS は日本語専用の符号化方式なので、海外では無視されることも多く、海外のソフトを使うときには "表" のように文字によってエスケープを入れたり、あるいはそのソフトを使うのをあきらめたりしなければいけませんでした。
Unicode の符号化文字集合にも同じ問題が起こりえます。今まで特別な意味を持っていたコードが文字の一部として入り込んでくることにより、文字解析のアルゴリズムが煩雑になり、パフォーマンスが落ちたりバグの温床となったりします。
そこで符号化を工夫することにより、この問題を回避します。5C が問題なのであれば、5C をバックスラッシュ以外のところに出さなければいいのです。そうすれば、文字列を表すバイトコードを最初から順に見ていったとき、最初に出てきた 5C がバックスラッシュであることが保証されます。
例えば UTF-8 の場合は、そのような工夫をして、既存のテキストと互換性を保ちながらパフォーマンスを上げています。
ところが UTF-8 は、一文字のバイト数が不定です。例えばアルファベットは一バイトですが、「表」は三バイトになります。バイト数が不定ということは、文字列の中の十番目の文字が文字列の何バイト目にあるのかは、必ず最初から見ていかなければわからないということになります。
そこで Windows は UTF-16 を採用しました。この符号化方式であれば、一文字は必ず二バイトになっていたので、内部表現として扱いやすかったのです。現在では、文字の種類が増えてそれでは符号化しきれなくなり、必ず二バイトとは限らなくなったので、そのアドバンテージは無くなり、使う機会は減りつつあります。
他に四バイトなら全部入るだろうということで UTF-32 もありますが、アルファベットのみのテキストファイルが大きくなりすぎるのと、互換性が無くなるので、広く使われているとは言い難いところです。
このように、様々な考え方から、符号化が検討されています。
投稿2019/08/12 07:07
編集2019/08/12 07:21
総合スコア28673
0
参照サイト
https://blog.shibayu36.org/entry/2015/09/14/102100
見てみました。
割とよく書かれているのではないかと思います。
(ネタ本、あまり好きじゃ無かったりするのですが)
文字集合で定めたコードポイントを、そのまま扱って(符号化方式でエンコードしない)文字を表示する方が分かりやすく効率が良いと思いました。
簡単には、文字集合で定めたコードポイントそのままでは、使えない場合があるという事です。符号化と言っても今、多くの人は、PC内部のコードと思う人も多いでしょうが、当初は通信を行うための符号化ですね。
通信経路によって、全てのコードが使えるとは限らないので、符号化となります。今の多くは 8bit = 1byteとして通信していますが、7bit=1byteも有ったりします。(そのため、通信系では、8bit = 1octet とする事も) その一方、今のPCの内部処理は、64bitだったり、、と。
それで、通信経路とかに依存しない コードポイント(文字集合)を決め、実際の使用は、符号化して使うという事になります。そして、符号化は、通信経路に最適にすべき、、でしょうが、過去との互換性などが絡み、、となります。
こんな感じでしょうか。
投稿2019/08/13 02:28
総合スコア6385
0
ベストアンサー
文字集合で定めたコードポイントを、そのまま扱って(符号化方式でエンコードしない)文字を表示する方が
分かりやすく効率が良いと思いました。
それがされていないのは、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
総合スコア86260
ほとんど余談に近いですが、
> 最初から4バイトなら日中韓の漢字統合は不要
当初、日本は(一部の方を除き)、積極的に関与して無かった。しかし中国は違って、積極的に関与し、漢字フォント等多くを提供したと聞きます。
非公式な話としては、大中華思想の元、漢字圏は、全て中国文化なので、中国が管理するものだとか(推測、誇張を含む)。実際に、Unicodeの漢字デザイン(例示フォント)の多くが中国漢字なのはそのため。(こちらは事実)
https://moji-memo.hatenablog.jp/entry/20130808/1375949975
Unicode に先んじて今昔文字鏡という有名なフォント・コード体系がありましたが、日本はそれを Unicode に持っていっています。積極的に関与していなかったというのはどういう意味でしょう？
日本の漢字だけではなく、五体字類から甲骨文字・ヒエログリフ・楔形文字に至るまでありとあらゆる文字が入っていました。
リンク先を見ると、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を意識しています。
日本政府というのは内閣のことですか？
もう一つよくわかりません。
私の聞いていた話では、日本も頑張ったが押し切られたということでしたが、私のソースもあやふやですね。
TRON コードを推し進めようとしていたために UTF-16(ユニコードではなく)を積極的に導入しようとしなかったという話とはまた別でしょうか？
もしその話であれば、TRON コードはユニコードと対立するものではないし、アメリカに潰されたということだったと思います。
私が聞いた(見た)のは
日本(一部関係者 Unix系が多かった)も頑張ったが (JIS関係等の公的機関の後押しも無く)押し切られたということ、という事です。
TRONも関係あったかも知れませんが、こちらは不明。
ただ、当時のJISに関与する人たちは、Unicodeに懐疑的だったと言われています。(そんなもの、出来ないだろう、と)
で、Unix系の多くは、Shift-JISで無かったりするので、5C関係あるのと? となります。
JIS は国内のことなので無関係ですし、政府の代表でもありませんし、元々後押しできるような立場にはないと思います。あくまでもユニコードの策定に関わったスタッフが関係者ですが、これが積極的に関わっていないというのは少し信じがたく思います。
5C の話は向こうでお願いします。この件については、かなり主旨を誤解されています。グリフの話は私はしていません。Unix も無関係ですね。
一点だけ、
> JIS は国内のことなので無関係です
ISO-10646も考慮してください。また、国際規格の場合、国の関与は大きく、実際に中国は積極的に関与したと聞く。
勝手で申し訳ありません、他の方のコメント欄ではこの辺で止めたいと思います。
そのソースも回答に上げていただければと思います。
Unicodeの動きも、ISO10646の原案が否決されてUnicodeとの統合案が出る前と後とでは大分風向きが違う気がします。「ユニコード戦記」も多分それ以降の話ですよね。
当初は、「多バイト文字をよく知らない米国企業がなんかやってる。2バイト？日本の漢字だけで何万文字あると思ってるんだ？」という受け取り方をする人が多かったと思います。
otn さん、ありがとうございます。貴重な資料ですね。面白いです。
otnさん、懐かしいものを見つけましたね。ヘッダ(Path)がバケツリレー(正式名は?)を示していたりして。リアルタイムだったか、後付けかは忘れましたが、見た記憶有ります。リアルタイムだったとしても、当時は"関わるな"って雰囲気が強かった。
「fj.kanji unicode」でググったのですが、これくらいしか見当たらずでした。
Google Groupにも1980年代の記事は無いし。
ちょっと情報無いかと思ったら、懐かしい記事がありましたので。
(小形克宏の「文字の海、ビットの舟」第1部 第2回)[https://internet.watch.impress.co.jp/www/column/ogata/part1_2.htm]
途中から、Unicodeの話になります。このシリーズ全編、当時、興味深く読ませてもらいました。 質問の趣旨とはちょっと外れるかと思いますが、参考までに。
回答ありがとうございます。
為になる情報ありがとうございました
0
一言でいうと、「話が逆」ですかね…。
素朴に文字コードを1個作った場合、「文字集合で定めたコードポイントを、そのまま扱って(符号化方式でエンコードしない)文字を表示する」ようなものができます。
で、その場合、文字集合・符号化方式という概念は生まれません。必要ないので。
でも世の中は複雑なので、様々な文字コードが作られます。
ここで、
- 新たに全く別の(例えば日本語に対して韓国語とかの)文字コードを作りたくなったとき、既存の文字コードの仕組みを変えずに流用すると楽です。
- 既存の文字コードが何か都合が悪くて(例えばステートフルだと面倒とか、バイト数と文字幅が揃ってたほうがいいとか)新しいものを作るとき、収録する文字のレパートリーは変える必要がありません。
そうしていくつもの文字コードが作られるとき、変わらない部分と変わる部分があることに気づきます。
1で変わらない部分が「符号化方式」、2で変わらない部分が「文字集合」です。
この概念があることで、「符号化方式EUCで、文字集合の違いでEUC-JPとEUC-KRがある」とか「文字集合JISに対して符号化方式の違いでISO-2022-JP・EUC-JP・Shift_JISがある」とか言えるようになります。
投稿2019/08/12 14:00
総合スコア3047
0
色々理由はありそうですが、utf-8などの文字符号化方式で優れているな、と思ったことがあって、
それは「文字の境界がすぐにわかる」ということです。 (参考)
これがないと、文字列データは先頭から厳密に文字区切りを意識しながら処理しないといけなくなります。
コードポイントそのままだと、区切りがすぐにはわからないのでこの状態になってしまい、色々な文字列処理とかでは結構不便になると思います。
※ 例えば、文字列の部分一致をしたいときに、単にバイト列の比較ではできない、ことになる
投稿2019/08/12 06:45
総合スコア948
0
まずはその参考サイトに挙げられているネタ元の書籍を読みましょう
又聞きレベルで質問されても、根本の理解には及ばないというのが見えてしまいます
まず、ユニコードという文字コード体型を理解することから始めましょう。
このユニコードでは１文字は何バイトで表現されるのかをまず調べてみることです。がんばってみてください。
投稿2019/08/12 06:41
総合スコア88168
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2019/08/12 12:45
2019/08/12 12:58
2019/08/13 01:48
2019/08/13 01:57
2019/08/13 02:03
2019/08/13 02:13
2019/08/13 02:14
2019/08/13 02:15
2019/08/13 02:36
2019/08/13 14:19