[21] [[BUCS]] とそれを使った [[SGML]] の[[文字コード][SGMLにおける文字コード]]処理モデル構想について。 [2] [CITE[技術セミナー 1997]], [TIME[2023-07-30T03:09:17.000Z]], [TIME[1997-10-15T22:24:32.178Z]] [3] >>2 > [PRE[ 3. 13:35 - 13:50 実装規約小委員会活動概要 小町祐史 (実装規約小委員会委員長) ]PRE] [1] [CITE[3. 実装規約小委員会活動概要]], [TIME[2023-07-30T02:38:39.000Z]], [TIME[1997-10-15T22:44:31.496Z]] > -漢字集合J-BUCS(Basic Unified Character Set)の完成 [4] >>2 > [PRE[ 6. 16:00 - 16:40 WG4活動報告 SDATAエンティティ, BUCS 等を 奥井康弘 (日本ユニテック) 用いた多言語文書交換 ]PRE] - [5] [TIME[2023-07-30T03:11:07.800Z]] [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] [DFN[BUCS]] ([DFN[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実体]]は > [PRE(SGML code)[ ]PRE] のような例が示されています。 [[SPREAD]] に乗っかって[[公開識別子]]の登録機関を設ける構想だったようです。 ;; [20] これはその後形を変えて [[ISO/IEC 10036]] による登録になったと思われます。 ;; [31] [[SPREAD]] の提案は[TIME[平成7(1995)年][1995]]、 [TIME[平成8(1996)年][1996]]。 [[SPREAD]] も [[SDATA実体]]を使った[[実体集合]]で、 そちらは明確に [[Unicode]] に基づいた定義。 [23] >>19 の雑な例文は[[康熙字典]]の文字の字形を使うという例示ですかね。 [24] [[公開テキスト]]もなくても > [PRE(SGML code)[ ............"> ]PRE] と [[SDATA実体]]に[[公式システム識別子]]で [[Base64]] [[符号化]]した 32×32 点グリフビットマップデータを定めるような方法で表せます。 [25] この [DFN[[CODE[BITMAP]]]] は本手法を表す[[蓄積域管理器]]と思われます。 発表資料だからかもしれませんが、[[グリフ]]データを具体的にどう[[符号化]]するのか (ビット並び順など) はよくわかりません。 [26] [[Base64]] は[[ASCII英数字]]、 [CODE[.][FULL STOP]]、[CODE[/]] と説明されていますが、 詳細不明です。 区切り文字ではない、と説明があります。 [[MIME]] の [[Base64]] は [CODE[+]], [CODE[/]] ですが、 [[SGML]] では[[区切子]]の [CODE[+]] を避けて [CODE[.][FULL STOP]] に変えたのでしょうか。 [CODE[/]] も [CODE[net]] ですが... ([CODE[+]], [CODE[/]], [CODE[.][FULL STOP]] のいずれもこの[[公式システム識別子]]の使い方では関係しないはずで、 [[区切子]]を避けるのは気分的なものでしかないと思われますが...) [SEE[ [[Base64]] ]] [27] [[実体名]]は [VAR[Owner-identifier.character-name]] のような命名規則で衝突を避けるとしていました。 [28] [[文字実体参照]]に[[SDATA実体]]を使うのは [[SGML]] の伝統的方法ですが、 [[SGML]] の世界では具体的にそれをどう使うか決めていない ([[実装依存]]になる) [[システムデータ]]として[[文字]]が表されていました。 各システムはそのシステムの[[文字コード]] (等) に置き換えて使うことで、 [[SGML文書]]から見れば[[文字実体参照]]によってシステム毎の[[文字コード]]の違いを吸収できる仕組みでした。 [29] この提案はその伝統的な機構を活用し、共通の[[実体集合]]と[[文字集合]]と[[グリフ集合]]を整備しようとしていたもの、ということでしょうか。 [30] [[DSSSL]] には[[SDATA実体]]を置き換える [CODE[map-sdata-entity]] があって、この提案でも [[DSSSL]] ではこれによって「共通文字」 に写像することにしていました。 [32] [CITE[5.1-5.4(平成9年度実装規約小委員会報告書)]], [TIME[2024-08-23T08:11:52.000Z]], [TIME[2001-05-16T15:44:08.063Z]] [33] [CITE[7.1, 7.2(平成9年度実装規約小委員会報告書)]], [TIME[2024-08-23T08:15:21.000Z]], [TIME[2001-05-16T16:25:51.967Z]]