BUCS

[21] BUCS とそれを使った SGML の文字コード処理モデル構想について。

[2] 技術セミナー 1997, 2023-07-30T03:09:17.000Z, 1997-10-15T22:24:32.178Z https://web.archive.org/web/19971015214216/http://bishamon.on.cs.keio.ac.jp/miyake/jbms/semina~1.htm

[3] >>2

3. 13:35 - 13:50   実装規約小委員会活動概要         小町祐史
						    (実装規約小委員会委員長)

[1] 3. 実装規約小委員会活動概要, 2023-07-30T02:38:39.000Z, 1997-10-15T22:44:31.496Z https://web.archive.org/web/19971015224140/http://bishamon.on.cs.keio.ac.jp/miyake/jbms/komach~1.htm

漢字集合J-BUCS(Basic Unified Character Set)の完成

[4] >>2

6. 16:00 - 16:40   WG4活動報告
                   SDATAエンティティ, BUCS 等を     奥井康弘 (日本ユニテック)
		   用いた多言語文書交換

[5] 2023-07-30T03:11:07.800Z https://web.archive.org/web/19971015214216/http://bishamon.on.cs.keio.ac.jp/miyake/jbms/97wg4.ppt

[6] >>5 >>4 の発表資料パワーポイントファイル。現在のツールでは文字化けしまくるか変換失敗で読めません。さすがに MS の純正ソフトウェアなら正しく読めると信じたいところですが。

[7] 当時のパワーポイントファイルにはコードページ情報が入っていないのでしょうかね。それとも今の欧米製変換ツールが文字コード変換をサボっているだけなのでしょうか。

[8] ネタがネタだけに、歴史の皮肉というべきか、現代人の愚かさというべきか。

[9] 失敗せず変換できるツールでテキストなり HTML なりで保存して (UTF-8 になる)、 UTF-8 から Windows-1252 に変換したものをシフトJISで読み込むと、所々化け化けながらなんとか文意がわからなくもない程度には読めるようになります。

[10] >>5 WG4 実装規約小委員会、というところが (SGML & HyTime の) CJK多言語文書の文字の交換、文字の表示について検討していた、と。

[11] >>5 の検討していたモデルでは、外部表現は既存の文字コード体系を利用 & SGML 実体参照 (SDATA実体) で記述し、応用はその文字コードを内部コードに変換、更には内部コードの文字とSDATA実体を「コード - 共通文字 - グリフ」の対応表を使って共通文字に変換して更にグリフを使って表示する、とされていました。具体的には DSSSL での利用が想定されました。

[12] SGML & DSSSL のオリジナルモデルでは曖昧な外部表現と内部表現のところが少し具体化している (もののやっぱりなんかふわっとしている) ものの、伝統的な SGML の世界の文字コード観とあまり変わっていない気もしますね。

[13] 参照処理モデルと比べるとまだ SGML 色が強いのと、内部コードが Unicode 固定とは言っていません。

[14] 対応表 (「マッピング表」) は「韓国語用」「日本語用」「中国語用」のように用意しておくとのこと。

[15] この辺は Adobe の CMap に近い世界観かもしれません。

[16] BUCS (Basic Unified Character Set) はこのモデルにおいて共通化された文字の集合として構想されていたもののようです。

[17] BUCS には「クラス」分けがあって、 1 が教育用、 2 が一般用、 3 が研究用とされます。

[18] 「BUCS サブセット」として各国用があって、

J-BUCS 日本
C-BUCS 中華人民共和国
T-BUCS 台湾
K-BUCS 韓国
V-BUCS ベトナム
S-BUCS シンガポール

が想定されました。

[22] 明らかに UCS / Unicode との関係が意識されているのでしょうが、具体的な関係性は述べられていません。まだ Unicode が当然になっていない時代というのもあるでしょうし、外部コードも内部コードも Unicode でもいいしそうでなくてもいいという CSI 的立場も取っていたのかもしれません。 (この時点ではまだ具体的な「BUCS サブセット」の策定作業に入っていないっぽいので、そのあたりどんな立場を取るか決めないで概念だけしかなかったのかも。)

[19] 公開の SDATA実体は

<!ENTITY kanxi123 
        PUBLIC "-//SPREAD//TEXT glyph kanxi123//CJK SDATA SPREAD-glyph">
<!NOTATION SPREAD-glyph 
        PUBLIC "-//SPREAD//NOTATION glyph shape encoding method//EN">

のような例が示されています。 SPREAD に乗っかって公開識別子の登録機関を設ける構想だったようです。

[20] これはその後形を変えて ISO/IEC 10036 による登録になったと思われます。

[31] SPREAD の提案は平成7(1995)年、平成8(1996)年。 SPREAD も SDATA実体を使った実体集合で、そちらは明確に Unicode に基づいた定義。

[23] >>19 の雑な例文は康熙字典の文字の字形を使うという例示ですかね。

[24] 公開テキストもなくても

<!ENTITY CJK.kanji1 SDATA    "<BITMAP>............">

と SDATA実体に公式システム識別子で Base64 符号化した 32×32 点グリフビットマップデータを定めるような方法で表せます。

[25] この BITMAP は本手法を表す蓄積域管理器と思われます。発表資料だからかもしれませんが、グリフデータを具体的にどう符号化するのか (ビット並び順など) はよくわかりません。

[26] Base64 はASCII英数字、 .、/ と説明されていますが、詳細不明です。区切り文字ではない、と説明があります。 MIME の Base64 は +, / ですが、 SGML では区切子の + を避けて . に変えたのでしょうか。 / も net ですが... (+, /, . のいずれもこの公式システム識別子の使い方では関係しないはずで、区切子を避けるのは気分的なものでしかないと思われますが...) Base64

[27] 実体名は Owner-identifier.character-name のような命名規則で衝突を避けるとしていました。

[28] 文字実体参照にSDATA実体を使うのは SGML の伝統的方法ですが、 SGML の世界では具体的にそれをどう使うか決めていない (実装依存になる) システムデータとして文字が表されていました。各システムはそのシステムの文字コード (等) に置き換えて使うことで、 SGML文書から見れば文字実体参照によってシステム毎の文字コードの違いを吸収できる仕組みでした。

[29] この提案はその伝統的な機構を活用し、共通の実体集合と文字集合とグリフ集合を整備しようとしていたもの、ということでしょうか。

[30] DSSSL にはSDATA実体を置き換える map-sdata-entity があって、この提案でも DSSSL ではこれによって「共通文字」に写像することにしていました。