シフトJISが符号化文字集合?

| コメント(5) | トラックバック(0)

文字コードに関して、符号化文字集合と文字符号化方式という区別がいわれることがあります。拙著『プログラマのための文字コード技術入門』でもその分類に従っています。

この区分によると、JIS X 0208やJIS X 0213は符号化文字集合で、シフトJISは文字符号化方式だということになります。

ところが、混乱させることをいうようですが、JIS X 0208:1997では、シフトJISは符号化文字集合だと書かれています。ウソだと思うなら、JIS X 0208:1997の附属書1を見てみると良いでしょう。

これはどういうことでしょう。シフトJISが文字符号化方式だというのが間違っているのでしょうか、それとも97JISの記述が間違っているのでしょうか?

結論をいってしまうと、これは単に用語法の問題ということになります。

そもそも、「符号化文字集合と文字符号化方式」という区分はISOやJISといった文字コード標準の世界で使われ始めたものではありません。多分に便宜的・慣用的な用語法でしかないのです (IETFのRFCにはそうした用語法が見えますが、IETFは文字コードを定める団体ではありません)。

ISOやJISの多くの規格では、符号化文字集合(coded character set)という用語は、「文字集合を定め、かつ、その集合内の文字とビット組合せとを1対1に対応付ける、あいまいでない規則の集合」として定義されています。そして文字符号化方式という用語はありません。シフトJISという文字コードの内実はこの用語の定義に合致しますから、JIS的にはシフトJISを符号化文字集合と呼ぶのは何らおかしいことではないのです。

ただ、拙著では、慣用的な用語法にも一定の便益があると認定して、あえて公的標準にない用語法を採用しました。

シフトJISやEUCといった文字コードは、JIS X 0208やJIS X 0213を変形したり他の符号化文字集合と組み合わせたりして作られているわけですから、そういうものに対しては符号化文字集合とは別の言葉で呼んだ方が分かりやすいという判断です。

しかしながら、「符号化文字集合と文字符号化方式」という区分がいつでも絶対にあるのだという立場をとってしまうと、ASCIIやLatin-1やBig5などを説明するときに、「符号化文字集合と文字符号化方式が一体になっている」といった苦しい説明をせざるを得なくなります。実際には、元々そんな区分はないにもかかわらずです。

肝心なことは、「符号化文字集合と文字符号化方式」という区分は絶対的・本質的なものでは必ずしもないということです。そういう区分を設けた方が便利なときだけ、採用すればいいわけです。

トラックバック(0)

トラックバックURL: http://yanok.net/yanok/mt-tb.cgi/283

コメント(5)

ISO/IEC 10646:2011 では以下のように語が定義されつつ、UCS encoding forms や UCS encoding schemes って章があったり、
4.8 coded character: association between a character and a code point
4.9 coded character set: set of coded characters
4.10 code point / code position: value in the UCS codespace

「公的標準」ではありませんが、UnicodeUTR#17 には CSS/CEF/CES という階層を導入しつつ既存の文字コードとの対応を試みているんですが、それは参照しないんですかね。
http://unicode.org/reports/tr17/

CSS/CESという階層が絶対的でなく、文脈によって意味が違ったり後付け要素が濃いってのは仰る通りで、慎重に語りたい時はどの「符号化文字集合」の定義を参照しているのか最初に宣言する必要があるってのは仰る通りですが。

まぁ、思うにこれは 2022 を前提としているか否かからくるんじゃないかなぁと思ったりもします。

他でたまたま同種の話題があったので更に良く見てみたんですが、JISにおいては
* いわゆる「符号化文字集合」UTR#17のCCSは「漢字集合」
* いわゆる「文字符号化方式」UTR#17のCESは「符号化表現」
* encodingとかcharsetとかUTR#17のCCS+CESが「符号化文字集合」
というような対応になってるんじゃないでしょうか。

Unicodeは独特ですね。まあ元々は16ビット固定長というのが金看板だったわけなので随分変わったなあという気がしますが。
UTR#17については、http://www.asahi-net.or.jp/~wq6k-yn/code/ccs.html をご覧ください。

ISO/IEC 10646 から見れば最初から 32bit だったわけで、そこはあんまり変わってないと思いませんけどね。8859の系譜としてみれば当然の流れでしょう。
「JISの区点番号は整数ではなく整数の組 (例えば「あ」なら区番号4、点番 号2という2つの整数の組) であるので、上の「非負整数の集合」へのマッピン グという定義には合致しない」という話ですよね。JIS X 0208:1997 では 5.1.3.2 に「16進表記」が定義されているので、この批判は誤りだと思います。

それは勘違いですよ。あくまでも区点番号を例として挙げているので、それは整数の組であり、整数ではないので、UTR#17は矛盾しています。
ただまあ、そんなことは所詮後付けの決めごとでしかないので、あまりこだわってもしようがないというのが本ブログの主旨です。このへんは昔いろいろ考えましたが、あまり形式ぶったモデルを打ち立てようとしても特に実りがないということに気付いたので、拙著第4章冒頭のような説明に落ち着いています。

コメントする

最近のブログ記事

National Geographic Your Shot で Daily Dozen に選ばれた話
ブログをさぼっている間に時間がずいぶん経…
情報処理学会から山下記念研究賞を頂いた話
ブログをさぼっている間に時間がずいぶん経…
Go と Rustの文字列
Go言語における文字列はUTF-8のバイ…
『[改訂新版] プログラマのための文字コード技術入門』のページ作成
発売されてから半年以上経ってようやくのこ…
『[改訂新版]プログラマのための文字コード技術入門』発売!
ばたばたしていて当サイトの更新も怠ってい…

広告