#?SuikaWiki/0.9 page-icon="字β"
*ISO/IEC 646/2022 系列
-[[ISO/IEC646]]
-[[ISO/IEC2022]]
-[[ISO/IEC4378]]
-[[ISO/IEC6429]]
-[[ISO/IEC8859]]
[[タイプライタ]]に喩えると、元の鍵盤 (646)
の文字ではたりなくなったので、鍵盤を入れ替えたり (2022)
2つ並べたり (8859) 出来るようになりました。
*ISO/IEC 10646
-[[ISO/IEC10646]]
-[[Unicode]]
切り替えは面倒なので、すっごくでっかな鍵盤に替えました。 (Unicode)
それでも足りないのでもっとでっかな鍵盤に替えましたが、
でっかくなりすぎた (と思い込んだ。) ので[[かんな]]で削ってしまいました。
いずれにせよでっかな鍵盤なので、引っ張ったり叩いたりして
変形させてみたり、小切りにして切り替えることにしてみたり
(さっきは嫌って言ったくせに!)、もうすき放題。
*8ビット(256)符号化文字集合
-[[WindowsCodePage]]
でっかな鍵盤に替える前、鍵盤を2つ並べたのにもちょっと飾りつけ
したやつ。
*多バイト独自符号化文字集合
-[[シフトJIS]]
--[[携帯電話のシフトJIS拡張]]
-[[GBK]]
-[[GB18030]]
-[[UHC]]
-[[Big5]]
別に1打鍵=1文字にしなくても、複数打鍵=1文字でもいいじゃん。
って方々。
*「文字コード」の類義語
それぞれ少しずつ意味が違ってます。同じ語でも仕様書・文書によって
定義が違っていたりもします。日本語訳は更に訳す人によりばらばらです。
最初に挙げた物ほど良い訳だと(筆者は)思います。 ([[JIS]] とかの訳と
合致するものとか。) (全部片仮名にしただけなのは、一部を除いて
入れてません。一般に、そんなクソな訳はするな。)
-bit combination, ビット組合せ
-character, 文字, キャラクター
-character code, 文字符号, 文字コード
-character encoding method
-character encoding scheme, CES, [[文字符号化方式]], 文字符号化方法, 文字符号化スキーム, 文字符号化スキーマ (誤訳)
-character set, [[文字集合]], 文字セット
-[[charset]]
-code, [[符号]], コード
-code page, CodePage, CP, [[コードページ]]
-code point, 符号位置, コード・ポイント
-code representation, 符号表現
-code set, codeset, 符号集合, コード・セット
-code table, 符号表, コード表
-code value, 符号値, コード値
-coded character set, CCS, [[符号化文字集合]], コード化文字セット
-coding method, 符号化方式
-coding system, 符号系, コード系, 符号化体系, 符号化系, 符号化機構
-encode, [[符号化]], 符号化方式, 符号化方法, エンコード
-encoding, [[符号化]], 符号化方式, 符号化方法, エンコード
-encoding scheme, [[符号化方式]], 符号化方法
-Kanji code, 漢字符号, 漢字コード
-Kanji set, 漢字集合, 漢字セット
これらは、その意味の一部又は全部が「文字コード」の類義であるもの
ですが、必ずしも交換可能ではありませんし、みれば分かりますが、
全然関係無さそうなものまで混じってます。
このように「文字コード」は多義語ですから、わざとぼかしたい
時以外には使わない方がいいでしょう。
[[#comment]]
* ISO/IEC の符号化文字モデル
[7] >>2 と同じ方法で表現してみました。
-ビット :∈ {0, 1}
-{ビット列}ビット組合せ (文字) := <(符号化文字集合が定義する、文字の関数)>
-{ビット列}バイト := <一つの単位として操作するビット列>
-{ビット列}符号化文字データ要素 :∈ {{情報交換の構成単位} | 規格適合; 列 of 符号化表現 (文字)} ;; 規格が情報交換の構成単位などと抽象的な言い方をしているのは、ビット表現に限らない一般の場合(?)を想定しているのだろうか?
-{ビット列}CCデータ要素 := 符号化文字データ要素
-文字 :∈ {データの構成、制御又は表現に用いる構成単位}
-{文字の集合}文字集合 := {文字}
-{規則}曖昧でない規則 (文字, ビット組合せ) := <文字とビット組合せとの一対一対応>
-{規則の集合}符号 := 符号化文字集合
-{規則の集合}符号化文字集合 := {曖昧でない規則 (文字, ビット組合せ) | ∀文字 ∈ 文字集合}
-{文字の集合}レパートリ := {文字 | ∃ビット組合せ (文字)}
[8] なんだかこっちもわけがわからん...
[9] こっちでいう[CODE[規則]]ってのが、 >>2 でいう関数
[CODE[符号化表現]]に相当するのだろうか?
[[JISX0201]] も [[JISX0202]] も
[[JISX0211]] も、「符号化表現」という語に定義を与えてない。
(自明?)
[10] >>9 [[JISX0208]] も [[JISX0213]] も。
[[#comment]]
* SGML の文字モデル
[1] SGML の文字の扱いのモデル (どう処理するかではなく、
SGML 的にはどう考えているのか) って、
さっぱりわからなくありません? と思ってまとめてみましたら、
余計に分からなくなりました。
[PRE[
{符号化表現の集合}
文字集合 ============> 符号集合
文 +-----+ 符号化表現 +----------+
| 'A'-|--------------|>66: %x42 |
字 |(↑文字) (符号集合位置↑) (↑ビット組合せ)
| 'B' | | 67: %x43 |
レ | 'C' | | 68: %x44 |
| : | | : : |
パ | : | | : : |
| 'Z' | | 91: %x5A |
| +-----+ +----------+
:'α' :
ト :'β' :
: : :
リ + - - +
]PRE]
%x42 について:
,66 ,文字番号
,1000010(2) ,ビット組合せ
,1000010(2) (== 'A'。) ,符号化表現
[2] >>1 とりあえず SGML の規格票の定義を関数風に表現してみた。
-{数値}数値化 (引数) := <引数を数値として評価したもの>
-{10進数}十進化 (引数) := <引数を10進数表記にしたもの (is‐a 文字列??)>
-{10進数}文字番号 (文字) := 十進化 (数値化 (符号化表現 (文字))) = 十進化 (数値化 (ビット組合せ (文字)))
-{文字の集合}文字レパートリ := {文字}
-{文字レパートリ}文字集合 := {文字 | ∃c :∈ 符号集合; c = 符号化表現 (文字)}
-文字 :∈ 文字レパートリ
-{ビット組合せ}符号化表現 (文字) := <(SGML では規定外の、文字の関数)>
-{ビット組合せの集合}符号集合 := {ビット組合せ}
この中で、関数 [CODE[数値化 (引数)]] と [CODE[十進化 (引数)]]
は都合上勝手に定義した。型 [CODE[[[ビット組合せ]]]]とかは未定義だけど、[[引用規格]]である
[[ISO/IEC646]] とかの定義が使われるのだと思われ。
- [3] >>1-2 [[ISO/IEC]] の[[符号化文字集合]]系規格を引用しているくせに、 (たぶんそれに従っていない符号化文字集合にも対応するために、) それと微妙に違う用語とかを採用してるから、分かりにくく思えるんだよね。
- [4] >>3 SGML の core な人達が符号化文字集合について造詣がないのが原因と思われ。
- [5] >>2 そうはいっても SGML で未定義なのは [CODE[{ビット列}ビット組合せ (文字) := <(符号化文字集合が定義する、文字の関数)>]] だけだ。これを補充したところで何の解決にもならんと思うが?
- [6] >>1-5 難しいこと考えなくても、 >>1 の図 + >>2 の[CODE[文字番号]]の定義でいいんじゃないか?
[[#comment]]
*メモ
- [11] [[図形文字の符号化]]モデル: [[文字]]はその[[図形記号]]により識別される。図形の個々の実現値は子細は異なるが、共通する骨格のようなもの ([[字体]]) を持つ。これと[[ビット組合せ]]を対応づける規則を決める。
- [12] 図形文字の符号化 + [[用字系]]モデル: 同字形でも、[[長音符号]]と[[ハイフン]]が同符号では不便だ。図形が同じでも用字系が異なれば異なる文字とみなす。
- [13] [[文字観念]]モデル: 文字を文字足らしめているのは「文字の意味」をもっと広義に採った文字観念とでもいうべきものであり、これにビット組合せを対応づける。[[字形]]が大きく異なるとも、共通の観念の支配するところなれば (例: [[異体字]]) それは同じ文字とみなす。
- [14] 抽象概念モデル: 文字観念モデルを更に推し進める。意味が同じ == 置換可能なら同じ文字である。同字形でも異なる意味を持てば異なる意味である。文字の本質はその抽象概念であって字形は表現形にすぎない。
- [15] 表音モデル: 文字とは音写記号である。同じ字形・意味であっても発音が異なれば異なる文字である。
- [16] 文字=記号論: ある人がこれは文字だと言えばそれは文字である。
- [17] >>16 s/それは文字/それはその人にとって文字/
- [18] 文字コードをめぐる問題の多くは、単なる図形記号 (タイプライタの時代。) から意味を具現化した最小単位への「文字」の定義のシフトの過程のどこで均衡を得るかに関する見解の対立と、一般の計算機で処理する情報の実質的な最小単位として (自然なこととはいえ) 文字を使ってしまった (文字 = バイトとしてしまった) ことの後処理という2つの大きな問題によるものとしてまとめることができるのではありませんか?
- [19] ''【UTF8】文字コード変換【SJIS】''
- [20] ''文字化け辞典作成委員''