平成 16 年度
e-Book に関する標準化調査研究
成 果 報 告 書
平成 17 年 3 月
財団法人
日本規格協会
情報技術標準化研究センター
□この報告書に添付している JIS/TR 原案は、制定の審議の過程において
変更があり得ます。
また、ISO 等での今後の国際的審議の結果、変更されることがあります。
まえがき
e-Book, e-Publishingは決して新しい概念ではなく, 文書の電子化が議論され始めた当時からその意義と実
用性が検討され, 国内・海外で幾度となく事業化への試みがなされてきた。実際に現在に至るまでの多くの
e-Book, e-Publishingの事例を見ることができる。しかしいずれも支配的な市場を獲得するに至っていない。
この現状を鑑みると, 幾つかの問題点を指摘することができる。その一つが国際的な標準化である。国内で
は, これまでにも幾つかのデファクト標準を目指す活動があったが, 国際的な活動には発展しなかった。電子
情報の流通・配布が国際と国内との境界を失った現在, 国際標準化なしにe-Book, e-Publishingの市場を期待
することはできないであろう。もちろんこれは必要条件であって充分条件ではない。
昨年度までの電子出版技術調査研究委員会(EPCom)では, e-Book, e-Publishingに用いられる文書情報の基
礎的な標準化をターゲットとしてきた。e-Book標準化調査研究委員会は, これらの成果を用い, さらにe-Book
固有な, またはe-Publishing固有な国際標準化対象をそのスコープとして, 2004年度にその活動を行った。
その結果, JEITAを経由してIEC/TC100に対して幾つものContributionを提出し, e-Book, e-Publishingに関
する標準化の指針を与える概念モデルの開発に関するプロジェクトをTC100の中に設立することになった。今
後は, このプロジェクトをさらに推進するとともに, 関連する標準化トピックを提出してこの分野の専門家を
集め, e-Book, e-Publishingの国際的なマーケットの立ち上げに寄与することが望まれる。
平成17年2月 e-Book標準化調査研究委員会
委員長 池田 克夫
目 次
1. 背景と経緯………….…………………………………………………………………………………...1
1.1 必要性と意義..………………………………………………………………………………………1
1.2 調査研究の内容..……………………………………………………………………………………1
1.3 期待される成果..……………………………………………………………………………………2
2. 委員会構成..……………………………………………..………………………………………………2
2.1 構成と作業分担..……………………………………………………………………………………2
2.2 委員..…………………………………………………………………………………………………2
3. 2004 年度活動計画..…………………………………………………………………………………….4
3.1 規格原案作成..………………………………………………………………………………………4
3.2 その他の活動..………………………………………………………………………………………4
4. 委員会開催一覧および審議内容....……………………………………………………………………6
4.1 親委員会..……………………………………………………………………………………………6
4.2 作業グループ..………………………………………………………………………………………6
5. 作業グループの活動……………………………………………………………………………………7
5.1 WG1.…………………………………………………………………………………………………7
5.2 WG2.………………………………………………………………………………………………..12
6. 今後の課題 ……………………………………………………………………………………………31
附属資料: 活動の成果
A.1：TS 原案および TR 原案
A.1.1 TS X 0106:2005 原案, 多目的インターネットメール拡張(MIME)－第 4 部: 登録手続
A.1.2 TS X 0107:2005 原案, 多目的インターネットメール拡張(MIME)－第 5 部: 適合基準
A.1.3 TS X 0069:2005 原案, 多目的インターネットメール拡張(MIME)－第 1 部:
インターネットメッセージ本体のフォーマット
A.1.4 TS X 0059 原案, XSLT ライブラリ
A.1.5 TS 原案, DSSSL 多機能組版ライブラリ
A.1.6 TR 原案, 縦組文書における数字表記方法
A.2：JIS 原案(NSK への JIS 化支援)
A.2.1 JIS X 7201:2005 原案, ニュース用マーク付け言語 (NewsML)
A.3：W3C への提案
A.3.1 XSL 拡張要求
A.4：IEC/TC100 への提案
A.4.1 NP 原案, Conceptual model for multimedia e-publishing (100/864/NP)
A.4.2 NP 原案, Generic format for e-publishing
A.4.3 Reader's format for e-publishing の検討資料(PDF サブセット)
A.4.4 Submission format for e-publishing の検討資料(XML 化 SPML)
A.5：ISO/IEC JTC1/SC34 への提案(CICC/DocSII とのリエゾン)
A.5.1 Amd.1 to ISO/IEC TR 19758
A.5.2 Amd.2 to ISO/IEC TR 19758
A.5.3 DAM3 to ISO/IEC TR 19758
1. 背景と経緯
1.1 必要性と背景
e-Book, e-Publishingは決して新しい概念ではなく, 文書の電子化が議論され始めた当時からその意義と実用
性が検討され, 国内・海外で幾度となく事業化への試みがなされてきた。
実際に現在に至るまでの多くのe-Book,
e-Publishingの事例を見ることができる。しかしいずれも支配的な市場を獲得するに至っていない。例えば,
2003年度は，新しいe-Book端末の発表やビジネスコンソーシアムの設立提案が相次ぎ，e-Book元年と期待され
ていた。しかし，ケータイインフラの利用は活発になってきつつあるものの，総体的にはいまだに浮上できな
い状態が続いている。
この現状を鑑みると, 幾つかの問題点を指摘することができる。その一つが国際的な標準化である。国内では,
これまでにも幾つかのデファクト標準を目指す活動があったが, 国際的な活動には発展しなかった。電子情報
の流通・配布が国際と国内との境界を失った現在, 国際的な標準化活動なしにe-Book, e-Publishingの市場を
期待することはできないであろう。
1.2 調査研究の内容
e-Book/e-Publishingに関する国際的な標準化活動を展開するには, その分野の専門家が集まって標準化の議
論を行う場が必要である。しかし最近のend-user specificな観点でのe-Bookを対象とする委員会は, ISOにも
IECにも存在しない。e-Book端末が情報家電的な取り扱いを受けていることを考慮すると, IEC/TC100がもっと
も現状のe-Bookのissueを扱い易いように思われる。
そこでIEC/TC100をターゲットとして幾つかの新作業課題(NP)を提案して, 複数のプロジェクトを成立させ,
しかる後にそれらを傘下におくTA(Technical Area; ISO/TCのSub-committeeに相当)を作るという戦略を立て
た。これを実現するため, いくつものe-Book/e-Publishing関連の新規課題をIEC/TC100/AGSに提案することを,
e-Book委員会の主眼に置いた。
e-Book/e-Publishing関連の新規課題の提案には, 関連技術の調査研究が不可欠である。さらに. このような
e-Book固有, またはe-Publishing固有なトビック以外にも, 昨年度までの電子出版技術調査研究委員会
(EPCom)が扱ってきたような文書情報の基礎的な標準化も, e-Book/e-Publishingの環境整備には必要である。
1.3 期待される成果
上記の戦略を実行するために, まずIEC/TC100に対してNPの提案をし, プロジェクトを成立させることを, こ
のe-Book委員会の期待される成果に位置付けることとした。
関連する成果としては, 文書情報の基礎的な規格として普及が期待されるもののJIS, TSまたはTRの原案作成
を挙げることができよう。
1
2. 委員会構成
2.1 構成と作業分担
2004年度の委員会構成と作業分担は次のとおりとする。
親委員会(EBPL):
成果のレビューと承認
作業グループ1 WG1(EBW1): e-Book, e-Publishingの要素技術の調査研究および
文書交換プロトコルの標準仕様書(TS)原案作成
作業グループ2 WG2(EBW2): e-Book, e-Publishing固有の標準化対象の調査研究および
関連する国際標準化のための新作業課題検討
予定する委員会開催は次のとおりである。
•
親委員会: 3回/年
•
WG1: 1回/月
•
WG2: 1回/月
2.2 委員
各委員会の構成委員(2005-02現在)を次に示す。
(1) 親委員会(EBPL)
委員長
池田克夫
委員
内山光一
大久保彰徳
小町祐史
長村玄
植村八潮
礪波道夫
内藤求
中村幹
平山亮
赤木孝次
矢ケ崎敏明
堀坂和秀
事務局
内藤昌幸
宮古牧子　大阪工業大学
東芝ソリューション(株)
(株)リコー
パナソニックコミュニケーションズ(株)
ネクストソリューション(株)
東京電機大学出版局
読売新聞東京支社
(株)シナジー・インキュベート
(株)印刷学会出版部
金沢工業大学
(社)日本新聞協会
キヤノン(株)
経済産業省産業技術環境局
(財)日本規格協会
(財)日本規格協会
(2) 作業グループ1 WG1(EBW1)
主査
小町祐史
パナソニックコミュニケーションズ(株)
委員
内山光一
東芝ソリューション(株)
平山亮
金沢工業大学
石野恵一郎 アンテナハウス(株)
大久保彰徳 (株)リコー
内藤求
(株)シナジー・インキュベート
長村玄
ネクストソリューション(株)
藤島雅宏
(有)イー・エイド
矢ケ崎敏明 キヤノン(株)
山田篤
(財)京都高度技術研究所
赤木孝次
(社)日本新聞協会
堀坂和秀
経済産業省産業技術環境局
事務局
内藤昌幸
(財)日本規格協会
宮古牧子　(財)日本規格協会
2
(3) 作業グループ2 WG2(EBW2)
主査
長村玄
ネクストソリューション(株)
委員
佐藤弘一
日本電気(株) NECソリューションズ
大久保彰徳 (株)リコー
植村八潮
東京電機大学出版局
加藤寿郎
凸版印刷(株)
小町祐史
パナソニックコミュニケーションズ(株)
矢ケ崎敏明 キヤノン(株)
高橋仁一
大日本印刷(株)
中村幹
(株)印刷学会出版部
野口高成
ネクストソリューション(株)
堀坂和秀
経済産業省産業技術環境局
事務局
内藤昌幸
(財)日本規格協会
宮古牧子　(財)日本規格協会
3
3. 2004年度活動計画
次の作業内容の推進を2004年度の計画として確認した。
3.1 TRおよびTSの原案作成
3.1.1 e-Publishing/e-Bookの国際規格提案
e-Publishing/e-Bookに関する標準化要求を調査し, IEC/TC100/AGSで検討された100/AGS/139(Multimedia epublishing and e-books - Conceptual model for multimedia e-publishing)に基づいて, 新作業課題(NP)の
国際提案を行う。
3.1.2 DSSSL多機能組版ライブラリ
ISO/IEC TR 19758は, TR X 0010に基づく日本からの提案であったが, その後, 幾つものAmendmentsが開発さ
れ, TR X 0010との乖離が顕著になった。そこで, 国際との整合を図るため, ISO/IEC TR 19758およびそのAmd.1,
Amd.2, Amd.3に整合する標準仕様書(TS)の原案の作成する。
3.1.3 MIMEのTS原案
昨年度の電子出版技術調査研究委員会(EPCom)の活動の結果, MIME-1, -2, -3がTRとして公表され, MIME-4, -5
についても原案の検討が行われていた。e-Book委員会においてもMIMEはその情報の交換にとって重要と位置付
けられ, EPComから引継いだ作業として, MIME-4, -5のTS化を行う。
さらに, 既にTRとして公表済みのMIME-1が2005年度で期限切れとなるため, 現状のTRをそのままTSとして, 今
後のJIS化作業に繋げる。
3.1.4 NewsMLのJIS化支援
6月の新聞協会(NSK)での会合で, NewsMLをJIS化する作業が承認され, e-Book/WG1に対してJIS化作業支援の要
求があった。さらに新聞協会は, NewsML・JIS原案作成委員会を設立し, e-Book委員会と密接なリエゾンをと
ることにした。NewsML・JIS原案作成委員会には, e-Book/WG1の委員数名がメンバとして参加する。
3.2 その他の活動
3.2.1 XSLTライブラリ
TR X 0059:2002を改正して, TS X 0059するための作業(昨年度の電子出版技術調査研究委員会の活動からの継
続)を行う。
3.2.2 縦組文書における数字表記方法
XML文書を縦組表示するため, 主として漢数字の縦組表記を整理して, 電子化レンダリングシステムにおける
推奨表記を明らかにする。
3.2.3 XSL機能拡張
W3C勧告のXSL1.0は, 電子出版技術調査研究委員会の活動によって, TR X 0088:2003, 拡張可能なスタイルシ
ート言語(XSL) 1.0 として公表された。このXSL 1.0を委員が実装した結果, いくつかの機能拡張の必要性が
提示されている。この内容を検討し, e-Book委員会としてW3Cに提案する。
3.2.4 PDF subsetの規定
携帯電話等のモバイル端末のアプリケーションを前提に，ユースケースを作成し，それに必要な機能項目を明
確にして，PDF subsetの基本プロファイル, オプションプロファイルを開発する。これは, IECに提案するeBook情報の交換フォーマットの一部に位置付ける。
4
3.2.5 原稿校正標準マーク付け言語(SPML)
以前のGLOCOM開発版に対してさらに検討を加え, XML対応を行う。これも, IECに提案するe-Book情報の交換フ
ォーマットの一部に位置付ける。
3.2.6 XSL, XSLT等のJIS化検討
XSL等のスタイル指定言語は, XML文書を利用者にvisibleに提供するための必須の規定として, 要求が高まっ
ている。そこで一連のスタイル指定言語規定に関する今後のJIS化の方策を検討する。
5
4. 委員会開催一覧および審議内容
4.1 e-Book標準化調査研究委員会[親委員会](EBPL)
e-Book標準化調査研究委員会[親委員会](EBPL)の開催一覧を表4.1に示す。
表4.1 EBPL開催一覧
開催番号 開催日
開催時間
開催場所
主な議題
11 2004-06-01 15:30～17:30 日本規格協会第802会議室 平成16年度活動計画の承認
11 2004-10-22 10:00～12:00 日本規格協会第801会議室 平成16年度上期作業の承認
12 2005-02-25 10:00～12:00 日本規格協会第801会議室 平成16年度活動成果の承認
4.2 作業グループ(EBW1, EBW2)
e-Book標準化調査研究委員会 作業グループ(EBW1, EBW2)の委員会開催一覧をそれぞれ表4.2, 表4.3に示す。
表4.2 作業グループ1(EBW1)開催一覧
開催番号 開催日
開催時間
開催場所
主な議題
63 2004-06-22 14:00～17:00 日本規格協会第802会議室 平成16年度活動計画の確認
64 2004-07-28 14:00～17:00 日本規格協会第801会議室 CSS1制定、MIME-4,-5の検討
65 2004-08-27 14:00～17:00 日本新聞協会　大会議室
XSLT-lib,PDF,MIME-4,-5の検討
66 2004-10-12 10:00～12:00 日本規格協会第201会議室 XSLT-lib,PDF,MIME-4,-5の検討
67 2004-11-30 14:00～17:00 日本規格協会第801会議室 XSLT-lib,PDF,漢数字表記の検討
68 2004-12-20 10:00～12:00 日本規格協会第801会議室 XSLT-lib,PDF,漢数字表記の検討
69 2005-01-20 14:00～17:00 日本規格協会第801会議室 NewsMLレビュー、W3Cへの提案
70 2005-02-18 14:00～17:00 日本規格協会第802会議室 平成16年度報告書まとめ
表4.3 作業グループ2(EBW2)開催一覧
開催番号 開催日
開催時間
開催場所
主な議題
1 (56) 2004-06-22 10:00～12:00 日本規格協会第802会議室 平成16年度活動計画の確認
2 2004-07-21 14:00～17:00 星陵会館　Ｃ会議室
eBookビジネスモデルの検討
3 2004-08-25 14:00～17:00 日本規格協会第202会議室 eBookビジネスモデル検討
4 2004-10-01 14:00～17:00 日本規格協会第802会議室 コンテンツ流通講演
5 2004-11-04 14:00～17:00 日本規格協会第801会議室 eBookビジネスモデルの検討
6 2004-12-07 10:00～12:00 日本規格協会第801会議室 PDF subsetの検討
7 2005-01-18 14:00～17:00 日本規格協会第801会議室 スリランカIT状況報告
8 2005-02-08 14:00～17:00 日本規格協会第303会議室 平成16年度報告書まとめ
8 2005-02-28 10:00～12:00 日本規格協会第801会議室 平成16年度報告書まとめ
6
5.1 WG1
5.1.1 TS X 0059, XSLTライブラリの改正
昨年度の電子出版技術調査研究委員会(EPCom)/WG1での活動を継承し, TR X 0059:2002がサポートしていた目
次の生成と索引の生成に, 次の機能を追加して, TS X 0059の原案とした。
•
文字列処理
•
タグの処理
•
属性の処理
•
日本語処理
TR X 0059:2002に含まれていた, 各処理のサンプルインスタンスについても, 改訂を行った。この原案を附属
資料A.1.4に示す。
5.1.2 NewsMLのJIS化支援
6月の新聞協会での会合でJIS化の作業を開始することが了承されたことを受けて, 新聞協会内に原案作成委員
会が設立され, eBook/WG1は原案りレビュー等の作業を支援することになった。
11月25日のJIS用語委員会で用語のレビューを受けた後, 12月に原案をJSAに提出して, 2005年1月26日の規格
調整委員会のコメントを反映したテキストを再提出した。2月には, METI内部審査に際してのコメントを受け,
修正テキストを作成した。この原案を附属資料A.2.1に示す。
3月23日の情報技術専門委員会で審議を受ける予定である。
5.1.3 縦組文書における数字表記方法
XML文書等の構造化文書をレンダリングする際に縦組表示が求められることがある。そこでレンダリングシス
テムへの縦組表示文書スタイル指定を記述するための指針としての数字表記方法を, TR原案としてまとめると
共に, XSLによるスタイル記述を行い, 適切なフォーマティングが実行されることを確認した。
これらの検討に際して, 関連する次の活動をもレビューした。
•
新聞社の縦横変換
•
数字列への読み付与
このTR原案を附属資料A.1.6に示す。
5.1.4 XSL機能拡張
昨年度の電子出版技術調査研究委員会(EPCom)/WG1での活動を継承し, XSL1.0に対する機能拡張を検討して,
拡張案(附属資料A.3.1を参照)をW3Cに提示した。
5.1.5 MIMEの残りのパート
情報技術専門委員会(第14回)議事録において,
>資料　２「ＴＳ　Ｘ００７１　多目的インターネットメール拡張（ＭＩＭＥ）
>第３部非ＡＳＣＩＩテキストへのメッセージヘッダ拡張」の公表
>原案作成者から説明の後, 異議なく承認された。
>また, ＭＩＭＥに関する他の規格については, 日本語への翻訳は終了
>しているもののＴＳの様式に編集する作業は第１１回情報技術専門委
>員会で決定された海外有力コンソーシアム規格をベースにしたＴＲは
>作成しないとの方針に基づきＴＳ化に向けた作業は行っていない状況
>が原案作成者から紹介された。
は, そのとおりですが, 次の議論があったことを追加していただけない
でしょうか?
7
それに対して, すでに翻訳が終了し原案作成が終了しているものに
ついては, 追加の費用発生はないのでTS原案として提出してほしい
との意見が委員から出された。
という要求があり, しかもパート1～3までが公表されて, 残るパート4～5が公表されないのは利用者に混乱を
与えるため, MIME-4, 5のTS原案を作成した。
これらのTS原案を附属資料A.1.1, A.1.2に示す。
5.1.6 MIME1のTS原案: TS X 0069
MIME1を規定するTR X 0069が期限切れとなるが, MIMEは既に広く利用され, しかも多くの規格から参照されて
いる。そこでTR X 0069をTSの様式に修正して, TS X 0069として公表するため, TS X 0069の原案作成を行っ
た。
このTS原案を附属資料A.1.3に示す。
5.1.7 XSL, XSLT等のJIS化検討
現在TRとして平成15年9月1日付けで制定されているTR X 0088 拡張可能なスタイルシート言語（XSL）1.0 に
ついて, JIS化するにつき考察したので報告する。
(1) 原情報の状況
現存するTRは, W3Cの”Extensible Stylesheet Language (XSL) Version 1.0”（2001年10月公表）に基づい
ている。W3Cのその後の活動を見るに, 活発な議論を経てVersion1.1として2004年12月16日にワーキングドラ
フトが出されている。しかしながら, ラストコールの期限が過ぎているにも拘わらず未だ討議中である。今後
の見通しとして, 2005年春にラストコールが出され, 同年秋には勧告として発行されるのが最短のスケジュー
ルであろう。勧告として発行される時期が更に遅れる可能性は十分にある。
(2) JIS化のタイミング
現存するTR XSL Version 1.0 のJIS化には次のような工程を経る必要がある。
•
現存するTRの文面を再度精査してJIS用語, 様式に適合していない部分は修正する。
•
JIS用のWordテンプレートに落とし, JISとしての体裁を整える。
•
以上の作業に少なくとも2005年度一杯を必要とする。
•
JIS化された規格が発行されるのは2006年度になる。
(3) JIS化の問題点
このようなタイムスケジュールを考えた場合, 以下のような問題点が考えられる。
•
W3Cの更改作業が遅れているとはいえ, 2006年にXSL Version 1.0 のJIS規格が発行された時点では, 少
なくともW3CからVersion 1.1 の勧告が発行されている可能性がある。
•
W3Cから出されたXSL Version 1.1のワーキングドラフトの内容を見ると, 全ページの約10％が追加若し
くは修正されている。
•
追加された機能は有用なものが多く, また解説も詳しくなされたものもある。
•
しかしながら, 基準となるW3Cの勧告が定まらないため, Version1.0のTRを見直し, TSとして発行する。
(4) TS化作業手順の提案
かかる観点から, TS化作業として以下の手順を提案する。
•
TS化のため, Version1.0のTRにつきJIS用語, 様式に適合しているかの精査を進める。
•
W3Cから出されているXSL 1.1のワーキングドラフトを基準に修正部分の翻訳作業を進めて, 新バージョ
8
ンへの対応の準備をする。
•
以上の項目を平成17年（2005年）度の作業とする。
(5) XSL_1.1の変更項目一覧
このリストはXSL 1.1の, XSL 1.0から変わった項目を列挙した。全ページの10％程度が追加あるいは見直され
ている。Revは修正項目, Newは新規追加項目を示す。
――――　追　加　項　目　――――
Status of this Document
Rev　約１ページ
5.5.6 Text-decoration Property
New：１段落
5.10.1 Number Functions
Rev：細かな変更
5.10.2 Color Functions
Rev：細かな変更
5.10.3 Font Functions
Rev：１段落書き換え
5.10.4 Property Value Functions
Rev：修正・追加２ページ
5.11 Property Datatypes
Rev：修正・追加項目あり
6.3 Formatting Objects Summary
New：２５項目追加あり
6.4.1.4 Flows and Flow Mapping
New/Rev：追加１項目　修正１項目
6.4.2 fo:root
Rev：追記事項あり
6.4.5 fo:page-sequence
New：２ページほど追加事項あり
6.4.6 fo:page-sequence-wrapper
New：新しい追加項目
6.4.13 fo:simple-page-master
Rev：修正１段落
6.4.14 fo:region-body
Rev：部分修正あり
6.4.22 fo:flow-map
New：新規項目
6.4.23 fo:flow-assignment
New：新規項目
6.4.24 fo:flow-source-list
New：新規項目
6.4.25 fo:flow-name-specifier
New：新規項目
6.4.26 fo:flow-target-list
New：新規項目
6.4.27 fo:region-name-specifier
New：新規項目　以上６項で３ページほど
6.5.3 fo:block-container
Rev/New：修正１段落　新規３段落ほど
6.6.8 fo:inline-container
New：２段落追加
6.6.11 fo:page-number-citation
Rev：１段落修正
6.6.12 fo:page-number-citation-last
New：新規項目
6.6.13 fo:folio-prefix
New：新規項目
6.6.14 fo:folio-suffix
New：新規項目
6.6.15 fo:scaling-value-citation
New：新規項目　以上４項で３ページ強
6.7.3 fo:table
New/Rev：２～３項目追加修正
6.7.4 fo:table-column
Rev：Note項目修正
6.7.6 fo:table-header
Rev：Note項目修正
6.7.7 fo:table-footer
Rev：Note項目修正
6.7.8 fo:table-body
Rev：Note項目修正
6.7.9 fo:table-row
Rev：Note項目修正
6.10 Formatting Objects for Indexing
New：新規追加
6.10.1 Introduction
New：新規項目
6.10.2 fo:index-page-number-prefix
New：新規項目
6.10.3 fo:index-page-number-suffix
New：新規項目
6.10.4 fo:index-range-begin
New：新規項目
6.10.5 fo:index-range-end
New：新規項目
6.10.6 fo:index-key-reference
New：新規項目
6.10.7 fo:index-page-citation-list
New：新規項目
6.10.8 fo:index-page-citation-list-separator
New：新規項目
6.10.9 fo:index-page-citation-range-separator
New：新規項目
6.11 Formatting Objects for Bookmarks
New：新規項目
6.11.1 fo:bookmark-tree
New：新規項目
6.11.2 fo:bookmark
New：新規項目
6.11.3 fo:bookmark-title
New：新規項目　以上21ページほど
6.13.1.1.1 Wrapper
New：新規項目
6.13.1.1.2 Table Markers
New：新規項目
6.13.2 fo:change-bar-begin
New：新規項目
6.13.3 fo:change-bar-end
New：新規項目　以上５ページほど
6.13.4 fo:wrapper
Rev/New：２～３段落　修正・追加
6.13.5 fo:marker
New：２項追加
6.13.7 fo:retrieve-table-marker
New：新規項目　２ページほど
9
7.7.28 border-right-color
New：新規項目
7.7.29 border-right-style
New：新規項目
7.7.30 border-right-width
New：新規項目
7.9.6 hyphenation-push-character-count
Rev：３項修正あり
7.9.7 hyphenation-remain-character-count
Rev：３項修正あり
7.11.1 margin-top
New：新規項目
7.11.2 margin-bottom
New：新規項目
7.11.3 margin-left
New：新規項目
7.11.4 margin-right
New：新規項目　どれも小さな項目
7.12.1 top
New：新規項目
7.12.2 right
New：新規項目
7.12.3 bottom
New：新規項目
7.12.4 left
New：新規項目　どれも小さな項目
7.14.1 allowed-height-scale
New：新規項目
7.14.2 allowed-width-scale
New：新規項目　合わせて１ページ強
7.14.4 content-height
New：２項追加あり
7.14.5 content-width
New：２項追加あり
7.15.2 hyphenation-ladder-count
New：１項追加あり
7.15.8 white-space-treatment
Rev：５項に修正あり
7.16.3 suppress-at-line-break
Rev：１項修正あり
7.16.4 text-decoration
New：３段落追加あり
7.18.1 clear
New：２項追加あり
7.18.2 float
New：２項追加あり
7.20.2 overflow
New：１項追加あり
7.23.1 index-class
New：新規項目
7.23.2 index-key
New：新規項目
7.23.3 page-number-treatment
New：新規項目
7.23.4 merge-ranges-across-index-key-references New：新規項目
7.23.5 merge-sequential-page-numbers
New：新規項目
7.23.6 merge-pages-across-index-key-references
New：新規項目
7.23.7 ref-index-key
New：新規項目　以上３ページほど
7.24.2 retrieve-boundary-within-table
New：新規項目　1/2ページ
7.24.6 retrieve-position-within-table
New：新規項目　1ページ強
7.26.7 initial-page-number
Rev：１項修正あり
7.26.18 flow-map-name
New：新規項目
7.26.19 flow-map-reference
New：新規項目
7.26.20 flow-name-reference
New：新規項目
7.26.21 region-name-reference
New：新規項目　以上で２ページほど
7.27.8 column-number
Rev：１項修正あり
7.27.14 number-rows-spanned
Rev：１項修正あり
7.28.7 writing-mode
Rev：Noteに修正あり
7.29.1 change-bar-class
New：新規項目
7.29.2 change-bar-color
New：新規項目
7.29.3 change-bar-offset
New：新規項目
7.29.4 change-bar-placement
New：新規項目
7.29.5 change-bar-style
New：新規項目
7.29.6 change-bar-width
New：新規項目　以上で４ページ強
7.29.9 intrinsic-scale-value
New：新規項目
7.29.10 page-citation-strategy
New：新規項目　以上で２ページ弱
7.29.11 provisional-label-separation
New：１項追加あり
7.29.12 provisional-distance-between-starts
New：１項追加あり
7.29.14 scale-option
New：新規項目　1/2ページ
(6) その他のW3C勧告
XSLT, XPathについては, 2月までの議論では, W3Cの動向を見るということにした。2月11日にW3Cから次の10
件がすべてWorking Draftとして公表された。
*
*
*
*
*
*
*
*
*
XQuery 1.0: An XML Query Language
XML Path Language (XPath) 2.0
XQuery 1.0 and XPath 2.0 Data Model
XQuery 1.0 and XPath 2.0 Functions and Operators
XSLT 2.0 and XQuery 1.0 Serialization
XQuery 1.0 and XPath 2.0 Formal Semantics
XQuery Update Facility Requirements
XML Query Use Cases
XML Syntax for XQuery 1.0 (XQueryX)
10
* XSL Transformations (XSLT) Version 2.0
2005年中にはCRへのカウントダウンが始まる可能性がある。
11
5.2 WG2
5.2.1 計画
前年度までの「電子出版技術標準化調査研究委員会」の活動の成果を受け，その課題を整
理したうえで，次の計画を立案し活動を行なった。なお，5.2.1.4 項については，当初 WG1
の活動として進められていたが，その一部を e-Publishing/e-Book との絡みもあって本 WG
で担当することになったものである。
5.2.1.1 e-Publishing/e-Book（国際規格提案）
（１）e-Publishing/e-Book の現状
2003 年度は，新しい e-Book 端末の発表やビジネスコンソーシアムの設立提案が相次ぎ，
e-Book 元年と期待されていた。しかし，ケータイ・インフラの利用は活発になってきつつ
あるものの，総体的にはいまだに浮上できない状態が続いている。一方で e-Book 端末とし
て先行していた米国では製造中止が発表され，e-Book の販売も縮小傾向にある年でもあっ
た。
ビューア，電子ペーパー，フォーマット，通信環境等は著しい発達を見せているが，それ
にもかかわらず，大きな推進力が得られない。
一方，広くデジタルドキュメントの状況を観察すると，インターネットやケータイでは日
夜，膨大な量のメールが流通している。また，2004 年は前年より続いていたウェブ日記ブ
ームを素地に blog コンテンツの爆発的は増加をみた年でもあった。さらにこのブームはソ
ーシャルネットワークサービス（SNS）に飛び火した。blog にしても SNS にしても，文字
情報を中心とした情報流通である。
つまり，e-Publishig が従来の出版ビジネスのプレーヤーによって，同じビジネスモデルを
用いて，なおかつ従来の出版産業のほぼ枠内で試みられている間に，その外側において膨
大な量のドキュメントデリバリーが，ほとんど無料で行われていることになる。そして，
この注目すべき領域に対し e-Publishing は，何らビジネスとして手がけられていない状態
である。
この状況を分析すると，
・新たな e-Book のビジネスモデルができていない
・膨大な量のデジタルドキュメント流通を e-Publishing が取り込めていない。
・さらに，コンテンツの生成をビジネス領域に誘導する環境が整っていない。
・電子辞書は成功したモデルであるが，これを e-Book に敷衍できるのか
などの疑問や課題が見えてくる。
（２）課題検討
12
このような視点から紙の本の製作工程を再確認すると，前工程ではかなりデジタル化され
てきたものの，実際には「一部デジタル」である。紙の出版物のフルデジタル移行に大き
なコストがかかる以上，印刷会社にとってフルデジタル処理を前提とした e-Book 制作や，
クライアント（出版社）
・ユーザ（読者）から求められるコストダウンへの対応は困難であ
る。
また読者のデジタル環境を見ると，ケータイなどの機能向上と普及が進む反面，PDA の売
上げは減少傾向にある。機能が限定された読書専用端末がユーザーニーズを掘り起こすの
か，あるいは読書専用端末を前提とした e-Book ビジネスモデルが成立するのか，動向が注
目されることになった。
さらに出版不況や多種類な e-Book ファイル形式，著作権管理システム，出版の既得権益を
守るための出版社の取り組みなど，いくつかの現実が e-Book 市場の離陸を阻害している一
因と思われる。そこで，
・中長期的な展望にたった市場予測
・有効なビジネスモデルとはどのようなものか
・それを実用に供するためのインフラ，とくに標準化に向けた提案
などを多角的に調査・分析していくことが急務であるとの認識を得た。
以上から本年度の中心的課題として，これらの具体的調査研究を行うことで e-Book のある
べき姿を検証し，その Conceptual Model や Generic Format を国際提案していくこととし
た。
（３）検討対象
その検討対象であるが，本委員会の名称は e-Book となっているが，書籍に限定することな
く，文書(マルチメディア)の入出力という技術分野で検討することとした。したがって，既
存の小説，書籍などに固定せず，有望な市場を想定して標準化検討を進めることとした。
また，デジタルカメラの普及により画像へのアクセスが容易になったことが，結果的に送
り手ニーズと受け手ニーズに変化をもたらしたこと，また，ユビキタス環境における情報
アクセスなども念頭において検討することとした。その際，マルチメディア機能すべてを
搭載することが条件ではなく，単機能であってもマルチメディア機能との整合がとれてい
ることを条件とした。
なお，本報告では，電子出版を e-Publishing，電子書籍を e-Book に統一して記述した。
5.2.1.2 DSSSL ライブラリ
TR X 0010:2000 の DSSSL ライブラリの内容に, TR X 0010 追補 1 の規定, および ISO/IEC
TR 19758 関連規定の内容を加えて, TS 原案を作成する。
13
5.2.1.3 原稿校正標準マーク付け言語（SPML）
以前，国際大学 GLOCOM で開発を行った版に対して，さらに検討を加えて，XML 対応版
とし，TS 原案を作成する。
5.2.1.4 PDF サブセット
携帯電話等のモバイル端末のアプリケーションを前提に，ユースケースを作成し，それに
必要な機能項目を明確にして，PDF サブセットの
① 基本プロファイル
② オプションプロファイル
の原案作成を行う。
なお，本活動は委員会 WG1 で PDF サブセット案を検討し，本委員会 WG２は電子ブック
（e-Book）のユースケースでの適用性を考察する。
5.2.2 活動概要
5.2.2.1 e-Publishing/e-Book（国際規格提案）
『平成 15 年度電子出版技術標準化調査研究委員会成果報告書』で e-Book のビジネスモデ
ルについて報告したが，これを受けてさらに Conceptual Model，Generic Format の前提
となるビジネスモデルについて，最新動向の調査，関連白書の分析，コンテンツ流通委員
会の活動に関する報告などを通じて，調査・分析を実施した。
「電子書籍ビジネス調査報告書 2004」(2)では，
「この 1 年間で大きく状況が変わった」と
して，市場規模について次のようにまとめている。
①ケータイが読書端末として大きくクローズアップされてきた。
② ブック，リブリエの登場で，電子ペーパー搭載の読書端末が現実のものになった。
e-Book 販売サイトの売上げの伸び率は 30～380%に達した。
③2003 年の市場規模は，前年比 1.8 倍の約 18 億円に拡大したと推定される。
また，音楽のダウンロード販売市場が米国に続いて日本でも注目化されている。ただし米
国では音楽権利関係が明確となっており，ビジネス展開が容易となっているが，日本では
不明確かつ複雑で展開が困難な状態となっている。
e-Book についても，著作権者と出版社の権利関係が確立していない状態であり，メーカー
や通信インフラにとってもシステム的に展開以前というのが実情である。特に日本の出版
業界の構造としては，小規模出版社－大規模印刷会社という構図があり，大多数の出版社
においての e-Book ファイル形式の標準化は必須と考えられる。
14
（１）e-Book ファイル形式の現状と標準化の必要性
e-Book 市場を成立させる条件として，初期の段階から e-Book ファイル形式の標準化につ
いては，その重要性が指摘されてきた。米国における e-Book リーダは Adobe Reader と
Microsoft Reader の二つであるが，日本では，統一の機運すらないままに今日にいたって
いる。
表５－１
ファイル形式
e-Book ファイル形式
リーダ
ハードウェア
DRM のレベル
PC,PDA
テキスト
PDF
Adobe Reader
PC
△
Adobe eBook
Adobe Reader
PC
◎
ドットブック
T-Time
PC, PDA
○
XMDF
ブンコビューワ
PDA, PC,他
○
ebi.jBook Reader
ebi.jBookReader
PC, Σブック
◎
デジブック
蔵衛門デジブック
PC
◎
Kacis Book
Kacis リーダ
PC
○
シーモア
シーモアリーダ
PDA, PC
◎
Hatch
Hatch ビューワ
Σブック
◎
BBeB Book
LIBRIe
LIBRIe, PC
◎
（
『電子書籍ビジネス調査報告書 2004』をもとに一部修正）
DRM のレベル
：改ざん可能。コピー可。
△：改ざん不可。コピー可
○：改ざん不可。コピー可だが購入データの記録により違法コピーを抑制
◎：改ざん不可。コピー可だが，１台の端末でのみ閲覧できる。
現在，e-Book のファイル形式とそのリーダには表に示すように多くの種類がある。文字系
コンテンツでは，メールなどで配信されているプレーンテキストが一番汎用性が高いが，
著作権保護が困難であり，組版情報や文書構造を持たすことができない。構造化文書とし
ては XML ベースのファイルフォーマットがある。
文書ファイル形式としては Adobe eBook にも対応した PDF が普及しているが，その割に
は e-Book ファイルフォーマットの主流になり得ていない。読者にとって不便である上に，
e-Book の出版社にとっても多用なファイ形式の存在が e-Book の生産性を落としているこ
とは明らかである。
（２）e-Book のダウンロード市場予測
e-Book のダウンロード市場は，右肩上がりではあるが，当面爆発的な拡大は見込めそうに
15
はない。しかしながら，ハード及びソフトの機能向上とともに，徐々に拡大していくもの
と考えられる。
そこで「電子書籍ビジネス調査報告書 2004」における，e-Book をどのような環境で読んで
いるのかという調査結果に基づき，今後の e-Book の利用形態を予測してみた。
「電子書籍ビジネス調査報告書 2004」における「どのような環境で電子書籍を読むか」で
は，下記のような調査結果であった（グラフ上は点線の位置）
パソコン：45.8%
その他：1.1%
PDA：36.6%
携帯電話：12.6%
電子書籍専用端末：2.5%
無回答：1.3%
この利用率から今後の傾向を以下のように予測した。
・パソコンでの利用は，今後も徐々に上昇していくと思われる。これは，パソコン端末
の軽量化，バッテリー駆動時間の長時間化により，ビジネスマンが通常持ち歩いてい
るパソコンで e-Book を閲覧することが多くなると予想できるからである。
・PDA は，パソコンと携帯電話の需要増に伴い，減少していくと思われる。
・携帯電話は，e-Book 機能を搭載した端末が増えていき，利用者もどんどん増えると思
われる。特に各キャリアとも専用のサイトを立ち上げているため，利用者も簡単に利
用できる点が，今後急速に普及すると思えるポイントである。
・2004 年に発売開始された e-Book 専用端末は，読みやすさという点ではかなり紙の本
に近いが，単一目的の端末としては，サイズが大きい，価格が高いなどの点から，普
及はむずかしいのではと思われる。
・2004 年に映像，画像，音楽などを持ち歩いて閲覧できるマルチメディアプレーヤーが
発売されたが，主にパソコンでマルチメディアコンテンツを利用している人たちが，
外出先でも気軽にコンテンツを閲覧するために，これらの端末を利用する人たちが急
増すると思われる。2005 年末ころには，機能として，e-Book の閲覧機能が追加される
のではと予想すると，端末の増加に伴い e-Book の利用者も増加すると予想できる。
以上から，e-Book 専用端末はユーザの利便性を考えると，今後マルチメディアプレーヤー
に機能統合されていくと思われる。現状のような単機能端末で生残り・普及が進むために
は，専用端末としての操作性・コストパフォーマンス等のユーザーメリットで，明確な優
位性を獲得する必要がある。
この傾向を図として表したのが次図である。
16
利用端末比率(%)
50％
PC
40％
PDA
30％
20％
携帯電話
マルチメディアプレーヤー
10％
電子書籍専用端末
0％
2003
2004
2005
2006
2007
図５－１ 現状の e-Book の利用端末と今後の予想
（３）2004 年度に話題となった e-Book プロジェクトの検討
① 週刊ポストのデジタル版
週刊ポスト(公称 50 万部発行)のデジタル版の記事内容を確認した。記事内容に関し，
次の意見があった。
・記事単位の販売（63 円，42 円）は印刷物に対し割高ではないか。
・ビジネスとして成功するかは見通しがたたない。
②
読書用閲覧ソフト「どこでもビューワ」
読書用閲覧ソフト「どこでもビューワ」の記事内容を確認した。記事内容に関し，次
の意見があった。
・携帯用ソフト(XMDF)が市場を大きく獲得するかは不明である。
③ ケータイによる小説の配信モデル
・新潮ケータイ文庫
ケータイ（携帯電話）で連載小説を読むシステムが，まだ規模は小さい（17 億円／03
年度）が広がってきていることを確認した。なお，携帯電話は，当初想定した「通勤
等の移動時」に限らず，ほとんど身に付けていると想定されることを確認した。
④ HDD 付きケータイ
HDD 付きケータイの新聞記事から，今後このようなハードが一般的モバイル端末の形
態となっていくと考えられる。
17
⑤ リブリエ
e-Book 端末として発売された「リブリエ」と e-Book ダウンロードサイト「タイムブ
ックタウン」について，そのビジネスモデルを検討した。
Book
⑥
e-Book 端末として発売された「 Book」と e-Book ダウンロードサイト「eBookJapan」
について，そのビジネスモデルを検討した。
⑦ e-Book に関する予備的アンケート
予備的アンケート(調査人数：37)の結果，概略次の内容が確認されたので，必ずしも正
確なデータとは言えないが，今後の参考データとした。
・e-Book リーダの一般認識はまだ希薄である。
・e-Book リーダは，ほぼ携帯電話と同等の価格帯と考えられている。
・e-Book リーダによる，利用料金（本一冊分）は本の料金の約 30%以下が適当と考え
られている。
5.2.2.2. DSSSL ライブラリ
TR X 0010:2000 の DSSSL ライブラリは日本語組版を前提にしているが，この ISO TR 化
（ISO/IEC TR 19758）に伴い，多言語環境にも対応させることとした。ISO/IEC TR 19758
は，その後，Amendment1～3 が提案され，これらは漢字圏から東南アジアの言語組版の
対応もなされたことから，TR X 0010，同追補 1，ISO/IEC TR 19758 Amd2～3（同 TR Amd1
は，TR X 0010 追補 1 に反映済み）を統合した新しい TS 原案を作成することとした。
なお，ISO/IEC TR 19758 Amd3 は CICC で原案を作成しているため，CICC とのリエゾン
をとった。
5.2.2.3 原稿校正標準マーク付け言語（SPML）
構造化文書の汎用的な校正用マーク付け言語がないこと，e-Book の機能としても重要な位
置付けであることから，国際規格として通用するレベルの校正用マーク付け言語を開発す
る計画を立案した。しかし，すでに SGML 文書校正マーク付け言語の JIS 原案が存在する
ため，これを元に，XML 対応等の修整を施す形でまとめることにした。
この JIS 原案については，1996 年 3 月に，通商産業省工業技術院（当時）が国際大学グロ
ーバルコミュニケーションセンター（GLOCOM）に対して委託し，これを受けて同センタ
ーが「SGML 文書校正マーク付け言語の提案型国際規格作成調査研究委員会」を設立して
1996 年 4 月から研究を行い，その結果を 1997 年 3 月に委託元に提出したものである。
この原案は，その後 JIS 化される機会がないままになっていたが，これに代わる有用な汎
用電子文書校正用言語が開発されることもなく，また，この WG で検討する eBook の
18
Conceptual Model の校正工程には必須と考えられたため，これをベースとすることにした
のである。
ただし，この原案は SGML 対応であったため，その DTD を XML 対応に変更する。
また，国際提案を志向するため，用語（とくに要素名）についても検討を加える。
5.2.2.4 PDF サブセット
本委員会 WG１で PDF サブセットとして，PDF/Mobile-mini，-mid，-full の機能一覧案を
以下の機能別に作成した。
① PDF/Mobile-mini（最小セット）は，表示として，多値/2 値画像のみをサポート
作成及び表示ソフトの容易性を追求
② PDF/Mobile-mid（中間セット）は，応用として，文字データでの利用が多いと考え
てフォントをサポートし，検索性を考慮してメタデータ機能を追加
③ PDF/Mobile-full（フルセット）は，表示として，グラフィック機能，アクセシビリ
ティへの応用を考慮した文書構造（タグ付 PDF）
，文書保護のために，デジタル署名，
暗号化等のセキュリティ機能を追加
本委員会 WG2 では，この機能一覧をベースに e-Book での妥当性を検証するユースケース
の検討を行った。
なお，上記機能一覧案に関しては，附録資料Ａ４.３を参照のこと。
5.2.3 成果
5.2.3.1 e-Publishing/e-Book（国際規格提案）
（１）現状におけるデジタルコンテンツ販売のビジネスモデル
要素Ａ(構成内容)，要素Ｂ(費用負担)に分けて検討した。
要素Ａ(構成内容)では，
①タイプＡ１:コンテンツ販売モデル
e-Book 販売サイトにおけるコンテンツダウンロード販売。電子辞書にみるパッケージ
販売。
②タイプＡ２：サービスベンダーモデル
デジタルコンテンツにサービスを統合する。ｅラーニングにおけるデジタル教材販売
がその例である。
③タイプＡ３：統合システムベンダーモデル
デジタルコンテンツとサービスを統合システムとして提供する。iTMS(iPod)などがそ
の例である。
要素Ｂ(費用負担)では，
19
①タイプＢ１：ユーザ負担
通常のコンテンツ販売のように，対価をユーザから回収するモデルである。
②タイプＢ２：広告主負担
民間放送，雑誌におけるフリーペーパーなど広告収入に依存するモデルである。
③タイプＢ３：ユーザ＋広告モデル
Ｂ１とＢ２の中間モデル。
以上からもわかるように，書籍はタイプＡ１でありＢ１ユーザ負担モデルである。雑誌の
多くはＢ３モデルである。
（２）e-Publishing の定義と e-Book
e-Publishing は，これまでの活動からは「文字・画像情報をデジタルデータに編集加工し
て，CD-ROM などの電子メディアやネットワークにより配布する出版活動」と定義されて
いる。これは「電子編集」
，
「CD-ROM などによるパッケージ系の e-Publishing」
，
「ネット
ワーク出版」という三つのカテゴリーに分け，既存の出版を基礎においている。
日本では電子出版物を狭義にとらえた場合，コンテンツの種類としては小説やエッセイな
どの読み物，マンガ，写真集などの書籍を指している。また CD-ROM によってある程度の
市場を確立した辞書，辞典などのリファレンス系電子出版物や電子辞書を含むこともある。
また，書籍をデジタル化したデータベースから，読者の要望によりオンデマンド印刷して
販売するオンデマンド出版も「電子編集制作」の概念に含むことができる。ただし，今日
では DTP やオンデマンド出版などは，情報技術による出版革命の独立した分野としてとら
え，
「オンライン書店」同様，e-Publishing には分類しないのが通例である。
なお電子出版物のうち，ネット販売されているデジタルコンテンツのダウンロード販売が
「e-Book」とか，しばしば「電子書籍」
，
「ｅブック」と呼ばれている。
『電子書籍ビジネス
調査報告書 2004』では，限定的に「電子書籍のダンロード販売」を取り上げている。
前述の定義では e-Publishing を「出版活動」の概念を借りて定義しており，説明の対象を
説明の前提とした同義反復ともいえる。出版という枠組みを外してメディア産業という側
面から「デジタルコンテンツのネットワークによる配信」とすれば，それは何も出版の専
売特許ではない。同じようなことを新聞社が行えば，
「電子新聞」であり，放送局ならば「イ
ンターネット放送」である。それぞれ文字と音声と画像を統合したマルチメディアを目指
した「デジタルコンテンツ産業」となる。
また『デジタルコンテンツ白書』ではデジタルコンテンツを映像系（DVD など），音楽系
（ディスク，着うたなど）
，ゲーム系（CD-ROM やオンラインゲームなど）
，出版・情報系
（リファレンス，学校教材）に分類している。かつてアナログメディアとしてそれぞれ独
立していたものが，デジタルメディアとして融合しつつあることがうかがえる。
e-Publishing が対象とする分野は，すでにアナログの概念における出版領域に限定できな
いことがわかる。
20
CD-ROM がニューメディア，マルチメディアブームを実現するメディアとして話題の中心
であった時代は，e-Publishing を出版の枠にとどめることができた。CD-ROM はパッケー
ジ商品であり従来の出版流通の中で取り扱われている。もちろん再販商品ではないことか
ら値引き販売が問われることもあるが，大きく流通を含む出版システムや商慣習を変える
ことはなかった。
しかし，ネットワークとデジタルコンテンツは出版・印刷や電子機器メーカーを含む製造
業だけでなく，流通，通信などのすべての産業にとって未体験の新市場に思えた。結果的
に多様な業種が参入し，新たなコンテンツ産業を形成した。この結果，従来の出版システ
ムでは対応できない面において，徐々に出版の領域を広げていくことになった。
e-Book がマルチメディアコンテンツまで含むデジタルデータと定義すると，既存のメディ
ア領域を超えた存在となる。つまり，デジタルコンテンツを従来のメディア区分である出
版，新聞，放送に当てはめた e-Publishing（電子出版）
，電子新聞，インターネット放送と
いったコンテンツ区分は存在し得ないことになる。
しかし，それでもなおビジネスの区分として存在し得るのは，新しいコンテンツメディア
がユーザの利用習慣に依存するからである。書籍の読書習慣の延長でデジタルコンテンツ
を利用すると e-Book としてみなされることになる。あるいはコンテンツプロバイダーが出
版社であったり，紙の出版流通モデルを模倣するなども考えられる。
（３）TC100 での議論
昨年度の TC100/AGS 会議
（2003 年 11 月）
に, EP/WG2 での検討に基づいて, 100/AGS/114,
Overview of e-publishing and e-books and their requirements for international
standardization が提出され, E-publishing and E-Books が IEC/TC100 の標準化課題とし
て認識された。
その議論を受けて今年度には, まず 5 月の TC100/AGS 会議で 2 件の寄書
・100/AGS/139, Multimedia e-publishing and e-books - Conceptual model for multimedia
e-publishing
・ 100/AGS/151, Conceptual model for multimedia e-publishing
が EB/WG2 および JEITA の AVIS での検討に基づいて, 提出・議論され,
・ conceptual model for multimedia e-publishing standardization
・ interchange/distribution formats for e-publishing.
に関する新作業課題提案(NP)をすることが行動計画として承認された。
この決定に基づき, 日本から次の NP が提出された。
（４）作業課題提案の提出
以上の結果を踏まえ，100/864/NP, Multimedia systems and equipment - Multimedia
e-publishing and e-books - Conceptual model for multimedia e-publishing(附属資料 A.4.1
21
参照)を提出した。
これは, 2005 年 1 月 14 日を期限とする NP 投票を受け, プロジェクトが承認された。この
NP に お い て , Author, Data preparer, Publisher, Reader か ら 成 る Content
creation/distribution model が提案され, それぞれの間の情報交換に用いる
・ Submission format
・ Generic format
・ Reader's format
の標準化の必要が示されている。Submission format においては, SPML の必要性が示され
ている（5.2.3.3 項を参照）
。SPML の素案を附属資料 A.4.4 に示す。
10 月の TC100/AGS 会議では, 寄書 100/AGS/162, E-publishing and E-books - Generic
format for e-publishing が EB/WG2 および JEITA の AVIS での検討に基づいて, 提出・議
論され, XML と名前空間とに基づくこの内容を NP(附属資料 A.4.2 参照)として提出するこ
とが求められた。
EB/WG2 では, これらの NP(附属資料 A.4.1，A.4.2)の原案を作成している。
5.2.3.2 DSSSL ライブラリ
（１）DocSII における DSSSL Library 検討
DocSII メンバに対して, 次の ISO 投票文書が配布され, コメントが求められた。
・ DAM1 to ISO/IEC TR 19758 (JTC1 N7441, N7441cov, Due date 2004-08-18)
・ DAM2 to ISO/IEC TR 19758 (JTC1 N7442, N7442cov, Due date 2004-08-18)
・ PDAM3 to ISO/IEC TR 19758 (SC34 N515, N515bal, Due date 2004-07-26)
コメントは, Bangladesh, Mongolia, Myanmar, Singapore, Thailand の各国から寄せられ,
さらに 2004 年 10 月の DocSII Symposium において関連する議論が展開された。
（２）ISO/IEC JTC1/SC34 での審議
2004 年 4 月の SC34 meeting において, 次の決定を行った。
・ WG は, WG2 N160 および WG2 N161 を, それぞれ ISO/IEC TR 19758/PDAM1 のコメ
ント対処および ISO/IEC TR 19758/Amd.1 の DAM テキストとして受理し, DAM テキ
ストを DAM 処理のために SC34 セクレタリアートに送付する。
・ WG2 は, WG2 N162 および WG2 N163 を, それぞれ ISO/IEC TR 19758/PDAM2 のコ
メント対処および ISO/IEC TR 19758/Amd.2 の DAM テキストとして受理し, DAM テ
キストを DAM 処理のために SC34 セクレタリアートに送付する。
・ WG2 は, WG2 N164 を, ISO/IEC TR 19758/Amd.3 の PDAM テキストとして受理し,
22
PDAM テキストを PDAM 処理のために SC34 セクレタリアートに送付する。
さらに, 2004 年 11 月の SC34 meeting において, 次の決定を行っている。
・ WG2 は, WG2 N187 および WG2 N188 を, それぞれ ISO/IEC TR 19758/DAM1 のコメ
ント対処および ISO/IEC TR 19758/Amd.1 の最終テキストとして受理し, 最終テキスト
を ITTF による出版のために SC34 セクレタリアートに送付する。
・ WG2 は, WG2 N189 および WG2 N190 を, それぞれ ISO/IEC TR 19758/DAM2 のコメ
ント対処および ISO/IEC TR 19758/Amd.2 の最終テキストとして受理し, 最終テキスト
を ITTF による出版のために SC34 セクレタリアートに送付する。
・ WG2 は, WG2 N191 および WG2 N192 を, それぞれ ISO/IEC 19758/PDAM3 のコメン
ト対処および ISO/IEC 19758/Amd.3 の DAM テキストとして受理し, DAM テキストを
JTC1 の DAM 処理のために SC34 セクレタリアートに送付する。
この会議では, DocSII メンバから寄せられたコメントに対して, Response 文書(WG2
N202)が作成された。会議の後, 上記最終文書(ISO/IEC TR 19758/Amd.1, ISO/IEC TR
19758/Amd.2, ISO/IEC 19758/DAM3, それぞれ附属資料 A.5.1, A.5.2, A.5.3)は, いずれも
ITTF に送付された。DocSII で議論されてきたレンダリング処理系の実装上のガイドライン
は, そのままではスタイル指定言語またはスタイル指定言語ライブラリとのスコープの区
別を設定しにくいため, 視点を変えて, 新作業課題 SC34 N578(Minimum requirements for
specifying document rendering systems)として提案されて, NP 投票に入った。この NP 投
票は 2 月 16 日に締め切られ, 規定数の participation を得てプロジェクトが成立した。
（３）TS 原案の作成
TR X 0010:2000 の DSSSL ライブラリの内容に, TR X 0010 追補 1 の規定, および ISO/IEC
TR 19758 の Amd1～3 の原案内容を加えて, TS 原案を作成した。
TR X 0010 からの主な追加・変更点は以下の通りである。
・ 名称の変更（DSSSL Library for Complex Compositions）
・ TR→TS
・ “引用規格”に ISO/IEC TR19758 を追記
・ “定義”に，
「区分セル」
，
「罫（けい）巻き」，
「ドロップキャップ」
，「行取り」を追加
・ “標準組体裁”に備考追記（とくに，結合音節文字体系の組版指定において，それらの
文字が上下に子音・母音・記号等が複数結合することが多いため，日本語組版等の指定
値とは異なる値をとることが多いのでコメントした）
・ “行間注”の備考に追記した
・ “行間注”の図を再描画した（プリントしたときにゴーストが出るため―原因不明―）
・ “圏点”の親文字に対する配置機能を拡大した
・ “順序付き章”に備考を追記した（南アジア系組版に多く見られる事例を付け加えた）
23
・ “段落字下げ体裁指定”に“段落字下げ 2 字下げ”を追加し，三者択一とした（中国／
台湾の基本体裁を加えた）
・ “スコア”で，とくにタイ語組版においてみられる罫（けい）線が文字にかかった場合
の中断の「する／しない」選択特性を備考に追記した
・ “表”を追加した（追補１で追加したもの）
・ “罫（けい）巻き”を追加した（日本でも一般に使われるが，とくに他のアジア系組版
で多用される）
・ “ドロップキャップ”を追加した（アジア系組版で多用される）
・ “行取り”を追加した（コンテントドリブン方式を採用する組版において，異なった組
体裁を混在させる場合に必須の機能であるため）
・ “強調のための文字間”を追加した
・ “第 1 段落の識別”を追加した
・ その他，若干の用語統一を行なった
そのテキスト部分を附属資料 A.1.5 に示す。
5.2.3.3 原稿校正標準マーク付け言語（SPML）
当初の計画では TS 原案を作成することを目標においたが，その後の事前審査において「TS
になじまない」との結論が出たため，TS 化を断念した。しかし前記(1)項の活動の中で，
Conceptual Model の中に
「校正も必要である」
との TC100/AGS メンバからの指摘もあり，
国際提案していくことになった。
GLOCOM 原案に対しては，DTD を XML 対応に変更した。
そのテキスト部分を附属資料 A.4.4 に示す。
5.2.3.4 PDF サブセット
本委員会 WG2 では，WG1 で検討された PDF/Mobile の-mini，-mid，-full の３つの機能
一覧(附属資料 A.4.3)に対して，電子ブック（e-Book）及び PDF のユースケース検討のた
めのスケッチを行った。
電子ブックのユースケースのためのスケッチ
本を探す
リストを探す(開ける)
選択する(キーワード入力)
本を買う(支払い)
24
登録する
支払い手続き
取り込む
ダウンロードする
保存する
本を読む
(本を開く)
途中で中断する
しおりを入れる
閉じる
蔵書に保存する
場所を決める
保管する
印刷する
プリンタと接続する(選択する)
サイズを選ぶ
選択する
印刷する
PDF のユースケースのためのスケッチ
本を開く
電源を入れる
本を選択する
頭出しをする
普通は自動でいく
目次，索引などに飛ぶ(新たな画面を表示する)多画面連携
目次，索引などを選択する
別の所に飛ぶ
元に戻る(元の画面を出す)
スクロール，ページめくり
ページ概念
文字サイズ変更
文字サイズを拡大・縮小する
(書体を変える)
レイアウト変更
紙面幅を変える
25
PDF を利用するハードウェアによる考慮
画面サイズ
解像度
カラー
アスペクト比
PDF を利用するコンテンツ(本)
タイトル
目次
見出し
本文
テキスト
イメージ
図表
柱
注釈
その他
検索(キーワード)
音声出力
PDF を利用するコンテンツ(報告書)
検索キーワード
全文
書誌的事項
本文(本と同じ)
注釈
次に，委員会 WG１で検討してきた３つのサブセットへの対応付けを行った。
PDF/M-mini PDF/M-mid.
一般機能
PDF/M-full
頭出し
－
－
－
目次連携
－
－
○
索引連携
－
－
○
元に戻る
－
－
－
スクロール
－
－
－
26
ページめくり
○
○
○
拡大/縮小
－
－
－
書体変更
－
－
－
紙面幅変更
－
－
－
画面サイズ
N/A
N/A
N/A
解像度
N/A
N/A
N/A
カラー
N/A
N/A
N/A
アスペクト比
N/A
N/A
N/A
タイトル
○
○
○
目次
－
○
○
見出し
－
○
○
テキスト
－
○
○
イメージ
○
○
○
図表
－
－
○
柱
○
○
○
注釈
－
○
○
－
○
○
音声出力
－
－
○
キーワード
－
○
○
全文
－
○
○
書誌的事項
○
○
○
テキスト
－
○
○
イメージ
○
○
○
図表
－
－
○
－
○
○
文字サイズ変更
レイアウト変換
ハード
本
本文
その他
検索（キーワ
ード）
報告書
検索
本文
注釈
5.2.4 今後の課題
（１）e-Publishing/e-Book
（ａ）e-Book の再定義
このような観点から，極めて限定的に紙の本のメタフォーに基づいて e-Book を再定義する
と，
①ハードとソフトが分離している書籍データ。したがって電子辞書は含まれない。
27
②冊子体を前提としたデジタルコンテンツ。読者にページめくりを意識させることがで
きるもの。テキスト，写真，動画，音声など含む。スクロールだけの書籍データは e-Book
とは呼ばない。
また e-Book をマルチメディアコンテンツとして技術的な可能性から拡大してとらえると，
①e-Book：文字，図形，静止画，動画，音声を編集したデジタル商品
②e-Publishing：e-Book（上記定義）を提供する出版活動
となる。
2003 年から 2004 年にかけて，e-Book 端末が相次いで発売されたが，それから１年たった
時点で評価すると，かならずしも成功したとは言えない。ビジネスとしてブレークするに
は至っていないのである。発売された２種類の e-Book 端末は，価格はほぼ同程度ではある
ものの，データの持ち方から課金の考え方に至るまで，まったく異なったモデルである。
この両方とも，まだ完全に浮上していない理由は，流通を含めたビジネスモデルが完成し
ていないからとも考えられる。
（ｂ）e-Book のビジネスモデル
ビジネスモデルについては，次のような議論があった。
e-Book 市場が拡大するには，電子化による他にはない独自の特徴が認知される必要があり，
単に紙の代替という発想はありえない。e-Book の特徴を発揮するためには，端末機能及び
コンテンツの内容の双方が組み合わされて成立するものであるが，さらに試行錯誤が続く
と考えられる。恐らく，その e-Book の概念はまったく新規のものと考えられるが，その発
想は従来システム（紙，情報システム，等）を十分検討し尽くした中からでてくると思わ
れる。
e-Book とは，ユビキタス社会の情報提供方法を示しているのではないか。さらに e-Book
の「キー」は，大容量(情報)対応機能「自分のバーチャルな書斎」ではないか（電子辞書は，
自分に必要な情報を検索する機能を提供して成功している）
。e-Book は，主に出版業界が模
索しているが，紙の本は紙の本として生き残っていく。むしろ e-Book はケータイを初めと
する情報端末として機能が追求されていくのではないだろうか。
そこで，
・e-Book で要求されるコンテンツを基本的に考える，又は考え直す必要がある。
・印刷物としての「本」から脱却した新規サービス形態を考える必要がある。
とした。
（ｃ）国際標準化の推進
e-Book は，ともすれば日本語組版や表現の特殊性を強調するあまり，国内だけの議論にな
りがちである。しかし，デジタルコンテンツの販売サイトとして期待されるオンライン書
店は，国境を越えたグローバルなビジネスとなっている。また文書ファイル形式や e-Book
28
端末の技術開発も国内にとどまることはない。
利用者のニーズを掘り起こしながら，公正な競争を促し，市場を拡大するためにもより一
層の国際標準化を推し進める必要がある。
（２）DSSSL ライブラリ
本年度の活動の結果，多言語環境における基本的な組版指定ライブラリは，ほぼ整ったも
のと思われる。今後は，さらに利用しやすい環境をつくることに重点を移すべきであろう。
とくに多言語組版においては，国際情報化協力センター（CICC）の「アジア多言語文書情
報交換技術委員会」
，DocSII（Asian Document Style Information Interchange）などとの
リエゾンをとりつつ，ライブラリを増やしていくことが求められる。
（３）原稿校正標準マーク付け言語（SPML）
本年度の活動においては，SGML 用に設計された GLOCOM 原案の DTD を XML 対応に変
更することを行っただけで終わった。
しかし「成果」にも記したように，これを国際提案する方向で検討しており，また，IEC
TC100 からも具体的提案を求められている。したがって，この提案にあたっては，eBook
の Conceptual Model との整合性をとった上で，内容の再評価を実施することが必要である。
DTD の要素名についても国際化を前提に見直すことが要求される。
いずれにしても，従来ほとんど手が付けられていなかった，校正作業環境の電子化を実現
するための言語モデルとしては有効性が高いと思われ，引き続き活動を行っていく必要が
ある。
（４）PDF サブセット
PDF を標準的なフォーマットとして用いる動きは高まってきている。PDF 自体は高機能
化に対応するために PDF1.6 にバージョンアップされたが，一方で特定の使い方に対応す
るためと、長期の安定利用のためにいくつかのサブセットについて標準化が行われた。印
刷ワークフロー標準化のため PDF/X が国際標準化され，長期保存性の確保のため PDF/A，
さらに技術文書の流通性を確保のため PDF/E の国際標準化が検討されている。
本委員会 WG2 も，PDF を電子ブックビジネスワークフローの一部であるリーダーズフォ
ーマットの有力な候補として検討を進めてきた。今後普及が本格化すると予想されるユビ
キタス環境での利用を考慮し、携帯を含む電子ブック機器端末をターゲットに，電子ブッ
クコンテンツの機器互換性確保等の実現ために PDF サブセットの国際標準化を進めていき
たいと考えている。
29
本年度電子ブックのレンダリング処理系として 3 つのレベルの PDF サブセットの提案を行
った。携帯電話にも使える軽い実装が可能なものということで，出来るだけ軽く実用的な
ものを目指した。今年度はその 3 つのレベルのサブセットの提案とユーザ要求をまとめた
が，今後それぞれのサブセットについてユースケースを用いて検証をしつつ，より実用性
の高いものにすることが期待される。
5.2.5 参考文献
(1)『平成 15 年度電子出版技術標準化調査研究委員会成果報告書』
（（財）
）日本規格協会
(2)『電子書籍ビジネス調査報告書 2004』インプレス
(3)『デジタルコンテンツ白書』
(4)「朝日新聞」2004 年 12 月 1 日号朝刊，『若者は「ケータイ」読書』
(5) 鈴木雄介『eBook 時代はじまる！』中経出版， 2004 年
(6)横山三四郎『ブック革命－電子書籍が紙の本を超える日』日経 BP 社，2003 年
30
6. 今後の課題
5.に示す各作業グループの今後の課題を, 次に整理して示す。
6.1.1 e-Book/e-Publishingの国際標準化
JEITAとリエゾンをとり, 今年度にIEC/TC100においてプロジェクトを成立させた課題
•
(1) Conceptual model for multimedia e-publishing
に加えて, 次の課題もNPとしてIEC/TC100に提案し, e-Book/e-Publishingの公正な競争と市場の拡大とに貢献
する。
•
(2) Generic format
•
(3) Submission format
•
(4) Reader's format
今年度に検討したSPMLおよびPDF subsetは, それぞれ(3), (4)の中の要素技術として提案する。これらの提案
を支援するe-Bookの定義とビジネスモデルについての調査研究も必要である。
6.1.2 DSSSLライブラリの国際提案フォロー
CICCとリエゾンをとり, DSSSLライブラリISO/IEC TR 19758の拡張として3件のAmendmentsを検討し, JTC1/SC34
に提案してきた。SC34におけるAmd.3の作業は2005年も継続し, それらの検討の中で生まれた新課題"Minimum
requirements for specifying document rendering systems"のSC34プロジェクトは2005年から活動を開始す
る。
これらの国際の活動をレビューし, 必要に応じてコメント/議論をSC34に投げかけることが望まれよう。
6.1.3 XSL, XSLT等のJIS化検討
最近特に利用者の増えている次のW3C勧告(いずれもTRとして公表済み)のJIS化を行うことが望ましい。ただし
5.1.7に示したとおり, W3Cでの改版の進捗を考慮する必要があり, JIS化に至る途中の公表手段としてTSの作
成も考慮する必要がある。
•
(1) XSL
•
(2) XSLT
•
(3) XPath
6.1.4 MIMEのJIS化
今年度のMIME1, 3, 5のTS化によって, MIMEの各パートがTS化された。これらをまとめてJISとして制定するこ
とが望ましい。
6.1.5 その他の2004年度成果のフォロー
2004年度成果である縦組文書における数字表記方法およびXSLTライブラリは, XML文書のレンダリングに際し
て必要とされる技術である。これらを2004年度報告書だけに止めることはせず, なるべく多くの利用者に提供
していく方策を検討する。
31
[附属資料－Ａ．１．１]
多目的インターネットメール拡張（MIME）－第４部：登録手続き
標準仕様書(TS) TS X 0106:2005
多目的インターネットメール拡張(MIME)－
第4部: 登録手続
まえがき
この標準仕様書は，工業標準化法に基づいて，日本工業標準調査会の審議を経て，経済産業大臣が公表した
標準仕様書(TS)である。
この標準仕様書(TS)の一部が，技術的性質をもつ特許権，出願公開後の特許出願，実用新案権又は出願公開
後の実用新案登録出願に抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査
会は，このような技術的性質をもつ特許権，出願公開後の特許出願，実用新案権又は出願公開後の実用新案
登録出願にかかわる確認について，責任はもたない。
原規定の状態
原規定(RFC 2048)は，インターネットコミュニティのためのインターネットの最善の現行(Internet Best
Current Practice)を規定するものであって，改善のための議論及び助言を要求する。原規定の配布には制限
はない。
著作権
原規定(RFC 2048)に関する著作権は，The Internet Societyに帰属する。
この標準仕様書(TS)には， 次に示す附属書及び解説がある。解説は，原規定には含まれていない。
z
z
附属書1(参考) 原規定の著者の連絡先
附属書A. 既得メディア型
1
目 次
序文
1. 導入
1.1 適用範囲
1.2 概要
2. メディア型の登録
2.1 登録木及び下位型名
2.1.1 IETF 木
2.1.2 ベンダ木
2.1.3 私的(又は私用の)木
2.1.4 特別な'x.'木
2.1.5 追加の登録木
2.2 登録の要件
2.2.1 機能に関する要件
2.2.2 名前付けに関する要件
2.2.3 パラメタに関する要件
2.2.4 正準化及びフォーマットに関する要件
2.2.5 交換に関する要件
2.2.6 セキュリティに関する要件
2.2.7 使用及び実装に関する非要件
2.2.8 公表に関する要件
2.2.9 追加の情報
2.3 登録手続
2.3.1 審査のためのメディア型のコミュニティへの提示
2.3.2 IESG による承認
2.1.3 IANA への登録
2.4 メディア型登録へのコメント
2.5 登録済みメディア型一覧の所在
2.6 メディア型登録のための IANA 手続
2.7 変更の制御
2.8 登録テンプレート
3. 外部本体アクセス型
3.1 登録の要件
3.1.1 名前付けに関する要件
3.1.2 機構の仕様に関する要件
3.1.3 公表に関する要件
3.1.4 セキュリティに関する要件
3.2 登録手続
3.2.1 アクセス型のコミュニティへの提示
3.2.2 アクセス型審査者
3.2.3 IANA への登録
3.3 登録済みアクセス型一覧の所在
3.4 アクセス型登録のための IANA 手続
4. 転送符号化
2
4.1 転送符号化の要件
4.1.1 名前付けに関する要件
4.1.2 アルゴリズム仕様に関する要件
4.1.3 入力領域に関する要件
4.1.4 出力範囲に関する要件
4.1.5 データ完全性及び一般性に関する要件
4.1.6 新機能に関する要件
4.2 転送符号化定義手続
4.3 転送符号化登録のための IANA 手続
4.4 登録済み転送符号化一覧の所在
5. 附属書 1(参考) 原規定の著者の連絡先
附属書 A. 既得メディア型
解説
3
標準仕様書(TS)
TS X 0106:2005
多目的インターネットメール拡張(MIME)－
第4部: 登録手続
Multipurpose Internet Mail Extensions (MIME) —
Part 4: Registration Procedures
序文
この標準仕様書(TS)は，1996年11月にInternat Engineering Task Force (IETF)から公表されたRFC 2048
"Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedure"を翻訳し，技術的
内容を変更することなく作成した標準仕様書(TS)である。
1. 導入
1.1 適用範囲
インターネット公式プロトコル規定STD 11であるRFC 822では，US-ASCIIメッセージヘッダについて多くの詳
細を規定したメッセージ表現プロトコルを定義しているが，メッセージ内容，すなわちメッセージ本体につ
いては，構造のないUS-ASCIIテキストだけとしている。この標準仕様書(TS)を含む一連の標準情報(TR)及び
標準仕様書(TS)は，多目的インターネットメール拡張又はMIMEと総称され，次のことを可能とするために，
メッセージのフォーマットを再定義する。
a)
b)
c)
d)
US-ASCII以外の文字集合でのテキストのメッセージ本体
非テキストのメッセージ本体のための異なるフォーマットの拡張集合
マルチパートメッセージ本体
US-ASCII以外の文字集合でのテキストのヘッダ情報
MIMEを規定する一連の標準情報(TR)及び標準仕様書(TS)は，RFC 934，STD 11及びRFC 1049に文書化されてい
る初期の成果に基づくが，それらを拡張及び改訂する。RFC 822では，メッセージ本体についてはごくわずか
に示しているだけなので，これらの標準情報(TR)及び標準仕様書(TS)の大部分は，RFC 822を改訂するという
より，RFC 822を補う。
この標準仕様書(TS)は，MIMEを規定する一連の標準情報(TR)及び標準仕様書(TS)の4番目であり，次の三つの
MIME機能のための幾つかのIANA登録手続について規定する。
a) メディア型
b) 外部本体アクセス型
c) 内容転送符号化
MIMEにおいて使われる文字集合の登録は，別に規定され，この規定では言及されない。
MIMEを規定する一連の標準情報(TR)及び標準仕様書(TS)は，RFC 1521, RFC 1522及びRFC 1590の改訂であっ
て，RFC 1521, RFC 1522及びRFC 1590は，RFC 1341及びRFC 1342の改訂であった。RFC 2049を原規定とする
標準仕様書(TS)(1)の附属書に，過去の版との違い及び変更を示す。
注(1) この標準仕様書(TS)と同時期に公表される。
1.2 概要
最近のインターネットのプロトコルは，ある領域については簡単に拡張できるように注意深く設計されてい
る。特に，MIME(TR X 0069)は拡張可能な枠組みであり，基本的なプロトコルを一切変更することなく，追加
のオブジェクトの型，文字集合及びアクセス方法を収容することができる。しかし，これらの値の組が，順
序良く，適正に，公開された方法で開発されることを保証するために，登録手続が必要である。
4
この規定は，これらの値の中央登録簿としてのInternet Assigned Numbers Authority (IANA)を使う登録手
続を規定する。
備考 メディア型の登録処理は，最初は，非同期インターネットメール環境の文脈で定義された。このメー
ル環境では，遠隔メールシステムの能力がわからないときにも相互運用の可能性を高めるために，多くの可
能なメディア型を制限する必要がある。メディア型は新しい環境で使用されるので，メディア型の急増は相
互運用性の障害とはならない。初期の手続は過度に制限的であったので，一般化されなければならなかっ
た。
2. メディア型の登録
新しいメディア型の登録は，登録提案の作成から始まる。登録は，以降に示す異なる要件をもつ多くの異な
る登録木において行われる。一般に，新しい登録提案は，関連する木に適した方法で，回覧及び審査され
る。提案が受け入れられると，メディア型が登録される。それぞれの異なる登録木で使用される要件及び手
続を次に示す。
2.1 登録木及び下位型名
登録手続の効率及び柔軟性を向上するため，異なる自然な要求を入れるように，下位型名のさまざのな構造
を登録してよい。例えば，インターネットコミュニティによって広いサポート及び実装が推奨される下位
型，又は専有のソフトウェアに関連するファイルを動かすのに使われる下位型などである。ファセットの名
前(例えば"tree.subtree...type"の形式の名前)の使用によって区別される登録"木"を次に定義する。この標
準仕様書(TS)に先立って定義された幾つかのメディア型は，次の名前付け規約には適合しないことに注意す
ること。これらの内容については附属書A.を参照すること。
2.1.1 IETF木
IETF木は，インターネットコミュニティに一般の興味がある型を想定した木とする。
IETF木における登録では，IESGの承認及びRFCの形式でのメディア型登録の公表を要求する。
IETF木に含まれるメディア型は，通常明示的にはファセットを含まない名前で表される。すなわち，ピリオ
ド("."，フルストップ)文字を含まない。
IETF木におけるメディア型登録の"所有者"は, IETF自体であることを想定する。この規定の変更又は入替え
は，はじめに登録するのに要求されるのと同レベルの処理を要求する(例えば，標準化手続)。
2.1.2 ベンダ木
ベンダ木は，商用の製品に関連したメディア型のために使用される。 "ベンダ"又は"製造者"は同じ意味に解
釈され，この文脈ではきわめて広範である。
特定の製品に関連してファイルを交換する必要がある人ならだれでも，ベンダ木の中に登録してよい。しか
し，登録は，公式には，ソフトウェア又はファイルフォーマットを製造したベンダ又は組織に所属してい
る。仕様の変更は，後述するように，そのベンダ又は組織の要求でなされる。
ベンダ木の登録は，"vnd."で始まるファセットによって区別される。その後に，登録の裁量によって，よく
知られた製造者からのメディア型名(例えば"vnd.mudpie")がきてよく, メディア型又は製品指定(例:
vnd.bigcompany.funnypictures)が後続する, IANAが承認した製造者名の指定がきてもよい。
ベンダ木に登録するメディア型の公開及び審査は要求されないが，審査のためにietf-type一覧を用いること
が，これらの仕様の品質を改善するために，強く推奨される。ベンダ木における登録は，IANAに直接提案し
てよい。
2.1.3 私的(又は私用の)木
実験的に作られたメディア型の登録又は商業的に配布されない製品の部分としてのメディア型の登録は，私
的(又は私用の)木に登録してよい。登録は，"prs."で始まるファセットによって区別される。
"私的の"登録及び関連する仕様の所有者は，登録を行う人若しくは実体，又は次に示すとおり責任を委譲さ
5
れた者とする。
私的木に登録するメディア型の公開及び審査は要求されないが，審査のためにietf-type一覧を用いること
が，これらの仕様の品質を改善するために，強く推奨される。私的木における登録は，IANAに直接提案して
よい。
2.1.4 特別な'x.'木
この登録方式のもつ利便性及び対称性のため，最初のファセットとして"x."をもつメディア型名は，"x-"で
始まる名前が通常使われるのと同じ目的で，使われてよい。これらの型は登録されない実験的なものであっ
て，それらを交換する集団の積極的な合意だけで使用されるほうがよい。
しかし，上に述べたベンダ木及び私的木のための簡易登録手続で，まれに未登録の実験の型を使用すること
が必要であり，"x-"及び"x."の両方を型をこのように使わないほうがよい。
2.1.5 追加の登録木
時々のコミュニティの要求に応じて，IANAは，IESGの勧告及び承諾をもって，新しい最上位登録木を作って
よい。 これらの木は, それが扱う科学に固有のメディア型に関する科学団体などの, よく知られた恒常的な
団体によって外部の登録及び管理のために作成されてよいことが, 明示的に想定される。 一般に，これらの
追加の登録木のひとつのための仕様の審査の品質は，IETFがそれ自体の木における登録に与えるものと等価
であることが期待される。これらの新しい木の制定は，IESGによって承認されるRFCの公表を通して告知され
る。
2.2 登録の要件
メディア型の登録提案は，すべて，次に示す多くの要件に適合することが期待される。要件の詳細は, 次に
再掲するとおり, 登録木に依存して異なる場合があることに注意すること。
2.2.1 機能に関する要件
メディア型は，実際のメディアフォーマットとして機能しなければならない。転送符号化，文字集合又は別
の型をもつ分離した実体の集合と考えたほうがよいものの登録は，許されない。例えば，base64転送符号化
[RFC 2045]を復号するアプリケーションは存在するが，base64は，メディア型としては登録できない。
この要件は，関連する登録木にかかわらずに適用される。
2.2.2 名前付けに関する要件
すべての登録されたメディア型は，割当てられたMIME型及び下位型でなければならない。これらの名前の組
合せは，メディア型を一意に識別することを提供し，下位型名のフォーマットは, 登録木を識別する。
最上位型名の選択は，関与するメディア型の性質を考慮して行わなければならない。例えば，通常静止画像
に使われるメディアは，audio内容型の音声情報を表現できたとしても，画像の内容型の下位型としたほうが
よい。最上位型の基本集合及びそれらの性質についての追加の情報は, RFC 2046を参照すること。
最上位型の新しい下位型は，もしあれば，最上位型の制限事項に適合してなければならない。例えば，マル
チパート内容型すべての下位型は，同じカプセル化の構文を使用しなければならない。
新しいメディア型が，現在定義されているどんな最上位内容型とも合わない場合がある。このような場合は
きわめて稀であろうが, もし，これが起きた場合には，それにあわせるために，新しい最上位型が定義でき
る。この定義は，標準化手続RFCを通してなされなければならない。追加の最上位内容型を定義するには，他
のどんな機構も使えない。
これらの要件を，関連する登録木にかかわらずに適用される。
2.2.3 パラメタに関する要件
メディア型は，一つ以上のMIME内容型のパラメタを使うことを選んでよく，幾つかのパラメタは，下位型の
どれにでも適用できるパラメタ集合を定義する内容型の下位型であることによって，自動的にメディア型に
6
利用可能になってもよい。どちらの場合も，どんなパラメタの名前，値及び意味も，メディア型がIETF木に
登録されるとき，完全に規定されなければならなず，メディア型がベンダ木又は私的木に登録される場合に
も可能な限り完全に規定されるほうがよい。
新しいパラメタは，既存の機能を変更しない追加の情報を伝えるために追加してもよいが，IETF木の型に新
しい機能を導入する方法として定義してはならない。この例として，JPEGなどの外部仕様の更新レベルを識
別する"revision"パラメタがある。同様の行為は，ベンダ木又は私的木に登録されるメディア型にも推奨さ
れるが，必須ではない。
2.2.4 正準化及びフォーマットに関する要件
すべての登録されたメディア型は，登録木にかかわらず，正準なデータフォーマットを用いなければならな
い。
IETF木に登録されたすべての型には，それぞれのメディア型のフォーマットの，正確で公開された仕様が要
求され，少なくとも，実際に含まれていなくても，メディア型の提案自体には参照されていなければならな
い。
フォーマット仕様及び処理細目は，ベンダ木に登録されるメディア型に関して，公開でもよく公開でなくて
もよい。これらの登録提案は，このメディア型を生成又は処理するソフトウェア及び版の仕様だけを含むこ
とを，明示的に許容している。登録提案の中でフォーマット仕様を参照したり含んだりすることは，推奨さ
れるが要求はされない。
フォーマット仕様は私的木でも登録が要求されるが，RFCとして公表されるか，そうでなければIANAに預けら
れてよい。預けられた仕様は，よく知られたTCPポートを登録するのと同様の基準に合致し，特に公開される
必要はない。
幾つかのメディア型は，特許で保護された技術の使用に関連する。特許で保護された技術に関連するメディ
ア型の登録は，明確に許される。しかし，標準化手続プロトコルの一部であるメディア型の仕様である場合
には， RFC 1602で発布された，標準化手続プロトコル中の特許で保護された技術の使用にあたっての制限事
項には，注意を払わなければならない。
2.2.5 交換に関する要件
メディア型は，可能な場合，可能な限り多くのシステム及びアプリケーション同士で相互運用できるほうが
よい。しかし，あるメディア型は，異なるプラットフォームで相互運用する問題をもつことは避けられな
い。版が異なり，バイト順が異なり，ゲートウェイ処理の特性が異なる問題が起こり得るし，実際起こるで
あろう。
メディア型の普遍的な相互運用性は要求されないが，可能ならば，既知の相互運用性に関する問題は識別さ
れたほうがよい。メディア型の公表は相互運用性に関する徹底的な審査を要求しないが，相互運用性を考慮
する節は，評価を継続することが課題となる。
これらの要件を，関連する登録木にかかわらずに適用される。
2.2.6 セキュリティに関する要件
セキュリティの問題の分析は，IETF木のすべての登録される型に，要求される。これは，すべてのIETFプロ
トコルへの基本の要求に従う。ベンダ木又は私的木に登録されたメディア型では，同様の分析を行うことが
推奨されるが，要件ではない。しかし，セキュリティ分析がされたかされなかったかにかかわらず，セキュ
リティ問題のすべての記述は，登録木にかかわらず，可能な限り正確でなければならない。特に，"この型に
関連するセキュリティ問題はない"という宣言は，"この型に関連するセキュリティ問題は評価されていな
い"と混同されてはならない。
どんな木に登録されるメディア型も安全である又は完全に危険がないという要件は絶対にない。にもかかわ
らず，すべての知られたセキュリティ上の危険は，登録木にかかわらず，メディア型の登録中に，識別され
なければならない。
すべての登録のセキュリティへの考慮の章は，継続的に評価され修正されることを条件とし，特に後続の節
に示される"メディア型へのコメント"機構を使用して，拡張されてよい。
7
メディア型のセキュリティ分析において注意を払うほうがよい課題を次に示す。
a) 複雑なメディア型は，受信者のファイル又はその他の資源で実行を起こす指示のための規定を含んでよ
い。多くの場合，規定は，開始者がそれによって破壊的な影響をもつかもしれない，制限されない方法で，
自由裁量の実行を規定するために作られている。このような指示の例及びそれらをどう取り扱うかについ
て，RFC 2046で規定するapplication/postscriptメディア型の登録を参照すること。
b) 複雑なメディア型は，受信者に直接は被害を与えないが，後続の攻撃を助長するか，又は受信者のプライ
バシを何らかの方法で犯す，情報の開示を起こすかもしれない指示のための規定を含んでよい。さらに,
application/postscriptメディア型の登録は, この指示がどのように取り扱われるかを示す。
c) メディア型は，アプリケーションのために，ある種のセキュリティ保障を要求するが，必要なセキュリテ
ィ機構そのものは提供しないことを志向するかもしれない。例えば，メディア型は，外部の機密性サービス
を要求する機密の医療情報の記憶のために，定義できる。
2.2.7 使用及び実装に関する非要件
遠隔メールエージェントの機能の情報がしばしば送信者に利用可能でない非同期メール環境では，最大限の
相互運用性は，広く実装されていると期待される"普通の"フォーマットの幾つかにメディア型を制限するこ
とによって，達成される。これは，可能なメディア型の数を制限した理由として過去に主張され，メディア
型のこれらの登録に大きな障害及び遅れをもつ登録手続となった。
しかし，"普通の"メディア型の必要性は，新しいメディア型の登録を制限することを要求しない。特定のア
プリケーションでメディア型の制限された集合が推奨されるとしても，それは，アプリケーション及び/又は
環境に特有の別の適用性の宣言によって知らせたほうがよい。
したがって，メディア型の普遍的なサポート及び実装は，登録の要件でない。しかし，メディア型が明示的
に限定的用法を意図する場合，その登録に際してそれを注記したほうがよい。
2.2.8 公表に関する要件
IETF木に登録されるメディア型の提案は，RFCとして公表されなければならない。 RFC公表は，ベンダメディ
ア型又は私的メディア型の提案には，推奨されるが，要件ではない。すべての場合において，IANAは，すべ
てのメディア型の提案の写しを保持し，それらをメディア型登録木自体の一部として"公表"しなければなら
ない。
IETF木以外では，データ型の登録は，IANA又はIETFによる是認，承認又は勧告を想定しない。仕様が妥当で
ある認定も，想定しない。インターネット標準(Internet Standards)となるためには，プロトコル，データ
オブジェクトなどは，IETF標準化処理を通さなければならない。これは，メディア型の便利な登録処理に
は，難しすぎるし，期間が長すぎる。
IETF木は，ベンダ木又は私的木にはない，本質的な審査及び承認処理が必要なメディア型のために存在す
る。これらの文脈で特に有用なことがわかるメディア型の，実装の推奨及びサポートのために，特定のアプ
リケーションのための適用性宣言が，時間がたつにつれて公表されていくことが期待される。
ここに示したとおり，最上位型の登録には標準化処理が要求されるので，RFC公表が要求される。
2.2.9 追加の情報
メディア型の規定には, もしあれば次のさまざまな種類のオプション情報を含んでよい。
a) マジック数(長さ，オクテット値)。マジック数は，いつでも提示されるバイト列で，与えられたメディア
型である実体を識別するのに使うことができる。
b) 与えられたメディア型を含むあるファイルを識別する，一つ又はそれより多いプラットフォームで通常使
われる，ファイル拡張子。
c)与えられためメディアの型を含むファイルをラベル付けするのに使用される，マッキントッシュのFile
Typeコード。
8
これらの情報は，実装者にしばしば非常に有用であり，可能な限り提供したほうがよい。
2.3 登録手続
新しいメディア型の審査及び承認のため，次の手続がIANAによって実装されている。これは，公式の標準化
過程ではないが，過度の時間遅れなしにコミュニティのコメント及び健全さの検査を許容することを想定し
た管理手続である。 IETF木への登録には，はじめの段階として，インターネットドラフトを提出し，次に示
すietf-types一覧への案内を行う，通常のIETF手続に従ったほうがよい。ベンダ木又は私的木での登録につ
いては，下記に示す初期の審査段階は省略してよく，テンプレート及びIANA([email protected])への直接の説明
を直接提出することによって型を登録してよい。しかし，ベンダ又は個人のメディア型の仕様の著者は，可
能なときにはいつでもコミュニティの審査及びコメントを探ることが推奨される。
2.3.1 審査のためのメディア型のコミュニティへの提示
2週間の審査期間のため，"[email protected]"メーリングリストへ，提案のメディア型登録を送る。この
メーリングリストは，提案のメディア型及びアクセス型を審査する目的のために設置されている。提案する
メディア型は，公式には登録されておらず，使ってはならない。 RFC 2045で規定される"x-"接頭辞は，登録
が完了するまで使うことができる。
公的な投稿の意図は，型/下位型の名前の選択へのコメント及びフィードバック，版及び外部のプロファイル
情報に関する参照の曖昧性のなさ，並びに相互運用性又はセキュリティへの考慮に対する審査を要請するこ
ととする。提出者は修正した登録を提出してよく, いつでも登録をすべて撤回してもよい。
2.3.2 IESGによる承認
IETF木に登録されたメディア型は，承認のためにIESGに提出しなければならない。
2.3.3 IANAへの登録
メディア型がメディア型の要件を満たし，必要な承認が得られたなら，著者は，IANAへ登録要件を提出して
よい。IANAは, メディア型を登録し，メディア型登録をコミュニティへ利用可能にする。
2.4 メディア型登録へのコメント
登録されたメディア型へのコメントは，コミュニティのメンバによって，IANAに提出されてよい。これらの
コメントは，できればメディア型の所有者に渡される。コメントの提出者は，メディア型の登録自体にコメ
ントを付けるように要求してよい。IANAが承認したら，コメントは型登録と共にアクセス可能になる。
2.5 登録済みメディア型一覧の所在
メディア型の登録は匿名FTPディレクトリ"ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/"に
投稿され，すべての登録されたアクセス型は，定期的に発行される"Assigned Nubmers"のRFC(現在[STD 2,
RFC 1700])に載る。メディア型の記述及びその他の補助資料は，"[email protected]"に送ることによっ
て，参考情報(Informatinal)RFCとして発行されてよい。RFC著者への指示[RFC 1543]に従うこと。
参考 原規定RFC 2048の発行時点現在で[RFC 1700]であり，この標準仕様書の発行時点現在ではない。
2.6 メディア型登録のためのIANA手続
IANAは，与えられた登録が承認されたことを宣言するIESGの通知に呼応して，IETF木にメディア型を登録す
るだけとする。ベンダ型及び私的型は，次の最低限の条件を満たす限りは何の公式審査もなしに，IANAによ
って自動的に登録される。
a) メディア型は，実際のメディアフォーマットとして機能しなければならない。特に，文字集合及び転送符
号化は, メディア型として登録してはならない。
b) すべてのメディア型は，正しい形式の型名及び下位型名をもたなければならない。すべての名前は, 標準
化手続RFCで定義されなければならない。すべての下位型名は，一意でなければならず，このような名前のた
めのMIME文法に適合しなければならず，正しい木の接頭辞を含まなければならない。
9
c) 私的木に登録された型は，フォーマット仕様又はそれへのポインタを提供しなければならない。
d) 与えられたすべてのセキュリティへの考慮は，明らかにいんちきであってはならない。 IANAがメディア
型登録の広範なセキュリティの審査を実施ことは可能ではないし必要もない。しかし，IANAは，不適格な資
料を明確に識別しそれを排除する権限をもつ。
2.7 変更の制御
ひとたびメディア型がIANAによって公表されたら，著者は, 定義の変更を要求してよい。異なる登録木の上
の記述は，登録の各々の型の"所有者"を指示する。変更要求は，登録要求と同じ手続に従う。
a) ietf-types一覧の修正したテンプレートを公表する。
b) コメントのため少なくとも2週間置いておく。
c) 必要であれば公式審査の後，IANAを使って公表する。
公表された仕様中に深刻な脱落又は誤りがある場合だけ，変更を要求した方がよい。審査が要求されると
き，前の定義で正当であった実体が新しい定義で不正となれば，変更の要求は拒絶されてよい。
内容型の所有者は，IANA及びietf-types一覧に知らせることによって，他の人又は機関に，内容型の責任を
渡してよい。これは議論又は審査なしで行うことができる。
IESGはメディア型の責任者を任命しなおしてよい。これのもっとも普通の場合は，登録の著者が死亡した
り，連絡が取れなくなったり，コミュニティにとって重要な変更を行えないその他の状態において，型の変
更を可能にすることであろう。
メディア型の登録は削除されてよい。もはや使うのに適していないと考えられるメディア型は，"intended
use"フィールドを変更してOBSOLETEと宣言することができる。このようなメディア型は，IANAが公表する一
覧表に明示的に印が付けられる。
2.8 登録テンプレート
To: [email protected]
Subject: Registration of MIME media type XXX/YYY
MIME media type name:
MIME subtype name:
Required parameters:
Optional parameters:
Encoding considerations:
Security considerations:
Interoperability considerations:
Published specification:
Applications which use this media type:
Additional information:
Magic number(s):
File extension(s):
Macintosh File Type Code(s):
Person & email address to contact for further information:
Intended usage:
(COMMON，LIMITED USE又はOBSOLETEのいずれか一つ)
10
Author/Change controller:
(著者が興味があると考えるその他の情報をこの行の下に追加してよい。)
3. 外部本体アクセス型
RFC 2046は，message/external-bodyメディア型を定義し，それによってMIME実体は，実体中に直接データを
含む代わりに，実際の本体データへのポインタとして振舞える。 message/external-body引用は，実際の本
体データを引いてくるのに使われる機構を決定するアクセス型を定義する。 RFC 2046は，アクセス型の初期
の集合を定義しているが，新しい，引き出し機構を提供するために，追加のアクセス型の登録を許してい
る。
3.1 登録の要件
新しいアクセス型の仕様は，次に示す幾つかの要件に適合しなければならない。
3.1.1 名前付けに関する要件
それぞれのアクセス型は，一意の名前をもたなければならない。この名前は，message/external-body内容型
ヘッダフィールドの中のaccess-typeパラメタとして表れ，MIME内容型パラメタ構文に適合しなければならな
い。
3.1.2 機構の仕様に関する要件
与えられたアクセス型によって使われる，プロトコル，トランスポート及び手続は，アクセス型自体の仕様
又はその他の公開された仕様によって，アクセス型が競合する実装者らによって実装されるに十分な詳細を
もって，記述されなければならない。アクセス型における秘密及び/又は専有の方法の使用は，明確に禁止さ
れる。特許で保護されたアルゴリズムの標準化についてのRFC 1602によって課された制限についても，同様
に考慮されなければならない。
3.1.3 公表に関する要件
すべてのアクセス型は，RFCによって規定されなければならない。すべてのアクセス型について標準化手続の
審査及び承認が推奨されるが， RFCは，標準化手続(standard-track)ではなく，参考情報(informational)で
あってもよい。
3.1.4 セキュリティに関する要件
アクセス型の使用からおこる既知のセキュリティ課題は，すべて完全かつ充分に規定されなければならな
い。アクセス型が安全であるか危険でないことは要求されないが，機知の危険は明らかにすることが要求さ
れる。新しいアクセス型の公表は，徹底的なセキュリティの審査を要求せず，セキュリティへの考慮の節が
継続的な評価の対象となる。追加のセキュリティへの考慮は，アクセス型仕様の改訂版の公表によって知ら
せた方がよい。
3.2 登録手続
新しいアクセス型の登録は，RFCの原案を作成することで始める。
3.2.1 アクセス型のコミュニティへの提示
提案するアクセス型仕様を，2週間の審査期間のために，"[email protected]"メーリングリストに送信す
る。このメーリングリストは，提案されたアクセス型及びメディア型を審査する目的のために設置されてい
る。提案するアクセス型は，公式には登録されてなく，使ってはならない。
公的な投稿の意図は，アクセス型仕様へのコメント及びフィードバックを要請し, セキュリティへの考慮の
審査を要請することとする。
3.2.2 アクセス型審査者
2週間の期間が過ぎたら，IETF Applications Area Director(IETFアプリケーション分野管理者)に任命され
たアクセス型審査者は，[email protected]へ要求を転送するか，メーリングリストでの顕著な反対を理由に要求
11
を却下する。
審査者の決定は，ietf-typesメーリングリストに14日以内に投稿されなければならない。審査者の決定に対
し，IESGに抗議してよい。
3.2.3 IANAへの登録
アクセス型が審査を合格するかIESGへの抗議に成功している場合，IANAは，アクセス型を登録し，登録をコ
ミュニティに利用可能にする。アクセス型の仕様は，RFCとしても公表されなければならない。それを"[email protected]"へ送ることで，参考情報(Informational)のRFCが公表される。 RFC著者への指示[RFC 1543]
に従うこと。
3.3 登録済みアクセス型一覧の所在
アクセス型の登録は, 匿名FTPディレクトリ"ftp://ftp.isi.edu/in-notes/iana/assignments/accesstypes/"に投稿され，すべての登録されたアクセス型は，定期的に発行される"Assigned Nubmers"のRFC(現在
[RFC 1700])に載る。
参考 原規定RFC 2048の発行時点現在で[RFC 1700]であり，この標準仕様書(TS)の発行時点現在ではない。
3.4 アクセス型登録のためのIANA手続
アクセス型審査者の同一性は，IESGによってIANAへ通知される。それからIANAは，アクセス型審査者によっ
て承認され, 登録のために審査者によってIANAへ送付されるか, 又はアクセス型定義の訴えがアクセス型審
査者の規則を覆したというIESGからの通知への返答におけるかのどちらかのアクセス型定義への返答として
活動するだけとする。
4. 転送符号化
転送符号化は，メディア型の正準形式への変換後に，MIMEメディア型に適用する変換である。転送符号化は
次の幾つもの目的で使用される。
a) 多くのトランスポート，特にメッセージトランスポートは，比較的短いテキストの行からなるデータだけ
を扱うことができる。これらの行で何の文字が使えるかの重要な問題もあり得る。あるトランスポートは,
US-ASCIIの小さな部分集合に制限され，別のトランスポートは, ある文字の並びを処理することができな
い。転送符号化は，2値データをこれらのトランスポートを生き残せるテキスト形式に変換するために使われ
る。この種の転送符号化の例は，TR X 0069で定義されるbase64及びquted-printable転送符号化を含む。
b) 画像，音声，映像，さらにアプリケーションの実体は，ときには極めて大きい。圧縮アルゴリズムは，大
きな実体の大きさを小さくするのに大変効果的であることが多い。転送符号化は，MIME実体への一般用の情
報欠損のない圧縮アルゴリズムとして適用できる。
c) 転送符号化は，MIMEの文脈で既存の符号化フォーマットを表現する手段として定義できる。
備考 多くの異なる転送符号化の標準化は，広範な相互運用性への重大な障壁と見られ，明らかにやめたほう
がよい。それでも，標準化が実際に正当化されれば, 次の手続は，追加の転送符号化を定義する手段を提供
するために定義される。
4.1 転送符号化の要件
転送符号化仕様は，次に示す幾つかの要件に適合しなければならない。
4.1.1 名前付けに関する要件
各転送符号化は，一意の名前をもたなければならない。この名前はContent-Transfer-Encodingヘッダフィー
ルドに現れ，このフィールドの構文に適合しなければならない。
4.1.2 アルゴリズム仕様に関する要件
転送符号化で使われるすべてのアルゴリズム(例えば，印字可能な形式への変換，圧縮)は，転送符号化仕様
12
の中で完全に規定されなければならない。標準化された転送符号化における秘密の及び/又は専有のアルゴリ
ズムの使用は，明確に禁止される。特許によって保護されたアルゴリズムの標準化についてのRFC 1602で規
定される制限にも，注意を払わなければならない。
4.1.3 入力領域に関する要件
すべての転送符号化は，どんな長さの任意のオクテット列に適用可能でなければならない。特定の入力形式
への依存は許されない。
7ビット及び8ビットの符号化がこの要件に適合しないことに注意したほうがよい。特殊な符号化をもつこと
が望ましくないことはさておき，ここでは，7ビット及び8ビットの行に沿って追加の符号化を加えることを
禁止することを意図する。
4.1.4 出力範囲に関する要件
特定の転送符号化が符号化出力の特定の形式を生成することの要件はない。しかし，各転送符号化の出力フ
ォーマットは，すべて完全に文書化されなければならない。特に，各仕様は，出力フォーマットが常に，7ビ
ットデータ，8ビットデータの範囲内にあるか，又は単に純粋の2値データであるかを明確に宣言しなければ
ならない。
4.1.5 データ完全性及び一般性に関する要件
すべての転送符号化は，すべてのプラットフォームで完全に可逆でなければならない。だれもが，対応する
復号操作を行うことによって，原データに戻すことができなければならない。この要件は，暗号化のすべて
の形式と同様に，情報欠損のある圧縮のすべての形式を転送符号化としての使用から効果的に除外すること
に注目されたい。
4.1.6 新機能に関する要件
すべての転送符号化は，何らかの新機能を提供しなければならない。ある程度の機能が以前に定義された転
送符号化と重複することは許されるが，新しい転送符号化は，他の転送符号化が与えないものも提供しなけ
ればならない。
4.2 転送符号化定義手続
新しい転送符号化の定義は，標準化手続(standard-track) RFCの原案を作成することから始まる。 RFCは，
転送符号化を，正確で完全に定義しなければならず，新しい転送符号化を定義し標準化するためのしっかり
した根拠も提供しなければならない。それからこの仕様を検討のためにIESGへ提出しなければならない。
IESGは, 次を行うことができる。
a) 標準化に不適当として，仕様をすぐに却下する。
b) IETFの手続に従って仕様の作業をするための，IETF作業グループの設立を承認する。又は,
c) 仕様をそのまま承認し，それを標準化手続に入れる。
標準化手続の転送符号化仕様は，標準化手続文書に関する通常のIETF規則に従う。転送符号化は，ひとたび
標準化手続にのれば，定義されることが考慮され，利用可能となる。
4.3 転送符号化登録のためのIANA手続
転送符号化をIANAに登録するための特別な手続は必要ない。すべての合法な転送符号化の登録は，標準化手
続(standard-track)RFCとして現れなければなない。そこで, 新しい転送符号化が承認されたとき, IANAに知
らせるはIESGの責任である。
4.4 登録済み転送符号化一覧の所在
転送符号化の登録は，匿名FTPディレクトリ "ftp://ftp.isi.edu/in-notes/iana/assignments/transferencodings/" に投稿され，すべての登録された転送符号化は，定期的に発行される"Assigned Numbers"のRFC
(現在[RFC 1700])に載る。
13
参考 原規定RFC 2048の発行時点現在で[RFC 1700]であり，この標準仕様書(TS)の発行時点現在ではない。
5．附属書1(参考) 原規定の著者の連絡先
さらに詳細な情報を得るには，次に示す原規定(RFC 2048)の著者にインターネットメールで連絡をとるのが
よい。
Ned Freed
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
USA
Phone: +1 818 919 3600
Fax: +1 818 919 3614
EMail: [email protected]
John Klensin
MCI
2100 Reston Parkway
Reston, VA 22091
Phone: +1 703 715-7361
Fax: +1 703 715-7436
EMail: [email protected]
Jon Postel
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
USA
Phone: +1 310 822 1511
Fax: +1 310 823 6714
EMail: [email protected]
14
附属書A. 既得メディア型
1996年より前に登録された多くのメディア型は，この規定の指針に従って登録されたならば，ベンダ木又は
私的木に置かれる。これらの型を，適切な木を反映するように再登録することは, 推奨されるが，必す(須)
ではない。この規定において大筋を示される所有及び変更制御の原則は，それらが上述の木に登録されたと
して，これらの型に適用される。
15
[附属資料－Ａ．１．２]
多目的インターネットメール拡張（MIME）－第５部：適合基準
標準仕様書(TS) TS X 0107:2005
多目的インターネットメール拡張(MIME)－
第5部: 適合基準
まえがき
この標準仕様書は，工業標準化法に基づいて，日本工業標準調査会の審議を経て，経済産業大臣が公表した
標準仕様書(TS)である。
この標準仕様書(TS)の一部が，技術的性質をもつ特許権，出願公開後の特許出願，実用新案権又は出願公開
後の実用新案登録出願に抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査
会は，このような技術的性質をもつ特許権，出願公開後の特許出願，実用新案権又は出願公開後の実用新案
登録出願にかかわる確認について，責任はもたない。
原規定の状態
原規定(RFC 2049)は，インターネットコミュニティのインターネット標準化手続で開発されたプロトコルを
規定するものであって，改善のための議論及び助言を要求する。このプロトコルの標準化状況及び状態につ
いては，現在の版のインターネット公式プロトコル規定(Internet Official Protocol Standards) (STD 1)
を参照のこと。原規定の配布に制限はない。
著作権
原規定(RFC 2049)に関する著作権は，The Internet Societyに帰属する。
この標準仕様書(TS)には， 次に示す附属書及び解説がある。解説は，原規定には含まれていない。
z
z
z
z
z
附属書1(参考) 原規定の著者の連絡先
附属書2(参考) 貢献者
附属書A. 複雑なマルチパートの例
附属書B. RFC 1521, 1522及び1590からの変更点
附属書C. 引用文献
1
目 次
1. 導入
2. MIME 適合性
3. 電子メールデータ送信の指針
4. 正準符号化モデル
5. 要約
6. セキュリティへの考慮
7. 附属書 1(参考) 原規定の著者の連絡先
8. 附属書 2(参考) 貢献者
附属書 A. 複雑なマルチパートの例
附属書 B. RFC 1521，1522 及び 1590 からの変更点
附属書 C. 引用文献
解説
2
標準仕様書(TS)
TS X 0107:2005
多目的インターネットメール拡張(MIME)－
第5部: 適合基準
Multipurpose Internet Mail Extensions (MIME) —
Part 5: Conformance Criteria and Examples
序文
この標準仕様書(TS)は，1996年11月にInternat Engineering Task Force (IETF)から公表されたRFC 2049
"Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples"を翻訳
し，技術的内容を変更することなく作成した標準仕様書(TS)である。
1. 導入
1.1 適用範囲
インターネット公式プロトコル規定STD 11であるRFC 822では，US-ASCIIメッセージヘッダについて多くの詳
細を規定したメッセージ表現プロトコルを定義しているが，メッセージ，すなわちメッセージ本体について
は, 構造のないUS-ASCIIテキストだけとしている。この標準仕様書(TS)を含む一連の標準情報(TR)及び標準
仕様書(TS)は，多目的インターネットメール拡張又はMIMEと総称され，次のことを可能とするために，メッ
セージのフォーマットを再定義する。
a)
b)
c)
d)
US-ASCII以外の文字集合でのテキストのメッセージ本体
非テキストのメッセージ本体のための異なるフォーマットの拡張集合
マルチパートのメッセージ本体
US-ASCII以外の文字集合でのテキストのヘッダ情報
MIMEを規定する一連の標準情報(TR)及び標準仕様書(TS)は，RFC 934，STD 11及びRFC 1049に文書化されてい
る初期の成果に基づくが，それらを拡張及び改訂する。RFC 822では，メッセージ本体についてはごくわずか
に示しているだけなので，これらの標準情報(TR)及び標準仕様書(TS)の大部分は，RFC 822を改訂するという
より，RFC 822を補う。
これらの一連の標準情報(TR)及び標準仕様書(TS)の最初であって，RFC 2045を原規定とするTR X 0069は，
MIMEメッセージの構造を記述するために使用される多くのヘッダを規定する。2番目のRFC 2046を原規定とす
るTS X 0070は，MIMEメディア型付けシステムの一般的構造を定義し，メディア型の初期集合を定義する。3
番目のRFC 2047を原規定とするTS X 0071は，非US-ASCIIでのインターネットメールヘッダフィールドの中で
非US-ASCIIデータを可能にするためのRFC 822の拡張を規定する。4番目のRFC 2048を原規定とする標準仕様
書(TS)(1)は，MIME関連機能のための多くのIANA登録手続を規定する。最後の5番目のRFC 2049を原規定とす
るこの標準仕様書(TS)は，MIME適合基準を示し，それと共に幾つかのMIMEメッセージフォーマットの例示，
貢献者及び参考文献を示す。
注(1) この標準仕様書(TS)と同時期に公表される。
RFC 2045, RFC 2046, RFC 2047, RFC 2048及びRFC 2049は，RFC 1521, RFC 1522及びRFC 1590の改訂であっ
て，RFC 1521, RFC 1522及びRFC 1590は, RFC 1341及びRFC 1342の改訂であった。附属書B.に，過去の版と
の違い及び変更を示す。
1.2 概要
MIME関連の一連の規定のうち，1番目のTR X 0069及び2番目のTS X 0070は，MIMEヘッダフィールド及びMIME
3
メディア型の初期集合を定義する。3番目のTS X 0071は，US-ASCII以外の文字集合を可能とするために，RFC
822フォーマットの拡張について規定する。この標準仕様書(TS)は，MIMEのどの部分が適合するMIME実装によ
ってサポートされなければならないかを規定する。それは，現代のメッセージングシステムの多くの落とし
穴を示し，MIMEが基づいている正準符号化モデルをも規定する。
2. MIME適合性
MIME関連規定で示される機構は，拡張に対応している。すべての実装がすべての可能なメディア型をサポー
トすることも，それらが同じ拡張を共有することも，全く期待されない。しかし相互運用性を推進するた
め，実装のある水準を定義する"MIME適合性"の概念を定義することは有用であり，これは，US-ASCIIテキス
トと異なる内容をもつメッセージの有用な交換を可能にする。 2.は，この適合性のための要件を規定する。
MIME適合であるメール利用者エージェントは，次を満たさなければならない。
a) それが作成するすべてのメッセージに, 常に"MIME-Version: 1.0"ヘッダフィールドを生成しなければ
ならない。
b) Content-Transfer-Encoding(内容転送符号化)ヘッダフィールドを認識し，quoted-printable実装又は
base64実装のどちらかによって符号化されたすべての受信データを復号しなければならない。 7ビット同
一変換，8ビット同一変換及び2値同一変換も認識されなければならない。
符号化せずに送られるすべての非7ビットデータは，8ビット又は2値の内容転送符号化で適切にラベル
付けされなければならない。下層にある転送機構が，8ビット又は2値をサポートしないとき(SMTP [RFC821]がサポートしないように)，送信者は，quoted-printable又はbase64などの適切な内容転送符号化を用
いて，データを符号化し, かつラベル付けすることが要求される。
c) 認識できないどのようなContent-Transfer-Encoding(内容転送符号化)も，実際のContent-Typeが認識
されるかどうかにかかわらず，それが"application/octet-stream"のContent-Typeをもつように扱わなく
てはならない。
d) Content-Typeヘッダフィールドを認識し解釈しなければならず，text以外のContent-Typeフィールドを
もつ生データを利用者に見せてはならない。実装は，少なくともtext/plainメッセージを，文字集合がUSASCIIでない場合には, charsetパラメタで指定する文字集合で送ることができなければならない。
e) 名前を認識できない内容型パラメタは無視しなければならない。
f) 次のメディア型値を，少なくとも次の程度まで明示的に処理しなければならない。
text:
{ 文字集合"US-ASCII"をもつ"text"メールを認識し, 表示しなければならない。
{ 他の文字集合を, 少なくとも，メッセージが使っている文字集合が何であるかについて利用者に知ら
せることができる程度まで, 認識しなければならない。
{ ISO-8859-*及びUS-ASCIIに共通の文字, すなわちオクテット値1～127で表現されるすべての文字を表
示できる程度まで，"ISO-8859-*"文字集合を認識しなければならない。
{ 既知の文字集合の認識できない下位型のために，正準形式から局所形式への内容変換の後に"生"の版
のデータを，利用者に見せるか見せることを提案しなければならない。
{ 未知の文字集合のデータは, それが"application/octet-stream"であるかのように扱わなければなら
ない。
image，audio及びvideo:
{ 少なくとも，すべての認識できない下位型を"application/octet-stream"であるかのように扱う機能
を提供しなければならない。
application:
{ この規定で定義されるquoted-printable符号化又はbase64符号化が使われ，結果の情報が利用者のフ
ァイルに置かれる場合，それを取り除く能力を提示しなければならない。
multipart:
4
{
{
{
{
混合の下位型を認識しなければならない。メッセージレベル及び本体部分ヘッダレベルのすべての関
連する情報を表示し，そして，それぞれの本体部分を独立に見せるか又は見せるかどうかを提示しな
ければならない。
"alternative"下位型を認識し，multipart/alternativeのメールの冗長な部分を利用者に見せること
を避けなければならない。
"multipart/digest"下位型を認識しなければならない。特に，"multipart/digest"実体内部の本体部
分のデフォルトのメディア型として，"text/plain"ではなく"message/rfc822"を使わなければならな
い。
すべての認識できない下位型を"mixed"であるかのように扱わなければならない。
message:
{ 少なくともRFC 822メッセージのカプセル化(message/rfc822)をすべての再帰構造を保持する方法で
認識及び表示しなければならない。すなわち，このメディア型に従ってカプセル化されたデータを，
表示するか又は表示するかどうかを提示しなければならない。
{ どんな認識できない下位型も"application/octet-stream"であるかのように扱わなければならない。
g) 認識できないContent-Typeフィールドに遭遇した際には，実装は，それがパラメタなし
の"application/octet-stream"のメディア型をもつかのように, それを扱わなければならない。これらの
データをどう処理するかは実装の問題になるが，これらの認識できないデータを処理する可能な選択肢に
は，メール転送フォーマットから復号されるファイルにそれ書き込むことを利用者に提供すること，又は
復号されるデータを入力として渡すプログラムを命名することを利用者に提供することが含まれる。
h) 適合利用者エージェントが, US-ASCII以外の文字集合を用いる非MIMEメッセージに対して非標準のサポ
ートを提供する場合，受信メッセージだけにそれを行うことが，適合利用者エージェントに要求される。
適合利用者エージェントは，US-ASCIIテキスト以外を含む非MIMEメッセージを送ってはならない。
特に，MIME-Versionフィールドなしのメールメッセージにおける非US-ASCIIテキストの使用は，異なる
局所変換の領域間でメッセージを送るときに相互運用性を妨げるので，強く非推奨とする。適合利用者エ
ージェントは，US-ASCII文字集合でプレーンテキスト以外のものをを送るとき，正しいMIMEラベル付けを
含まなければならない。
さらに非MIME利用者エージェントは，たとえMIME中で他の何もサポートしない場合でも，それが送った
メッセージに適切なMIMEヘッダ情報を含むことが可能なように更新されたほうがよい。この更新は，あっ
たとしても, ほとんど非MIME受信者に影響を与えず, これらのメッセージを正しく表示するのにMIMEを援
助する。これは，他のMIME機能を将来採用することへの円滑な移行の道筋をも提供する。
i) 適合利用者エージェントは，"=?"で始まり"?="で終わる"*text"又は"*ctext"の中にある非空白で印字
可能なUS-ASCII文字のどの文字列も, 妥当な符号化語(valid encoded-word)であることを保証しなければ
ならない。ここで, "始まる"は，フィールド本体の先頭又は線形空白(linear-white-space)の直後を意味
し，"終わる"は，フィールド本体の末尾又は線形空白の直前を意味する。さらに，"=?"で始まり"?="で終
わる"phrase"の中にあるどんな"word"も，妥当な符号化語でなければならない。
j) 適合利用者エージェントは，符号化語がメッセージヘッダ中の適切な位置に現れたらいつでも，4.に規
定する規則に従って, 符号化語を"text"，"ctext"又は"word"から区別できなければならない。それは, そ
れがサポートするどの文字集合に対しても，"B"符号化及び"Q"符号化の両方をサポートしなければならな
い。そのプログラムは，符号化されないテキストを, 文字集合が"US-ASCII"であれば, 表示できなければ
ならない。 ISO-8859-*文字集合に関して，メールを読むプログラムは，少なくともUS-ASCII集合にも含ま
れる文字を表示できなくてはならない。
これらの条件に適合する利用者エージェントは，MIME適合であるといえる。この句の意味は，これらのメー
ルシステムの利用者に，適切にマーク付けされたどんな種類のデータも事実上送ることが, "安全"であると
想定されることとする。それは，これらのシステムが，少なくともそのデータを区別されない2値として扱う
ことができ，疑わない利用者の画面上にそれをまき散らすことはないことによる。
MIME適合のフォーマットでデータを送ることは常に"安全"であるというもう一つ意義がある。それは, それ
らのデータが, 壊れることはなく, RFC 821及びRFC 822に適合するどんな既知のシステムによっても壊され
ないこととする。MIME適合の利用者エージェントは，利用者がテキストとして見られることを決して想定し
ないデータを見せられないという，追加の保証をもつ。
5
3. 電子メールデータ送信の指針
インターネットメールは，完全で一様なシステムではない。メールは，最終目的地に行く途中の多くの段階
で，壊れてしまうことがある。特に，インターネットを通って送られた電子メールは，多くのネットワーク
技術を通過し得る。多くのネットワーク技術及びメール技術は，SMTP転送環境で可能な全機能をサポートす
るわけではない。これらのシステムを通過するメールは，それが転送され得るように，変更され易い。
インターネットには, 多くの非適合MTAがある。これらのMTAは，SMTPプロトコルで交信する際に, それが実
装されているホストの内部データ構造を利用して動作中にメッセージを改変するか，又ははっきりと壊され
る。
次の指針は，最も広範なネットワーク技術及び既知の壊れたMTAで無傷に生き残るために想定されるデータフ
ォーマット(メディア型)を工夫する人に有用であろう。 base64符号化で符号化されるものは，これらの規則
を満たすが，よく知られた機構, とりわけUNIXのuuencode機能はそれを満たさないことに注意されたい。
Quoted-Printable符号化で符号化されたものは，大部分のゲートウェイで無傷に生き残るが，EBCDIC文字集
合を使うシステムへのいくつかのゲートウェイでは生き残れない可能性がある。
a) いくつかの状況下では，通常のゲートウェイの一部又は利用者エージェント操作として，データに使わ
れる符号化を変更してよい。特に，base64からquted-printableへの変換及びその逆変換は, 必要かもしれ
ない。これは，テキスト本体中の行区切りで, CRLF列の混乱を起こすかもしれない。そうであるから，行
区切りではないものとしてのCRLFの保存性は, 信頼してはならない。
b) 多くのシステムは，局所的な改行変換を使って，テキストデータを表示し，保存することを選択してよ
い。局所的な改行変換は，RFC 822のCRLF規約, つまり, CRだけ，LFだけ，CRLF，又は数えたレコードを使
うことが知られるシステムには一致しないことがある。その結果, 孤立したCR文字及びLF文字は, 一般に
は許されない。それらは，あるシステムでは，失われるか又は区切り子に変換されるかもしれないので,
信頼してはならない。
c) NUL(US-ASCII値の0)の転送は，インターネットメールでは問題がある。これは，プログラム言語Cにお
いて多くの標準ランタイムライブラリルーチンによって終端文字として使われているNULの結果によるとこ
ろが大きい。終端文字としてのNULの使用の実行は，いまでは確立されたものだから，メッセージが保存さ
れることを信じないほうがよい。
d) TAB(HT)文字は，誤って解釈され得るか，異なる数のスペースへ自動的に変換されるかもしれない。こ
れは，ある環境では，特にUS-ASCII文字集合に基づかない環境では，避けられない。これらの変換は，強
く非推奨とするが，もしそれが起きる場合には，メールフォーマットはTAB(HT)文字の保存性に依存しては
ならない。
e) 76文字より長い行は，ある環境では，折り返されるか又は切り取られる。メール転送で行われる行の折
返し又は切取りは，強く非推奨とするが，いくつかの場合には避けられない。長い行を要求するアプリケ
ーションは，無指定(soft)行区切りと指定(hard)行区切りとを何とかして区別しなければならない。これ
を行う簡単は方法に，quoted-printable符号化の使用がある。
f) 行の末尾の"空白"文字(SPACE，TAB(HT))は，ある転送エージェントで捨てられるかもしれない。他の転
送エージェントが, これらの文字で行を埋めて，メールファイル中のすべての行を同じ長さにすることも
ある。したがって, 末尾の空白の保存性をあてにしてはならない。
g) 多くのメールドメインは，US-ASCII文字集合での変種を使うか，又はUS-ASCIIの文字の多くを含むがす
べては含んでいないEBCDICなどの文字集合を使う。 "不変の"集合にない文字の正しい翻訳は，文字変換ゲ
ートウェイに頼ることはできない。例えば，この状況は，uuencodeされた情報を，EBCDICシステムである
BITNETを通して送る場合に問題となる。多くのインターネットのホストは，内部ではUS-ASCII以外の文字
集合を使うので，類似の問題は，ゲートウェイを通さない場合にも起る。 X.400におけるPrintable
String(印字可能文字列)の定義は，ある特定の場合にさらに制限を加えている。特に，すべてのゲートウ
ェイを通して一貫性があると知られている文字は, 大文字のAからZまで, 小文字のaからzまで，0から9ま
での10数字，及び次の11の特別な文字である73文字だけである。
6
"'"
"("
")"
"+"
","
"-"
"."
"/"
":"
"="
"?"
(US-ASCIIの10進値で39)
(US-ASCIIの10進値で40)
(US-ASCIIの10進値で41)
(US-ASCIIの10進値で43)
(US-ASCIIの10進値で44)
(US-ASCIIの10進値で45)
(US-ASCIIの10進値で46)
(US-ASCIIの10進値で47)
(US-ASCIIの10進値で58)
(US-ASCIIの10進値で61)
(US-ASCIIの10進値で63)
最も大きな可搬性のあるメール表現は，73文字のこの集合から意味のある文字だけを使ったテキストの比
較的短い行に限ることになる。base64符号化はこの規則に従う。
h) いくつかのメール転送エージェントは，ある文字列を含むデータを壊す。特に，ピリオド(".")だけの
行は，いくつかの(正しくない)SMTP実装によって壊されることが知られており，"From "の5文字(最後の文
字はSPACE)で始まる行も通常壊される。注意深い作成エージェントは，そのデータを符号化することによ
って破壊を防ぐことができる。例えば，quoted-printable符号化において行の先頭にある"From "の場所
に"=46rom "を使い，行の"."だけの場所には"=2E"を使う。
上述の一覧は，MTAに関する推奨される実行の一覧ではないことに注意されたい。 RFC 821のMTAは，空白の
文字を変更すること又は長い行を折り返すことを禁止している。これらの悪い不正な実行は，設置されたネ
ットワークで起ることが知られていて，実装は，それらが引き起こし得る悪い影響を扱う際に頑健であるこ
とが望ましい。
4. 正準符号化モデル
MIME規定の初期の版では，電子メールデータが正準形式に変換し符号化されるとき，特にこの過程がどのよ
うに，システムごとに大きく異なる改行の表現が与えられるCRLFの振る舞いに，影響するかについて，混乱
があった。この理由によって，符号化の正準モデルを次に示す。
MIME実体を作成する過程は，いくつかの段階で行われるものとしてモデル化できる。これらの段階は，大雑
把に言って，PEM [RFC-1421]で使われる段階と似ていて，それぞれの"最も内側のレベル"の本体に対して実
行される。
a) ローカル形式の作成
システムの固有フォーマットで，転送する本体を生成する。固有の文字集合が使われ，適切であれば，同
様に局所的な行の終端の変換が行われる。本体は，UNIXスタイルのテキストファイル，Sunのラスタ画像，
VMSのインデックス付きファイル，メモリ内だけに保存される形式のシステム依存の音声データ，又は情報
のある形式の表現ための局所的なモデルに対応するその他のものであってもよい。基本的に，データは，
メディア型で指定される型に対応する"固有の"形式で作成される。
b) 正準形式への変換
レコード長, 可能なファイル属性情報などの"out-of-band"情報を含むすべての本体は，普遍的な正準形式
に変換される。本体の特定のメディア型及び関連する属性は，使われる正準形式の性質を指示する。正し
い正準形式への変換は，文字集合の変換，音声データの変換，圧縮，又はさまざまなメディア型に固有の
多くの他の操作を含んでよい。しかし文字集合の変換を含む場合には，どんな文字集合の変換にも強い意
味をもつであろう，メディア型のセマンティクスを理解する注意が払われなければならない。例え
ば，"plain"以外のテキスト下位型における構文上意味のある文字にいて注意を払わなければならない。
例えば，text/plainデータの場合，テキストはサポートされる文字集合に変換されなければならず，RFC
822に従ってCRLF区切り子で行を区切らなくてはならない。次の段階でquoted-printable符号化又はbase64
符号化のどちらかを用いるならば，RFC 822に伴う行の長さの制限はなくなる。
c) 転送符号化の適用
この本体に適切なContent-Transfer-Encoding(内容転送符号化)を適用する。メディア型と転送符号化との
間には固定的な関係はないことに注意すること。特に，base64又はquoted-printableの選択の基礎を, 本
7
体の与えられたインスタンスに固有の文字頻度数に置くことは適切であろう。
d) 実体への挿入
符号化された本体は，MIME実体に適切なヘッダとともに挿入される。それから実体は，必要に応じてもっ
と高いレベルの実体(メッセージ又はマルチパート)に挿入される。
実体形式から局所形式への変換は，これらの段階を逆にすることによって達成される。もとの形式と最終的
な局所形式とが同じである保証はないので，これらの段階の逆は異なる結果を生成するかもしれないことに
注意すること。
これらの段階はモデルにすぎないことに注意することは重要である。これらは，実際のシステムがどのよう
に構築されるかの青写真では決してない。特にモデルは，次の二つの共通設計を説明できない。
a) 多くの場合，符号化に先立つ正準形式への変換は，局所フォーマットを直接理解できる符号化器そのも
に含まれる。例えば，テキスト本体の局所的な改行の変換は，そのフォーマットが何であるかの知識に基
づいて, 符号化器そのものを通して実行されるであろう。
b) 符号化器の出力は，メッセージとして転送される前に，一つ以上の追加の段階を通らなければならない
かもしれない。そうであるから，符号化器の出力は，RFC 822に規定されるフォーマットに適合しないかも
しれない。特に，変換器の出力が，標準的なRFC 822のCRLF区切り子を使うのではなく，局所的な改行変換
を使って表現されることが再び適切であるかもしれない。
他の実装上の多様性も同様に考えられる。この議論の重要な点は，要求される段階を崩したり追加処理を挿
入したりする最適化にかかわらず，結果のメッセージはここに示されたモデルによって生成されたものと整
合していなければならないことである。例えば，次のヘッダーファイルをもつメッセージは，はじめに
text/foo形式で表現され，それから必要に応じて，"bar"文字集合によって表現され，最後にbase64アルゴリ
ズムによってmail-safe形式に変換されなければならない。
Content-type: text/foo; charset=bar
Content-Transfer-Encoding: base64
備考 RFC 822のCRLF変換と異なる局所的な改行変換を使うフォーマットでメッセージを表現するシステムに
よって，ある混乱が起きていた。これらのフォーマットが正準なRFC822/MIMEではないことに注意すること
は, 重要である。これらのフォーマットは，メッセージの正準表現におけるCRLF列が局所的な改行変換とし
て符号化される，RFC 822の代理"符号化"である。例えば，LFは, CRLF行分離列の部分でないLFオクテットを
含む2値データを含むMIMEメッセージを表現できないので, CRLF列を符号化するフォーマットに注目された
い。
5. 要約
この標準仕様書(TS)は，MIME適合が何を意味するかを定義した。それは, インターネットの電子メールシス
テムに存在することが知られているさまざまな問題, 及びこれらを克服するためにMIMEをどのように使うか
をも詳述した。最後に，MIMEの正準符号化モデルを示した。
6. セキュリティへの考慮
セキュリティについては，MIME関連の2番目の規定であるTS X 0070に示されている。
7. 附属書1(参考) 原規定の著者の連絡先
さらに詳細な情報を得るには, 次に示す原規定(RFC 2049)の著者にインターネットメールで連絡をとるのが
よい。
Ned Freed
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
8
USA
Phone: +1 818 919 3600
Fax: +1 818 919 3614
EMail: [email protected]
Nathaniel S. Borenstein
First Virtual Holdings
25 Washington Avenue
Morristown, NJ 07960
USA
Phone: +1 201 540 8967
Fax: +1 201 993 3032
EMail: [email protected]
MIMEは，Internet Engineering Task Force (IETF)のRFC 822拡張に関する作業グループの作業の結果であ
る。作業グループの議長Greg Vaudreuilの連絡先を示す。
Gregory M. Vaudreuil
Octel Network Services
17080 Dallas Parkway
Dallas, TX 75248-1905
USA
EMail: [email protected]
8. 附属書2(参考) 貢献者
原規定(RFC 2049)は，IETF-SMTP及びIETF-822のメーリングリスト及びその他の場所での，多くのIETF会議で
の多くの人々の集積した努力の結果である。どんな列挙にもひどい抜けはあるであろうが，次の列挙は，こ
の努力への多くの貢献者の中の一覧である。
Harald Tveit Alvestrand
Randall Atkinson
Philippe Brandon
Kevin Carosso
Peter Clitherow
Cristian Constantinof
Mark Crispin
Stephen Crocker
Walt Daniels
Frank Dawson
Hitoshi Doi
Steve Dorner
Chris Eich
Johnny Eriksson
Patrik Faltstrom
Roger Fajman
Martin Forssen
Stephen Gildea
Thomas Gordon
Terry Gray
James Hamilton
Mark Horton
Bill Janssen
Risto Kankkunen
Alan Katz
Neil Katin
Kyuho Kim
John Klensin
Jim Knowles
Bob Kummerfeld
Stellan Lagerstrom
Timo Lehtinen
Warner Losh
Marc Andreessen
Bob Braden
Brian Capouch
Uhhyung Choi
Dave Collier-Brown
John Coonrod
Dave Crocker
Terry Crowley
Jim Davis
Axel Deininger
Kevin Donnelly
Keith Edwards
Dana S. Emery
Craig Everhart
Erik E. Fair
Alain Fontaine
James M. Galvin
Philip Gladstone
Keld Simonsen
Phill Gross
David Herron
Bruce Howard
Olle Jarnefors
Phil Karn
Tim Kehres
Steve Kille
Anders Klemets
Valdis Kletniek
Stev Knowles
Pekka Kytolaakso
Vincent Lau
Donald Lindsay
Carlyn Lowery
9
Laurence Lundblade
John R. MacMillan
Rick McGowan
Leo Mclaughlin
Tom Moore
Erik Naggum
Chris Newman
Mats Ohrman
Michael Patton
Erik van der Poel
Christer Romson
Marshall T. Rose
Guido van Rossum
Harri Salminen
Yutaka Sato
Richard Alan Schafer
Mark Sherman
Peter Speck
Einar Stefferud
Klaus Steinberger
James Thompson
Stuart Vance
Greg Vaudreuil
Larry W. Virden
Rhys Weatherly
Dave Wecker
Sven-Ove Westberg
John Wobus
Rayan Zachariassen
Charles Lynn
Larry Masinter
Michael J. McInerny
Goli Montaser-Kohsari
John Gardiner Myers
Mark Needleman
John Noerenberg
Julian Onions
David J. Pepper
Blake C. Ramsdell
Luc Rooijakkers
Jonathan Rosenberg
Jan Rynning
Michael Sanderson
Markku Savela
Masahiro Sekiguchi
Bob Smart
Henry Spencer
Michael Stein
Peter Svanberg
Steve Uhler
Peter Vanderbilt
Ed Vielmetti
Ryan Waldron
Jay Weber
Wally Wedel
Brian Wideen
Glenn Wright
David Zimmerman
原規定の著者は，この一覧から抜けている人に謝罪する。意図的に抜かしたのでは断じてない。
10
附属書A. 複雑なマルチパートの例
複雑なマルチパートメッセージの概要を次に示す。このメッセージは，連続的に表示される五つの部分，す
なわち，二つの導入のプレーンテキストオブジェクト，組み込まれたマルチパートメッセージ，
text/enrichedオブジェクト，非ASCII文字集合でのカプセル化された最後のテキストから成る。組み込まれ
たマルチパートメッセージ自体は，並列的に表示される二つのオブジェクト, つまり写真及び音声素片を含
む。
MIME-Version: 1.0
From: Nathaniel Borenstein
To: Ned Freed
Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT)
Subject: A multipart example
Content-Type: multipart/mixed;
boundary=unique-boundary-1
This is the preamble area of a multipart message.
Mail readers that understand multipart format
should ignore this preamble.
If you are reading this text, you might want to
consider changing to a mail reader that understands
how to properly display multipart messages.
--unique-boundary-1
... Some text appears here ...
[Note that the blank between the boundary and the start
of the text in this part means no header fields were
given and this is text in the US-ASCII character set.
It could have been done with explicit typing as in the
next part.]
--unique-boundary-1
Content-type: text/plain; charset=US-ASCII
This could have been part of the previous part, but
illustrates explicit versus implicit typing of body
parts.
--unique-boundary-1
Content-Type: multipart/parallel; boundary=unique-boundary-2
--unique-boundary-2
Content-Type: audio/basic
Content-Transfer-Encoding: base64
... base64-encoded 8000 Hz single-channel
mu-law-format audio data goes here ...
--unique-boundary-2
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
... base64-encoded image data goes here ...
--unique-boundary-2---unique-boundary-1
Content-type: text/enriched
This is enriched.
as defined in RFC 1896
11
Isn't it
cool?
--unique-boundary-1
Content-Type: message/rfc822
From: (mailbox in US-ASCII)
To: (address in US-ASCII)
Subject: (subject in US-ASCII)
Content-Type: Text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: Quoted-printable
... Additional text in ISO-8859-1 goes here ...
--unique-boundary-1--
12
附属書B. RFC 1521, 1522及び1590からの変更点
MIME関連の一連の規定は，RFC 1521，1522及び1590の改訂である。初期の規定を熟知している人に便利なよ
うに，初期の規定からの変更点をこの附属書に要約する。それ以前の履歴に関して，RFC 1521がその前の版
のRFC 1341とどのように異なるかをRFC 1521のAppendix Hが示している。
a) この規定は完全に再構成され，複数の規定に分割された。これは，参照原稿であるために必要とされ
る，この規定のプレーンテキスト版の品質を高めるために行われた。
b) MIMEオブジェクトヘッダの全体構成を記述するBNFが追加された。これは，文書化の変更だけで，根本
的な構文は変わっていない。
c) MIMEの七つのメディア型のための固有のBNFは削除された。このBNFは，不正確で，不完全で，型独立の
BNFとは矛盾した。型独立のBNFはすでに多くのMIMEヘッダの構文を完全に規定しているので，型固有のBNF
は，結局，完全に不要であり，かえって問題を起こした。
d) これらの規定の多くの部分における非公式の用語であるASCIIの使用は，もっと固有の"US-ASCII"とい
う文字集合名に置き換えられた。
e) 主下位型という非公式の概念を削除した。
f) 用語"オブジェクト"は, 一貫性なしに用いられていた。この用語の定義は，関連の用語"本体"，"本体
部分"及び"実体"とともに明確化され，用法は適切に訂正された。
g) 境界マーカに先行するCRLFが，先行する本体部分ではなくマーカそのもののの一部であることを明確に
するため，マルチパートメディア型のためのBNFは再整理された。
h) マルチパートオブジェクト内の本体部分は，境界パラメタ文字列で始まる行を含んではならないことを
明確にするため，マルチパートメディア型を記述する普通文及びBNFは変更された。
i) "message/partial"MIME実体を再組立てする規則において，内部メッセージからとるために，ヘッダの
一覧に"Subject"が追加され, この点を明確にするため例が修正された。
j) "message/partial"素片化子は，行境界でのMIMEオブジェクトの分割だけに制限される。
k) application/postscript型の議論において，PoseScript MIME実体の中での2値データの組込みによって
引き起こされる可能性のある相互運用可能性の問題についての警告をする追加の段落を加えた。
l) 次の二つの形式を明確にするために，Content-Typeヘッダフィールドのための基本構文規則に対して明
確化の備考を加えた。
Content-type: text/plain; charset=us-ascii (comment)
Content-type: text/plain; charset="us-ascii"
これには, 完全に等価である。
m) MIME-Versionヘッダの議論から次の文を削除した。 "しかし，適合ソフトウェアは，版番号を検査し，
認識できないMIME-Versionに遭遇したとき, 利用者に少なくとも警告することが推奨される。"
n) "message/external-body"ではなく"application/external-body"とした誤植を修正した。
o) 要件を明確にするため，文字集合の定義を再構成した。
p) "image/gif"メデイァ型の定義は，別文書に移した。この変更は，特許で保護された技術の標準化を管
理するIETF規則と矛盾が生じる可能性があるため，行われた。
13
q) "7ビット"及び"8ビット"の定義を厳しくしたので，はだかのCR及びLFは行終端列として使用されるだけ
とした。この規定も，NUL文字を保存することをもはや要求しない。それは, MIMEを実世界の実装と整合さ
せる。
r) MIMEにおける正準テキストの定義を厳しくしたため，行区切りはCRLF列で表現されなければならない。
CR文字及びLF文字は, この用法以外には許容されない。それに伴って, quoted-printable符号化の定義が
変更された。
s) quoted-printable符号化の定義は，quoted-printble符号化器が不適切に符号化されたデータをどう扱
うのが最もよいかについて，今では多くの推奨を含む。
t) "8bit"又は"binary"データにカプセル化するメッセージ実体又はマルチパートで, "7bit"，"8bit"及
び"2値"の転送符号化の使用を明確にする普通文を加えた。
u) MIME適合性の節において，最小限のMIME適合性に関する要件の一覧に"multipart/digest"のサポートを
追加した。"message/rfc822"のサポートのための用件も，再帰構造を認識することの重要性を明確にする
ために, 強化された。
v) "message"の下位型のさまざまな制限は，今では下位型ごと完全に規定されている。
w) "message/rfc822"の定義は，"From"，"Subject"又は"Date"ヘッダの少なくとも一つが存在しなければ
ならないことを示すように変更した。
x) 認識できない下位型の"application/octet-stream"としての必須処理は，型定義の節及び適合性指針の
両方において, もっと明示的に作成された。
y) text/richtextを用いた例は，text/enrichedに変更された。
z) 下位型のBNF定義は，IANA登録済み下位型又は非標準の"X-"下位型のどちらかがContent-Typeヘッダフ
ィールドで使わなければならないことを明らかにすために変更された。
aa) 使用するために単に登録されるMIMEメディア型と, IETFによって標準化されるMIMEメディア型とは,
今ではMIME BNFにおいて区別される。
ab) さまざまなMIME登録手続きのすべてを広範囲に改訂した。文字集合に関するIANA登録手続きは，この
一連の規定に含まれない別の規定に移動した。
ac) これらの規定が定義しているUS-ASCII文字集合及びISO-8859-X文字集合におけるエスケープ機構及び
シフト機構の使用を明確にした。これらの機構は，これらの文字集合, 及びそれらの使用が定義されない
ときの影響と一緒に使用してはならない。
ad) message/external-bodyのためのAFSアクセス型の定義を削除した。
ae) multipart/alternativeとmessage/external-bodyとの組合せの処理には，今は特に言及していない。
af) message/external-bodyに固有のセキュリティの課題は，今では細かく示されている。
14
附属書C. 引用文献
[ATK]
Borenstein, Nathaniel S., Multimedia Applications
Development with the Andrew Toolkit, Prentice-Hall, 1990.
[ISO-2022]
International Standard -- Information Processing -Character Code Structure and Extension Techniques,
ISO/IEC 2022:1994, 4th ed.
参考 JIS X 0202-1998 情報技術 - 文字符号の構造及び拡張法 が, この規格に
対応している。
[ISO-8859]
International Standard -- Information Processing -- 8-bit
Single-Byte Coded Graphic Character Sets
- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987, 1st ed.
- Part 2: Latin Alphabet No. 2, ISO 8859-2:1987, 1st ed.
- Part 3: Latin Alphabet No. 3, ISO 8859-3:1988, 1st ed.
- Part 4: Latin Alphabet No. 4, ISO 8859-4:1988, 1st ed.
- Part 5: Latin/Cyrillic Alphabet, ISO 8859-5:1988, 1st
ed.
- Part 6: Latin/Arabic Alphabet, ISO 8859-6:1987, 1st ed.
- Part 7: Latin/Greek Alphabet, ISO 8859-7:1987, 1st ed.
- Part 8: Latin/Hebrew Alphabet, ISO 8859-8:1988, 1st ed.
- Part 9: Latin Alphabet No. 5, ISO/IEC 8859-9:1989, 1st
ed.
International Standard -- Information Technology -- 8-bit
Single-Byte Coded Graphic Character Sets
- Part 10: Latin Alphabet No. 6, ISO/IEC 8859-10:1992,
1st ed.
[ISO-646]
International Standard -- Information Technology -- ISO
7-bit Coded Character Set for Information Interchange,
ISO 646:1991, 3rd ed.
参考 JIS X 0201:1997 7ビット及び8ビットの情報交換用符号化文字集合 が, この
規格に対応している。
[JPEG]
JPEG Draft Standard ISO 10918-1 CD.
[MPEG]
Video Coding Draft Standard ISO 11172 CD, ISO
IEC/JTC1/SC2/WG11 (Motion Picture Experts Group), May,
1991.
[PCM]
CCITT, Fascicle III.4 - Recommendation G.711, "Pulse Code
Modulation (PCM) of Voice Frequencies", Geneva, 1972.
[POSTSCRIPT]
Adobe Systems, Inc., PostScript Language Reference
Manual, Addison-Wesley, 1985.
[POSTSCRIPT2]
Adobe Systems, Inc., PostScript Language Reference
Manual, Addison-Wesley, Second Ed., 1990.
[RFC-783]
Sollins, K.R., "TFTP Protocol (revision 2)", RFC-783,
MIT, June 1981.
[RFC-821]
Postel, J.B., "Simple Mail Transfer Protocol", STD 10,
RFC 821, USC/Information Sciences Institute, August 1982.
15
[RFC-822]
Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", STD 11, RFC 822, UDEL, August 1982.
[RFC-934]
Rose, M. and E. Stefferud, "Proposed Standard for Message
Encapsulation", RFC 934, Delaware and NMA, January 1985.
[RFC-959]
Postel, J. and J. Reynolds, "File Transfer Protocol", STD
9, RFC 959, USC/Information Sciences Institute, October
1985.
[RFC-1049]
Sirbu, M., "Content-Type Header Field for Internet
Messages", RFC 1049, CMU, March 1988.
[RFC-1154]
Robinson, D., and R. Ullmann, "Encoding Header Field for
Internet Messages", RFC 1154, Prime Computer, Inc., April
1990.
[RFC-1341]
Borenstein, N., and N. Freed, "MIME (Multipurpose
Internet Mail Extensions): Mechanisms for Specifying and
Describing the Format of Internet Message Bodies", RFC
1341, Bellcore, Innosoft, June 1992.
[RFC-1342]
Moore, K., "Representation of Non-Ascii Text in Internet
Message Headers", RFC 1342, University of Tennessee, June
1992.
[RFC-1344]
Borenstein, N., "Implications of MIME for Internet Mail
Gateways", RFC 1344, Bellcore, June 1992.
[RFC-1345]
Simonsen, K., "Character Mnemonics & Character Sets", RFC
1345, Rationel Almen Planlaegning, June 1992.
[RFC-1421]
Linn, J., "Privacy Enhancement for Internet Electronic
Mail: Part I -- Message Encryption and Authentication
Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG,
February 1993.
[RFC-1422]
Kent, S., "Privacy Enhancement for Internet Electronic
Mail: Part II -- Certificate-Based Key Management", RFC
1422, IAB IRTF PSRG, IETF PEM WG, February 1993.
[RFC-1423]
Balenson, D., "Privacy Enhancement for Internet
Electronic Mail: Part III -- Algorithms, Modes, and
Identifiers", IAB IRTF PSRG, IETF PEM WG, February 1993.
[RFC-1424]
Kaliski, B., "Privacy Enhancement for Internet Electronic
Mail: Part IV -- Key Certification and Related
Services", IAB IRTF PSRG, IETF PEM WG, February 1993.
[RFC-1521]
Borenstein, N., and Freed, N., "MIME (Multipurpose
Internet Mail Extensions): Mechanisms for Specifying and
Describing the Format of Internet Message Bodies", RFC
1521, Bellcore, Innosoft, September, 1993.
16
[RFC-1522]
Moore, K., "Representation of Non-ASCII Text in Internet
Message Headers", RFC 1522, University of Tennessee,
September 1993.
[RFC-1524]
Borenstein, N., "A User Agent Configuration Mechanism for
Multimedia Mail Format Information", RFC 1524, Bellcore,
September 1993.
[RFC-1543]
Postel, J., "Instructions to RFC Authors", RFC 1543,
USC/Information Sciences Institute, October 1993.
[RFC-1556]
Nussbacher, H., "Handling of Bi-directional Texts in
MIME", RFC 1556, Israeli Inter-University Computer
Center, December 1993.
[RFC-1590]
Postel, J., "Media Type Registration Procedure", RFC
1590, USC/Information Sciences Institute, March 1994.
[RFC-1602]
Internet Architecture Board, Internet Engineering
Steering Group, Huitema, C., Gross, P., "The Internet
Standards Process -- Revision 2", March 1994.
[RFC-1652]
Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M.,
Stefferud, E., and Crocker, D., "SMTP Service Extension
for 8bit-MIME transport", RFC 1652, United Nations
University, Innosoft, Dover Beach Consulting, Inc.,
Network Management Associates, Inc., The Branch Office,
March 1994.
[RFC-1700]
Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, USC/Information Sciences Institute, October
1994.
[RFC-1741]
Faltstrom, P., Crocker, D., and Fair, E., "MIME Content
Type for BinHex Encoded Files", December 1994.
[RFC-1896]
Resnick, P., and A. Walker, "The text/enriched MIME
Content-type", RFC 1896, February, 1996.
[RFC-2045]
Freed, N., and and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, Innosoft, First Virtual Holdings,
November 1996.
参考 TR X 0069:2002 多目的インターネットメール拡張(MIME) 第1部 インターネット
メッセージ本体のフォーマット が, この規定に一致している。
[RFC-2046]
Freed, N., and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
Innosoft, First Virtual Holdings, November 1996.
参考 TS X 0070:2004 多目的インターネットメール拡張(MIME) 第2部 メディア型 が,
この規定に一致している。
[RFC-2047]
Moore, K., "Multipurpose Internet Mail Extensions (MIME)
Part Three: Representation of Non-ASCII Text in Internet
17
Message Headers", RFC 2047, University of
Tennessee, November 1996.
参考 TS X 0071:2004 多目的インターネットメール拡張(MIME) 第3部 非ASCIIテキスト
へのメッセージヘッダ拡張 が, この規定に一致している。
[RFC-2048]
Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: MIME
Registration Procedures", RFC 2048, Innosoft, MCI,
ISI, November 1996.
参考 TS X 0106:2005 多目的インターネットメール拡張(MIME)－第4部: 登録手続 が, この
規定に一致している。
[RFC-2049]
Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049 (this document), Innosoft, First
Virtual Holdings, November 1996.
[US-ASCII]
Coded Character Set -- 7-Bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[X400]
Schicker, Pietro, "Message Handling Systems, X.400",
Message Handling Systems and Distributed Applications, E.
Stefferud, O-j. Jacobsen, and P. Schicker, eds., NorthHolland, 1989, pp. 3-41.
18
[附属資料－Ａ．１．３]
多目的インターネットメール拡張（MIME）－第１部：
インターネットメッセージ本体のフォーマット
標準仕様書(TS) TS X 0069:2005
多目的インターネットメール拡張(MIME)－
第1部: インターネットメッセージ本体のフォーマット
まえがき
この規定は，工業標準化法に基づいて，日本工業標準調査会の審議を経て，経済産業大臣が公表した標準仕
様書(TS)である。
この標準仕様書(TS)の一部が，技術的性質をもつ特許権，出願公開後の特許出願， 実用新案権又は出願公開
後の実用新案登録出願に抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査
会は，このような技術的性質をもつ特許権，出願公開後の特許出願，実用新案権又は出願公開後の実用新案
登録出願にかかわる確認について，責任はもたない。
原規定の状態
原規定(RFC 2045)は，インターネットコミュニティのインターネット標準化手続きで開発されたプロトコル
を規定するものであって，改善のための議論及び助言を要求する。このプロトコルの標準化状況及び状態に
ついては，現在の版のインターネット公式プロトコル規定(Internet Official Protocol Standards) (STD
1)を参照のこと。原規定の配布に制限はない。
著作権
原規定(RFC 2045)に関する著作権は，The Internet Societyに帰属する。
この標準仕様書(TS)には，次に示す附属書及び解説がある。解説は, 原規定には含まれていない。
z
z
附属書1(参考) 原規定の著者の連絡先
附属書A. 文法一覧
1
目 次
1. 導入
2. 定義，規約及び共通 BNF 文法
2.1 CRLF(復帰改行)
2.2 文字集合
2.3 メッセージ
2.4 実体
2.5 本体部分
2.6 本体
2.7 7 ビットデータ
2.8 8 ビットデータ
2.9 2 値データ
2.10 行
3. MIME ヘッダフィールド
4. MIME-Version(MIME 版)ヘッダフィールド
5. Content-Type（内容型）ヘッダフィールド
5.1 Content-Type ヘッダフィールドの構文
5.2 Content-Type デフォルト
6. Content-Transfer-Encoding(内容転送符号化)ヘッダフィールド
6.1 Content-Transfer-Encoding 構文
6.2 Content-Transfer-Encoding セマンティクス
6.3 新しい Content-Transfer-Encoding
6.4 解釈と及び使用
6.5 翻訳符号化符号化の変換
6.6 正準符号化モデル
6.7 Quoted-Printable(印字可能引用) Content-Transfer-Encoding
6.8 Base64 Content-Transfer-Encoding
7. Content-ID(内容識別子)ヘッダフィールド
8. Content-Description(内容記述)ヘッダフィールド
9. 追加の MIME ヘッダフィールド
10. まとめ
11. セキュリティへの考慮
12．附属書 1(参考) 原規定の著者の連絡先
附属書 A. 文法一覧
解説
2
標準仕様書(TS)
TS X 0069:2005
多目的インターネットメール拡張(MIME)－
第1部: インターネットメッセージ本体のフォーマット
Multipurpose Internet Mail Extensions (MIME) —
Part 1: Format of Internet Message Bodies
序文
この標準仕様書(TS)は，1996年11月にInternat Engineering Task Force (IETF)から公表されたRFC 2045
"Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"を翻訳
し，技術的内容を変更することなく作成した標準仕様書(TS)である。
1. 導入
1.1 適用範囲
インターネット公式プロトコル規定STD 11であるRFC 822では，US-ASCIIメッセージヘッダについて多くの詳
細を規定したメッセージ表現プロトコルを定義しているが，メッセージ内容，すなわちメッセージ本体につ
いては，構造のないUS-ASCIIテキストだけとしている。この標準仕様書(TS)を含む一連の標準情報(TR)及び
標準仕様書(TS)は，多目的インターネットメール拡張又はMIMEと総称され，次のことを可能とするために，
メッセージのフォーマットを再定義する。
1.
2.
3.
4.
US-ASCII以外の文字集合でのテキストのメッセージ本体。
非テキストのメッセージ本体のための異なるフォーマットの拡張集合。
マルチパートのメッセージ本体。
US-ASCII以外の文字集合でのテキストのヘッダ情報。
MIMEを規定する一連の標準情報(TR)及び標準仕様書(TS)は，RFC 934，STD 11及びRFC 1049に文書化されてい
る初期の成果に基づくが，それらを拡張及び改訂する。RFC 822では，メッセージ本体についてはごくわずか
に示しているだけなので，これらの標準情報(TR)及び標準仕様書(TS)の大部分は，RFC 822の改訂というより
は，RFC 822を補うものである。
これら一連の標準情報(TR)及び標準仕様書(TS)の最初であって，RFC 2045を原規定とするこの標準仕様書
(TS)では，MIMEメッセージの構造を記述するために使用される多くのヘッダを規定する。2番目のRFC 2046を
原規定とする標準情報(TR)では，MIMEメディア型付けシステムの一般的構造を定義し，メディア型の初期集
合を定義する。3番目のRFC 2047を原規定とする標準情報(TR)では，インターネットメールヘッダフィールド
の中で非US-ASCIIデータを可能にするためのRFC 822の拡張について記述する。4番目のRFC 2048を原規定と
する標準仕様書(TS)では，MIME関連機能のための多くのIANA登録手続きについて規定する。最後の5番目の
RFC 2049を原規定とする標準仕様書(TS)では，MIME適合基準について記述し，それと共に，幾つかのMIMEメ
ッセージフォーマットの例示，貢献者及び参考文献を提供する。
RFC 2045, RFC 2046, RFC 2047, RFC 2048及びRFC 2049は，RFC 1521, RFC 1522及びRFC 1590の改訂であっ
て，RFC 1521, RFC 1522及びRFC 1590はRFC 1341及びRFC 1342の改訂であった。RFC 2049を原規定とする標
準仕様書(TS)の附属書に，過去の版との違い及び変更について記述する。
1.2 概要
RFC 822は，1982年に出版されて以来，インターネットにおけるテキストのメールメッセージの標準フォーマ
ットを定義してきた。このフォーマットは成功を修め，インターネット及びRFC 821で定義されるインターネ
ットSMTPトランスポートの範囲外においても，RFC 822のフォーマットが全部又は一部採択されるなどしてい
る。このフォーマットは，広範に使えるようにみえるが，利用者コミュニティにとって制約となる，数々の
3
限界があることが，明らかになってきた。
RFC 822はテキストメッセージのためのフォーマットを規定することを想定していた。したがって，音声又は
画像を含むかもしれないマルチメディアメッセージなどの，非テキストメッセージについては言及していな
い。テキストの場合であっても，US-ASCIIより豊富な文字集合の使用を必要とする言語を使うメール利用者
の必要を満たさない。RFC 822は，音声，映像，アジア言語のテキスト，又は大部分の欧州言語のテキストで
さえも，それらを含むメールのための機構を規定していないので，追加の規定が必要になる。
RFC 821及びRFC 822に基づくメールシステムの顕著な制限の一つは，電子メールメッセージの内容が，7ビッ
トのUS-ASCIIの比較的短い行(例えば，1000文字以下 [RFC-821])に制限されるということである。このこと
は，局所的なメールUA(利用者エージェント，人間の利用者がメールを送信したり受信したりするプログラ
ム)を起動する前に，テキストでない送りたいデータを，印字可能なUS-ASCII文字で表現される7ビットのバ
イト列に変換することを，利用者に強いる。インターネットで現在使われているこのような符号化の例に
は，純粋な16進数，uuencode，RFC 1421で規定される3-in-4 base 64方式，Andrewツールキット表現
[ATK]，及びその他の多くの符号化がある。
RFC 822ホストとX.400ホストとの間のメールメッセージの交換を可能にするために，ゲートウェイが設計さ
れると，RFC 822メールの制限はさらに明らかになった。X.400 [X400] は，電子メールメッセージ内にテキ
ストでないデータを含める機構を規定する。X.400メッセージにRFC 822メッセージを対応付けするための現
在の規格は，テキストでないX.400のデータを，IA5Textフォーマットに(符号化するのではなく)変換する
か，又は，RFC 822利用者に廃棄が起こったことを通知して廃棄するかのどちらかでなければならないことを
規定する。このことは，利用者が受け取ることを望むかもしれない情報を失うので，明らかに好ましくな
い。利用者エージェントがテキストでないデータを処理する能力をもたない場合であっても，利用者は，デ
ータから利用可能な情報を抽出する機構をUAの外部にもっているかもしれない。さらに，こうした状況は，
メッセージが最終的にX.400メッセージ通信処理システムへゲートウェイによって転送されて(すなわち，
X.400メッセージがインターネットメールを通り抜けるだけで)，テキストでない情報が確かに再び使えるよ
うになる，ということを許容しない。
この標準仕様書(TS)は，現存するRFC 822の世界に深刻な非互換性をもたらすことなしに，これらの問題の多
くを解決するために組み合わせて使う，幾つかの機構について記述する。特に，次の四つの事項を記述す
る。
(1) MIME-Version(MIME版)ヘッダフィールド。 MIMEに適合するメッセージを宣言するために版番号を使用
し，MIMEに適合するメッセージと，このようなフィールドがないことを仮定した旧式又は非適合のソフトウ
ェアによって作成されたメッセージとを，メール処理エージェントが区別することを可能にする。
(2) Content-Type(内容型)ヘッダフィールド。 RFC 1049から一般化されたもので，メッセージの本体のデー
タのメディア型及び下位型を指定するため，並びにこれらのデータの本来の表現(正準形式)を完全に指定す
るために使用することができる。
(3) Content-Transfer-Encoding(内容転送符号化)ヘッダフィールド。本体に適用された符号化変換及びその
結果の領域の双方を指定するのに使用することができる。同一(identity)変換以外の符号化変換は，通常，
データ又は文字集合に制限をもつかもしれないメール転送機構を通り抜けることを可能にするために，デー
タに適用される。
(4) Content-IDヘッダフィールド及びContent-Descriptionヘッダフィールド。本体内のデータをさらに記述
するために使うことができる二つの追加のヘッダフィールドである。
この標準仕様書(TS)で定義されるすべてのヘッダフィールドは，RFC 822に規定されるヘッダフィールドの一
般構文規則に従っている。特に，Content-Disposition(内容配置)を除くこれらのすべてのフィールドは，意
味的な内容をもたずMIME処理中には無視することが望ましいRFC 822注釈を含むことができる。
最後に，相互運用性を規定し促進するため，RFC 2049を原規定とする標準仕様書(TS)は，この標準仕様書
(TS)に"適合"する最小限のレベルを定義する上記機構のサブセットのための，基本的な適用可能性宣言を提
供する。
4
備考 MIMEを規定する標準情報(TR)及び標準仕様書(TS)に記述される機構の多くは，最初に読むときには，幾
分不思議又は風変わりに思われるかもしれない。既存の規定との互換性及び既存の実践における頑健さは，
この一連の標準情報(TR)及び標準仕様書(TS)の原規定を作成した作業グループの，最優先事項のうちの二つ
であった。特に，互換性が，優雅さよりも，常に支持された。このプロトコルの標準化状況及び状態につい
ては，"インターネット公式プロトコル規定"の現在の版を参照すること。RFC 822及びSTD 3であるRFC 1123
も，MIMEの適合実装はそれらに違反できないため，MIMEの本質的な背景を供給している。加えて，他の多く
の参考情報(Informational) RFC文書，特に，RFC 1344，RFC 1345及びRFC 1524は興味深いであろう。
2. 定義，規約及び共通BNF文法
MIMEを規定する標準情報(TR)及び標準仕様書(TS)で規定される機構は，すべて通常の文章で記述されている
が，そのほとんどはRFC 822の強化BNF記法を用いて形式的にも記述される。実装者は，MIMEを規定する標準
情報(TR)及び標準仕様書(TS)を理解するためには，この記法に親しむ必要があり，強化BNF記法の完全な説明
のためにRFC 822を参照する。
MIMEを規定する標準情報(TR)及び標準仕様書(TS)における強化BNFの幾つかは，RFC 822で定義される構文規
則へ名前付きで参照されている。そのため，完全な形式文法は，MIMEを規定する標準仕様書(TS)の文法一覧
の附属書と，RFC 822のBNF及びRFC 1123で定義されるRFC 822の修正(具体的にいうと，"return"，"date"及
び"mailbox"の構文の変更)とを組み合わせることによって得られる。
MIMEを規定する標準情報(TR)及び標準仕様書(TS)では，すべての数値及びオクテット値は，10進記法で与え
られる。定義されているとおりの，すべてのメディア型値，下位型値及びパラメタ名は，大文字・小文字を
区別しない。しかし，パラメタ値は，特定のパラメタで特に指定される場合を除いて，大文字・小文字を区
別する。
備考 本質的な事項を失うことなく読み飛ばしてもよい，追加の非本質的な情報は，このような備考として提
供する。これらの非本質的な備考の主な目的は，MIMEを規定する標準情報(TR)及び標準仕様書(TS)の理論的
根拠についての情報を与えること，又はMIMEを規定する標準情報(TR)及び標準仕様書(TS)を適切な歴史的又
は発展的な文脈に位置づけることである。これら情報は，とりわけ，適合した実装を構築することだけに注
目している人々は読み飛ばしてもよいが，特定の設計上の選択が何故なされたかを理解したい人々には有用
かもしれない。
2.1 CRLF(復帰改行)
用語CRLFは，MIMEを規定する標準情報(TR)及び標準仕様書(TS)では，CR(10進の値が13)及びLF(10進の値が
10)の二つのUS-ASCII文字に対応し，この順番で一緒に用いられ，RFC 822メールでは行区切りを示してい
る，オクテット列とする。
2.2 文字集合
用語"文字集合"は，MIMEでは，オクテット列を文字列に変換する方法とする。無条件であいまい性のない逆
方向への変換は要求されないことに注意すること。すなわち，一つの与えられた文字集合が，必ずしもすべ
ての文字を表現できないともよいし，特定の文字列を表現するのに二つ以上のオクテット列を提供してもよ
い。
この定義は，US-ASCIIなどの単純な単一の表による対応付けから，ISO 2022の技法を使う複雑な表切換え方
法まで，多くの種類の文字符号化を，文字集合として使用するために許すことが意図されている。しかし，
MIME文字集合名に関連する定義は，実行される対応付けを完全に規定しなければならない。特に，正確な対
応付けを決定する外部プロファイル情報を使用してはならない。
備考 用語"文字集合"は，元来は，1オクテットから1文字への単純な1対1写像(対応付け)をもつ，US-ASCII及
びISO-8859-1といった単純な方式を記述するものであった。複数オクテット符号化文字集合及び切換え技法
は，状況をより複雑にしている。例えば，ある人々は，MIMEでいうところの"文字集合(character set)"に対
して，"文字符号化(character encoding)"という用語を使うが，オクテットではない整数から文字への抽象
的な対応付けをあらわすのに"符号化文字集合(coded character set)"という語句を使う。
5
2.3 メッセージ
用語"メッセージ"は，さらに限定されない場合には，ネットワークに転送される(完全又は最上位の)RFC 822
メッセージを意味するか，又は"message/rfc822"若しくは"message/partial"の型で本体にカプセル化された
メッセージを意味する。
2.4 実体
用語"実体"は，特に，メッセージか，又はマルチパート実体の本体における複数の部分の一つか，それらの
いずれかの，MIMEで定義されたヘッダフィールド及び内容とする。これら実体の規定が，MIMEの本質になっ
ている。実体の内容は"本体"と呼ばれることが多いので，実体の本体について語ることは意味がある。実体
のヘッダには，どのような種類のフィールドも存在してよいが，実際には，"content-"で始まるフィールド
だけがMIMEに関係する意味をもつ。このことは，"content-"で始まらないフィールドが全く意味をもたない
ことを意味するわけではない。RFC822で意味が定義されている非MIMEヘッダフィールドをもつメッセージも
実体である。
2.5 本体部分
用語"本体部分"は，マルチパート実体の内部の実体とする。
2.6 本体
用語"本体"は，さらに限定されない場合には，実体の本体の意味とする。すなわち，メッセージ又は本体部
分の本体とする。
備考 2.3～2.6の四つの定義は，明らかに循環的である。MIMEメッセージ全体の構造は実際に再帰的なので，
このことは避けられない。
2.7 7ビットデータ
"7ビットデータ"は，CRLF行分離シーケンスの間の，998オクテット以下の相対的に短い行として表現される
データとする[RFC-821]。10進の値が127より大きいオクテットがあってはならず，NUL(10進の値が0のオクテ
ット)があってはならない。CR(10進の値が13)及びLF(10進の値が10)は，CRLF行分離シーケンスの一部として
だけ現れるものとする。
2.8 8ビットデータ
"8ビットデータ"は，CRLF行分離シーケンスの間の，998オクテット以下の相対的に短い行として表現される
データとする[RFC-821]。10進の値が127より大きいオクテットを使用してもよい。7ビットデータと同様に，
NULがあってはならず，CR(10進の値が13)及びLF(10進の値が10)は，CRLF行分離シーケンスとしてだけ現れる
ものとする。
2.9 2値データ
"2値データ"は，どのようなオクテットの列も含むことができるデータとする。
2.10 行
"行"は，CRLFシーケンスによって分離された，オクテットの列として定義される。この定義は，RFC 821及び
RFC 822の両方と整合している。"行"は，メッセージの中のデータの単位としてだけ参照され，利用者エージ
ェントが実際に表示するものと対応していてもよいし，対応していなくてもよい。
3. MIMEヘッダフィールド
MIMEは，MIME実体の内容を記述するために使用される多くの新しいRFC 822ヘッダフィールドを定義する。こ
れらのヘッダフィールドは，少なくとも次の二つの文脈で出現する。
6
1. 通常のRFC 822メッセージヘッダの一部として。
2. マルチパート構成内でMIME本体部分ヘッダの中で。
これらのヘッダフィールドの形式定義は，次のとおりとする。
entity-headers := [ content CRLF ]
[ encoding CRLF ]
[ id CRLF ]
[ description CRLF ]
*( MIME-extension-field CRLF )
MIME-message-headers := entity-headers
fields
version CRLF
; このBNF定義が含むヘッダフィールドの順序付けは,
; 無視するほうがよい。
MIME-part-headers := entity-headers
[ fields ]
; "content-"で始まらないすべてのフィールドは,
; 定義された意味をもつことはできず，無視してよい。
; このBNF定義が含むヘッダフィールドの順序付けは,
; 無視するほうがよい。
種々の特定のMIMEヘッダフィールドの構文は，4.以下に示す。
4. MIME-Version(MIME版)ヘッダフィールド
1982年にRFC 822が公開されて以来，それがインターネットメッセージのフォーマット規定として唯一のもの
であり，使われているフォーマットの規定を宣言する必要性はほとんど認知されていなかった。この標準仕
様書(TS)は，RFC 822を補完する独立の規定とする。この標準仕様書(TS)で，拡張は，RFC 822と互換性のあ
る方法で定義されてはいるが，そうであっても，新しい規定を用いてメッセージが作成されたかどうかを，
メール処理エージェントが知っていることが好ましいかもしれない状況が存在する。
そのために，この標準仕様書(TS)は，使われているインターネットメッセージ本体のフォーマット規定の版
を宣言するために使用する，新しいヘッダーフィールド"MIME-Version"を定義する。
この標準仕様書(TS)に従って作成されるメッセージは，このヘッダフィールドを，次のテキストをそのま
ま，含まなければならない。
MIME-Version: 1.0
このヘッダフィールドがあることは，メッセージがこの規定に従って作成されていることを明言している。
将来の規定がメッセージフォーマットの規定を再び拡張するかもしれないことを可能とするので，MIMEVersionフィールドの内容のための形式BNFは，次による。
version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
そこで，"1.0"を置き換える又は拡張するかもしれない，将来のフォーマット指定子は，ピリオドで分離され
た2つの整数フィールドに制限される。"MIME-Version"値が"1.0"以外のメッセージを受け取る場合，この規
定に適合するとみなすことはできない。
MIME-Versionヘッダフィールドは，メッセージの最上位に要求されることに注意すること。マルチパート実
体のそれぞれの本体部分には要求されない。"message/rfc822"型又は"message/partial"型の本体に組み込ま
れたヘッダに対しては，組み込まれたメッセージそれ自体がMIME適合になっていると主張される場合にだ
け，要求される。
この規定で定義されるとおりにMIMEと適合するメールリーダが，将来到着するかもしれない"1.0"以外の
7
MIME-Versionの値をもつメッセージをどう扱うのがよいかを，完全に規定することは可能ではない。
特定のメディア型の版管理は，MIME-Version機構を使っては，達成されないことに注意すること。特に，
application/postscriptといった幾つかのフォーマットは，メディアフォーマット内部に版番号付け規約を
もつ。これら規約が存在する場合には，MIMEはそれにとって代わることはしない。これら規約が存在しない
場合には，必要があれば，MIMEメディア型は，内容型フィールドの中で"version"パラメタを使うかもしれな
い。
備考 MIME-Versionの値を検査するとき，RFC 822注釈文字列がある場合には，それらを無視しなければなら
ない。特に，次の四つのMIME-Versionフィールドは等価とする。
MIME-Version: 1.0
MIME-Version: 1.0 (produced by MetaSend Vx.x)
MIME-Version: (produced by MetaSend Vx.x) 1.0
MIME-Version: 1.(produced by MetaSend Vx.x)0
MIME-Versionフィールドがなかった場合，受信側のメール利用者エージェントは，MIME要件に適合していて
もしていなくても，局所的な規約に基づき，メッセージの本体を解釈することを選んでよい。多くのこれら
規約は現在使われており，実際には非MIMEメッセージが，ほとんど何でも含むことができることに注意した
ほうがよい。
非MIMEメールメッセージが，実際にUS-ASCII文字集合を用いたプレーンテキストであるかは，確実ではな
い。これは，MIME以前の非標準の局所的な規約の集合を使って，他の文字集合を用いたテキスト，又は例え
ば圧縮(compress)されてuuencodeされたUNIX tarファイルなどの，自動的には認識できない方法によって表
現されたテキストでないデータを含むメッセージであるかもしれないことによる。
5. Content-Type(内容型)ヘッダフィールド
Content-Typeフィールドの目的は，受信側の利用者エージェントが，利用者にデータを表示するために，適
切なエージェント若しくは機構を選ぶこと，又は適切な方法でデータを扱うことができるほど十分に，本体
に含まれるデータを記述することとする。このフィールドに含まれる値は，メディア型と呼ばれる。
備考 Content-Typeヘッダフィールドは，最初，RFC 1049で定義された。RFC 1049では，より単純で強力では
ない構文を使っていたが，その多くは，この標準仕様書(及び原規定のRFC 2045)で与える機構と互換性があ
る。
Content-Typeヘッダフィールドは，メディア型及び下位型の識別子を与えること，及び特定のメディア型に
要求されてもよい補助情報を提供することによって，実体の本体中のデータの性質を指定する。メディア型
及び下位型の名前の後の，ヘッダフィールドの残りは，単に，"属性=値"の記法で指定されたパラメタの集合
とする。パラメタの順番は意味をもたない。
一般に，最上位のメディア型は，データの一般的な型を指定し，下位型は，そのデータの型に対する特定の
フォーマットを指定する。そこで，メディア型"image/xyz"は，利用者エージェントが"xyz"という特定の画
像フォーマットを知らなかったとしても，データが画像であることを知らせるのに十分である。これら情報
は，例えば，認識されない下位型からの生データを利用者に見せるかどうかを決定するのに使うことができ
る。これら動作は，テキストの認識されない下位型に対しては理にかなっているかもしれないが，画像又は
音声の認識されない下位型に対してはそうでないかもしれない。この理由から，テキスト，画像，音声及び
映像の登録された下位型は，実際には異なる型となる組込み情報を含まないほうがよい。これら複合フォー
マットは，"multipart"型又は"application"型を使用して表したほうがよい。
パラメタは，メディア下位型の修飾子であって，内容の性質には，基本的には影響しない。意味のあるパラ
メタの集合は，メディア型及び下位型に依存する。ほとんどのパラメタは，単一の特定の下位型に関連す
る。ただし，与えられた最上位のメディア型が，その型のどの下位型へも適用可能なパラメタを定義しても
よい。内容型又は下位型の定義によって，パラメタは必須であってもよいし，オプションであってもよい。
8
MIME実装は，認識しない名前のパラメタを無視しなければならない。
例えば，"charset"パラメタは，"text"のあらゆる下位型に適用できるが，"boundary"パラメタ
は，"multipart"メディア型のあらゆる下位型に要求される。
すべてのメディア型に適用される大域的に意味のあるパラメタは存在しない。真に大域的な機構は，MIMEモ
デルでは，付加的なContent-*ヘッダフィールドの定義によって，最もよく言及される。
七つの最上位メディア型の初期集合は，RFC 2046で定義される。そのうち五つは，MIME処理が関係する限り
においては，本質的に不透明な内容をもつ別々の型とする。残りの二つは，MIME処理系によって追加の処理
が必要な内容の複合型とする。
最上位メディア型のこの集合は，実質的に，完全となることを意図されている。一般に，サポートされる型
のより大きな集合への追加は，これら初期の型の新しい下位型を作ることによって，達成される。将来，こ
の規定への標準化手続き拡張によってだけ，より多くの最上位の型を定義してよい。何らかの理由によって
他の最上位型を使うことが望ましい場合，非標準の状況を示すため，及び将来の公式の名前と衝突する可能
性を避けるために，その型には，"X-"で開始する名前を与えなければならない。
5.1 Content-Typeヘッダフィールドの構文
Content-Typeヘッダフィールドの値は，RFC 822の強化BNF記法を用いて，次のとおりに定義される。
content := "Content-Type" ":" type "/" subtype
*(";" parameter)
; メディア型及び下位型の合致は，
; 常に大文字・小文字を区別しない。
type := discrete-type / composite-type
discrete-type := "text" / "image" / "audio" / "video" /
"application" / extension-token
composite-type := "message" / "multipart" / extension-token
extension-token := ietf-token / x-token
ietf-token := <標準化手続きRFCによって定義され，IANAで登録された拡張トークン>
x-token := <"X-"又は"x-"の2文字で始まり，空白を含まない，任意のトークン。>
subtype := extension-token / iana-token
iana-token := <公式に定義された拡張トークン。
この形式のトークンは，RFC2048で規定されるとおりに
IANAに登録されなければならない。>
parameter := attribute "=" value
attribute := token
; 属性の合致は，
; 常に大文字・小文字を区別しない。
value := token / quoted-string
token := 1*<SPACE，CTL，tspecialsを除く，任意の(US-ASCII) CHAR>
tspecials :=
"(" / ")" / "<" / "gt;" / "@" /
"," / ";" / ":" / "\" / <"gt;
"/" / "[" / "]" / "?" / "="
; パラメタ値内で使うため，
; quoted-stringでなければならない。
tspecialsの定義は，"/"，"?"及び"="の3文字を追加したこと，並びに"."を削除したこと以外は，RFC 822の
9
specialの定義と同じであることに注意すること。
下位型の指定は必須であることにも注意すること。すなわち，下位型の指定は，Content-Typeヘッダフィー
ルドから省いてはならない。このように，デフォルトの下位型は存在しない。
型名，下位型名及びパラメタ名は，大文字・小文字を区別しない。例えば，TEXT，Text及びTeXtは，等価な
最上位のメディア型とする。パラメタ値は，通常，大文字・小文字を区別するが，意図される使用によって
は，大文字・小文字を区別しないように解釈されることがある。例えば，マルチパート境界は大文字・小文
字を区別するが，message/External-bodyの"access-type"パラメタは大文字・小文字を区別しない。
引用文字列(quoted string)パラメタの値は引用符を含まないことに注意すること。すなわち，quotedstringの中の引用符はパラメタ値の一部ではなく，単にパラメタ値を区切るのに使われる。さらに，構造化
ヘッダフィールドに関するRFC 822規則に従う注釈は許される。そこで，次の二つの形式は完全に等価とす
る。
Content-type: text/plain; charset=us-ascii (Plain text)
Content-type: text/plain; charset="us-ascii"
この構文以外の，下位型名の定義における構文上の唯一の制約は，それらの使用は重複してはならないとい
う要求とする。すなわち，二つの異なる意味の"Content-Type: application/foobar"を使う，二つの異なる
コミュニティがあることは望ましくない。そこで，新しいメディア下位型を定義する過程は，制限を課すた
めの機構を意図しているのでなく，単純にそれらの定義及び使い方を公にする機構とする。そのために，新
しいメディア下位型を定義するための受け入れ可能な次の二つの機構が存在する。
1. "X-"で始まる私的な値は，外部での登録又は標準化なしに二つの協力的エージェントの間で双方で(合
意して)定義してよい。これら値は，登録又は標準化することはできない。
2. 新しい標準の値は，RFC 2048に記述されるとおりにIANAで登録するほうがよい。
MIMEを規定する2番目の，RFC 2046を原規定とする標準情報(TR)では，MIMEのメディア型の初期集合を定義す
る。
5.2 Content-Typeデフォルト
MIMEのContent-TypeヘッダなしのデフォルトのRFC 822メッセージは，このプロトコルによって，US-ASCII文
字集合によるプレーンテキストとされ，明示的に次のとおりに指定できる。
Content-type: text/plain; charset=us-ascii
このデフォルトは，Content-Typeヘッダフィールドが指定されなかった場合を想定している。構文的に有効
でないContent-Typeヘッダフィールドに遭遇したときにも，このデフォルトを想定することが望ましい。
MIME-Versionヘッダフィールドが存在し，Content-Typeヘッダフィールドが存在しない場合，受信側の利用
者エージェントは，プレーンUS-ASCIIテキストが送信者の意図であったと想定することもできる。MIMEVersionが存在しない，又は構文上有効でないContent-Typeヘッダフィールドが存在する場合であって，送信
者の意図が違っていたかもしれない場合であっても，プレーンUS-ASCIIテキストを想定してもよい。
6. Content-Transfer-Encoding(内容転送符号化)ヘッダフィールド
電子メールによって便利に転送できる多くのメディア型は，8ビット文字又は2値データとして，"自然な"フ
ォーマットで表現される。これらデータは，幾つかの転送プロトコルでは伝送することができない。例え
ば，RFC 821 (SMTP) は，メールメッセージを，末尾のCRLF行分離子を含む1000文字以下の行をもった7ビッ
トUS-ASCIIデータに制限する。
したがって，これらデータを7ビットの短い行のフォーマットに符号化する標準的な機構を定義する必要があ
る。制限の少ないトランスポート上での直接使用のために，制限の少ないフォーマットの中での符号化され
ていないデータを適切にラベル付けすることも望まれる。この標準仕様書(TS)は，これら符号化が新し
い"Content-Transfer-Encoding"ヘッダフィールドによって指示されることを規定する。このフィールドは，
10
今までのいかなる規定によっても定義されていない。
6.1 Content-Transfer-Encoding構文
Content-Transfer-Encodingフィールド値は，次に列挙されるとおり，符号化の型を指定する単一トークンと
する。形式文法は次による。
encoding := "Content-Transfer-Encoding" ":" mechanism
mechanism := "7bit" / "8bit" / "binary" /
"quoted-printable" / "base64" /
ietf-token / x-token
これらの値は大文字・小文字を区別しない。Base64，BASE64及びbAsE64はすべて等価とする。7BITの符号化
型は，本体が既に7ビットメールに使える表現であることを要求する。これは，デフォルト値とする。すなわ
ち，Content-Transfer-Encodingフィールドがない場合は，"Content-Transfer-Encoding: 7BIT"が仮定され
る。
6.2 Content-Transfer-Encodingセマンティクス
この単一のContent-Transfer-Encodingトークンは，実際には，二つの情報を提供する。これは，本体がどん
な種類の符号化変換に従っているか，そのために，それを元の形式に戻すためにどの復号操作が使わなけれ
ばならないか，及び結果の領域が何になるかを指定する。
Content-Transfer-Encodingの変換部は，符号化されたオクテットのいかなる列に対しても，符号化される前
の元のオクテット列に変換するか，又は符号化列として不正であることを示すかのいずれかを行なう，単一
の明確に定義された復号アルゴリズムを，明示的に又は暗黙的に，指定する。Content-Transfer-Encoding
は，適切な操作のために追加される外部プロファイル情報に依存することはない。復号器は，有効な符号化
に対して，単一の明確に定義された出力を生成しなければならないが，符号化器にはこのような制限はない
ことに注意すること。すなわち，与えれたオクテット列を，異なっている等価な符号化列へと符号化するこ
とは完全に正しい。
同一(符号化変換)，"quoted-printable"(印字可能引用)符号化及び"base64"符号化の三つの変換が，現在定
義されている。その(変換の)領域は，"binary"，"8bit"及び"7bit"とする。
Content-Transfer-Encoding値の"7bit"，"8bit"及び"binary"は，すべて同一符号化変換がなされること，す
なわち，いかなる符号化変換もなされないことを意味する。このように，それらは単に本体データの領域の
指示子として役に立ち，与えられたトランスポートシステムにおいて転送のために必要かもしれない符号化
の種類についての有用な情報を提供する。用語"7ビットデータ"，"8ビットデータ"及び"2値データ"は，すべ
て2.で定義されている。
quoted-printable符号化及びbase64符号化は，任意の領域からの入力を"7ビット"範囲のデータへと変換する
ので，制限のあるトランスポート上で運ぶのを安全にする。変換の特定の定義は，以下で与える。
正しいContent-Transfer-Encodingラベルが常に使われなければならない。8ビット文字を含む符号化されて
いないデータを"7bit"とラベル付けしてはならず，行に基づかない符号化されていないデータを"binary"以
外にラベル付けしてはならない。
メディア下位型と違って，Content-Transfer-Encoding値の増加は好ましくないし不必要でもある。しか
し，"7bit"領域への単一の変換だけを制定することはできそうにない。多くのバイナリデータの小規模で効
率的な符号化に対する要望と，ほとんどが7ビットだがすべてではないデータのある程度可読性のある符号化
に対する要望との間にはトレードオフが存在する。この理由によって，少なくとも二つの符号化機構，すな
わち，多かれ少なかれ可読性のある符号化(quoted-printable)及び"密な"又は"一様な"符号化(base64)が，
必要になる。
符号化されていない8ビットデータのメールトランスポートは，RFC 1652で定義されている。この標準仕様書
(TS)の原規定の初期の公開のときには，メール本体に符号化されていないバイナリデータを含めるのに適正
11
な，標準化されたインターネットメールトランスポートは存在しなかった。そこで，インターネットメール
において"binary" Content-Transfer-Encodingが実際に有効である状況は存在しなかった。しかし，2値メー
ルトランスポートがインターネットメールで現実のものとなるか，又はMIMEが他の2値可能なメールトランス
ポート機構と一緒に使われる場合には，2値の本体は，この機構を使うものとしてラベル付けされなければな
らない。
備考 Content-Transfer-Encodingフィールドのために定義される五つの値は，そのフィールドが符号化され
たアルゴリズム，又は符号化されない場合にはトランスポートシステム要件以外は，メディア型について何
も示唆しない。
6.3 新しいContent-Transfer-Encoding
実装者は，必要ならば，私的Content-Transfer-Encoding値を定義してよいが，例えば，"Content-TransferEncoding: x-my-new-encoding"など，非標準の状態を示す"X-"で始まる名前の，x-tokenを使わなければなら
ない。追加の標準化されたContent-Transfer-Encoding値は標準化手続きRFCによって規定されなければなら
ない。これら規定が満たさなければならない要件は，RFC 2048で与えられる。このようにして，"X-"で始ま
るものを除き，すべての内容転送符号化の名前空間は，IETFで将来の使用のために明示的に予約されてい
る。
参考 Content-Transfer-Encoding値は大文字・小文字を区別しないので，"X-"と"x-"とは同等である。
メディア型及び下位型と異なり，新しいContent-Transfer-Encoding値の生成は，ほとんど可能性のない利益
のために互換性を妨げることが多いと考えられるので，強く非推奨とする。
6.4 解釈及び使用
Content-Transfer-Encodingヘッダフィールドが，メッセージヘッダの一部として現れる場合，そのメッセー
ジの本体全体に適用される。Content-Transfer-Encodingヘッダフィールドが，実体ヘッダの一部として現れ
る場合，その実体全体に適用される。実体が"multipart"の型である場合，Content-Transfer-Encoding
は，"7bit"，"8bit"又は"binary"以外の値をもってはならない。"message"型の幾つかの下位型へは，さらに
厳しい制限を適用する。
ほとんどのメディア型は，ビットでなくオクテットを用いて定義されていて，ここで示される機構は，ビッ
トストリームではなく，任意のオクテットストリームを符号化するための機構となっていることに注意する
ほうがよい。これらの機構のうちの一つを通してビットストリームが符号化される場合，ネットワークで標
準のビット順(big-endian)，すなわち，ストリームの中で最初の方のビットが，8ビットバイトの中の高位ビ
ットになるように，まず最初にビットストリームが8ビットバイトストリームに変換されなければならない。
8ビット境界で終わらないビットストリームは，0を用いてパディングされなければならない。RFC 2046を原
規定とする標準情報(TR)は，"padding"パラメタをもつapplication/octet-streamメディア型の場合に，それ
らパディングの追加に言及する機構を提供する。
ここで定義する符号化機構は，US-ASCIIのすべてのデータを明示的に符号化する。そこで，例えば，次のヘ
ッダフィールドをもつ実体を想定する。
Content-Type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: base64
これは，本体が，元はISO-8859-1だったデータのbase64 US-ASCII符号化であって，復号後は，その文字集合
になることを意味すると，解釈されなければならない。
あるContent-Transfer-Encoding値は，あるメディア型だけに使われてもよい。特に，複合的なメディア型，
すなわち，他のContent-Typeフィールドを再帰的に含むメディア型をもつ，"7bit"，"8bit"又は"binary"以
外の符号化を使用することは，明確に禁止される。現在，複合的なメディア型は，"multipart"及
び"message"だけとする。multipart又はmessageの型の本体のために望まれるすべての符号化は，符号化され
ることが必要な実際の本体を符号化することによって，最も内側のレベルでなされなければならない。
定義によって，複合的な実体が"7bit"といった転送符号化値をもつが，それに取り囲まれた実体の一つ
12
が"8bit"といったより制限のゆるい値をもつ場合，外側の"7bit"というラベル付けは，8ビットデータが含ま
れているので，エラーであるか，又は内側の"8bit"というラベル付けは，実際の含まれているデータが7ビッ
ト安全だったので，トランスポートシステムに不必要な高い要求を課すことになる，ということにも注意す
ること。
備考 複合的な本体データに内容転送符号化(content-transfer-encoding)を使うことを禁止するのは過度に
制限的と思われるかもしれないが，これは，データが一つの符号化アルゴリズムを複数回通過し，適切に見
るために複数回復号をしなければならないという，入れ子になった符号化を防ぐために必要とする。入れ子
になった符号化は，利用者エージェントに相当な複雑さを加える。これら複数回符号化の明白な効率の問題
とは別に，入れ子になった符号化は，メッセージの基本構造を不明瞭にすることがある。特に，入れ子にな
った符号化は，メッセージがどんな型の本体を含むかを単に見つけるために，何回もの復号操作が必要にな
ることを示唆する。入れ子になった符号化を禁止することは，特定のメールゲートウェイの仕事を複雑にす
るかもしれないが，入れ子になった符号化が利用者エージェントへ及ぼす影響に比べれば，問題が少ないよ
うに思われる。
認識されないContent-Transfer-Encodingをもつ実体は，Content-Typeヘッダフィールドに実際に何と書いて
あるかにかかわらず，"application/octet-stream"のContent-Typeをもつものとして取り扱われなければな
らない。
備考 Content-Transfer-Encodingは，符号化されるメディアの特質から推測できるか，又は少なくともある
Content-Transfer-Encodingを特定のメディア型とともに使用するのが必須となるものと思われるかもしれな
い。これが事実でない幾つもの理由がある。まず，メールに使われるトランスポートの様々な型を与えられ
た場合，ある符号化はメディア型とトランスポートとのある組合せに対して適切だが，他の組合せには適切
でなくともよい。例えば，8ビットトランスポートでは，特定の文字集合によるテキストに対して符号化は必
要でないが，7ビットSMTPでは，それら符号化が明白に必要とされる。
次に，特定のメディア型は，異なる状況では異なる型の転送符号化を要求することがある。例えば，多くの
PostScriptの本体は，全体的には7ビットデータの短い行から構成されるかもしれないので，その場合，符号
化は必要でない。他のPostScriptの本体，特に，レベル2 PostScriptの2値符号化機構を使った本体は，2値
トランスポート符号化を使った場合にだけ適切に表現されてよい。最後に，Content-Typeフィールドは拡張
可能な指定機構となることを意図しているので，メディア型と符号化との間の関連の厳密な指定が，応用プ
ロトコルの指定と特定の下位トランスポートとを効果的に結びつけることになる。このことは，メディア型
の開発者が，使われているすべてのトランスポート及びそれらの制限について意識しなければならないの
で，好ましくない。
6.5 符号化の変換
quoted-printable符号化及びbase64符号化は，それらの間の変換が可能なように設計されている。これら変
換において生じる唯一の課題は，quoted-printable符号化出力での指定(hard)行区切りの扱いである。
quoted-printableからbase64に変換するとき，quoted-printable形式の指定(hard)行区切りは，データの正
準形式のCRLF列で表現される。そこで，その行区切りは，データのbase64形式での対応する符号化された
CRLFへ変換されなければならない。同様に，base64復号後に得られるデータの正準形式でのCRLF列は，テキ
ストデータを変換するときにだけ，quoted-printableでの指定(hard)行区切りに変換されなければならな
い。
6.6 正準符号化モデル
この標準仕様書(TS)の原規定であるRFCの以前の版では，電子メールデータが正準形式に変換され符号化され
るときのモデルについて，特に，システムごとに改行の表現が非常に異なっているときに，この(変換)処理
が，CRLFの振る舞いにどう影響するか，及び内容転送符号化と文字集合との間の関係にどう影響するかにつ
いて，多少の混乱があった。この理由から，符号化のための正準モデルが，RFC 2049で提示される。
6.7 Quoted-Printable(印字可能引用)Content-Transfer-Encoding
Quoted-Printable符号化は，大部分がUS-ASCII文字集合の中の印字可能文字に対応するオクテットから構成
されるデータを表現することを意図している。この符号化は，結果として生じるオクテットがメールトラン
13
スポートによって修正されることはまずないといった方法で，データを符号化する。符号化されるデータが
ほとんどUS-ASCIIテキストの場合，データの符号化された形式は，人によって大部分認識可能なままになっ
ている。全体がUS-ASCIIである本体も，文字変換及び/又は行折返しを行うゲートウェイをメッセージが通過
する場合に，データの完全性を保証するために，Quoted-Printableによって符号化してもよい。
この符号化では，オクテットは，次の規則によって決定されるとおりに表現されるのが望ましい。
1. 一般8ビット表現
符号化されるデータの正準形式(標準形式)のCRLF行区切りの一部であるCR又はLFを除くあらゆるオクテ
ットは，一つの"="にそのオクテットの値の16進表現の二つの数字(2桁の16進数)を続けたもので表して
よい。この目的のために使う16進の数字は，"0123456789ABCDEF"とする。大文字を使わなくてはなら
ず，小文字は使ってはならない。例えば，10進の値が12(US-ASCII form feed)は"=0C"で表現でき，10
進の値が16(US-ASCII EQUAL SIGN)は"=3D"で表現できる。後続の規則が代替の符号化を許す場合を除
き，この規則には従わなければならない。
2. 文字表現
10進の値が33以上60以下及び62以上126以下のオクテットは，それらのオクテットに対応するUS-ASCII
文字，それぞれ，EXCLAMATION POINTからLESS THANまで及びGREATER THANからTILDEまで，として表現
してよい。
3. 空白
10進の値が9及び32のオクテットは，US-ASCIIのTAB(HT)文字及びSPACE文字として表現してよいが，符
号化された行の末尾で表現してはならない。そこで，符号化された行のTAB(HT)文字及びSPACE文字に
は，印字可能文字がその行で後続しなければならない。特に，符号化された行の末尾の"="は，無指定
(soft)行区切り(5番目の規則を参照)を示しているが，一つ以上のTAB(HT)文字又はSPACE文字に続いて
もよい。これは，符号化された行の末尾で10進の値が9又は32のオクテットは，1番目の規則によって表
現されなければならないことに従っている。MTA[Message Transport Agent(メッセージ転送エージェン
ト)，すなわち，一人の利用者から他の利用者へのメッセージを転送する，又はそれら転送の一部を実
行するプログラム]の中には，テキストの行をSPACEでパディングするものがあることが知られていて，
さらに行末から"空白"文字を取り除くものも知られているので，この規則が必要になる。そのために，
中間の転送エージェントによって空白が加えられることが避けがたいので，Quoted-Printable本体を復
号するとき，行の末尾についているすべての空白を削除しなければならない。
4. 改行
テキストの正準形式ではCRLF列として表現される，テキスト本体中の行区切りは，Quoted-Printable符
号化では，やはりCRLF列であるRFC 822の行区切りによって表現されなければならない。テキスト以外
のメディア型の正準表現は一般にはCRLF列としての行区切りの表現を含まないので，指定(hard)行区切
り(すなわち，意味があり，利用者に表示されることを意図している行区切り)は，これらの型の
quoted-printableには出現できない。もちろん，quoted-printableで表現されたテキストでないデータ
には，"=0D", "=0A", "=0A=0D"及び"=0D=0A"といった列は，機械的に現れることがある。
多くの実装は，まず正準形式に変換し，符号化し，それから局所的な表現に戻すのではなく，直接に
様々な内容型の局所的な表現を符号化することを選んでもよいことに注意すること。特に，このこと
を，CRLF終端子列ではない改行規約を使うシステムで，プレーンテキストのデータに適用してもよい。
このような実装の最適化は許されるが，(それと)組み合わされた正準化符号化の段階が，三つの段階を
別々に実施するのと等価な場合だけに限る。
5. 無指定(soft)行区切り
Quoted-Printable符号化では，符号化された行が76文字を超えてはならない。Quoted-Printable符号化
でそれより長い行が符号化される場合，"無指定(soft)"行区切りが使われなければならない。符号化さ
れた行の最後の文字としての等号は，符号化されたテキストの中で意味がない"無指定(soft)"行区切り
を示す。
そこで，行の"元の(raw)"形式が，次の符号化されていない単一の行の場合を考える。
Now's the time for all folk to come to the aid of their country.
14
Quoted-Printable符号化では，これを次のとおりに表せる。
Now's the time =
for all folk to come=
to the aid of their country.
これは，利用者エージェントによって元に戻されるといった方法で，長い行を符号化する機構を提供する。
76文字制限は，末尾のCRLFを数えないが，等号を含めた他のすべての文字を数える。
ハイフン文字("-")は，それ自体，Quoted-Printable符号化で表現してよいので，一つ以上のマルチパート実
体の内部にquoted-printableで符号化された本体をカプセル化するときには，その境界区切り子(1)が，符号
化された本体のどこにも現れないことを保証するために，注意をしなければならない。よい戦略としては，
quoted-printable(で符号化された)本体には現れることのない"=_"といった文字列を境界に選ぶことがあ
る。RFC 2046のマルチパートメッセージの定義を参照すること(1)。
注1
RFC 2046において，境界区切り子は，ハイフン文字を使って定義されている。
備考 quoted-printable符号化は，可読性と転送における信頼性との折衷的なものを表現している。quotedprintable符号化で符号化された本体は，ほとんどのメールゲートウェイにおいて高い信頼性で動作するが，
少数のゲートウェイ，特に，EBCDICへの変換を伴うものでは完全には動かないかもしれない。より高いレベ
ルの信頼性は，base64 Content-Transfer-Encodingによって提供される。EBCDICゲートウェイを通る妥当な
信頼性のある転送を得る方法は，1番目の規則に従って，次のUS-ASCII文字も，quoted-printable符号化する
ことである。
!"#$@[\]^`{|}~
quoted-printableデータは一般に行に基づくことを仮定しているので，改行規約の異なるシステム間で渡さ
れるとき，インターネットメールにおいてプレーンテキストメールが常に変更されてきたのと同じ様に，
quoted-printableデータの行の間の区切りの表現は，転送中に変更されるかもしれないと予想される。これ
ら変更が，データの変造を引き起こす可能性がある場合，quoted-printable符号化ではなく，base64符号化
を使うことが恐らくより賢明といえる。
備考 quoted-printable内容転送符号化のための符号化規則に従って，ある種の部分文字列を生成することは
できない。したがって，quoted-printable符号化器の出力にそれらが出現する場合は，形式的には不正とす
る。この備考は，これらの場合を列挙し，復号されるquoted-printableデータの中で次のどれかに出会う場
合，それら不正な部分文字列を取り扱う方法を示す。
1. 一つ又は両方が"abcdef"のうちのいずれかの小文字となっている二つの16進数字に後続される"="は，
形式的には不正とする。頑健な実装は，それらを対応する大文字として認識するとよいかもしれない。
2. "abcdef"の場合を含む16進の数字でなく，CRLF対のCR文字でもない文字に後続される"="は，不正とす
る。この場合は，それ自体がquoted-printable符号化に従っていない，メッセージのquoted-printable
部分に含まれている，US-ASCIIテキストの結果の可能性がある。頑健な実装でによる理にかなった方針
は，復号されたデータに，"="文字及びそれに後続する(一つの)文字を変換せずに含ませ，可能な場合
には，利用者に，データのこの箇所で適切な復号ができなかったことを示すことかもしれない。
3. "="は，符号化されたオブジェクトの中で最後又は最後から2番目の文字となることはできない。これ
は，前項の場合として取り扱ってよい。
4. TAB，又はCRLF対の一部としてのCR及びLF，以外の制御文字は現れてはならない。10進の値が126より大
きい値のオクテットに対しても同じとする。それら文字が，復号器によって，到着したquotedprintableデータの中に発見された場合，頑健な実装は，復号されたデータからそれら文字を除外し，
利用者に不正文字が発見されたことを警告するとよいかもしれない。
5. 符号化した行は，末尾のCRLFを数えずに，76文字より長くてはならない。より長い行が到着した符号化
されたデータの中に発見された場合，頑健な実装は，エラーではあるがその行を復号し，利用者にエラ
ーのある符号化であることを報告するとよいかもしれない。
備考 2値データがquoted-printableで符号化される場合，CR文字及びLF文字をそれぞれ"=0D"及び"=0A"とし
て符号化することに注意しなければならない。特に，2値データでのCRLF列は，"=0D=0A"と符号化するのがよ
い。そうでない場合であって，CRLFが指定(hard)行区切りとして表現される場合，異なった行区切り規約を
15
もつプラットホームでは，正しく復号されないかもしれない。
quoted-printableデータの構文は，次の形式文法で記述される。
quoted-printable := qp-line *(CRLF qp-line)
qp-line := *(qp-segment transport-padding CRLF)
qp-part transport-padding
qp-part := qp-section
; 最大長76文字。
qp-segment := qp-section *(SPACE / TAB) "="
; 最大長76文字。
qp-section := [*(ptext / SPACE / TAB) ptext]
ptext := hex-octet / safe-char
safe-char := <10進の値が33～60及び62～126をもつ任意のオクテット>
; さらに，RFC 2049の"mail-safe"の一覧にない
; 文字も推奨しない。
hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; 127より大きな文字，=，又は行末のSPACE若しくはTABには
; オクテットが使われなければならず，
; RFC 2049で"mail-safe"の一覧にない文字のためには
; オクテットが推奨される。
transport-padding := *LWSP-char
; 送信者は，長さが0ではないトランスポート
; パディングを生成してはならないが，
; 受信者は，メッセージトランスポート
; によって追加されたパディングを
; 処理できなければならない。
このBNFでは構造化ヘッダフィールドを規定していないので，このBNFに示される要素間でのLWSPの追加は許
されない。このことは，重要である。
6.8 Base64 Content-Transfer-Encoding
Base64 Content-Transfer-Encodingは，任意のオクテット列を，人が読めなくともよい形式で，表現するた
めに設計された。符号化及び復号のアルゴリズムは単純だが，符号化されたデータは，符号化されていない
データに比べ，一貫しておよそ33パーセントほど大きい。この符号化は，実質的に，RFC 1421で定義されて
いる，Privacy Enhanced Mail (PEM) アプリケーションと同等になっている。
US-ASCIIの65文字の部分集合を使用し，印字可能な一つの文字ごとに6ビットを表現可能とする。65番目の文
字"="は，特別な処理機能を意味するために使用する。
備考 この部分集合は，US-ASCIIを含むISO 646のすべての版で同一に表現されるという，重要な特性を持
ち，こののすべての文字は，EBCDICのすべての版でも，同一に表現される。uuencodeユティリティ，
Macintoshのbinhex 4.0 [RFC-1741]及びLevel 2 PostScriptの一部として規定されるbase85符号化といっ
た，他のよく利用される符号化は，この特性を共有せず，そのために，メール用の2値転送符号化が満たさな
ければならない可搬性要件を満足しない。
符号化処理は，四つの符号化文字の出力列として，入力ビットの24ビット(単位の)群(24-bit group)を表現
する。左から右へと進めて，一つの24ビットの入力群が，三つの8ビット入力群を連結することによって，形
成される。次に，これらの24ビットを，四つの連結された6ビット群として取り扱い，それぞれをbase64アル
ファベット(base64の構成単位)における単一の数字へと変換する。base64符号化を通じてビットストリーム
を符号化する場合，ビットストリームは，最上位ビットが先になる順番と仮定されていなければならない。
すなわち，ビットストリームの最初のビットは，最初の8ビット(単位の)バイトの中の上位ビットとなり，8
16
番目のビットは，最初の8ビット(単位の)バイトの中の下位ビットとなる，など，以下同様とする。
それぞれの6ビット群は，64個の印字可能文字の配列へのインデクスとして使われる。インデクスにより参照
される文字が，出力列の中に置かれる。次の表1で識別されるこれらの文字は，広い範囲で表現可能なように
選ばれ，例えば，"."，CR，LFなどの，SMTPに対して特定の意味をもつ文字，及び例えば"-"などのRFC 2046
で定義されるマルチパート境界区切り子に対して特定の意味をもつ文字を除外してある。
表1 Base64アルファベット
値
0
1
符号
A
B
値
17
18
符号
R
S
値
34
35
符号
i
j
値
51
52
符号
z
0
2
3
C
D
19
20
T
U
36
37
k
l
53
54
1
2
4
5
6
E
F
G
21
22
23
V
W
X
38
39
40
m
n
o
55
56
57
3
4
5
7
8
9
H
I
J
24
25
26
Y
Z
a
41
42
43
p
q
r
58
59
60
6
7
8
10
11
K
L
27
28
b
c
44
45
s
t
61
62
9
+
12
M
29
d
46
u
63
/
13
14
N
O
30
31
e
f
47
48
v
w
15
16
P
Q
32
33
g
h
49
50
x
y
(pad) =
符号化された出力ストリームは，それぞれ76文字を超えない行で表現されなければならない。すべての行区
切り又は表1にない他の文字は，復号ソフトウェアによって，無視されなければならない。base64データの中
の，表1以外の文字，行区切り及びその他の空白は，おそらく，ある状況では警告メッセージ又はメッセージ
拒否が適切かもしれない，転送誤りを示す。
符号化されるデータの末尾において，24ビットに満たない場合には，特別な処理が実行される。本体の末尾
では常に欠けることのない符号化の分量で完結する。入力群の中で，24よりも少ない入力ビットが存在する
場合，値0のビットが右に追加され，6ビット群を単位とする整数倍の数へと整形される。データの末尾への
パディングは"="文字を使って実行される。すべてのbase64入力はオクテットの整数倍の数なので，次の場合
だけが発生する。
1. 符号化入力の最後の分量が，24ビットの整数倍になっている。この場合，符号化出力の最後の単位(か
たまり)は，"="パディングなしで4文字の整数倍となる。
2. 符号化入力の最後の分量が，ちょうど8ビットになっている。この場合，符号化出力の最後の単位(かた
まり)は，二つの文字に，二つの"="パディング文字が後続したものとなる。
3. 符号化入力の最後の分量が，ちょうど16ビットになっている。この場合，符号化出力の最後の単位(か
たまり)は，三つの文字に，一つの"="パディング文字が後続したものとなる。
"="文字はデータの最後のパディングのためだけに用いられるので，途中で切り取られなかった場合に
は，"="文字の出現はデータの最後に到達した証拠とみなしてもよい。しかし，伝送されたオクテットの数が
3の倍数であって"="文字が存在しないときは，このような保証は可能ではない。
base64アルファベット以外の文字は，base64符号化データの中では，無視するのが望ましい。
17
正準形式に変換されていないテキストデータに対してbase64符号化を直接に適用する場合には，行区切りの
ために適切なオクテットを使うように注意しなければならない。特に，テキストの行区切りは，base64符号
化の前に，CRLF列に変換されなければならない。実装にの中には，この変換を，先行する正準化段階ではな
く，符号化器によって直接に行なうものもあるという点に注意することが重要である。
備考 マルチパート実体の内部のbase64符号化本体内で，存在する可能性のある境界区切り子を引用する
(quote)ことについては，心配する必要はない。これは，base64符号化では"-"(ハイフン)文字は使用されな
いことによる。
7. Content-ID(内容識別子)ヘッダフィールド
高機能の利用者エージェントを作成する際，ある本体が他の本体への参照を行なうのを可能にすることが望
まれる場合がある。それに従って，本体は，構文的にはMessage-IDヘッダフィールドと同一の，Content-ID
ヘッダフィールドを使ってラベル付けしてよい。
id := "Content-ID" ":" msg-id
Message-ID値と同様に，Content-ID値は，世界で一意となるように生成されなければならない。
Content-ID値は，幾つかの文脈においてMIME実体を一意に識別するために，特に，message/external-body機
構によって参照されるデータをキャッシュするために使ってよい。Content-IDは一般にオプションだが，オ
プションのMIMEメディア型である"message/external-body"のデータを生成する実装では，その使用は必須と
する。すなわち，それぞれのmessage/external-body実体は，これらデータのキャッシュ化を許すために
Content-IDフィールドをもたなければならない。
Content-ID値は，multipart/alternativeメディア型のの場合には特別なセマンティクスをもつことに注意す
ることも重要である。このことは，RFC 2046を原規定とする標準情報(TR)において，multipart/alternative
について扱う箇条で示される。
8. Content-Description(内容記述)ヘッダフィールド
説明的な情報を与えられた本体と関連付ける能力が，望まれることが多い。例えば，"image"本体に"スペー
スシャトルエンデバーの写真"といった印をつけることは役に立つかもしれない。それらテキストは，
Content-Descriptionヘッダフィールドの中に置いてよい。このヘッダフィールドは，常にオプションとす
る。
description := "Content-Description" ":" *text
この記述(description)は，US-ASCII文字集合で与えられることを想定する。ただし，RFC 2047で規定される
機構を使って，非US-ASCII文字をContent-Descriptionフィールドの値としてもよい。
9. 追加のMIMEヘッダフィールド
将来の規定では，種々の目的のために追加のMIMEヘッダフィールドを定義することを決定してもよい。メッ
セージの内容をさらに記述する新しいヘッダフィールドは，メッセージヘッダに現れるそれらフィールドを
通常のRFC 822ヘッダフィールドと区別するために，文字列"Content-"で始めることが望ましい。
MIME-extension-field := <文字列"Content-"で始まる
任意のRFC 822ヘッダフィールド>
10. まとめ
MIME-Versionヘッダフィールド，Content-Typeヘッダフィールド及びContent-Transfer-Encodingヘッダフィ
ールドを使って，標準化された方法で，RFC 822に適合するメールメッセージに任意の型のデータを含ませる
ことが可能になる。RFC 821又はRFC 822のどちらかによって課される制約に違反しない。幾つかのインター
ネットメール転送機構の特徴によって追加的に課される制約が引き起こす問題を避けるための注意が行なわ
18
れた。これについては，RFC 2049を原規定とする標準仕様書(TS)を参照すること。
MIMEを規定する一連の標準情報(TR)及び標準仕様書(TS)の中の，RFC 2046を原規定とする標準情報(TR)で
は，これらのヘッダを使ってラベル付けされ及び転送されることができるメディア型の初期集合を規定す
る。
11. セキュリティへの考慮
セキュリティに関しては，MIMEを規定する一連の標準情報(TR)及び標準仕様書(TS)の中の，RFC 2046を原規
定とする標準情報(TR)で論じられる。
12．附属書1(参考) 原規定の著者の連絡先
原規定(RFC 2045)についての追加的な情報のために原規定(RFC 2045)の著者に連絡をとる場合には，インタ
ーネットメールを使うほうがよい。
Ned Freed
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
USA
Phone: +1 818 919 3600
Fax: +1 818 919 3614
EMail: [email protected]
Nathaniel S. Borenstein
First Virtual Holdings
25 Washington Avenue
Morristown, NJ 07960
USA
Phone: +1 201 540 8967
Fax: +1 201 993 3032
EMail: [email protected]
MIMEは，Internet Engineering Task ForceのRFC 822の拡張に関する作業グループの作業の結果である。作
業グループ議長のGreg Vaudreuilには，次の連絡先によって連絡できる。
Gregory M. Vaudreuil
Octel Network Services
17080 Dallas Parkway
Dallas, TX 75248-1905
USA
EMail: [email protected]
19
附属書A. 文法一覧
附属書Aでは，この標準仕様書(TS)で規定されるすべての構文の，完全なBNF文法を示す。
しかし，この文法は，それ自体だけでは不完全である。この文法は，RFC 822で定義される幾つかの構文規則
を名前によって参照する。これらの定義をここで再び示し，二つの間で意図しない差異を生じる危険を冒す
のではなく，この規定は，残りの定義については，読者にRFC 822を参照してもらうことにした。項(term。
構文の中の終端子又は非終端子。)が定義されていない場合には，それは，RFC 822の定義を参照している。
attribute := token
; 属性の合致は，
; 常に大文字・小文字を区別しない。
composite-type := "message" / "multipart" / extension-token
content := "Content-Type" ":" type "/" subtype
*(";" parameter)
; メディア型及び下位型の合致は，
; 常に大文字・小文字を区別しない。
description := "Content-Description" ":" *text
discrete-type := "text" / "image" / "audio" / "video" /
"application" / extension-token
encoding := "Content-Transfer-Encoding" ":" mechanism
entity-headers := [ content CRLF ]
[ encoding CRLF ]
[ id CRLF ]
[ description CRLF ]
*( MIME-extension-field CRLF )
extension-token := ietf-token / x-token
hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; 127より大きな文字，=，又は行末のSPACE若しくはTABには
; オクテットが使われなければならず，
; RFC 2049で"mail-safe"の一覧にない文字のためには
; オクテットが推奨される。
iana-token := <公式に定義された拡張トークン。
この形式のトークンは，RFC2048で規定されるとおりに
IANAに登録されなければならない。>
ietf-token := <標準化手続きRFCによって定義され、IANAで登録された拡張トークン>
id := "Content-ID" ":" msg-id
mechanism := "7bit" / "8bit" / "binary" /
"quoted-printable" / "base64" /
ietf-token / x-token
MIME-extension-field := <文字列"Content-"で始まる
任意のRFC 822ヘッダフィールド。>
MIME-message-headers := entity-headers
fields
version CRLF
; このBNF定義が含むヘッダフィールドの順序付けは,
; 無視するほうがよい。
MIME-part-headers := entity-headers
[ fields ]
; "content-"で始まらないすべてのフィールドは,
20
; 定義された意味をもつことはできず，無視してよい。
; このBNF定義が含むヘッダフィールドの順序付けは,
; 無視するほうがよい。
parameter := attribute "=" value
ptext := hex-octet / safe-char
qp-line := *(qp-segment transport-padding CRLF)
qp-part transport-padding
qp-part := qp-section
; 最大長は76文字。
qp-section := [*(ptext / SPACE / TAB) ptext]
qp-segment := qp-section *(SPACE / TAB) "="
; 最大長は76文字。
quoted-printable := qp-line *(CRLF qp-line)
safe-char := <10進の値が33～60及び62～126をもつ任意のオクテット>
; さらに，RFC 2049の"mail-safe"の一覧にない
; 文字も推奨しない。
subtype := extension-token / iana-token
token := 1*<SPACE，CTL，tspecialsを除く，任意の(US-ASCII) CHAR>
transport-padding := *LWSP-char
; 送信者は，長さが0ではないトランスポート
; パディングを生成してはならないが，
; 受信者は，メッセージトランスポート
; によって追加されたパディングを
; 処理できなければならない。
tspecials :=
"(" / ")" / "<" / "gt;" / "@" /
"," / ";" / ":" / "\" / <"gt;
"/" / "[" / "]" / "?" / "="
; パラメタ値内で使うため，
; quoted-stringでなければならない。
type := discrete-type / composite-type
value := token / quoted-string
version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
x-token := <"X-"又は"x-"の2文字で始まり，空白を含まない，任意のトークン。>
21
[附属資料－Ａ．１．４]
ＸＳＬＴライブラリ
（第 4 章まで抜粋）
標準仕様書(TS) TS X 0059:2004
XSLTライブラリ
まえがき
この規定は, 工業標準化法に基づいて, 日本工業標準調査会の審議を経て, 経済産業大臣が公表した標準仕
様書(TS)である。
この標準仕様書(TS)の一部が, 技術的性質をもつ特許権, 出願公開後の特許出願, 実用新案権又は出願公開
後の実用新案登録出願に抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査
会は, このような技術的性質をもつ特許権, 出願公開後の特許出願, 実用新案権又は出願公開後の実用新案
登録出願にかかわる確認について, 責任はもたない。
この標準仕様書(TS)には, 次に示す附属書及び解説がある。
附属書A.
附属書B.
附属書C.
附属書D.
附属書E.
文字列処理サンプルXMLインスタンス
タグの処理サンプルXMLインスタンス
属性の処理サンプルXMLインスタンス
日本語処理サンプルXMLインスタンス
目次・索引の生成サンプルXMLインスタンス
1
目　次
序文
1. 適用範囲
2. 引用規定
3. 定義
4. 機能
4.1 文字列処理
4.2 タグの処理
4.3 属性の処理
4.4 日本語処理
4.5 目次・索引の生成
5. ライブラリ
5.1 文字列処理
5.2 タグの処理
5.3 属性の処理
5.4 日本語処理
5.5 目次・索引の生成
附属書 A.
附属書 B.
附属書 C.
附属書 D.
附属書 E.
文字列処理サンプル XML インスタンス
タグの処理サンプル XML インスタンス
属性の処理サンプル XML インスタンス
日本語処理サンプル XML インスタンス
目次・索引の生成サンプル XML インスタンス
解説
2
標準仕様書(TS) TS X 0059:2004
XSLTライブラリ
XSLT Library
序文
この標準仕様書(TS)は，2000～2001年度における(財)日本規格協会 情報技術標準化研究センター(INSTAC)の
電子出版技術調査研究をもとに工業標準化の促進に関連して特に重要と判断される技術情報をまとめたTR X
0059:2002に対して，さらに2003年度の電子出版技術調査研究において機能追加を施し, 標準仕様書(TS)タイ
プⅡとして公表するものである。
1. 適用範囲
この標準仕様書(TS)は, XML文書に対する変換処理を共有する手段としてのXSLTライブラリを規定する。変換
対象のXML文書における文書構造要素はXPathによって制限し, 変換先はXML文書又はHTML文書とする。
2. 引用規定
次に示す規格等は, この標準仕様書(TS)に引用されることによって, この標準仕様書(TS)の規定の一部を構
成する。
TR X 0048:2001, XSL変換(XSLT) 1.0
備考 XSL Transformations (XSLT) Version 1.0, W3C Recommendation, 1999-11 がこの規定に
一致している。
JIS X 4159:2002, 拡張可能なマーク付け言語 (XML)
備考 Extensible Markup Language (XML)1.0, W3C Recommendation, 2000-06 がこの規格に一致
している。
TR X 0089:2003, XMLパス言語 (XPath) 1.0
備考 XML Path Language (XPath) Version 1.0, W3C Recommendation, 1999-11 がこの規定に一
致している。
JIS X 4156:2000, ハイパテキストマーク付け言語(HTML)
備考1 ISO/IEC 15445:2000, Information Technology — Document Description and Processing
Languages — HyperText Markup Language (HTML), 2000-05 がこの規格に一致している。
備考2 JIS X 4156:2000及びISO/IEC 15445:2000は, HyperText Markup Language HTML 4.0, W3C
Recommendation, 1998-04 を参照している。
3. 定義
このTSでは, TR X 0048及びTR X 0089における定義, 並びに次の定義を適用する。
3
a) XSLTライブラリ 特定の用途のために記述されたXSLT記述の集合。XSLT記述の中のパラメタ及び変数を変
更することによって, 利用環境への適合を行う。
4. 機能
XSLT処理系でXML文書を変換処理するためのXSLTライブラリは, 処理後の用途に応じて提供される。ここで
は，次に示すXSLT処理の変換機能を扱う。
4.1 文字列処理
4.1.1 文字列の検索
文字列の検索機能を, XSLTライブラリとして提供する。
ライブラリ本体である5.1.1 a)のXSLT指定は, 次の手順によって使用される。
a) ライブラリの名前空間を指定する。
xmlns:xsltlib="http://jsa.or.jp/xsltlib/search_string"
b) ライブラリをインポートする。
<xsl:import href="xsltlib_search_string.xsl"/>
c) 検索したい文字列(検索対象の用語集)を, XPathを使って, 変数xsltlib:search_stringsの値に指定す
る。
<xsl:variable name="xsltlib:search_strings"
select="document('')/*/xsltlib:word_list/word"/>
変数xsltlib:search_stringsの指定を省略すると何も検索されない。
複数文字列を指定した場合は, 指定した順で検索される。
d) 検索したい文字列が含まれている可能性のあるテキストノードを子要素としてもつ要素(検索対象要素)
を, XPathを使って, 変数xsltlib:search_string_targetの値に指定する。
<xsl:variable name="xsltlib:search_string_target" select="//*"/>
変数xsltlib:search_string_targetの指定を省略するとデフォルト値として, 任意の場所にあるテキス
ト要素が用いられる。
e) 検索された文字列に付与する要素名(検索結果要素)を指定する。
複数の検索対象用語に対して異なる検索結果要素を指定する場合は, 変数
xsltlib:search_string_result_tagsの値にそれらを指定すると, 指定した順で使われる。
検索対象によらず固定の文字列を用いる際には, 変数xsltlib:search_string_result_literalを指定す
る。この指定も省略するとデフォルト値として, 要素名xsltlib:resultが用いられる。
f) 検索対象要素以下を再帰的に検索する場合は, 変数xsltlib:search_string_recursiveの値をtrueに設定
する。デフォルトでは再帰的に検索しない。
<xsl:variable name="xsltlib:search_string_recursive" select="true()"/>
g) 名前付きテンプレートxsltlib:search_stringsを呼び出すと, 呼び出した位置にオリジナルインスタンス
に対して検索された箇所に検索結果要素が付加されたものが生成される。
<xsl:call-template name="xsltlib:search_strings"/>
h) 名前付きテンプレートxsltlib:search_strings_eachを引数xsltlib:search_string_targetを指定して呼
び出すと, 変数xsltlib:search_string_targetの値にかかわらず, 引数xsltlib:search_string_targetの値
に対して検索した結果が返される。
4
<xsl:call-template name="xsltlib:search_strings_each">
<xsl:with-param name="xsltlib:search_string_target" select="."/>
</xsl:call-template>
このライブラリの使用例を, 5.1.1 b)に示す。
4.1.2 文字列の置換
文字列の置換機能を, XSLTライブラリとして提供する。
ライブラリ本体である5.1.2 a)のXSLT指定は, 次の手順によって使用される。
a) ライブラリの名前空間を指定する。
xmlns:xsltlib="http://jsa.or.jp/xsltlib/replace_string"
b) ライブラリをインポートする。
<xsl:import href="xsltlib_replace_string.xsl"/>
c) 置換したい文字列(置換対象の用語集)を, XPathを使って, 変数xsltlib:replace_stringsの値に指定す
る。
<xsl:variable name="xsltlib:replace_strings"
select="document('')/*/xsltlib:word_list/replace/org"/>
変数xsltlib:replace_stringsの指定を省略すると何も置換されない。
複数文字列を指定した場合は, 指定した順で置換される。
d) 置換後の文字列(置換結果の用語集)を, XPathを使って, 変数xsltlib:replace_with_stringsの値に指定
する。
<xsl:variable name="xsltlib:replace_with_strings"
select="document('')/*/xsltlib:word_list/replace/to"/>
変数xsltlib:replace_with_stringsの指定を省略するとNULL文字列で置換される。
e) 置換したい文字列が含まれている可能性のあるテキストノードを子要素としてもつ要素(置換対象要素)
を, XPathを使って, 変数xsltlib:replace_string_targetの値に指定する。
<xsl:variable name="xsltlib:replace_string_target" select="//*"/>
変数xsltlib:replace_string_targetの指定を省略するとデフォルト値として, 任意の場所にあるテキ
スト要素が用いられる。
f) 置換された文字列に付与する要素名(置換結果要素)を指定する。
複数の置換対象用語に対して異なる置換結果要素を指定する場合は, 変数
xsltlib:replace_string_result_tagsの値にそれらを指定すると, 指定した順で使われる。
置換対象によらず固定の文字列を用いる際には, 変数xsltlib:replace_string_result_literalを指定
する。この指定も省略すると置換位置に要素は付与されない。
g) 置換対象要素以下を再帰的に置換する場合は, 変数xsltlib:replace_string_recursiveの値をtrueに設定
する。デフォルトでは再帰的に置換しない。
<xsl:variable name="xsltlib:replce_string_recursive" select="true()"/>
h) 名前付きテンプレートxsltlib:replace_stringsを呼び出すと, 呼び出した位置にオリジナルインスタン
スに対して置換された結果が生成される。
<xsl:call-template name="xsltlib:replace_strings"/>
i) 名前付きテンプレートxsltlib:replace_strings_eachを引数xsltlib:replace_string_targetを指定して
5
呼び出すと, 変数xsltlib:replace_string_targetの値にかかわらず, 引数xsltlib:replace_string_target
の値に対して置換した結果が返される。
<xsl:call-template name="xsltlib:replace_strings_each">
<xsl:with-param name="xsltlib:replace_string_target" select="."/>
</xsl:call-template>
このライブラリの使用例を, 5.1.2 b)に示す。
4.1.3 文字列の削除
文字列の削除機能を, XSLTライブラリとして提供する。
ライブラリ本体である5.1.3 a)のXSLT指定は, 次の手順によって使用される。
a) ライブラリの名前空間を指定する。
xmlns:xsltlib="http://jsa.or.jp/xsltlib/delete_string"
b) ライブラリをインポートする。
<xsl:import href="xsltlib_delete_string.xsl"/>
c) 削除したい文字列(削除対象の用語集)を, XPathを使って, 変数xsltlib:delete_stringsの値に指定す
る。
<xsl:variable name="xsltlib:delete_strings"
select="document('')/*/xsltlib:word_list/delete"/>
変数xsltlib:delete_stringsの指定を省略すると何も削除されない。
複数文字列を指定した場合は, 指定した順で削除される。
d) 削除したい文字列が含まれている可能性のあるテキストノードを子要素としてもつ要素(削除対象要素)
を, XPathを使って, 変数xsltlib:delete_string_targetの値に指定する。
<xsl:variable name="xsltlib:delete_string_target" select="//*"/>
変数xsltlib:delete_string_targetの指定を省略するとデフォルト値として, 任意の場所にあるテキス
ト要素が用いられる。
e) 文字列が削除された箇所に付与する要素名(削除結果要素)を指定する。
複数の削除対象用語に対して異なる削除結果要素を指定する場合は, 変数
xsltlib:delete_string_result_tagsの値にそれらを指定すると, 指定した順で使われる。
削除対象によらず固定の文字列を用いる際には, 変数xsltlib:delete_string_result_literalを指定す
る。この指定も省略すると削除位置に要素は付与されない。
f) 削除対象要素以下を再帰的に削除する場合は, 変数xsltlib:delete_string_recursiveの値をtrueに設定
する。デフォルトでは再帰的に削除しない。
<xsl:variable name="xsltlib:delete_string_recursive" select="true()"/>
g) 名前付きテンプレートxsltlib:delete_stringsを呼び出すと, 呼び出した位置にオリジナルインスタンス
に対して削除された結果が生成される。
<xsl:call-template name="xsltlib:delete_strings"/>
h) 名前付きテンプレートxsltlib:delete_strings_eachを引数xsltlib:delete_string_targetを指定して呼
び出すと, 変数xsltlib:delete_string_targetの値にかかわらず, 引数xsltlib:delete_string_targetの値
に対して削除した結果が返される。
<xsl:call-template name="xsltlib:delete_strings_each">
<xsl:with-param name="xsltlib:delete_string_target" select="."/>
</xsl:call-template>
6
このライブラリの使用例を, 5.1.3 b)に示す。
4.2 タグの処理
4.2.1 タグの置換
タグの置換機能を, XSLTライブラリとして提供する。
ライブラリ本体である5.2.1 a)のXSLT指定は, 次の手順によって使用される。
a) ライブラリの名前空間を指定する。
xmlns:xsltlib="http://jsa.or.jp/xsltlib/replace_tag"
b) ライブラリをインポートする。
<xsl:import href="xsltlib_replace_tag.xsl"/>
c) 置換したいタグ名(置換対象要素)を, XPathを使って, 変数xsltlib:replace_tagsの値に指定する。
<xsl:variable name="xsltlib:replace_tags"
select="document('')/*/xsltlib:tag_list/replace/org"/>
変数xsltlib:replace_tagsの指定を省略すると何も置換されない。
複数タグ名を指定した場合は, 指定した順で置換される。
d) 置換後のタグ名(置換結果要素)を, XPathを使って, 変数xsltlib:replace_with_tagsの値に指定する。
<xsl:variable name="xsltlib:replace_with_tags"
select="document('')/*/xsltlib:tag_list/replace/to"/>
変数xsltlib:replace_with_tagsの指定を省略すると何も置換されない。
e) 置換したいタグを子要素としてもつ要素(置換対象親要素)を, XPathを使って, 変数
xsltlib:replace_tag_targetの値に指定する。
<xsl:variable name="xsltlib:replace_tag_target" select="//*"/>
変数xsltlib:replace_tag_targetの指定を省略するとデフォルト値として, 任意の場所にある要素が用
いられる。
f) 置換対象親要素以下を再帰的に置換する場合は, 変数xsltlib:replace_tag_recursiveの値をtrueに設定
する。デフォルトでは再帰的に置換しない。
<xsl:variable name="xsltlib:replce_tag_recursive" select="true()"/>
g) 名前付きテンプレートxsltlib:replace_tagsを呼び出すと, 呼び出した位置にオリジナルインスタンスに
対して置換された結果が生成される。
<xsl:call-template name="xsltlib:replace_tags"/>
h) 名前付きテンプレートxsltlib:replace_tags_eachを引数xsltlib:replace_tag_targetを指定して呼び出
すと, 変数xsltlib:replace_tag_targetの値にかかわらず, 引数xsltlib:replace_tag_targetの値に対して
置換した結果が返される。
<xsl:call-template name="xsltlib:replace_tags_each">
<xsl:with-param name="xsltlib:replace_tag_target" select="."/>
</xsl:call-template>
このライブラリの使用例を, 5.2.1 b)に示す。
4.2.2 タグの削除
タグの削除機能を, XSLTライブラリとして提供する。
7
ライブラリ本体である5.2.2 a)のXSLT指定は, 次の手順によって使用される。
a) ライブラリの名前空間を指定する。
xmlns:xsltlib="http://jsa.or.jp/xsltlib/delete_tag"
b) ライブラリをインポートする。
<xsl:import href="xsltlib_delete_tag.xsl"/>
c) 削除したいタグ名(削除対象要素)を, XPathを使って, 変数xsltlib:delete_tagsの値に指定する。
<xsl:variable name="xsltlib:delete_tags"
select="document('')/*/xsltlib:tag_list/delete"/>
変数xsltlib:delete_tagsの指定を省略すると何も削除されない。
複数タグ名を指定した場合は, 指定した順で削除される。
d) 削除したいタグを子要素としてもつ要素(削除対象親要素)を, XPathを使って, 変数
xsltlib:delete_tag_targetの値に指定する。
<xsl:variable name="xsltlib:delete_tag_target" select="//*"/>
変数xsltlib:delete_tag_targetの指定を省略するとデフォルト値として, 任意の場所にある要素が用
いられる。
e) 削除対象要素の内容も含めて削除する場合は, 変数xsltlib:delete_tag_contentsの値をtrueに設定す
る。デフォルトでは内容は削除しない。
<xsl:variable name="xsltlib:delete_tag_contents" select="true()"/>
f) 削除対象親要素以下を再帰的に削除する場合は, 変数xsltlib:delete_tag_recursiveの値をtrueに設定す
る。デフォルトでは再帰的に削除しない。
<xsl:variable name="xsltlib:delete_tag_recursive" select="true()"/>
g) 名前付きテンプレートxsltlib:delete_tagsを呼び出すと, 呼び出した位置にオリジナルインスタンスに
対して削除された結果が生成される。
<xsl:call-template name="xsltlib:delete_tags"/>
h) 名前付きテンプレートxsltlib:delete_tags_eachを引数xsltlib:delete_tag_targetを指定して呼び出す
と, 変数xsltlib:delete_tag_targetの値にかかわらず, 引数xsltlib:delete_tag_targetの値に対して削除
した結果が返される。
<xsl:call-template name="xsltlib:delete_tags_each">
<xsl:with-param name="xsltlib:delete_tag_target" select="."/>
</xsl:call-template>
このライブラリの使用例を, 5.2.2 b)に示す。
4.3 属性の処理
4.3.1 属性名の置換
属性名の置換機能を, XSLTライブラリとして提供する。
ライブラリ本体である5.3.1 a)のXSLT指定は, 次の手順によって使用される。
a) ライブラリの名前空間を指定する。
xmlns:xsltlib="http://jsa.or.jp/xsltlib/replace_attribute"
b) ライブラリをインポートする。
<xsl:import href="xsltlib_replace_attribute.xsl"/>
8
c) 置換したい属性名(置換対象属性)を, XPathを使って, 変数xsltlib:replace_attributesの値に指定す
る。
<xsl:variable name="xsltlib:replace_attributes"
select="document('')/*/xsltlib:attribute_list/replace/org"/>
変数xsltlib:replace_attributesの指定を省略すると何も置換されない。
複数属性名を指定した場合は, 指定した順で置換される。
d) 置換後の属性名(置換結果属性)を, XPathを使って, 変数xsltlib:replace_with_attributesの値に指定す
る。
<xsl:variable name="xsltlib:replace_with_attributes"
select="document('')/*/xsltlib:attribute_list/replace/to"/>
変数xsltlib:replace_with_attributesの指定を省略すると何も置換されない。
e) 置換したい属性をもつ要素(置換対象親要素)を, XPathを使って, 変数
xsltlib:replace_attribute_targetの値に指定する。
<xsl:variable name="xsltlib:replace_attribute_target" select="//*"/>
変数xsltlib:replace_attribute_targetの指定を省略するとデフォルト値として, 任意の場所にある要
素が用いられる。
f) 名前付きテンプレートxsltlib:replace_attributesを呼び出すと, 呼び出した位置にオリジナルインスタ
ンスに対して置換された結果が生成される。
<xsl:call-template name="xsltlib:replace_attributes"/>
g) 名前付きテンプレートxsltlib:replace_attributes_eachを引数xsltlib:replace_attribute_targetを指
定して呼び出すと, 変数xsltlib:replace_attribute_targetの値にかかわらず, 引数
xsltlib:replace_attribute_targetの値に対して置換した結果が返される。
<xsl:call-template name="xsltlib:replace_attributes_each">
<xsl:with-param name="xsltlib:replace_attribute_target" select="."/>
</xsl:call-template>
このライブラリの使用例を, 5.3.1 b)に示す。
4.3.2 属性の削除
属性名の削除機能を, XSLTライブラリとして提供する。
ライブラリ本体である5.3.2 a)のXSLT指定は, 次の手順によって使用される。
a) ライブラリの名前空間を指定する。
xmlns:xsltlib="http://jsa.or.jp/xsltlib/delete_attribute"
b) ライブラリをインポートする。
<xsl:import href="xsltlib_delete_attribute.xsl"/>
c) 削除したい属性名(削除対象属性)を, XPathを使って, 変数xsltlib:delete_attributesの値に指定する。
<xsl:variable name="xsltlib:delete_attributes"
select="document('')/*/xsltlib:attribute_list/delete/org"/>
変数xsltlib:delete_attributesの指定を省略すると何も削除されない。
複数属性名を指定した場合は, 指定した順で削除される。
d) 削除したい属性をもつ要素(削除対象親要素)を, XPathを使って, 変数xsltlib:delete_attribute_target
の値に指定する。
9
<xsl:variable name="xsltlib:delete_attribute_target" select="//*"/>
変数xsltlib:delete_attribute_targetの指定を省略するとデフォルト値として, 任意の場所にある要
素が用いられる。
e) 名前付きテンプレートxsltlib:delete_attributesを呼び出すと, 呼び出した位置にオリジナルインスタ
ンスに対して削除された結果が生成される。
<xsl:call-template name="xsltlib:delete_attributes"/>
f) 名前付きテンプレートxsltlib:delete_attributes_eachを引数xsltlib:delete_attribute_targetを指定
して呼び出すと, 変数xsltlib:delete_attribute_targetの値にかかわらず, 引数
xsltlib:delete_attribute_targetの値に対して削除した結果が返される。
<xsl:call-template name="xsltlib:delete_attributes_each">
<xsl:with-param name="xsltlib:delete_attribute_target" select="."/>
</xsl:call-template>
このライブラリの使用例を, 5.3.2 b)に示す。
4.4 日本語処理
4.4.1 ひらがなとカタカナの相互変換
ひらがな, カタカナの変換機能を, XSLTライブラリとして提供する。
ライブラリ本体である5.4.1 a)のXSLT指定は, 次の手順によって使用される。
a) ライブラリの名前空間を指定する。
xmlns:xsltlib="http://jsa.or.jp/xsltlib/convert_hiragana_katakana"
b) ライブラリをインポートする。
<xsl:import href="xsltlib_convert_hiragana_katakana.xsl"/>
c) 変換したい文字列が含まれている可能性のあるテキストノードを子要素としてもつ要素(変換対象要素)
を, XPathを使って, 変数xsltlib:convert_hiragana_katakana_targetの値に指定する。
<xsl:variable name="xsltlib:convert_hiragana_katakana_target" select="//*"/>
変数xsltlib:rconvert_hiragana_katakana_targetの指定を省略するとデフォルト値として, 任意の場
所にあるテキスト要素が用いられる。
d) 変換対象要素以下を再帰的に置換する場合は, 変数xsltlib:convert_hiragana_katakana_recursiveの値
をtrueに設定する。デフォルトでは再帰的に置換しない。
<xsl:variable name="xsltlib:convert_hiragana_katakana_recursive" select="true()"/>
e) 名前付きテンプレートxsltlib:convert_hiragana_to_katakanaを呼び出すと, 呼び出した位置にオリジナ
ルインスタンスに対してひらがながカタカナに変換された結果が生成される。
<xsl:call-template name="xsltlib:convert_hiragana_to_katakana"/>
f) 名前付きテンプレートxsltlib:convert_katakana_to_hiraganaを呼び出すと, 呼び出した位置にオリジナ
ルインスタンスに対してカタカナがひらがなに変換された結果が生成される。
<xsl:call-template name="xsltlib:convert_katakana_to_hiragana"/>
このライブラリの使用例を, 5.4.1 b)に示す。
4.4.2 全角英数文字と半角英数文字の相互変換
全角英数文字と半角英数文字の変換機能を, XSLTライブラリとして提供する。
10
ライブラリ本体である5.4.2 a)のXSLT指定は, 次の手順によって使用される。
a) ライブラリの名前空間を指定する。
xmlns:xsltlib="http://jsa.or.jp/xsltlib/convert_zenkaku_hankaku"
b) ライブラリをインポートする。
<xsl:import href="xsltlib_convert_zenkaku_hankaku.xsl"/>
c) 変換したい文字列が含まれている可能性のあるテキストノードを子要素としてもつ要素(変換対象要素)
を, XPathを使って, 変数xsltlib:convert_zenkaku_hankaku_targetの値に指定する。
<xsl:variable name="xsltlib:convert_zenkaku_hankaku_target" select="//*"/>
変数xsltlib:rconvert_zenkaku_hankaku_targetの指定を省略するとデフォルト値として, 任意の場所
にあるテキスト要素が用いられる。
d) 変換対象要素以下を再帰的に置換する場合は, 変数xsltlib:convert_zenkaku_hankaku_recursiveの値を
trueに設定する。デフォルトでは再帰的に置換しない。
<xsl:variable name="xsltlib:convert_zenkaku_hankaku_recursive" select="true()"/>
e) 名前付きテンプレートxsltlib:convert_zenkaku_to_hankakuを呼び出すと, 呼び出した位置にオリジナル
インスタンスに対して全角英数文字を半角英数文字に変換された結果が生成される。
<xsl:call-template name="xsltlib:convert_zenkaku_to_hankaku"/>
f) 名前付きテンプレートxsltlib:convert_hankaku_to_zenkakuを呼び出すと, 呼び出した位置にオリジナル
インスタンスに対して半角英数文字を全角英数文字に変換された結果が生成される。
<xsl:call-template name="xsltlib:convert_hankaku_to_zenkaku"/>
このライブラリの使用例を, 5.4.2 b)に示す。
4.5 目次・索引の生成
4.5.1 目次の生成
目次の生成機能を, XSLTライブラリとして提供する。
ライブラリ本体である5.5.1 a)のXSLT指定は, 次の手順によって使用される。
a) ライブラリの名前空間を指定する。
xmlns:xsltlib="http://jsa.or.jp/xsltlib/make_toc"
b) ライブラリをインポートする。
<xsl:import href="xsltlib_make_toc.xsl"/>
c) 目次に含めたい要素を, XPathを使って, 変数xsltlib:toc_entの値に指定する。
<xsl:variable name="xsltlib:toc_ent" select="//chapter/title | //section/title"/>
この指定を省略すると, 変数xsltlib:toc_entのデフォルト値として, サンプルインスタンスの中の任
意の場所にあるchapter要素の子要素であるtitle要素が用いられる。
d) 目次を生成したい場所で, 名前付きテンプレートxsltlib:make_tocを呼び出す。
<xsl:call-template name="xsltlib:make_toc"/>
このライブラリの使用例を, 5.5.1 b)に示す。変数xsltlib:toc_entの値として, サンプルインスタンスの中
の任意の場所にあるchapter要素の子要素であるtitle要素, 及び任意の場所にあるsection要素の子要素であ
るtitle要素を指定することによって, これらの内容が名前付きテンプレートsltlib:make_tocを呼び出した
場所に挿入される。
11
4.5.2 索引の生成
索引の生成機能を, XSLTライブラリとして提供する。
ライブラリ本体である5.5.2 a)のXSLT指定は, 次の手順によって使用される。
a) ライブラリの名前空間を指定する。
xmlns:xsltlib="http://jsa.or.jp/xsltlib/make_index"
b) ライブラリをインポートする。
<xsl:import href="xsltlib_make_index.xsl"/>
c) 索引に含めたい要素(索引項目)と, そこから参照したい要素とを, XPathを使って, 変数
xsltlib:index_ent及びxsltlib:index_refの値に指定する。
<xsl:variable name="xsltlib:index_ent" select="//term | //term1"/>
<xsl:variable name="xsltlib:index_ref" select="//title"/>
この指定を省略すると, 変数xsltlib:index_entのデフォルト値として, サンプルインスタンスの中の
任意の場所にあるterm要素が, またxsltlib:index_refのデフォルト値として, サンプルインスタンス
の中の任意の場所にあるtitle要素が用いられる。
d) 索引を生成したい場所で, 名前付きテンプレートxsltlib:make_indexを呼び出す。
<xsl:call-template name="xsltlib:make_index"/>
このライブラリの使用例を, 5.5.2 b)に示す。変数xsltlib:index_entの値として, サンプルインスタンスの
中の任意の場所にあるterm要素, 及び任意の場所にあるterm1要素を指定し, xsltlib:index_refの値として,
サンプルインスタンスの中の任意の場所にあるtitle要素を指定することによって, 名前付きテンプレート
xsltlib:make_indexを呼び出した場所に索引が挿入される。索引項目は単純にソートされる。このとき, 索
引項目が同じ場合は1つにまとめられる。また, 個々の索引項目に対応する要素としては, その索引項目に対
して共通の親をもつ要素のうち逆文書順でもっとも近いものが選ばれる。
12
[附属資料－Ａ．１．５]
ＤＳＳＳＬ多機能組版ライブラリ
第５．２章まで抜粋
標準仕様書（TS）
（案）
TS
X XXXX：0000
DSSSL 多機能組版ライブラリ
DSSSL Library for Complex Composition
序文
この標準仕様書(TS)は，それぞれ 2000 年及び 2003 年に公表された TR X 0010 日本語組
版の DSSSL ライ ブラリ 及びそ の追補 1 に基 づ いて作 成され た, ISO/IEC TR 19758:2003
Information technology - Document Description and Processing Languages - DSSSL library for complex
compositions 及び TR 19758/Amd.1, 並びに TR 19758/Amd.2 及び TR 19758/Amd.3 を翻訳し,
技術的内容を変更することなく統合して作成した標準仕様書(TS)である。
1.
適用範囲
この標準仕様書 (TS)は, 標準一般化マーク付け言語 SGML(JIS X 4151)又は拡
張可能なマーク付け言語 XML(JIS X 4159)で記述された構造化文書に対して, DSSSL(JIS X
4153)を用いてフォーマット指定を行う場合に用いる DSSSL ライブラリを提供する。このライブ
ラリを用いることによって, DSSSL 及び組版に関する専門的な知識を必要とせずに, 基本的な日
本語組版フォーマットから多言語を含む多機能フォーマットに至るまで，広範な DSSSL 指定を
行うことができる。
2.
引用規格
次に掲げる規格等は，この標準仕様書(TS)に引用されることによって，この標準
仕様書(TS)の規定の一部を構成する。これらの引用規格のうちで発行年を付記してあるものは，
記載の年の版だけがこの規格の規定を構成するものであって，その後の改正版・追補には適用し
ない。発効年を付記していない引用規格は，その最新版(追補を含む。)を適用する。
JIS X 4153:2005 文書スタイル意味指定言語(DSSSL)
備考 ISO/IEC 10179:1996 Information technology - Processing languages - Document Style
Semantics and Specification Language (DSSSL), ISO/IEC 10179/Cor.1:2001 及び
ISO/IEC 10179/Amd.1:2003 が, この規格に一致している。
ISO 8879:1986 Standard Generalized Markup Language (SGML)
備考 JIS X 4151:1992 文 書 記 述 言 語
SGML が , ISO 8879:1986 及 び ISO
8879/Amd.1:1988 の内容に技術的追加及び編集上の変更を加えたものである。
JIS X 4159:2005 拡張可能なマーク付け言語(XML) 1.0
備考 W3C Recommendation, REC-xml-20040204, Extensible Markup Language (XML) 1.0
3rd Edition が, この規格に一致している。
JIS X 4051 日本語文書の行組版方法
JIS X 0208:1997 7 ビット及び 8 ビットの 2 バイト情報交換用符号化漢字集合
JIS Z 8125:2004 印刷用語 - デジタル印刷
1
JIS X 4161:2002 フォント情報交換 第 1 部 体系
備考 ISO/IEC 9541-1:1991 Information technology - Font information interchange - Part 1:
Architecture, ISO/IEC 9541-1/Amd.1, ISO/IEC 9541-1/Amd.2 及 び
ISO/IEC
9541-1/Amd.3 が, この規格に一致している。
JIS X 4156:2005 HTML 4.01
3.
定義
3.1
この標準仕様書 (TS)で用いる主な用語の定義は，次による。
アキ(space)
隣接する文字の仮想ボディの間隔又は隣接する行の仮想ボディの間隔。
3.2
行送り (line leading)
行の基準点から次の行の基準点までの距離。
3.3
行間
(line space)
隣接する行の仮想ボディの間隔。
3.4
組方向
組版システムなどにおいて行を構成する方向。主として縦組又は横組とする。
3.5
グループルビ
ルビ対象文字列全体に付けるルビ。
3.6
圏点
特に強調したい語句の脇(縦組では右，横組では上)に付ける記号。
3.7
小口 (edge)
書籍などのページの綴じていない 3 辺。上辺を天小口，下辺を地小口といい，綴じと反対側の
辺を前小口又は単に小口という。
3.8
字下げ (indentation)
行頭を字詰方向に移動させること。
3.9
字詰数
1 行の文字数。字詰ともいう。
3.10 順序文字
順序付き箇条書きにおける各箇条項目の先頭に付ける，順序を表す文字。
3.11 セル (cell)
表組における基本単位。
3.12 添え字 [superscript/subscript (superior/inferior)]
親文字に付ける上付き文字又は下付き文字。
3.13 単一ページ
見開きに対し, 単独なページを指す。
3.14 段 (column)
1 ページの組版面を一つ以上の流し込み領域に区分して組む場合の１区分。
3.15 段間
隣接する二つの段の間隔。
2
3.16 地 (tail edge)
書籍などのページ面のレイアウトにおける下部の余白，又は書籍などの下部。
3.17 天 (head，top edge)
書籍などのページ面のレイアウトにおける上部の余白，又は書籍などの上部。
3.18 DSSSL ライブラリ (DSSSL library)
DSSSL 指定の集合。
3.19 時計数字
時計の文字盤用にデザインされたローマ数字。
3.20 ２字ルビ
字詰方向の仮想ボディがルビ対象文字 1 文字の仮想ボディの 1/2 の大きさであるルビ。
3.21 ノド (gutter)
書籍などの背が接する部分又は綴じ代側の部分。
3.22 ノンブル (page number)
印刷物などの各ページの順序を示す番号。
3.23 柱 (head line)
ページの版面外に表記した書名，章名，節名など。
3.24 版面 (image area)
主に本文が組まれる領域。
3.25 表記方向 (writing mode)
行を構成する際のグリフの公称送り方向[グリフ座標系において, 位置決め点(position point)か
ら送り点(escapement point)に向かう方向]。日本語組版においては, 右向き(LEFT-TO-RIGHT)又は
下向き(TOP-TO-BOTTOM)とする。
3.26 表ネーム (table caption)
表の内容をあらわす記述。表番号が付くこともあり，表見出し，表タイトル，表題，又はキャ
プションともいう。
3.27 付加文字
順序文字の前及び/又は後ろに付ける文字。
3.28 ベタ (solid matter 又は solid)
隣接する文字又は隣接する行にアキを設けない組版。
3.29 抹消線 (strike-through 又は strike-out)
文字に重ねて引く取消し線。
3.30 見開き (page facing)
書籍などを開いて，左右のページが向い合っている状態。
3.31 文字サイズ (character size)
文字の仮想ボディの大きさ。
3.32 モノルビ
ルビ対象文字 1 文字ごとに対応して付けるルビ。
3.33 ルビ
3
文字のそばに付けて，その文字の読み，意味などを示す小さな文字。
3.34 区分セル (distinguishable cell)
セルに対角線を引き，そこで区切られた領域に文字列を流し込むために，仮想的な区分を設定
したセル。
3.35 罫(けい)巻き
罫(けい)線で文字，又は文字列を囲うこと，又は囲まれた文字（列）
。
3.36 ドロップキャップ (drop cap)
段落の始まりで，開始文字をその段落を構成する文字サイズより大きいサイズとし，それに続
くテキストの中に埋め込んで組むこと。その段落を目立たせる効果を狙った方法の一つ。
3.37 行取り
一定の行送り量を持つ領域において，ある行数分の領域に他のテキスト又は図などを配置する
ために，その領域を確保すること。“見出しを２行取り中央”などと指定する。この例を図 3.1
に示す。
備考 行取りは，基本組体裁とは異なる指定をコンテントドリブン方式の中に配置する場合
の組版に必須の機能である。
la cs
L L(n
L(n) = (n×la) + (la – cs)
C
la – cs = 行間値
図 3.1
4.
組版指定要素及び指定パラメタ
２行取りの例
DSSSL ライブラリで扱う範囲の組版指定要素，及びその
指定パラメタについて規定する。
4.1
用紙サイズ
次のサイズについてモデルを規定する。
ａ)
Ａ判
A6，A5，A4
ｂ)
Ｂ判
B6，B5
“単一ページ”又は“見開き”の選択を可とする。
“見開き”の場合，これらの a）,b)に規定
した判サイズの倍のサイズを許容する。
参考 A4 見開きは, A3 判となる。
4.2
用紙の向き
4
“縦置き”及び“横置き”を対象とする。デフォルトは“縦置き”とする。
4.3
使用単位指定
mm，ポイント，Ｑの 3 種とする。
ポイント単位については，１ポイント＝0.3514mm とする。ポイントとＱとの単位は正確には
一致しないが，実用的に表 4.1 の換算表を用いて換算する。
表 4.1 Ｑとポイントとの関係
4.4
Ｑ
ポイント
Ｑ
ポイント
7
5
15
10.5
8
5.5
16
11
9
6
18
12
10
7
20
14
11
7.5
21
15
12
8
24
16
13
9
26
18.5
14
10
28
20
基本組体裁指定
原則として, 次の項目を指定する。
ａ)
版面の大きさ
ｂ)
余白
ｃ)
基本組体裁
組方向，文字サイズ，字詰数，行数，行間(行送り)，段数，及び段間
これらを設定する方法として，これらをすべて数値で指定する方法，及び 4.5 において指定す
る方法の 2 種類を対象とする。
備考 版面・余白の求め方としては，
用紙サイズ－余白＝版面
（レイアウトドリブン）
用紙サイズ－版面＝余白
（コンテントドリブン）
の２種類があるが，日本における組版原則はコンテントドリブンが一般的であり，版
面の大きさを確定してから余白を決める方法とする。
4.5
判型別書籍などの標準組体裁
4.5.1
用紙に対する版面位置
用紙に対する版面位置指定は，次の 3 種類とする。
ａ)
天地左右中央（デフォルト）
ｂ)
天：地，ノド：小口の各々の比を指定
ｃ)
天，地，ノド，小口の各々の絶対値を指定
備考 版面の大きさが指定されない場合, その縦及び横のサイズは, 用紙の対応するサイズ
5
の 0.8 倍とする。
4.5.2
標準組体裁
判型ごとの標準組体裁を次の表 4.2～表 4.8 のとおり定める。表 4.2～表 4.8 においては，
“字
詰数”を“字詰”
，ポイント系の数値表記を“ポ”と略記する
備考 ある言語文書では，表に明示されている値とは異なった行送り値，及び段間が採用さ
れる場合がある。とくに結合音節文字を持つ言語系では，表に示す行送り量及び段間
よりも大きな値を指定することが多い。
表 4.2
組方向
B6 判 縦置き ポイント系
文字サイズ
字詰
行数
行送り
段数
縦組
９ポ
43
14
18 ポ
１
縦組
９ポ
43
15
18 ポ
１
縦組
９ポ
43
16
17 ポ
１
縦組
９ポ
44
17
16 ポ
１
縦組
８ポ
50
18
15 ポ
１
縦組
８ポ
50
19
14 ポ
１
縦組
８ポ
25
20
14 ポ
２
２字
縦組
８ポ
26
20
14 ポ
２
２字
横組
９ポ
30
23
17 ポ
１
横組
８ポ
33
25
16 ポ
１
横組
８ポ
33
27
15 ポ
１
横組
８ポ
34
27
15 ポ
１
表 4.3
組方向
段間
B5 判 縦置き ポイント系
文字サイズ
字詰
行数
行送り
段数
縦組
８ポ
24
31
13 ポ
１
横組
９ポ
43
32
18 ポ
１
横組
９ポ
23
44
14 ポ
２
２字
横組
９ポ
22
41
15 ポ
２
２字
横組
８ポ
25
51
12 ポ
２
２字
段間
表 4.4
組方向
段間
B5 判 縦置き Ｑ数系
文字サイズ
字詰
行数
行送り
段数
横組
13Q
42
31
26Q
1
横組
13Q
22
43
20Q
2
6
２字
横組
13Q
21
39
22Q
2
２字
横組
12Q
23
48
18Q
2
２字
段間
表 4.5
組方向
A6 判 縦置き ポイント系
文字サイズ
字詰
行数
行送り
段数
縦組
８ポ
41
13
17 ポ
１
縦組
８ポ
41
14
16 ポ
１
縦組
８ポ
42
15
15 ポ
１
縦組
８ポ
42
13
16 ポ
１
縦組
８ポ
42
14
16 ポ
１
縦組
８ポ
43
15
15 ポ
１
縦組
８ポ
43
15
15 ポ
１
縦組
８ポ
43
16
14 ポ
１
縦組
８ポ
43
18
13 ポ
１
縦組
８ポ
43
19
13 ポ
１
表 4.6
A5 判 縦置き ポイント系
文字サイズ
字詰
行数
行送り
段数
縦組
９ポ
51
16
18 ポ
１
縦組
９ポ
52
16
18 ポ
１
縦組
９ポ
52
17
18 ポ
１
縦組
９ポ
52
18
17 ポ
１
縦組
９ポ
52
19
17 ポ
１
縦組
９ポ
25
20
15 ポ
２
２字
縦組
８ポ
30
24
13 ポ
２
２字
縦組
８ポ
29
23
14 ポ
２
２字
横組
９ポ
35
26
18 ポ
１
横組
９ポ
35
28
17 ポ
１
横組
９ポ
35
30
16 ポ
１
横組
８ポ
40
30
16 ポ
１
横組
８ポ
38
33
14 ポ
１
組方向
表 4.7
組方向
横組
段間
A5 判 縦置き Q 数系
文字サイズ
字詰
行数
行送り
段数
13Q
34
27
25Q
1
7
段間
横組
13Q
34
29
23Q
1
横組
12Q
37
28
24Q
1
横組
12Q
36
31
21Q
1
表 4.8
組方向
4.6
A4 判 縦置き Q 数系
文字サイズ
字詰
行数
行送り
段数
段間
横組
13Q
51
41
24Q
1
横組
14Q
48
39
25Q
1
横組
14Q
24
42
23Q
2
２字
横組
14Q
16
42
23Q
3
２字
書体指定
この標準仕様書 (TS)では，
“mincho”
“gothic”などの一般名称で指定し，固有の書体名指定は
行わない。
この標準仕様書 (TS)においては，フォントファミリ名の中で，
“書体名，ウェイト”を指定す
る。
“posture”，漢字と仮名との区分等は対象としない。
4.7
文字サイズ
ポイント又は Q によって指定する。
備考 長体，平体，斜体などの変形は, この標準仕様書 (TS)では対象外とする。
4.8
4.8.1
柱体裁指定
柱の数
次の 2 種類とする。
ａ)
柱を付けない。
ｂ)
1 種類の柱を付ける。
4.8.2
柱の位置
柱の位置は, 次の中から選択する。
ａ)
奇数ページ小口寄りの天
ｂ)
両ページ小口寄りの天
ｃ)
奇数ページ小口寄りの地
ｄ)
両ページ小口寄りの地
ｅ)
天の中央（本文が横組の場合だけ）
いずれの場合も柱文(はしらぶん)は, 横組とする。小口寄りで天地関係がノンブルと同じ場合
は，ノンブルから全角，又は 1.5 倍のアキをとって柱を続ける。
柱文の字割りルールは, 4.15 による。
4.8.3
柱文の内容
左右のページにおいて，異なった柱文を付ける場合の体裁は, 次のとおりとする。
8
ａ)
両ページ小口寄りの天
ｂ)
両ページ小口寄りの地
ｃ)
天の中央(横組の場合だけ)
構文構造において，上位の内容を柱文とする方を，その構文を構成する文章が始まる側と反対
側のページに表記し，下位の文章をその逆のページに表記する。文章が開始されるページには,
柱を表記しない。
4.9
ノンブル体裁指定
縦組又は横組に関係なく，次の 2 種類の体裁を標準とする。
ａ)
天寄りの小口
洋数字
ｂ)
地寄りの小口
洋数字
いずれの場合も，ノンブル文字サイズは本文文字サイズと同じ，又は 1 サイズ小さくする。版
面との隔たり量は, 本文文字サイズ，又はそれより若干大きい値とする。
4.10 注体裁指定
このモデルで対象とする注は, 次の 4 種類とする(割注は, 4.11 において規定する。)。
ａ)
傍注（横組）
ｂ)
脚注（横組）
ｃ)
頭注（縦組）
ｄ)
行間注
後注は, 本文の続きと見なす。
指定要素は, 次の a)～d)とする。
ａ)
合印の種類(“合印なし”を含む)，体裁
合印の種類は, ＊，†，‡，§，∥，＃，アラビア数字，漢数字，アルファベット とする。
無指定の場合は, １）, ２）．
．．とする。
参考 体裁の組合せ例を次に示す。
＊
＊＊＊
＊１
＊２
＊３
１）
２）
３）
一、
二、
三、
（ａ）
ｂ)
＊＊
（ｂ）
（ｃ）
合印の位置指定
1) 行間で注対象語句の先頭
2) 行間で注対象語句の末尾
3) 行中の注対象語句の後ろ
ｃ)
合印の文字サイズ指定
ｄ)
注の種類（行間注，傍注，頭注，脚注）
備考 1. 日本語組版をはじめ，とくに漢字圏の組版においては，備考 2.～ 6.に示す種類の
注がある。ただし傍注，脚注，後注は，世界共通に用いられる注形式である。
2.
行間注
説明の必要な語句のすぐ側の行間に組む注
9
横組では語句の上，又は下の行間に，縦組では語句の右の行間に組む。
横組における行間注は，垂直に構成されたテキスト，及び，その逆もまた同様に表
示することがある。
横組の例を図 4.1 に示す。
□□□□□□□□□□□□□□□□□□
（■■■■■■）
□□□□□■■■■■■□□□□□□□
□□□□□□□□□□□□□□□□□□
図 4.1 横組における行間注の組み方例
3.
傍注
横組において，ページの小口寄りに領域を取って，そこに組まれる注。図
4.2 を参照。
傍
傍
注
注
図 4.2 傍注
4.
頭注 縦組において，本文のページの上部に組まれる注。図 4.3 を参照。
頭
頭
注
図 4.3 頭注
10
注
5.
脚注
本文のページの下部に組まれる注。図 4.4 を参照。
脚
注
脚 注
図 4.4 脚注
6.
後注
本文の編，章，節，段落などの区分の終わり，又は巻末に組む注。
4.11 割注
この規定では, 2 行の割注だけを対象範囲とする。
割注は“行内行処理”として扱う。行内行の詳細は, 4.24 による。
特に指定をしない場合は, 割注パーレン付きとし，パーレンのサイズは本文文字サイズと同一
とする。
割注文字のデフォルトサイズは, 本文文字サイズの 50％とし，変更可とする。
割注行の行間は, デフォルトを 0 とし，変更可とする。
割注行の行組版規則は, フォーマタ依存とする。
4.12 圏点
文字，語又は段落単位で, 圏点を付けることができる。
圏点は，対象となる文字(親文字)の右又は左(縦組)，あるいは上又は左(横組)に置くことを原
則とする。
圏点を付けるためのルールは, “mark style”で指定することができる。
圏点の付け方は, “文字ごと”又は“文字群に対して均等”を選択可とする。
デフォルトは, “文字ごと”“スタイルなし”とする。
“文字群に対して均等”を選択した場合の圏点の始終点位置は, フォーマタ依存とする。
4.13 添え字
上付文字，下付文字を対象とする。
縦組では上付文字を対象となる文字(親文字)の下右，下付文字を親文字の下左の位置に，それ
ぞれ読み替える。
上付文字，下付文字のサイズは, 親文字に対して 1/2(二分)とする。
一つの親文字に対して, 上付文字及び下付文字の両方を同時に付けることができる。ただし，
11
その振る舞いに関してはフォーマタ依存とする。
親文字に対する位置に関してはフォーマタ依存とするが，親文字ボディの外側には出ないこと
を想定する。親文字ボディの外側に出る場合でも，4.24 の“行内行”の対象として扱う。
4.14 字取り
字取り行長は, 文字サイズに文字数を乗じたものとして指定する。
文字間アキ量は，文字サイズ，字取り数，文字数を用いて次式によって求める(ただし, 全角
かつ同一文字サイズの場合)。
文字間アキ量 ＝ (字取り行長－(文字サイズ×文字数))÷文字間の個数
＝ (文字サイズ×(字取り数－文字数))÷(文字数－1)
備考 字取りは，表組のセルなどに文字列を組む場合など，文字数が異なる文字列を一定の
長さに揃えるための指定として用いる。図 4.5 に例を示す。
図 4.5 字取りの例
4.15 字割り
代表的な見出し字割り数について規定する。
この規定は, 柱の字割り標準としても援用する。
表 4.9 見出し文字数による文字間のアキ量
Ｂ５判縦組
Ｂ５判横組
文字数
アキ量
文字数
アキ量
2字
3 倍アキ
2字
2 倍アキ
3字
全角半アキ
3字
全角四分アキ
4字
全角アキ
4字
2 分 4 分アキ
5字
2 分アキ
5字
3 分アキ
6字
4 分アキ
6字
1 ポアキ
7字
1 ポアキ
7 字以上
ベタ組
8 字以上
ベタ組
備考 柱，見出しなど，比較的字数の少ない行を組む際に，文字数に応じて字間にアキを入
12
れて組むことをいう。図 4.6 に例を示す。
8字
ベタ
7字
1 ポアキ
４字
全角アキ
３字
全角半(1.5 倍)アキ
図 4.6 字割りの例
4.16 章の指定
次の 2 種類とする。
ａ)
順序付き章
ｂ)
順序なし章
4.16.1 順序付き章
ａ)
次のいずれかの字種を指定する。
英大文字，漢数字，アラビア数字，ローマ数字大文字，時計数字
ｂ)
ｃ)
順序文字に付加する文字として次のいずれかの字種を使用する。
１)
付加文字なし
２)
順序文字の前に第，及び後に編，章，部，項，節などを使用
３)
順序文字の後ろに章など
４)
順序文字の後ろにピリオド（和文，欧文いずれかのピリオド）
５)
漢数字の後ろに読点
順序文字の書体
ｄ） 無指定の場合には, 第１章, 1.1, 1.1.1 とする。
備考 1. 順序付き箇条書きの順序記号は，数値以外の，番号を表す文字列，又は単語で表示
することがある。
備考 1. 入れ子の階層を指し示すために，次に示すように入れ子の番号付けをする代わりに，
入れ子の階層の深さを示す数だけ，順序記号を並べることがある。
a) 項目 1
b) 項目 2
aa) 入れ子項目 1
bb) 入れ子項目 2
c) 項目 3
備考 1. 入れ子になった最初の項目は，次に示すように，改行せずに上位の項目のすぐ後に
組版することがある。
1) 項目 1 a) 入れ子項目 1
13
b) 入れ子項目 2
c) 入れ子項目 3
2) 項目 2
4.16.2 順序なし章
ａ)
順序文字に付加する文字として, 次のいずれかを使用する。
文字なし，イメージ
備考 1. イメージとは，次に示す例の先端部のように，見出し行に付加される図形などを意
味する。
イメージ処理
2.
字下げは, 4.19 で扱う。
3.
マニュアル類の章建ては対象外とする。
4.
第１章の前に章番号のない“はじめに”などがある場合は，No Numbering 指定を
行う。
4.17 箇条書き
次の 2 種類とする。
ａ)
順序付き箇条書き
ｂ)
順序なし箇条書き
4.17.1 順序付き箇条書き
ａ)
次のいずれかの字種を指定する。
英大文字，英小文字，漢数字，アラビア数字，ローマ数字大文字，ローマ数字小文字，
時計数字，平仮名，片仮名
ｂ)
順序文字に付加する文字として，次のいずれかを指定する。
１)
付加文字なし
２)
丸付き（英大文字，英小文字，アラビア数字，平仮名，片仮名に対して）
備考 ①，②など
３)
順序記号の前後に丸括弧（和文，欧文いずれかの丸括弧）
備考 (1), (2)など
４)
順序記号の後ろに丸括弧（和文，欧文いずれかの丸括弧）
備考 1), 2)など
５)
順序記号の後ろにピリオド（和文，欧文いずれかのピリオド）
備考 1. 2.など
６)
順序記号の後ろに読点
備考 一、二、など
ｃ)
仮名の順序
１)
五十音順
14
２)
ｄ)
イロハ順
順序記号の書体
ｅ） 無指定の場合には, (1), A., a) とする。
4.17.2 順序なし箇条書きに使用する文字
ａ)
記号
・
（中点），◆，○，漢数字の一と読点，文字の名前（符号化文字の規格などが規定する文字の
名前）
ｂ)
漢数字の書体
4.17.3 箇条書きの字下げ
ａ)
段落字下げ数（箇条書き１行目の字下げ）
１字下げ，２字下げ
ｂ)
字下げ字数（箇条書き折り返し２行目の字下げ）
字下げなし，１字下げ，２字下げ，３字下げ
4.18 表ネーム
4.18.1 表の本文と表ネームの文字サイズとの関係
表の本文と表ネームの文字サイズとの関係は使用する書体により，次のとおりとする。
ａ)
ゴシック体
ｂ)
明朝体
同サイズ
１ポイント又は１Ｑ下げ
表注(表の説明文)が 2 行以上になった場合の行間値は, 注文字サイズの半角アキとする。
4.18.2 表と版面，本文とのアキ
ａ)
版面 1mm
ｂ)
本文
本文文字サイズの 1.5 倍アキ(端数は表注側で吸収する。)
4.19 見出し体裁指定
この組版においては, 4.19.1 及び 4.19.2 に示す 2 種類の指定モデルを提供する。ただしライ
ブラリ化は, 4.19.2 のモデルだけとする。
4.19.1 見出し文字サイズ選択指標
見出しの推奨文字サイズを次に示す。
ａ)
大見出し 24～32Q 又は 16～22 ポイントの中から選択。
ｂ)
中見出し 18～20Q 又は 12～14 ポイントの中から選択。
ｃ)
小見出し 14～16Q 又は 10～11 ポイントの中から選択。
備考 この指標は, 本文文字サイズを８～９ポイント(12～13Ｑ)としたときの各見出し文字
サイズの選択幅を示している。選択される書体，ウェイトによっても変化するため，
これらの指標はライブラリ化はしない。
4.19.2 見出し組
ポイント系で示す。Ｑ数指定の場合は 4.3, 表 4.1 の換算表を適用する。
“A5 判 縦組
本文 9 ポ組”及び“A5 判・B5 判 横組
本文 9 ポ・8 ポ組”の例を示す。他
の判型，本文サイズの場合は，これをもとに指定する。ａ）～ｂ）の表記においては，ポイント
の数値表記を“ポ”と略記する。
15
ａ)
A5 判 縦組
１)
２)
本文 9 ポ組
単独見出しの例
大見出し（14 ポ）
本文９ポ４字下がり
４行取り中央
中見出し（12 ポ）
６字下がり
３行取り中央
小見出し（10 ポ）
７字下がり
２行取り中央
大・中・小見出し 3 本の例
１行アキ
大見出し（14 ポ）
本文９ポ４字下がり
３行取り中央
中見出し（12 ポ）
６字下がり
２行取り中央
小見出し（10 ポ）
７字下がり
２行取り中央
最初の１行アキを含めて８行取り
３)
大・中見出し２本の例
１行アキ
大見出し（14 ポ）
本文９ポ４字下がり
２行取り中央
中見出し（12 ポ）
６字下がり
３行取り中央
最初の１行アキを含めて６行取り
４)
大・小見出し２本の例
１行アキ
大見出し（14 ポ）
本文９ポ４字下がり
３行取り中央
小見出し（10 ポ）
７字下がり
２行取り中央
最初の１行アキを含めて６行取り
５)
中・小見出し２本の例
１行アキ
中見出し（12 ポ）
本文９ポ６字下がり
２行取り中央
小見出し（10 ポ）
７字下がり
２行取り中央
最初の１行アキを含めて５行取り
６)
見出しのない例
本文のはじめを 2 行分空けて組む
ｂ)
A5 判・B5 判 横組
１)
２)
本文 9 ポ・８ポ組
単独見出しの例
大見出し（14 ポ）
位置は本文版面左右中央
４行取り中央
中見出し（12 ポ）
位置は本文版面左右中央
３行取り中央
小見出し（10 ポ）
左右中央又は１字下がり
２行取り中央
大・中・小見出し 3 本の例･･････････改ページ
１行アキ
大見出し（14 ポ）
位置は本文版面左右中央
３行取り中央
中見出し（12 ポ）
位置は本文版面左右中央
２行取り中央
16
小見出し（10 ポ）
左右中央又は１字下がり
２行取り中央
最初の１行アキを含めて８行取り
３)
大・中見出し２本の例･･････････改ページ
１行アキ
大見出し（14 ポ）
位置は本文版面左右中央
２行取り中央
中見出し（12 ポ）
位置は本文版面左右中央
３行取り中央
最初の１行アキを含めて６行取り
４)
大・小見出し２本の例･･････････改ページ
１行アキ
大見出し（14 ポ）
位置は本文版面左右中央
３行取り中央
小見出し（10 ポ）
左右中央又は１字下がり
２行取り中央
最初の１行アキを含めて６行取り
５)
中・小見出し２本の例･･････････改ページ・追い込み
１行アキ
中見出し（12 ポ）
位置は本文版面左右中央
２行取り中央
小見出し（10 ポ）
左右中央又は１字下がり
２行取り中央
最初の１行アキを含めて５行取り
4.20 ルビ体裁指定
次の範囲を標準とする。
ａ)
2 字ルビに限定する。
ｂ)
縦組，横組とも中付きとする。
ｃ)
モノルビ，グループルビの双方を許容する。
ｄ)
モノルビの場合，ルビ文字数の増大とともに，原則的には左右(上下)対称にルビ行長を伸ば
す。ルビ文字はベタに配置する。
ｅ)
ルビ対象文字に隣接する漢字には，ルビ文字が掛かってはならない。
ｆ)
ルビ対象文字に隣接する仮名には，ルビ１字だけ掛かってもよい。
ｇ)
グループルビの場合，アキ量の関係は図 4.7 のとおりとする(ただしルビ行長がルビ対象文
字列よりも長い場合には，ルビ列はベタとする。)。
1
2
2
2
図 4.7 グループルビにおけるルビ文字のアキ
17
1
ｈ)
行頭・行末の処理は，ルビ対象文字基準とする。
4.21 段落字下げ体裁指定
“字下げなし”
，“段落行頭 1 字下げ”又は“段落行頭 2 字下げ”の三者択一とする。
備考 1. 節内の第１段落は，字下げなしを採用することがある。
備考 1. 段落字下げの直後に，段落開始として開始引用符を置くことがある。
4.22 スコア
次の 3 種類とする。縦組の場合は，下線，上線を左線，右線とそれぞれ読み替える。スコアの
例を添付して, 次に示す。
下線
［例］あいうえお
上線
［例］あいうえお
抹消線
［例］あいうえお
備考 1. 下線，上線（左線，右線）を傍線と総称することもある。線種は 4.23 を参照のこ
と。
備考 1. タイ語組版等では，下線，又は上線は，文字との接触を避けるために中断させ，及
び／又は語間スペースの箇所で中断することがある。特性は，
“中断”，又は“中断
しない”の二者択一とする。
4.23 罫(けい)
罫(けい)線種は表 4.10 に示す範囲とする。例示する線の太さは参考とし，実際の線幅及び線
間は, フォーマタ依存とする。
表 4.10 罫線種
罫線種
表
形
状
罫
中太罫
裏
罫
点
線
ミシン罫
一点鎖線
二点鎖線
双柱罫
子持ち罫
4.24 行内行
１行を構成する文字列において，行方向に幅をもつ要素が付加されることがある。ここでは次
の組版指定要素がそれに該当する。
ａ)
注の合印
ｂ)
割注
ｃ)
圏点
18
ｄ)
添え字
ｅ)
ルビ
ｆ)
スコア
これらの要素を指定して組版する場合は，4.24.1 及び 4.24.2 に述べる原則に基づいて組版する
ものとする。
4.24.1 当該行の行幅
これらの要素が付加されない場合と同一の値をとることを原則とする。
4.24.2 当該行の位置
これらの要素が付加されない場合と同一の位置をとる。
4.25 表
4.25.1 表の体裁
対象とする表の体裁を次のとおりとする。“○”は文字(列)を表す。
表ヘッダ（上／下）
列
○○○○○
行
○○
○○
○○
○○○
○○○
○
○○
○○○
○
○○
○○○
表ヘッダ（右／左）
セル
図 4.8
a)
対象とする表の体裁
表の外郭は長方形とする。ただし四角を丸めること(round)を許容する。
1)
要素 TABLE の属性として，ROUND を用いる。ROUND の値は，true 又は false のい
ずれかとし，初期値は false とする。
2)
丸める角の扇の半径を設定するために，要素 TABLE の属性として，RADIUS を用い
る。RADIUS の値は，数値とし，初期値は 0 とする。
b) 大きさの指定の単位は，mm, cm, pt 又は em とする。
1)
要素 TABLE の属性として，UNIT を用いる。UNIT の値は，mm, cm, pt 又は em とし，
初期値は mm とする。
c)
画像を貼り込むことができるセルの中に画像を貼り付ける場合，要素 TABLECELL の
属性として，IMAGESRC，IMAGEHEIGHT，IMAGEWIDTH 及び IMAGETYPE を用い
る。
1)
行内の場合は，要素 TABLECELL の子要素として IMAGE を用い，前述の属性を設定
する。
2)
それぞれの値を次のとおりとする。
－ IMAGESRC 任意のパスとし，設定は必須とする。
－ IMAGEHEIGHT 及び IMAGEWIDTH 数値とし，初期値は実際の画像の大きさとす
る。
－ IMAGETYPE 任意の文字列とし，初期値は JPEG とする。
19
4.25.2 表の外郭のラウンド設定
長方形の表を作成する際は，定義された table-style を使用し，表の四角を丸める場合には
corner-rounded-table-style を使用する。corner-rounded-table-style では，半径 table-corner-radius の設
定も可能とする。
4.25.3 セルの背景色の指定
表全体，表ヘッダ，フッタ，行単位，列単位，セル単位のそれぞれに対して，背景色を設定可
能とする。
4.25.4 セルの罫(けい)線体裁の設定
罫(けい)線を引く場合は cell-border-style を選択する。初期値は#t とする。すべてに罫(けい)線
を引かない場合は nonborder-style を選択する。罫(けい)線が同じ座標を指定する場合の優先順位
の付け方は，次のとおりとする。
a)
要素レベルでの優先順位 優先順位は，次のとおりとする。
TABLE > TABLECELL > TABLECOLUMN >TABLEROW > TABLEHEADER >
TABLEFOOTER
b) 上下左右での設定 全体の色指定に対して，上下左右それぞれに対する個別の設定が優
先される。
例 全体の色指定に対して，上下左右それぞれに対する個別の設定が優先される。
<TABLECELL BORDERCOLOR="red" BORDERRIGHTCOLOR="blue">
右辺は青とし，右辺以外は赤となる。
4.25.5 セルにおけるマージン体裁の設定
マージンをつける場合は，cell-margin-style を選択する。初期値は 1mm とする。すべてにマー
ジンをつけない場合は，non-margin-style を選択する。
4.25.6 列の設定
unit-columns によって列の数及び幅を設定する。
例
unit-columns(1 1 1)の場合は，等幅の列を三つ生成する。
unit-columns(1 3 5)の場合は，1:3:5 の幅をもつ三つの列を生成する。
4.25.7 区分セル
セルに対角線を引き,そこで区切られた領域に文字列を流し込むことができる。行に関係する
文字列を ROW_STRING，列に関係する文字列を COLUMN_STRING とする。列の左右ポジショ
ン 設 定 は ， COLUMN_STRING で あ れ ば ， distinguishable-column-position に よ っ て 行 い ，
ROW_STRING であれば，distinguishable-row-position によって行う。
値は，left, center, right 又は数値とする。初期値は center とする。体裁設定は，
make-distinguishable-cell によって定義する。
区分セルを図 4.9 に示す。
“○”は文字(列)を表す。
20
○○○
○○○
図 4.9
区分セル
4.26 罫(けい)巻き
１文字以上の文字列に所定の罫(けい)線を巻く。罫(けい)巻き対象文字（列）
，罫(けい)線種，
文字からのオフセット，角丸の特性を持つ。
備考 罫(けい)巻きの範囲が行をまたぐことを許容するかどうかは実装による。
4.27 ドロップキャップ
段落の始まりにおいて，開始文字を 2 行分の高さを持つサイズをデフォルトとする。行数，文
字数，文字の大きさ，及びフォントの特性を持つ。
4.28 行取り
行取りは，確保する範囲，行数，及び基本文字サイズの特性を持つ。
4.29 強調のための文字間
強調するために文字列内の文字間を広げる場合の文字間は，文字間スペースの特性を持つ。
4.30 第 1 段落の識別
文書の最初を指し示すために，第１段落すべてに対して，それ以外の文章と識別できるような
書体，又は他の適切な表現を持つことができる。指定方法は規定しない。
4.31 段落分割
段落間の分割を強調するために，直前の段落との間に特別な記号を置く場合，段落分割の記号
は，グリフ識別子によって指定しなければならない。
5.
DSSSL ライブラリ
DSSSL ライブラリは, 多言語環境における構造化文書の文書スタイル意味指定言語(DSSSL)
の指定を，簡便に行うための枠組み及び DSSSL 記述集合とする。
DSSSL は, SGML 文書に対する構造変換及びフォーマット処理の指定方法を規定する。DSSSL
の指定では, 詳細なフォーマット処理に関する指定が可能であり, 高度な記述が可能であるが,
指定方法として低レベルであって, 多くの利用者が簡単に記述できるものではない。 そこで
DSSSL ライブラリによって, DSSSL 指定を簡易化することが望まれる。
21
DSSSL ライブラリは, 利用者の簡易な指定から詳細な指定を作り出す scheme プログラムを用
意し, 標準的に使われる組版要素及びページモデルの DSSSL の関数記述群を用意して, DSSSL
指定に際しての利用者の記述を軽減する。簡易な指定から詳細な指定を作り出すためには,組版
の標準的な規則, 指定要素及びそれらに用いるパラメタの値が必要となる。ここでは, 4.に示し
た組版の標準的な組版指定要素及び指定パラメタを用いて, 詳細指定の生成を行う。
備考 このライブラリでは, 次の指定要素は扱わない。
4.10 注体裁指定における, 行間注, 傍注及び頭注
4.19.2 見出し組
4.24 行内行に示すとおり, ルビなどの付与による行幅加算が行われないフォーマタを想定し
て, このライブラリは設計されている。
5.1
ライブラリの枠組み
DSSSL は, 処理系に非依存で詳細な指定が可能な一般性の高い規定内容をもつ。その指定を
記述するには, 次の DSSSL 利用の知識が必要となる。
a) DSSSL の処理
b) 組版
c) 組版要素に対応する DSSSL の流し込みオブジェクト
d) SGML
e) DSSSL 内部表現であるグローブ
f) Scheme(式言語)
g) Scheme 上の DSSSL 指定方法(SDQL, グローブ及び流し込みオブジェクトの操作)
指定の簡易化によって, これらの知識を必ずしも十分にもたない利用者にとっても DSSSL を
使うことのできる方策が望まれるが, 組版に対する多様な要求を満し, しかも記述能力を低下さ
せないで簡易化を実現する必要がある。 つまり柔軟性を維持したまま, 利用者の知識の負担を
減らす必要がある。
そこでこのライブラリでは, 利用者の知識水準に応じて段階的に高度な拡張を可能にする
DSSSL の記述パッケージを提供する。利用者の知識水準に基づく利用形態を, 次のとおりに分類
する。
a) level 0
変更なしにスタイルそのものを利用する。例えば, 単に HTML の文書を, おしきせのスタイル
で出力したい。
b) level 1
組版要素の指定を変更できる。スタイルシートの内容を理解して, 段組を変えたり要素の見栄
えを変えたりできる(指定パラメタの変更。)。
c) level 2
DTD に対応して, DSSSL 記述においてスタイルに変更を加えることができる。
d) level 3
22
新しいスタイルを定義できる。カスタマイズしたスタイルを, 再利用可能なライブラリとして
利用者が定義する。
スタ イ ル シー ト の 位置 付 けは, 裸の DSSSL を plain-TeX( 又は assembler) に たと え る と,
LaTeX(又は C 言語)に相当するものと言えよう。利用者は, 必要に応じて高レベル記述のパラメ
タを変更したり, 低レベル記述の追加変更を行うことによって, 柔軟な記述を行える。
この標準仕様書 (TS)では, 主として level 1 の利用形態を対象としたライブラリを提供する。
5.2
DSSSL ライブラリの処理の流れ
DSSSL ライブラリは, 図 5.1 に示す処理を想定している。
図 5.1 DSSSL ライブラリの構成
ライブラリでは, 次の四つの部分を提供する。
a) 詳細パラメタ生成プログラム
b) 関数群, つまり組版指定要素に対応する関数群
c) ページモデル群, つまり標準のページモデル記述
d) 特定 DTD ルール群, つまり特定 DTD に対する construction rule 記述
5.2.1
簡易パラメタ
DSSSL ライブラリは, 利用者からの単純な要求に対して DSSSL の詳細な指定を補間して提供
する必要がある。そのためにできるだけ組版の標準的なデフォルト値を用意しておく。 例えば
23
ルビについては, ルビ文字が親文字の半分の大きさであることが多い。たとえば漢字圏の組版で
は, 紙上の文字領域は, ”13Q で 22 字詰, 段間２字分”の例に見られるとおり, 使用フォントの何
文字分かで表現することが多い。
利用者が標準的でない場合, 又はシステムのデフォルト値では満足できない場合に, 簡易パラ
メタに必要な指定を与える。この指定は, 詳細パラメタ生成プログラムで解釈され, 詳細パラメ
タに変換される。詳細パラメタで自動的に生成される宣言は, すべて簡易パラメタでも与えるこ
とができる。つまり, 透過的にパラメタは渡される。
5.2.2
詳細パラメタ生成プログラム
詳細パラメタ生成プログラムは, 利用者からの単純な指定に基づいて, DSSSL で使用する詳細
なパラメタを生成する。生成プログラムは, 本来はすべて DSSSL 処理系上で処理することが望
まれる。しかし, DSSSL の式言語(scheme サブセット)で生成した記述をさらに DSSSL の記述(ス
タイル言語)として利用できないこと, 及び DSSSL の式言語では副作用のない記述だけしか認め
られていない(set!などによる変数の代入がない。)ことにより, この生成プログラムを導入した。
4.の”組版指定要素及び指定パラメタ”を利用して, 次の関数群及びページモデル群で利用する
詳細なページの指定などを生成する。ルビサイズの指定などは, 指定がなければデフォルト値が
生成される。プログラムの内容は, 附属書 A “詳細パラメタ生成プログラム”に示す。
5.2.3
関数群
組版指定要素に対応する DSSSL 記述上の関数群が用意される。これは, 詳細パラメタで与え
られた各種の指定をもとに construction rule で使用する DSSSL の流し込みオブジェクト生成関数
及びそのサポート関数から成る。組版要素に対して DSSSL のスタイル言語が規定する流し込み
オブジェクトを生成するための関数及びスタイル指定を定義している。指定の詳細は, 附属書 B
“関数群”に示す。
5.2.4
ページモデル群
この標準仕様書 (TS)が提供する DSSSL のページモデル記述であり, 詳細パラメタで与えられ
た各種の指定を使って対応するページモデルを与える。 詳細パラメタの指定を具体的な DSSSL
のスタイル言語の page-model 定義としている。 指定の詳細は, 附属書 C “ページモデル群”に示
す。
5.2.5
特定 DTD ルール群
特定 DTD に対応した具体的な DSSSL 指定を与える部分であり, 詳細パラメタ, 関数群及びペ
ージモデル群を利用して具体的な DTD のタグに対応して DSSSL の流し込みオブジェクトを生
成していくための construction rule を記述している。 この版では, HTML 3.2 に対するものを用意
した。 DTD の要素に対して流し込みオブジェクトを生成する処理を記述してあり, 詳細パラメ
タ, 関数群及びページモデル群を利用する。指定の詳細は, 附属書 D “特定 DTD ルール群”に示す。
5.3
簡易パラメタ
詳細パラメタは, 詳細パラメタ生成プログラムによって生成される DSSSL 記述であり, ほと
んどが変数の宣言によって構成される。詳細パラメタの元となる簡易パラメタは, 詳細パラメタ
生成プログラムに対してパラメタの連想リスト(association list)の形式で与えられる。次に指定可
能なパラメタを列挙する。
24
長さ又は大きさの指定は, 単位なしの場合, mm 単位となり, 9pt のように単位を指定すること
もできる[pt(ポイント) = 0.3514mm, Q = 0.25mm]。
*paper-name*
用紙サイズ(文字列: "a4" など)(デフォルト値 "a4")
*paper-direction*
用紙の向き（文字列: "portrait"/"landscape")(デフォルト値 "portrait")
*writing-direction*
基本となる組方向(文字列: "horizontal"/"vertical")(デフォルト値 "horizontal")
*paper-width*
用紙の幅([mm]: *paper-name*依存)
*paper-height*
用紙の長さ([mm]: *paper-name*依存)
*column-number*
段数(数値)(デフォルト値 1)n
*base-font-size*
本文文字サイズ([mm])
*standard-composition*
版面の標準名指定。(文字列)
*page-spec*
基本組体裁 (本文文字サイズ 字詰 行数 行送 段数 段間)。
*page-region-width*
版面の幅([mm])
*page-region-height*
版面の高さ([mm])
*area-x-ratio*
版面のページ上のx方向相対位置指定(0.0～1.0)(デフォルト値 0.5)
*area-y-ratio*
版面のページ上のy方向相対位置指定(0.0～1.0)(デフォルト値 0.5)
*page-region-x-offset*
版面のページ上x絶対位置(ページ左上隅から版面左上隅までの長さ)
*page-region-y-offset*
版面のページ上y絶対位置(ページ左上隅から版面左上隅までの長さ)
*font-table*
見出しフォント情報 (リスト)
*rubi-font-size-factor*
本文文字サイズに対するルビ文字の大きさ比率(0.0～1.0)(デフォルト値 0.5)
25
*subscript-font-size-factor*
本文文字サイズに対する下付文字文字の大きさ比率(0.0～1.0)(デフォルト値 0.6)
*superscript-font-size-factor*
本文文字サイズに対する上付文字文字の大きさ比率(0.0～1.0)(デフォルト値0.6)
*base-font-family*
本文文字サイズの書体指定(文字列)(デフォルト値 "mincho-light,sans-medium")
*jisage-factor*
段落の標準の字下げ文字数(数値)(デフォルト値 1)
*indent-factor*
箇条書き字下げの標準下げ幅文字数(デフォルト値 2)
*has-header-nonburu*
天の位置へのノンブルの有無(#t/#f)(デフォルト値 #t)
*has-header-hasira*
天の位置への柱の有無(#t/#f)(デフォルト値 #t)
*has-footer-nonburu*
地の位置へのノンブルの有無(#t/#f)(デフォルト値 #f)
*has-footer-hasira*
地の位置への柱の有無(#t/#f)(デフォルト値 #f)
*hasira-rect*
見開き右ページの柱に書かれる文字列の指定
*hasira-verso*
見開き左ページの柱に書かれる文字列の指定
*footnote-number-desc*
脚注の順序文字の指定
*enum-number-desc*
箇条書きの順序文字の指定
*title-number-desc*
見出しの順序文字の指定
26
[附属資料－Ａ．１．６]
縦組文書における数字表記方法
Ａ.１.６
縦組文書における数字の表記方法（案）
序文
これは，2004 年度の e-Book 調査研究における標準化に関する調査研究をもとに，従来は
ほとんど省みられることがなかった情報処理の分野において，表示のために縦横変換等を
行なうときの数字表記の混乱をなくす目的で，縦組数字表記方法をまとめたものである。
１．適用範囲
構造化文書においては，文書の内容と組版スタイルは分離されている。組版スタイルを付
与する場合，利用目的等によって縦組・横組といった基本組体裁を任意に選択できること
が暗黙のうちに期待されていると考えられるが，この変換時に問題となるのは拗促音，括
弧類だけではなく，数字表記においても組み方向にあったルールを確立しておかなければ
正しい変換はできない。
とくに，原稿はテキストエディタを用いることが多いため，横組を前提にした用語を用
いて執筆しがちであり，これを縦組に組む場合に誤変換が生じる虞がある。
そこで，ここではとくにユレが大きい縦組における漢数字表記の基本的なルールをまと
め，組版スタイルの自動変換をスムーズに行える環境を提供することを狙いとした。
縦組を前提としているため，一般的なオフィス文書だけではなく，縦組で書かれる一般
文書，新聞・書籍（但し小説等のような，著者の意向が強く，汎用化に馴染まないものを
除く）なども対象とする。但し，法令については記法が確立しており，これに倣うものと
する。
２．数字の種類と名称
一般の文書に使用される数字には，
・漢数字
一，二，三，……
・アラビア数字
・ローマ数字
九，〇
1, 2, 3, ……
i, ii, iii, iv, ……
9, 0
I, II, III, IV,
がある。漢数字は，和数字とも呼ばれることもある。アラビア数字は，算用数字とも呼ば
れるが，過去には洋数字とも言われていた。ローマ数字は欧文アルファベットの組合せで
表記する数字であり，時計数字とも呼ぶと言われることもあるが，時計数字は I∼XII まで
を正方形の中にデザインしたものであって，正規のプロポーションを生かしたアルファベ
ットの並びで構成されるローマ数字とは別物である。
本仕様では，漢数字及びアラビア数字を対象とする。
1
３．漢数字表記の基準を示す目的
本仕様においては縦組数字表記の基準を示す。１．適用範囲に述べたように，構造化文書
が内容と体裁を分離したものであることから，同一のコンテンツを横組にも縦組にも表示
することが多くなり，その場合はもとの原稿で記述した表記とは異なった表記に変換しな
ければならないこともあり得る。この変換処理は，できるだけ自動で行えることが望まし
い。後に述べるように，漢数字表記に関しては，従来から「十字方式」及び「一〇方式」
というルールが存在するが，現在はこの方式に依拠しない表記が広がってきたため，より
どころがなくなってきている。したがって，変換処理を効率よく行うためには何らかの新
しいルールが必要になる。
また，漢数字を数字列として使用しているかどうかの自動識別が困難であったことから，
本来であれば段落中の強制改行時に分割禁止にすべき箇所を特定することができないとい
う問題があった。これは，たとえば組み方向に無関係にアラビア数字で記述し，組方向が
確定された時点で漢数字変換処理を行うようにすれば，分割禁止領域を特定できることに
なり，可読性の高い組版を実現できことにつながる。
この仕様は，変換のためのルールの原則を示すことであるが，コンテンツの種類，系統
によっては同一のルールを適用できない場合もある。たとえば，次項に述べるように，新
聞ではできるだけ効率よく文章を一定の領域に収めるために，２桁数字を全角扱いにする
こと，又は位取りのカンマ（又はテン）を省略することなどが行われる。こうした方式を
一般に敷衍することはかならずしも得策ではないが，この種の表記が増えている実態を考
慮し，一種類の基準とはせずに，できるだけ実態に合わせた表記ルールを示すことにとど
めた。
４．縦組における表記方式
4.1 概要
一般的な縦組文書における数値表現は，原則として漢数字を用いることとし，表記は「一
〇方式」とする。「一〇方式」の詳細は「解説」で詳述する。
全角のアラビア数字を使用できる箇所は，アラビア数字を用いてもよい。但し全体の整合
性に注意する。
新聞などのように限られたスペースに多くの情報を入れなければならない特殊な場合は，
２桁（又は３桁）アラビア数字を縦中横で用いる。但し新聞社などにおいては年齢用組合
せ数字の使用など，独自ルールによる表記が行われているため，原則を示すにとどめる。
非常に桁数が多い数字列（たとえば円周率を小数点以下 20 桁まで表示する，など）では，
可読性の面からアラビア数字を用いて組んでもよい。但し，この場合は行を改めて，別に
組むことを奨励する。
【備考１】伝統的な漢数字表記としては，数字を発音通りに配列する「十字方式」が主
流であったが，アラビア数字の置き換えに近い「一〇方式」が多用されるようになって
2
きた。横書き原稿から縦組に変換することが多いことなど，歴史的，実用的見地から，
ここでは「一〇方式」を基本的な表記方式とする。
【備考２】このことによって「十字方式」を排除しようとするものではない。とくに文
芸作品等においては「十字方式」が用いられることも多い。また法令の箇条番号は「読
み」との整合をとることができる「十字方式」が用いられる。
【備考３】
「十字方式」，
「一〇方式」の詳細は，解説 2.5 項，及び同 2.6 項を参照のこと。
4.2 原則
4.2.1 「一〇方式」の採用
縦組においては，標準的な数字表記として「一〇方式」を採用する。この場合，単位語は
原則として「万」以上とする。但し概数を表記する場合は，「十」
，「百」，「千」の単位語を
用いることを奨励する。この場合においては，形式は「十字方式」と同一になる。
【備考】概数表記の詳細は，解説 2.6 (e)項を参照。
三桁区切りのテンは，基本ルールとしては用いない。使用する場合は，西暦年などの慣
用的に使用しない対象を除き，統一的に使用するものとする。また，読点との区別ができ
ることを考慮する。以下の内容が，1,990 個なのか，あるいは 990 個なのかがテンの解釈に
よって変わるからである。基本的には全角で組むか半角で組むか，という差で認識できる
が，通常の読点であっても，禁則処理のために半角組みとすることがあるので注意を要す
る。
唯 一、
九九〇個の
唯一、九九〇個の
概数を表記する場合，“〇”（ゼロ）を重ねることはふさわしくないために単位語を用い
る。この例を下図に示す。
約 五千 円
約二百種類
約百メートル
年月日の表記は「十字方式」によることを原則とする。アラビア数字表記を採用する場
合はこの限りではない。
法令関係の文書では発音通りの表記に近い「十字方式」を用いるものとし，この規則を
適用しない。
3
【備考】「一〇方式」の考え方と事例は「解説」を参照のこと。
4.2.2 アラビア数字の使用
伝統的には漢数字を使用すべき箇所であっても，可読性に支障を来たさない範囲でアラビ
ア数字を使用することができる。但し，解説 2.2 項に示すように，横組においても漢数字で
表記する慣わしがあるものについては，アラビア数字表記は行わない。
単位語は漢数字の使用時と同様，原則として「万」以上とする。三桁区切りのテンは使
用しない。小数点は“中点”で示す。西暦年を表記する際の省略のためのアポストロフィ
ーは用いない。
縦組におけるアラビア数字の使用事例を以下に示す。
２００５年１月
７０００∼８０００年前
６５４０億ドル
１５００万円
２・２兆円
５６歳
１億５７９０万件
１９７０件
９・５％
アラビア数字は，原則として全角モノを用いるが，２桁数字については半角数字を縦中
横で使用してもよい。使用事例を以下に示す。半角数字を用いる場合は，同一文書におい
てユレがないようにする。
70
80
２００５年
23
∼ 年前
65
億ドル
25
万円
65
・２兆円
37
歳
87
12
月
億５７９０万件
件
・２％
10
表記にあたっては，
①
二桁数字に限っては，特例を設けずに半角二桁のアラビア数字を採用する
②
基本的に二桁の数字以内しか持たない種類の箇所にだけ半角二桁のアラビア数字を
採用する
という２つの方法が考えられる。②の例では，西暦下２桁表記，月日，時間（時・分・秒），
年齢（この場合は 100 歳以上もあり得るが，特例と考える）などがある。つまり，時間・
年齢表記だけを対象にするというものである。②の例を以下に示す。
4
月
12
26
31
54
日午前 時
15
秒
16
時 分
05
年３月期
13
歳まで
( 逮)捕
25
歳から
∼容疑者
歳で定年
60
10
もともと半角二桁のアラビア数字を縦中横で使用できるかどうかはアプリケーションに
依存する面もあり，上記①，②のどちらでも統一的に使用するのであれば許容することと
する。
【備考】不整合がないという理由から，②の方式を推奨する。
５．アラビア数字列を縦組用漢数字列に変換する基本ルール
5.1 原則
①
対象数字列を確定する
②
その中に位取りのカンマがあれば，それを削除する（もともとない場合もある）
③
アラビア数字→漢数字変換を行う
④
下一位から４桁ごとに区切り，単位語を自動挿入する
⑤
数字列の間にあるピリオドは中点に変換する（小数点表記。ここではフランス表記
方式は対象としない）
⑥
その他，必要とする変換を行う。
①において，縦組で表示する場合においても，アラビア数字のままにしなければならな
い場合があり，それに該当する数字は対象から除外しなければならない。たとえば，
・判型（“A4 判”，
“B5 判”など。但し四六判などは横組においても漢数字を用いるので
注意）
・絵画のサイズ（“100 号の大作”，
“25 号の油彩”など）
・道路番号（“国道 135 号線”など）
・自動車番号（たとえば“品川な 0123”など）
・列車・航空機の名称，便名（“700 系のぞみ”，
“ひかり 130 号”，
“全日空 25 便”など）
・元素番号（“ウラン 235” など）
・スポーツ選手の背番号
・鉛筆の硬さ（“2B”，“3H”など）
・家屋の間取り（“2LDK”など）
がある。これらは，数字の前後の文字列から判断しなければならないが，種類も多く，表
記も多岐にわたるため，全自動による変換は難しい。
⑥は，たとえば“−”を“マイナス”に変換するなどである。横組・アラビア数字使用
5
の場合においても，文章中では“−”を用いず，“マイナス”と表記すべきであるが，アラ
ビア数字列の直前に“−”があった場合（場合によっては数字列の間に入ることもある）
はマイナスの意味と判断して文字の置き換えを行うのである。“＋”も同様とする。
5.2 単位語をつけない処理
5.1 項ステップ③では，無条件に単位語を付けることになる。しかし解説 2.6 ｇ）に示すよ
うに，数値の内容によって単位語を付けないものもあり，一律に処理することはできない。
この処理を自動的に行うためには助数詞を認識し，それによって単位語を付加するかどう
かを決定する。
さらに，被変換文書はまったく表記方向に非依存であることはありえない。ほとんどの
文書作成がエディタを用いると考えれば，作成時点では横組が連想されていると思われる。
この環境では，横組対応の助数詞が記載されることが多いはずであり，縦組変換に際して
は，助数詞自体の変換が必要になる場合が多いと考えられる。
したがって，
①
助数詞を認識
②
単位語を付加するかどうかの検定
③
単位語の付加（又はスキップ）
④
（必要に応じて）助数詞の変換
というステップを踏むことになる。
④項は，たとえば
Kg → キログラム
dB → デシベル
cal → カロリー
ml → ミリリットル
などの変換をいう。これらを単位記号のままで表記するか，カナ表記するかは選択できる
ことが好ましい。
【備考】「選挙関係」，「標高・水深」，「気象」，「科学的測定値」などにみられるように，
助数詞が数字の直前・直後に来ない場合，助数詞の種類を限定できない場合，もともと
助数詞を伴わない場合などがあり，全ての種類を自動で認識させることは困難である。
5.3 十字方式を採用する場合の処理
これについても，基本的には助数詞で判断することになる。「年月日」，「概数」，
「漠然とし
た数」がこれに当る。
年月日については，“∼年∼月∼日”，又は“∼年∼月”，“∼月∼日”という一連の文字
列であれば判定しやすいが，とくに“∼日”だけの場合には特定の日にちを表すのか，あ
るいは積算日数（たとえば“今日で五〇〇日連続となる”など）を表すのかがわからない
6
場合もある。後者の場合は一〇方式でよいが，意味理解を伴うため，自動変換対象にはな
りにくい。
概数については，たとえば次のものが該当する。
・数字列の直前に付くもの：
約∼，数∼（“二百数十円”のように，数字列の間に入るものもある），何∼（“十何人”
のように，数字の後ろに付く場合もある），およそ∼，おおむね∼，ほぼ∼
・数字列の直後に付くもの：
∼強，∼弱，∼余り，∼足らず，∼前後，∼程度
しかし，解説 2.6ｅ）に示すように概数の単位語の種類が多く，完全に絞り込むことは難
しい。また，「大略の数値を示せば次の通りである。」などという文章の後に数字列を記述
する場合，直前・直後の語だけで判断することができない。
漠然とした数は，一種の数値幅を持っており，その間をカンマ，又はテンで区切る（数
字の幅を示すのものとは異なることに注意）。カンマの場合，位取りのカンマと混同しない
ように注意する必要がある。
5.4 その他
数字表記の原則を決める理由の一つは，組版品質の向上にある（解説 １．概説を参照）。
すなわち，アラビア数字で表記された数字列は，行末の強制改行の際の分割位置を制御で
きるが，漢数字の場合は数字列を定義しにくく，強制改行分割禁則とならないという問題
を改善することである。
この実装方法等は処理系に委ねることであるが，基本的考え方について以下にまとめる。
①
アラビア数字列を漢数字に置換した際，その対象文字列に対して分割禁則対象の属
性を付与する。
②
その文字列の中に単位語，又は小数点を表す中点がある場合，単位語の後ろを分割
禁則対象から除外する。
③
助数詞全体を分割禁則対象とするかどうかについては，とくに定めない。この条件
を必須とすると，３文字分（３倍）以上の次行への移動が生じ，隣接行の字数が違
いすぎる弊害がでる可能性が高いからである。
四万五〇〇〇箇所
四万五〇〇〇個
A
B
C
D
A
B
C
D
上図左の例において， 印は分割可能点である。いま，成り行きで“A”点が行末にな
った場合は，もっとも近い分割可能点である“五”の上で改行する。この場合は１字
7
の追い出しになる。“B”が行末になったときにも，もっとも近い分割可能点は“五”
の上であるが，この場合の調整字数は２字分になる。
“C”の場合は，
“個”の下が最適
分割点になるが，この場合も調整字数は２字分になる。“D”の場合も同様に“個”の
下が最適分割点になり，調整字数は１字分である。
しかし，上図右の例では，成り行きで“C”点が行末になった場合，前後どちらの可
能点も３字分を調整しなければならず，これは実用的な分割禁則を実現できない。し
たがって，助数詞の文字列が２字以上あった場合でも，最初の１字の後ろを分割可能
点にすることが現実的である（同図
印）。
8
変換例
以上の基本的なルールを適用し，XML 文書に対して XSL Formatter に数字変換機能を仮
実装し，それを用いたスタイル指定によって横組／縦組に自動変換した例を以下に示す。
9
解
説
１．概説
文書の意味情報の扱いについては，さまざまな研究がなされているが，もっとも基本的な
日本語検索機能についてみると，
・ひらがな⇔カタカナ
・小仮名／大仮名，音引きの有無のユレ
・ローマ字表記のユレ
・異体字の包摂
などに関しては，いくつかの解決策が提示されている。しかし数字については，アラビア
数字表記を自明の理と考えられているためか，ほとんど検討されていなかった。
数字表記で，とくに問題になるのが漢数字（かつては「和数字」とも呼ばれていた）で
ある。漢数字は，従来から縦組（縦書き）では標準的に用いられているが，文字単位にみ
ると漢字の中の一つにしか過ぎず，意味情報を取り出すことが難しい。そのため組版上は，
アラビア数字では一般的に数字列を分離禁止にして可読性が損なわれることを防いでいる
のに対して，漢数字表記においては何らの対応もとらず，漢字を並べただけと変わらない
処理になっている（下図）。
◎
横組・アラビア数字使用の場合
−
一般のアプリケーションで以下のような自動変
換が可能
□□□□□□□□
1234□□□□□□
□□□□□□□12
又は
34□□□□□□
□□□□1234
□□□□□□
◎
縦組・漢数字使用の場合
□□□□
□□一二三四
□□□□一二
三四□□□□□
このような処理は，
できなかった。
10
原因のもう一つは，漢数字表記にも表記方法が複数存在し，しかも個々にユレがある場
合が多いことである。そのために，数字列の意味内容を理解して必要な変換処理を行なう
ということも困難であった。
構造化文書が普及し，内容情報と体裁情報が分離されることによって，横組のアラビア
数字表記と縦組の漢数字表記が自動的に行われる環境が必要になる。漢数字表記の方法が
明確になれば，この変換アルゴリズムを構築することも不可能ではなくなる。
この仕様の目的は，このような状況を踏まえて漢数字表記の実態を調査し，その使用実
態にできるだけ合わせて統一的よりどころを規定し，縦組表記への自動変換等に供するこ
とである。したがって，これは新たなルールを設定するものではない。
２．漢数字の表記方式
2.1 漢数字表記の種類
漢数字の表現には，いくつかの種類があるが，
「十字方式」及び「一〇方式」が一般的であ
る。現在では「一〇方式」多く用いられるが，読みに忠実な表現形式である「十字方式」
も捨て難い。表記の内容によっては「一〇方式」と「十字方式」が同じ表記になるものも
多く，「十字方式」についても解説する。
【備考】表記内容によっては横組においても漢数字を用いる場合がある。
2.2 横組における漢数字の使用
横組であっても，漢数字を用いる場合がある。ここに挙げた事例では，縦組でアラビア数
字を用いる場合でも，漢数字でなければならない。以下に例示とともに示す。
ａ）ひとつ，ふたつ，みっつと読む場合
一つ屋根の下，二間続き，四葉のクローバー，五つ星のホテル，開始十日後
ｂ）固有名詞，熟語，慣用語句
一日千秋，一寸の虫にも五分の魂，二束三文，二人三脚，御三家，万歳三唱，三色
スミレ，三日天下，再三再四，三寒四温，四苦八苦，四面楚歌，五里霧中，五臓六
腑，第六感，七転八倒，八方美人，八百長，九死に一生，十字架，十人十色，十二
指腸，いろは四十七文字，五十肩，百も承知，百貨店，百発百中，千客万来，千載
一遇，白髪三千丈，迷惑千万，万一に備える
ｃ）数字が特別な意味を持つもの
一族郎党，一姫二太郎，一芸に秀でる，空一面，いの一番，一網打尽，一目瞭然，
一目散，一夜漬け，第一印象，一花咲かせる，一時金，三角形，四つ角，三百六十
度の展望
ｄ）数字を含む語が明確に多くの人が認識しているもの
四大文明，四半世紀，五大陸，加賀百万石
11
ｅ）伝統的日本文化に関わるもの
初七日，お七夜，十三回忌，四十九日法要
ｆ）勲位，段位
勲三等，柔道四段，アマ五段，珠算二級
ｇ）肩書き等の，「代」
，
「世」など
六代目菊五郎，第十五代将軍，二代目社長，十三世名人
ｈ）日本の旧度量衡
十一文の足袋，五万石の大名，
ｉ）その他，漢数字書きが馴染んだ表記
三冠王，五五年体制，百八十度の方向転換
など。
2.3 縦組におけるアラビア数字の使用
次に示す例は，縦組においてもアラビア数字を用いる。縦組の数字表記をアラビア数字に
第２四半期
する場合においても，この例の場合における「四半期」は漢字表記とする。
2.4 漢数字表記に用いる数字文字
原則として，次の数字及び単位語を用いる。
・数字：〇，零，一，二，三，四，五，六，七，八，九，十，百，千
・単位語：万，億，兆，京（以下略）
（百，千は，区切りのよい数値の場合，及び概数表記の場合に単位語として用いる）
数字としての壱，弐，参，伍，拾，廿，卅など，及び単位語の萬は，特殊の場合以外に
は用いない。
2.5 一〇方式と十字方式との違い
ａ）十字方式
十字方式は，「じゅう」と読ませる場合は十と表記し，「ひゃく」と読ませる場合は
百と表記することを原則とする表記方式である。
ｂ）一〇方式
一〇方式は，用いる数字と発音の一致性よりも，表記の簡便性と視覚で理解するこ
とを重視し，アラビア数字による表記との一致にも配慮した表記方式である。
12
2.6 一〇方式，十字方式の表記方法
数字表記の種別ごとに，例示して説明する。
ａ）一般数
以下に例示するように，
“一〇方式”では“〇”で表記し，
“十字方式”は 10 の桁を
“十”で表記する違いがある。
まず，二桁数字の例を示す。
三四個
九五個
二十個
三十四個
九十五個
十六個
二〇個
一六個
十一個
十個
十字方式：
一一個
一〇個
一〇方式：
一〇方式で次図の（Ａ）のように表記する場合，「34 個」の意味になる。「さんよん
こ」を表記する場合は，同図（Ｂ）のように表記する。十字方式ではどちらも「さ
んよんこ」の意味になるが，同図（Ｂ）は許容とする。
三、
四個
三四個
（Ａ） （Ｂ）
ｂ）三桁以上の数
十字方式においても“〇”を使う場合がある。たとえば三桁又は四桁数字において，
一∼九の数字が二つ以上ある場合には“〇”を用いる。但し熟語成句の場合はこの
限りではない（たとえば「二百十日」）。
三四〇〇本
二〇五枚
一二〇日
位取りのテンは入れない。
一〇方式では，“百”
，“千”の単位語は原則として用いない。しかし十字方式におい
ては，区切りのよい数字の場合は，
“百”，
“千”を用いて表記してもよい。この場合，
表記は十方式と同一になる。
五〇〇〇円
二〇〇種類
一〇〇メートル
一〇方式：
13
五 千円
二百種類
百メートル
十字方式：
ｃ）一〇方式における万の位（五桁）以上の数
“万”，“億”
，“兆”
，“京”などの位は漢字記号を用いる。
“10,000”，“100,000,000”などを表す場合は，誤読を避けるために，“一”を付け
五億一〇〇〇万人
二万一〇〇〇個
四億五七〇万六八三種
五一億八〇〇万人
三億四〇〇〇万光年
一億個
一万倍
る。
一〇方式において，ゼロが数字の最初に来る場合は以下の（Ａ）のように表記する。
十方式では同（Ｂ）の表記を原則とするが，（Ａ）も許容する。
午前零時十五分
午前〇時十五分
（Ａ） （Ｂ）
ｄ）法令における数字表記
法令においては縦書きを通例としており，数字表記も漢数字が用いられる。この場
合の基準はおおむね以下の通りである（本仕様の一般原則は，ここには適用しない）
。
１）正確な発音通りに表記することを原則とする。これは「十字方式」に該当する。
特に数字は印刷，解釈に誤りがないようにするためである。
第百二十五条第二項第一号
法律第五十一号
14
２）多くの数字を表に掲げる場合，単位語を入れず，数字列だけにした方が分かり
やすいことが多いため，次のような表記が許容される。この場合，数の単位区分は，
三進法により，千，百万，十億，一兆の各単位に“、”を付けて示す。
一九七、八〇〇円
二五一、〇〇〇円
二四四、一〇〇円
仮定俸給年額
二〇三、四〇〇円
基礎となる俸給年額
︵略︶
表以外の条文の規定中においても，多くの数字を用いる場合は上記と同様の表記を
許容する。
３）文章の中で分数を表記する場合，次のように記載する。
百分の三十五
三分の二
４）小数点のある数字については，次のように記載する。
百七十四・八二五
〇・五二
５）倍数については，数字の後ろに「倍」を付けて表す。
15
６）期日又は期間を表すための数字表記においては，以下のように記載する。
十五年
三月
一週間
十二月一日
三月三十一日
７）期間を示すものと暦年を示すものの区別が難しい場合，以下のように「箇」を
加えて記載する。
五箇年
ｅ）概数
十字方式の表記とする。
１）数字のはじめに「約」を付ける。
約五千円
約二百種類
約百メートル
２）数字のはじめに「数」を付ける。
十字方式の表記とする。数字表記の途中に「数」を付ける場合もある。
二百数十箇所
数 千円
数百種類
数百メートル
３）数字の最後に「強」，「弱」，「余り」，「足らず」，「前後」，「ぐらい」，「程度」な
どを付ける。十字方式とする。
半角の読点を挿入する。十字方式の表記とする。
16
五千円程度
五千円ぐらい
五千円前後
二百種類足らず
百メートル余り
百メートル弱
百メートル強
４）漠然とした数値表記
五、六千円
四、五百種類
二、三百メートル
５）一定の基準の前後を表す表記
数字の最後に「未満」，「以内」，「以下」，「まで」，「以前」，「以上」，「から」を付け
る。なお，この場合は一〇方式の表記でよい。
十月以前
五〇〇〇円から
五〇〇〇円以上
五〇〇〇円まで
五〇〇〇円以下
五〇〇〇円以内
五〇〇〇円未満
ｆ）数の幅
数の幅を示すときは，“−”（ダーシ）を挟む。“∼”はできるだけ用いない。
【備考】横組においては“∼”を用いる。
一五〇︱二〇〇円
一九〇四︱〇五年
七九四︱一三三三年
五二︱六五ページ
十八︱十九世紀
五千ないし七千人
ｇ）単位語の扱い
漢数字表記には，原則として単位語を付ける。但し，単位語を省略する例外もある。
以下に例示とともに示す。
【備考】法令・条文も単位語を入れないが，これに関しては解説 3.7 d)項で詳述する。
イ．住所の番地
ロ．西暦年
ハ．選挙の結果，表決の票数など
ニ・統計表，株価，為替レートなど
ホ．百分比，ポイント
ヘ．経度，緯度
ト．標高，水深，水位
17
チ．温度，気圧，降雨量，積雪量などの
気象，台風，地震
リ．身長，体重，脈拍，翼長，体長
ヌ．速度
ル．船のトン数（原則としては単位語を入れないとされるが，「二十万トン級」など
という場合を含めて，単位語を入れることも行われており，両方を許容する）
ヲ．車の排気量，馬力
ワ．騒音，濃度，角度，こう配，周波数，
放射線量，その他科学的な測定値
以上の用例を以下に示す。
平成丸︵五万二五四五トン︶
ル、
平成丸︵五二五四五トン︶
風速四五メートル
ヌ、
毎時三二〇キロ
六四キロ
リ、
一六九センチ
チ、九四三ヘクトパスカル
一四二二キロヘルツ
ワ、
一〇〇デシベル
二五〇馬力
ヲ、
一八〇〇
18
三七・八メートル
ト、
三二六〇メートル
北緯三七度二五分
ヘ、
三五度
ホ、八六・一％
ニ、一ドル＝一〇三円
ハ、東西市︵定数五〇︶
八〇年代
ロ、
一九六〇年
イ、北区南町五の一三の二
cc
６．実際の事例
6.１ 新書の例
専門書ではなく，一本的な読者を想定した縦組の書籍として「新書」の事例を挙げる。
のコ アを 四 二
団地は五階建が三一棟、一〇〇〇戸の大規模集合住宅で、
一九六〇年代から七〇年代まで、
全 棟 の 約三 分の 一 に相 当する 一 〇棟 から 直 径 一〇
本採取して、
コンクリートの体積の七〇∼八〇％を占めている。
一九五五︵昭和三〇︶年にはわずか二七〇〇に過ぎなかった国道の
に増大したことになる。一方、一九六七年以前にはわずか四万戸に
橋梁は、一九九〇年には六万三〇〇〇に達した。四〇年間に二三倍
過ぎなかった分譲マンションは、大都市近郊を中心として急速に普
ア ル カリ 量 は 〇 ・ 二 六 ％と な る 。 両 者 を 合 算 す る と アル カ リ 量 は
〇・七九％となる。
体重が一〇〇倍になればエネルギー消費は三二倍、一〇〇〇倍なら
一七八倍、一〇〇〇〇倍なら一〇〇〇倍、ちなみに、体重四トン︵ゾ
ウのサイズの動物︶と体重四〇グラム︵ハツカネズミのサイズ︶とでは、
しかない！
体重差は一〇万倍あるが、エネルギー消費の増加は、体重の増加の
−
係なく、一キログラムあたり〇・七三八ジュールとなるし、一生の
哺乳類では、心臓が一回打つ間に消費するエネルギー量は体重に関
間の総エネルギー使用量は、一五億ジュールと一定になる。ちなみ
に一五億ジュールとは、灯油に換算すれば四万リットルを燃やした
エネルギーにあたる。
この式にＷ＝六〇キログラムを入れて、ヒトのサイズの動物の密度
を求めてみると、一・四匹／平方キロメートルとなる。一九八五年
の日本の人口密度は三二〇人／平方キロメートルなので、サイズか
ら予測される密度の、なんと二三〇倍の密度でギュウギュウ暮らし
ていることになる。
うなるだろうか。体重六〇〇キロ︵ウマのサイズ︶まで大きくすると、
骨格系の重量が体重の一・三三乗に比例して増えたと考えると、ど
体重の三四％が骨格系、体重一〇・八トン ︵ギネスブックにのってい
る最大のアフリカゾウのサイズ︶まで大きくすると、なんと八八％が骨
中公新書「ゾウの時間ネズミの時間」
本川達雄著
1
18
で埋まる計算となる。
19
岩波新書「コンクリートが危ない」より
小林一輔著
cm
及し、一九九六年末には約三一六戸に達している。三〇年間に八〇
倍に増えたことになる。
m2
モルタル中のセメント重量は六六〇 ／ であるので、海砂由来の
kg
旅順港攻撃のために六万人の戦死者を費やした ︵日露戦争での全戦死
。 しか し 、 一 九 〇 四 年 一二 月 六 日 、 つ い に二 〇
者は 八 万 五 〇 〇 〇 人 ︶
三高地は陥ちた。
外資借入残高は一三億二五〇〇万円に上がった。これは当時のＧＮ
Ｐ三三・〇億円の四〇・二％となり、元利支払いのために輸出等外
貨収入の三六・九％を費やさなければならなかった。
一九一七年∼一八年にかけて、中国の段祺瑞政権に対して満州・蒙
古での利権を担保に鉄道建設、電信建設などに一億四五〇〇万円の
資金を提供した。
高齢者︵五五歳以上︶の情報機器装備率である。パソコンの所有率
を見ると、全米平均の三七％に対して二一％、ネットワークへの接
続率を見ると、全米平均の一九％に対して九％にすぎない。
一万五〇〇〇のアカウントを対象にして、一秒間に約七五〇の割合
でパスワードをチェックした。はじめの一五分で三パーセント弱、
一週間で二〇パーセント以上も当ったという。
五〇〇〇年かかるという例題、一七年後に六〇〇人のグループがボ
ランティアをかって出て、一六〇〇台のコンピュータを使い、八か
月かけて解くことができたという。
レンタルショップの料金は一回二五〇円であった。当時、レコード
一枚の値段は二八〇〇円だったので、
米国政府は情報公開のために年間五億ドルを超えるコストをかけ、
う
連邦捜査局はこのために二〇〇人、司法省は六三〇人相当の事務量
を抱えているという議会証言もあった。
九八年時点で寄託図書館の数は一三六〇、
3
9
0
0
0
6
6
6
.
8
1
になってしまう。
、の⋮⋮
九八年度に、ＧＰＯは三万八九八九タイトル計一四四四万点
ち電子本は八三六タイトル、計三三万点
⋮⋮となるはずのものが、
20
すでに一九〇九年に、従業員一〇〇人以上の大工場では八八・四％
に達していたが、これは主として蒸気力によるものであった。従業
員五∼二九人の工場での動力化率は二〇・五％にすぎなかった。
満州から五七〇〇万斤の輸入をしたが、日本全体の輸入量は二〇億
五〇〇〇万斤に及ぶ。︵中略︶領有以後すでに一〇余年たつが、何
の経済的利益ももたらさない。
日本の正貨保有高は一九二〇年︵大正九年︶末には二一億七九〇〇
万円まで増加した。二〇年当時の日本のＧＤＰは、一五八億九六〇
〇万円であるから、これはＧＤＰの一三・七％に当たる巨額の外資
である。ところが一九三〇年末には九億六〇〇〇万円にまで減少し
た。
丸善ライブラリー「デジタル・ミレニアルの到来」より
名和小太郎著
ちくま新書「日米関係の経済史」より
原田泰著
6.2 一般書の例
米国の防衛産業は東西の冷戦終結とともに、一九九一年をピークに
縮小し続けている。国防総省は一九九五年度に兵力一〇万人を削減
し、さらに一九九六年度にも約四万人を継続して減らす。そうする
と、一九八七年のピーク時に比べて三二％減にまでなる。国防費も
年間五％程度ずつ減少し続け、これに伴い防衛産業の売上高も毎年
三％から一〇％近く減少している。
企業内でも社会的にも当てはまるが、異なるシステム間の変換には
膨大な数のシステムが必要になる。二つのシステム間の変換は二変
換システム︵二変換器︶だけであるが、これが五システム間になる
と二〇変換システム、一〇システムで九〇、一〇〇システムで九九
⋮住民とともにコミュニティイントラネット﹁縁えんネット﹂を構
築し、１９９８年８月から２０００年３月にわたって社会実験を行
３３世帯、９４９人であり、地域の約４０００世帯の１割が参加し
なった。実験終了時点で、ＩＤ・パスワードを付与された住民は４
たことになる。
行政情報化の推進状況調査﹂によれば、電子自治体に向けた推進体
総務省が、２００１年４月１日に実施した﹁地方公共団体における
制として、新たな専門課︵係︶を設置した団体は都道府県において
・９％︶である。
団体︵
・
団体︵ ・８％︶、市区町村では３０１団体︵９・３％︶である。
９％︶、市区町村では１５２２団体︵
既 存 の 課 ︵ 係 ︶ が 担 当 した 団 体 は 都 道 府県 に おいて
社の入札額は最低 万円から最高１・１億円であり、総合評価
２ ０ ０ １ 年 ９ 月 に 行わ れ た 東 京 都の 電 子 調 達 シス テ ムで は 応 札 し
46
31
46
ことである。ある意味、 世紀をリードするＩＴ産業が⋮
ことである。第三に、情報サービス産業の健全な発展が阻害される
えで は電 子自治 体 サー ビスの 品 質 に 関する 創 意工 夫が阻 害 され る
ープ程度に絞られてきた感が強い。第二に、安ければいいという考
ある。実際、電子政府、電子自治体システムの受注は、４、５グル
第一に、受注企業が資金力にまさる大手ベンダーに限られることで
００万円程度の予算に対しＢ社が７５０円で落札した。
京都の文書総合管理システムでは最低価格方式であったため８、５
方式を導入していたためＡ社が１０００万円で落札したが、続く東
10
21
21
15
22
た
10
〇〇、一〇〇〇システム間の変換になると九九万九〇〇〇もの変換
システムが必要になるのだ。
末松千尋「CALS の世界」ダイヤモンド社 1995 より
石井良一・名取雅彦・小林慎太郎「電子自治体経営イノベーション」ぎょうせい 2002 より
6.3 新聞の例（年齢文字など，組合せ文字は個別文字に置き換えてある）
国と地方の税財政改革︵三位一体改革︶に関する全体像を決定した。
二〇〇五、〇六年度の国から地方向けの補助金削減額は約二兆三百
八十億円が確定。その見返りに地方に委譲する税源は〇四年度分の
六千五百六十億円も含め約四千百六十億円となった。
主要生命保険十四社︵グループ︶の二〇〇四年度上半期業績が二十
六日出そろった。保険料収入は国内主要八社が前年同期に比べ四・
三％落ち込む一方、外資系や損保系など新興生保六社は一五・五％
年の２５５億ドルから１００億ドル程度に減る見
年の貿易の内訳は輸出が５５５０億ドル輸入が５４５０億ド
ル、貿易黒字は
通し。１∼９月期でみると、中国の最大の貿易相手はＥＵ︵欧州連
合︶で１２８０億ドル、ついで米国の１２２２億ドル、 年は通年
月の消費者物価は、前年同月比
で首位だった日本は１２１７億ドルで３番目。
日発表した
上昇が続いていたが５ヵ月ぶりに下回った。
４・３％増で９月より０・９ポイント下がった。６月から５％台の
中国国家統計局が
03
日本損害保険協会は 日、新潟県中越地震による地震保険の支払
年１月、７８３億円︶と芸予地震︵
年３月、１６９億円︶
19
増となり、成長力で明暗を分けた。
10
い見込み額が、１万 件、約１３８億円に上ると発表した。阪神大
震災︵
に続く３番目の規模。
01
日本経団連が二十六日発表した二〇〇三年度の電力や石油、鉄鋼な
12
▽十日市町８０１件、 億円など。
地域別では長岡市５５１８件、 億円▽小千谷市９２６件、 億円
73
ど主要三十四業種の二酸化炭素︵ＣＯ ２︶排出量は、前年度比一％
増の五億二百三十九万トンだった。増加は二年連続。
03
04
万円、ほか１名を同
万円とした。
⋮東京簡裁は 日、罰金 万円の略式命令を出した。また製造・販
︶を同
月、３人に対し、無許可でカプセル６４０錠を６万４
千円で販売するなどした。
昨年５月∼
東京地検によると、３人とも罪を認めているという。高橋代表は
売した会社役員︵
30
22
12
15
20
50
一 〇・一一五％の幅で推移。二〇〇五年十二月物も今週に入って
95
44
78
12
12
二〇〇五年六月物の金利︵公式終値ベース︶は、十一月上旬から〇・
〇・二〇五 〇・二二％で動きを止めた。
「日本経済新聞」2004.11.27 朝刊より
「朝日新聞」2004.11.13 朝刊より
北海道新幹線の新規着工が決まり、青函トンネルが再び脚光を浴び
ようとしている。新青森 新函館は百四十九キロ。うちトンネル区
間の八十二キロは新幹線仕様で創られ、将来に備えてあった◆トン
ネルを管理しているのはＪＲ北海道だ。毎分二十一トン、一か月で
東京ドーム〇・七杯分に及ぶ湧き水を、ポンプでくみ出している。
作 業 には 毎年７ 億 円 近 くかか る とい う◆か つて 旧 大蔵省 の 主計 官
住居地域は海岸に面していたため、直接 メートルを超える津波を
囲約 キロ。震源地から北西約５００キロに位置する。約３万８０
５００人のうち１５０人が死亡したという。カールニコバル島は周
受け、４、５階建てのアパートが破壊された。空軍の軍人や家族約
15
００人が住んでいたが、津波被害の全容は明らかになっていない。
︶の得票率は ・８％。暫定投票率は
％と報道されたが、
中央選管によると、２位の人権活動家、ムスタファ・バルグーティ
氏︵
選は
年以来年ぶり２回目で、７人が立候補した。
年の地方選挙は、９県で知事選があり、東京都議選か７月
日の
種出口調査の結果に基づき早々と勝利宣言。︵中略︶自治政府議長
有権者数は１８０万人と推計されている。アッバス氏は９日夜、各
これは登録有権者１１０万人を母数に計算したもので、投票可能な
70
に﹁戦艦大和などと並ぶ昭和の三大バカ査定の一つ﹂と酷評された。
い ま は 一 日 当た り 上 下 各十 八 本 の 旅 客 列 車 と 二 十 三 本の 貨 物列 車
に利用され、人の往来よりむしろ、北海道の農水産物などを全国に
送り届ける物流の当脈として、それなりに役立っている。
︶が ・３％
30
50
96
が決まっている 市を含め１６５予定されている。︵中略︶
任期満了に伴って行われる。市区長選は現時点で、新設合併で誕生
22
選挙管理委員会は十日、パレスチナ解放機構︵ＰＬＯ︶主流派ファ
タハの公認候補マフムード・アッバスＰＬＯ議長︵
の票を獲得し、当選したと発表した。穏健派アッバス氏が二位以下
との和平交渉は、再開に向けて動き出した。
の六候補に大差をつけて圧勝したことで、中断していたイスラエル
同社によると、最近十年間の災害の発生は、一九六〇年代の二・二
倍に増えた。この間の経済損失は５１４５億ドル︵約 兆円︶にの
ぼる。
インドネシア・スマトラ島沖地震・津波は、未体験国も多かったこ
05
知事選は、山形、岐阜両県が６日に告示され、既にそれぞれ３候補
による選挙戦に入っている。
千葉県警千葉東署は 日、同区内の私立高校１年の生徒ら少年３人
︵いずれも
分ごろ竪穴式住居︵直径約５メー
歳︶を非現住建造物等放火容疑で逮捕した。
調べでは、３人は 日午前３時
３人は﹁寒かったので温まろうと思った﹂と容疑を認めているとい
トル、高さ約５メートル︶にライターで火を付け全焼させた疑い。
年に国指定史跡となった。
う。同遺跡は面積約 万平方メートル。縄文中∼後期︵３０００∼
４５００年前︶の貝塚が二つ隣接し、
77
とから、約十か国で十五万人以上もの犠牲者を出した。その損害額
積もっている。
20
23
19
10
13
62
について、同社は１００億ユーロ︵約１兆４千億円︶を超えると見
50
10
16
69
52
「読売新聞」2005.1.11 朝刊より
「毎日新聞」2005.1.11 朝刊より
参考文献
・戸台俊一著
・2002 年度版
新版
校正ハンドブック
朝日新聞の用語の手引
・毎日新聞用語集（2002 年）
・読売スタイルブック 2002
ダヴィッド社
朝日新聞社
毎日新聞社
読売新聞社
・記者ハンドブック（第９版 2001 年）
・用字用語ブック（第３版 2000 年）
共同通信社
時事通信社
・ワークブック法制執務＜全訂＞ 2003 年 30 版
24
株式会社ぎょうせい
[附属資料－Ａ．２．１]
ニュース用マーク付け言語
（第 4 章まで抜粋）
X 7201：2005
まえがき
この規格は，工業標準化法第 12 条第 1 項の規定に基づき，社団法人日本新聞協会(NSK)／財団法人日本
規格協会(JSA)から，工業標準原案を具して日本工業規格を制定すべきとの申出があり，日本工業標準調査
会の審議を経て，経済産業大臣が制定した日本工業規格である。
この規格の一部が，技術的性質をもつ特許権，出願公開後の特許出願，実用新案権，又は出願公開後の
実用新案登録出願に抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査会
は，このような技術的性質をもつ特許権，出願公開後の特許出願，実用新案権，又は出願公開後の実用新
案登録出願にかかわる確認について，責任はもたない。
JIS X 7201 には，次に示す附属書がある。
附属書 A（参考）この規格と NewsML1.0 版及び 1.1 版との整合性
附属書 B（規定）NewsML DTD（注釈なしの版）
附属書 C（参考）参考資料
附属書 D（参考）原規定作成の貢献者
1
X 7201：2005
目 次
ページ
序文························································································································································································ 1
1.
適用範囲········································································································································································ 1
1.1
概観 ·············································································································································································· 1
1.2
ニュースの交換及び管理のための枠組み ··········································································································· 1
1.3
XML に基づく構成··················································································································································· 1
1.4
メディア中立 ····························································································································································· 1
2.
引用規格········································································································································································ 1
3.
定義 ················································································································································································ 2
3.1
用語定義······································································································································································ 2
3.2
略語 ·············································································································································································· 3
3.3
XML 語い(彙) ···························································································································································· 4
4.
この規格の状態 ························································································································································· 10
5.
機能 ···············································································································································································11
5.1
文書の構造·································································································································································11
5.2
Catalog······································································································································································· 12
5.3
TopicSet ····································································································································································· 16
5.4
NewsEnvelope··························································································································································· 19
5.5
NewsItem の構造 ····················································································································································· 24
5.6
NewsManagement···················································································································································· 28
5.7
NewsComponent の構造········································································································································· 34
5.8
ContentItem の構造 ················································································································································ 41
5.9
メタデータ································································································································································ 44
5.10
NewsLines（メタデータの人間への見え方） ································································································ 52
5.11
NewsItem の改訂版の発行 ·································································································································· 55
5.12
ポインタの使用 ····················································································································································· 56
5.13
拡張 ·········································································································································································· 56
5.14
認証及びセキュリティ········································································································································· 56
附属書 A（参考）この規格と NewsML1.0 版及び 1.1 版との整合性 ··································································· 59
附属書 B（規定）NewsML DTD（注釈なしの版） ································································································· 61
附属書 C（参考）参考資料············································································································································ 80
附属書 D（参考）原規定作成の貢献者······················································································································· 81
ニュース用マーク付け言語（NewsML） 解
説 ···································································································· 82
2
X 7201：2005
日本工業規格（案）
JIS
X 7201：2005
ニュース用マーク付け言語（NewsML）
News Markup Language (NewsML)
序文
この規格は，
2003 年 10 月に国際新聞電気通信評議会
（International Press Telecommunications
Council，以下，IPTC という。
）から公表された NewsML1.2 版を翻訳し，技術的内容を変更する
ことなく作成した日本工業規格である。
なお，この規格で点線の下線を施した記述は，原規定にない事項である。
1.
適用範囲
1.1
概観 NewsML は，XML 並びに他の適切な規格及び仕様をもとに，ニュースのために，
小形で，拡張性が高く，柔軟な構造化の枠組みを提供する。電子的なニュース項目，ニュース項
目の集合，それらの間の関係，及び関連のメタデータの表現を支援する。NewsML は，同じ情
報の複数表現の規定を可能とし，あらゆるメディア型，フォーマット，言語及び符号化を混在し
て使用する。ニュースのライフサイクルのあらゆる場面を支援し，ニュース項目の繰返しの修正
変更を可能とする。NewsML は，メディア独立だが，テキストを扱うための特別の手法を提供
する。NewsML は，メタデータ及びニュース内容の両方の出所を明らかにする。
1.2
NewsML は，元来ニュース交換のためのフォー
ニュースの交換及び管理のための枠組み
マットとなることを目的としているが，ニュースの蓄積のためのフォーマットとして，又はネッ
トワークコンピューティング環境におけるニュースの作成，編集，管理及び発行の補助としても
使用される。
1.3
XML に基づく構成
NewsML 文書は，XML 文書であって，NewsML の文書型定義
）に従ったものとする［附属書 B 参照］
。
（Document Type Definition，以下，DTD という。
すべての XML 文書と同様に，NewsML 文書は，物理的というよりは論理的なオブジェクトと
する。NewsML 文書は，XML 規定で定められた実体参照（entity references）又は NewsML 文書
内のポインタ機構を使って，複数の物理ファイルの内容として構成されてもよい。
1.4
メディア中立
NewsML は，メディア型，フォーマット又はニュースオブジェクト符号化
について，何も前提としていない。NewsML 文書は，テキスト，動画，音声，画像，写真，そ
の他のメディア，
今後開発されるメディアなど，
あらゆるメディアの組合せを含むことができる。
3
X 7201：2005
2.
引用規格
次に掲げる規格は，この規格に引用されることによって，この規格の規定の一部
を構成する。これらの引用規格のうちで発行年を付記してあるものは，記載の年の版だけがこの
規格の規定を構成するものであって，その後の改正版・追補には適用しない。発効年を付記して
いない引用規格は，その最新版（追補を含む。
）を適用する。
JIS X 0301:2002
備考
情報交換のためのデータ要素及び交換形式―日付及び時刻の表記
ISO 8601:2000
Data elements and interchange formats -- Information interchange --
Representation of dates and times からの引用事項は，この規格の該当事項と同等であ
る。
JIS X 0304:1999
備考
国名コード
ISO 3166-1:1997
Codes for the representation of names of countries and their
subdivisions -- Part 1: Country codes が，この規格と一致している。
JIS X 0412-1:2004
備考
言語名コード－第 1 部：2 文字コード
ISO 639-1:2002
Codes for the representation of names of languages -- Part 1: Alpha-2
code からの引用事項は，この規格の該当事項と同等である。
JIS X 0412-2:2004
備考
言語名コード－第 2 部：3 文字コード
ISO 639-2:1998
Codes for the representation of names of languages -- Part 2: Alpha-3
code からの引用事項は，この規格の該当事項と同等である。
JIS X 4151:2001
備考
文書記述言語 SGML
ISO 8879:1986
Information processing -- Text and office systems -- Standard
Generalized Markup Language，ISO 8879/Amd.1:1988，ISO 8879/Cor.1:1996，及び ISO
8879/Cor.2:1999 が，この規格と一致している。
JIS X 4159:2002
備考
拡張可能なマーク付け言語(XML)
Extensible Markup Language (XML)1.0, 2nd Edition, World Wide Web Consortium,
2000-06 が，この規格と一致している。
XML Schema Part 0: Primer, Part 1: Structures and Part 2: Datatypes, World Wide Web
Consortium, 2001-05
備考
TR X 0054:2002, XML スキーマ 第 0 部 基本，TR X 0063:2002, XML スキーマ 第
1 部 構造及び TR X 0064:2002, XML スキーマ 第 2 部 データ型が，それぞれこれ
らの W3C 勧告に一致している。
3.
IETF RFC2141
URN Syntax
IETF RFC3066
Tags for the Identification of Languages
定義
3.1
用語定義
この規格で用いる用語の定義は，JIS X 4151 及び JIS X 4159 における定義によ
るほか，次による。
3.1.1
補完（complements） それぞれは，必要とされる全体情報の一部しか提供しないので，
一緒にすることが望ましいニュースオブジェクトの関係を表す概念。
4
X 7201：2005
3.1.2
統制語い(彙)（controlled vocabulary）
定義された用語及びその意味の一覧。正式な変
更管理処理（3.1.8 参照）に従って保守される。
3.1.3
既定語い(彙)（default vocabulary） 他の個別に参照される統制語い(彙)によって上書き
されるまで，又は上書きされない場合に，既定の意味及び許可された値を与える統制語い(彙)。
3.1.4
等価（equivalents）
含まれる情報が等しいために，その中で選択が行われることが望
ましいニュースオブジェクトの関係を表す概念。
3.1.5
フォーマット（format）
データオブジェクト（テキストの記事，写真及びそのキャプ
ション，ベクトル図形など各種データで構成されるオブジェクト）内の情報を運ぶために使われ
るファイルの様式。フォーマットが，オブジェクトを処理，解釈，又はレンダリングすることが
可能なアプリケーションを決定する。フォーマットの例として，GIF，JPEG，WAV 及び XML
がある。
3.1.6
メディア型（media type）
データオブジェクトに含まれる情報を人に示す媒体の型。
メディア型の例として，映像，音声，ラスタ画像，ベクトル図形及びテキストがある。
3.1.7
メタデータ（metadata） システムがデータオブジェクトを適切に扱うことを可能にす
る目的で，データオブジェクトと関連付けられたデータ。システムは，コンピュータアプリケー
ション，人が扱う業務処理，又はそれら二つの組合せであってよい。
3.1.8
命名方式（naming scheme）
3.1.9
ニュースオブジェクト（news object）
既知の意味をもつ名前又は符号の集合。
NewsML 文書の主な構成物の一つ。ニュースオ
ブジェクトの種類には，NewsEnvelope，NewsItem，NewsComponent 及び ContentItem がある。
3.1.10 ポインタ（pointer）
データオブジェクトを識別することを目的とする文字列。そのオ
ブジェクトにリンクを生成するか，又は文書を送信するたびにそのオブジェクトそれ自体を送る
必要なしに文書内にオブジェクトそれ自体を含めるかのいずれかのために用いる。
3.1.11 生データ（raw data） NewsML によって定義されない構造をもつデータ。したがって，
NewsML アプリケーションによって，別のアプリケーションへ転送されるか，解釈又は処理の
ために利用者へ転送されなければならない。
3.1.12 スキーマ（schema）
XML 文書クラスの構造の形式的定義。スキーマは，それ自体が
XML 文書であって，W3C の XML スキーマ規定（3.2.9
参照）に適合する。DTD において表現
可能なものより，もっと充実した制約及び構造規則の集合を規定できる。
3.1.13 トピック（topic） 一つのニュースの中で参照されることが可能なあらゆる実世界のも
の又は概念。トピックの例として，
“イラン・イラク戦争”
，
“トニー・ブレア”
，
“パキスタンの
首相”
，
“○○株式会社”
，
“国連”
，
“○○電気掃除機”
，
“中国”
，
“パリ”
，
“クレムリン”などがあ
る。
3.1.14 トピック参照（topic reference） ディレクトリ内でトピックへのポインタの役割を果た
す要素。
3.2
略語
3.2.1
DTD
文書型定義（Document Type Definition）
備考 XML 文書の構造を決定する宣言の集合。DTD は，文書自体の中にある内部サブセッ
ト（internal subset）
，文書型宣言によって参照されるファイル内にある外部サブセッ
5
X 7201：2005
ト（external subset）
，又はその両方の組合せに含むことができる。
3.2.2
IETF
インターネット技術タスクフォース（Internet Engineering Task Force）
3.2.3
IPTC
国際新聞電気通信評議会（International Press Telecommunications Council）
3.2.4
MIME
多目的インターネットメール拡張（Multipurpose Internet Mail Extensions）
備考 IETF の公式の規定。インターネット上で伝達されるデータ対象物を解釈，処理又は
表現する能力のあるアプリケーションへ，その準拠を可能とするために，データ対象
物のフォーマットを規定する仕組みを示す。
3.2.5
URI
統一資源識別子（Uniform Resource Indicator）
備考 特定の資源を識別する（場合によっては，場所を特定する）ために使われる大域的に
一意な文字列。URL 又は URN になることが多い。
3.2.6
URL
統一資源位置指定子（Uniform Resource Locator）
備考 本来はウェブ上で資源を見つけることのできるアドレス。しかし，これは，ウェブ資
源の識別子でもあって，
“http://”のプロトコル表示部分がウェブ資源を識別し，それ
にアクセスするために使われる。
3.2.7
URN
統一資源名（Uniform Resource Name）
備考 現在の場所とは無関係に，資源を特定する大域的に一意な文字列。
3.2.8
UTC
協定世界時（Coordinated Unversal Time）
備考 国際時報局が定義した時間の基準で，標準的な周波数及び時間信号の基礎となる。
UTC は，
（不正確ではあるが，
）グリニッチ標準時（GMT）と呼ばれることも多い。
3.2.9
W3C
3.2.10 XML
ワールドワイドウェブコンソーシアム（World Wide Web Consortium）
拡張可能なマーク付け言語（Extensible Markup Language）
備考 W3C が 1998 年 2 月に（最新の版を）勧告。
3.2.11 XPath
XML パス言語（XML Path Language）
備考 W3C が 1999 年 11 月に勧告。特定の XML 文書中のオブジェクトを参照する方法を規
定する。
3.2.12 XPointer
XML ポインタ言語（XML Pointer Language）
備考 W3C の 2000 年 6 月勧告案（標準化作業中）
。はん用的な XML 文書中のオブジェク
トを参照する方法を規定する。
3.2.13 XSLT
XSL 変換（XSL Transformations）
備考 W3C が 1999 年 11 月に勧告。
3.3
3.3.1
XML 語い(彙)
AdministrativeMetadata 要素
管理メタデータ。
XML コンテンツ管理システムにおいて，
NewsComponent の出所についての情報，及び命名法の指示を提供するメタデータを表す要素。
3.3.2
AllowedValues 属性
特性に対して許される値の範囲を決める統制語い(彙)を示す
Property 要素の属性。
3.3.3
AssignedBy 属性
誰が，又はどのシステムが，メタデータを割り当てた（assigned）の
かを示す属性。
6
X 7201：2005
3.3.4
assignment
属性から成る実体。その属性によって，メタデータを割り当てた（assigned）
人物又はシステム，信頼性の度合い，割当てに与える重要性，文脈（context）での参照トピック
の存在という性質などを判断できる。
3.3.5
AssociatedWith 要素
関連した素材を伴った NewsItem への参照を表す要素。
3.3.6
BasisForChoice 要素 NewsComponent の下位要素。その内容は，NewsComponent 内の各
項目に関連し，項目間の選択基準として使われる値をもつデータオブジェクトを識別する XPath
宣言とする。
3.3.7
ByLine 要素
3.3.8
ByLineTitle 要素
3.3.9
Catalog 要素 Resource 要素及び TopicUse 要素の親要素（container）
。Resource 要素は，
筆者又は作成者の情報を示す要素。
表示可能な筆者又は作成者の肩書の情報を表す要素。
（一つ以上の）URN から（一つ以上の）URL への対応付けをし，木内ですぐ上位の Catalog 要
素から始まる部分木内のある要素の形式名に適用される既定（デフォルト）語い(彙)を示してい
る。
3.3.10 Characteristics 要素
解釈前又は解釈後のデータを処理するために必要な，システム要
件に関係のある ContentItem の物理的な特徴についての情報を提供する要素。これは，ファイル
サイズのバイト数といったもの，利用者が統制語い(彙)を介して定義するもの，先々の版で
NewsML DTD に加えられるかもしれない他の特性を表すものなどとする。
3.3.11 Comment 要素
様々な言語によって，着目している要素を記述したり，その要素につい
て記述する要素。コメントの親要素に含まれる情報を詳しく説明した，人間が理解できる形の付
加情報を提供する。
3.3.12 Confidence 属性 所定の文脈（context）で割り当てられたトピック参照の信頼度を表す
属性。Confidence 属性の値は，統制語い(彙)によって制御されている。
3.3.13 ContentItem 要素
人間に対し表示することを意図した表現内容（例えば，テキスト，
画像，動画，音声など）を伝達するデータオブジェクトを含み，そのデータオブジェクトへのポ
インタを提供するニュースオブジェクトを表す要素。
3.3.14 Context 属性
その値が XPath パターンである TopicUse 要素の属性。現在の Catalog 要素
に当てはまる部分木内にあり，参照トピックが使用された文脈を示す。
3.3.15 Contribution 要素
ニュースオブジェクトの制作又は変更を行うことを目的とする Party
（NewsItem に対し特別な関係がある個人，会社，組織など）の関与内容を表す要素。
3.3.16 Contributor 要素
生成されたニュースオブジェクトに修正又は拡張を行った個人，会社，
組織又はその組合せを示す要素。
3.3.17 Copyright 要素
ニュースオブジェクトの著作権を表す要素。
3.3.18 CopyrightDate 要素
著作権の発生日付の自然言語表現を表す要素。
3.3.19 CopyrightHolder 要素
3.3.20 CopyrightLine 要素
3.3.21 Creator 要素
著作権所有者情報の自然言語表現を表す要素。
著作権情報の自然言語表現を表す要素。
ニュースオブジェクトを作成した個人，会社，組織又はその組合せを表
す要素。
3.3.22 CreditLine 要素
信用情報の自然言語表現を表す要素。
7
X 7201：2005
3.3.23 DataContent 要素 ContentItem の内容を保持するデータを表す要素。
3.3.24 DateAndTime 要素及び DateAndTime 属性
日付及び任意選択の時刻，又はその両方の
形式表現を表す要素及び属性。JIS X 0301 基本形式（YYYYMMDDThhmmss｛+ 又は -｝hhmm）
すなわち，世紀，年，月，日，時間分離子（JIS X 0301 では時刻の指示記号）
，時，分，秒，時
間帯分離子（JIS X 0301 では時間帯の指示記号）
，時，及び分で表現される。システムで自動処
理可能。
備考 DateAndTime 属性は，当該要素を割り当てた日付時刻を表す。DateAndTime 要素の日
付時刻は，当該親要素によって意味が与えられる。
3.3.25 DateId 要素 NewsItem の日付識別子を表す要素。JIS X 0301 の簡略日付フォーマット
（YYYYMMDD）
。DateId は，NewsItem の形式的な識別子であって，同じ NewsItem の一連の版
では同じ値が維持されなければならない。
3.3.26 DateLabel 要素
日付及び／又は時刻の文字列表現を表す要素。人が NewsItem を確認す
るために使用。
3.3.27 DateLine 要素
作成された日付及び場所の自然言語表現を表す要素。
3.3.28 DefaultVocabularyFor 要素 既定語い(彙)を与える親資源を示す要素。既定語い(彙)は，
NewsML 文書の部分木の特定の部分に出現し，意味と許可されたデータ値を決定する。
3.3.29 Delete 要素
現在の NewsItem より前の版の NewsItem の中に指定された要素の削除命令
を表す要素。
3.3.30 DerivedFrom 要素 NewsItem がどこから得られたかを示す要素。
3.3.31 Description 要素 Topic を示す記述を表す要素。それによって，Topic に関連付けられた
形式名の意味を示す。任意選択の Variant 属性によって同じ言語で書かれた複数の記述が可能な
ため，他のものと区別できる。
3.3.32 DescriptiveMetadata 要素
NewsComponent の内容を記述するメタデータ情報を表す要
素。
3.3.33 Details 属性 Topic 要素の属性。URL 又は URN の形式で，Topic に関する追加情報への
ポインタを提供。
3.3.34 Duid 属性 文書内一意識別子（document-unique identifier）を示す属性。この任意選択の
属性によって，要素は，NewsML 文書の中で一意のものとして識別される。
3.3.35 DuidRef 属性 参照要素 の Duid 属性に値が一致する属性。
3.3.36 Encoding 要素及び Encoding 属性
ContentItem の内容を包含するデータの符号化を表す
要素及び属性。
3.3.37 EndDate 要素
使用権が終了する日付を指定する自然言語表現を表す要素。
3.3.38 EquivalentsList 属性 NewsComponent 要素の属性の一つで，その中のニュースオブジェ
クトが，内容及び／又は意味において別のニュースオブジェクトに対して等価（equivalents）か
どうか，又は補完（complements）かどうかを指し示す。
3.3.39 Essential 属性 NewsComponent 要素の属性の一つで，配信社がこの NewsComponent を
重要であるとみなしているかどうかを示す。
8
X 7201：2005
3.3.40 Euid 属性
要素内一意識別子（element-unique identifier）を示す属性。すべての NewsML
要素型の任意選択属性。同じ親要素内の同じ要素型の間で，要素が一意のものとして識別される
ことを可能にする。
3.3.41 FileName 要素 NewsItem の示唆された又は実際の蓄積ファイル名を表す要素。
3.3.42 FirstCreated 要素 NewsItem が最初に作成された日付を表す要素。任意選択としてその
時間を含む。JIS X 0301 基本形式で表現する。
3.3.43 formalname
FormalName 属性，Vocabulary 属性及び Scheme 属性から成る実体。
FormalName 属性は，統制語い(彙)によってその意味が決定される文字列から成る。Vocabulary
属性が存在する場合，それは，FormalName 属性値の意味を解釈するために使用できる統制語い
(彙)TopicSet へのポインタを提供する。Scheme 属性が存在する場合，それは，統制語い(彙)の中
に恐らく多数存在する命名方式のうち，当該 FormalName 属性値を管理しているものを識別する
のに役に立つ。
3.3.44 FormalName 要素及び FormalName 属性 統制語い(彙)の中の命名方式によって意味が
決定される文字列を表す要素及び属性。統制語い(彙)は，
（要求はされないが）NewsML TopicSet
の形式をとる場合もある。
備考 FormalName 要素は，NewsML TopicSet の中で統制語い(彙)を定義する。FormalName
属性は，統制語い(彙)を参照する場合に用いる。
3.3.45 Format 要素 ContentItem のフォーマットを表示する要素。
3.3.46 FutureStatus 要素
指定された将来の日付における NewsItem の状態を表示する要素。
3.3.47 Genre 要素 NewsComponent の表現分類を表示する要素。
3.3.48 Geography 要素
特定の使用権が当てはまることを指定した地域の自然言語表現を表す
要素。
3.3.49 HeadLine 要素
表示できる見出しを表す要素。
3.3.50 HowPresent 属性
3.3.51 Href 属性
メタデータを適用する方法を表現する属性。
情報が NewsML 文書又は外部資源のどこに存在するかを指し示す属性。
3.3.52 Identification 要素 NewsItem の識別に役立つメタデータを表す要素。NewsIdentifier 要
素，あらゆる NameLabel 要素，DateLabel 要素及び任意選択で反復可能な Label 要素を含む。
3.3.53 Importance 属性
メタデータを付与する party が付けた重要性の格付けを表す属性。
3.3.54 InsertAfter 要素 NewsItem の内部で，指定された要素の後に内容を挿入する指示を表す
要素。
3.3.55 InsertBefore 要素 NewsItem の内部で，指定された要素の前に内容を挿入する指示を表
す要素。
3.3.56 Instruction 要素
ニュース配信社から NewsItem 受信社への指示を表す要素。
3.3.57 KeywordLine 要素
ニュースオブジェクトに関係のあるキーワードの表示可能な一群を
表す要素。これは，手動又は自動の検索を助けるために，NewsML システムによって使用でき
る。
3.3.58 Label 要素 NewsItem 用の人が解読可能なラベルを表す要素。
3.3.59 LabelText 要素
特定の LabelType の Label を構成するテキストを表す要素。
9
X 7201：2005
3.3.60 LabelType 要素
Label の利用者定義型を表す要素。FormalName 属性の値は，LabelType
に対しての形式名とする。
3.3.61 Language 要素 ContentItem で使用される言語の識別子を表す要素。
3.3.62 Location 要素 NewsItem の内容に有意な，実際の場所示す識別子を表す要素。
3.3.63 Limitations 要素
特定の使用権に適用される用語及び条件の自然言語表現を表す要素。
3.3.64 MediaType 要素 ContentItem のメディア型を指示する要素。
3.3.65 Metadata 要素
メタデータの利用者定義型のための入れ物を表す要素。
3.3.66 MetadataType 要素
当該 Metadata 要素内の Property 要素によって表されるメタデータ
型を指示する要素。
3.3.67 MimeType 要素 ContentItem の MIME 型を指示する要素。
3.3.68 NameLabel 要素 NewsItem の識別を支援する名前として，人間の使用者が使う記号列を
表す要素。
3.3.69 NewsComponent 要素
ニュースオブジェクトの入れ物を表す要素。相互の関連でニュー
スオブジェクトの役割を識別し，メタデータをそれらに基づくものとするために使用する。
3.3.70 NewsEnvelope 要素
一つ以上の NewsItem を NewsML 文書として送信することに関する
情報を表す要素。
3.3.71 NewsIdentifier 要素 NewsItem のための固有の識別子を表す要素。ProviderId 要素値，
DateId 要素値，NewsItemId 要素値及び RevisionId 要素値という四つの部分から構成される一つ
の識別子と，これら四つの下位要素の構成物すべてを結び付ける PublicIdentifier 要素とから成る。
3.3.72 NewsItem 要素
ニュースの意味ある項目となる NewsItem を表す要素。NewsML 文書内
の XML 要素型。NewsItem は，簡単又は複雑なものであって，何らかの媒体によるもの又は媒
体の組合せによるものであってよい。それが NewsItem と分かるのは，あるできごと及び／又は
事件に関し，特定の時間に，ある視点を表す管理情報を加えることができることによる。このた
めには，最低限，視点を表すための時間と素材の供給元（人又は組織）とを関連付けるのに十分
なメタデータが必要になる。
3.3.73 NewsItemId 要素
特定の NewsItem について配信社が決める固有の識別子を表す要素。
NewsItem の同一性の構成を決定し，これに基づき管理された方法で NewsItemId を割り当てるの
は，配信社の側とする。
3.3.74 NewsItemRef 要素 NewsItemRef 要素を置き換えるための，外部の NewsItem へのポイン
タを表す要素。
3.3.75 NewsItemType 要素 NewsItem の型を指示する要素。
3.3.76 newsline
テキストから成る特殊なニュースメタデータであって，利用者に対し，ニュ
ースメタデータに関連する NewsItem に関する情報の鍵になる項目を提供することを意図する。
NewsLine 自体によって運ばれる情報は，NewsItem 自体によって運ばれる情報の一部又は他のニ
ュースメタデータの幾つかを複写したものであってもよい。NewsLine の例には，HeadLine 要素
及び ByLine 要素がある。
3.3.77 NewsLine 要素
NewsML の規定には含まれない型の newsline を表す要素。
3.3.78 NewsLines 要素 NewsComponent に存在するすべての NewsLine の入れ物を表す要素。
10
X 7201：2005
3.3.79 NewsLineText 要素
利用者定義型の newsline テキストを表す要素。一つの NewsLine に
複数の NewsLineText 要素が存在することがあり，それらは，言語によって区別される。
3.3.80 NewsLineType 要素
利用者定義の NewsLine 型を表示する要素。
3.3.81 NewsManagement 要素 NewsItem の管理に関連した情報を表す要素。
3.3.82 NewsML 要 素
NewsML 文 書 の ル ー ト 要 素 。 一 つ の NewsML 文 書 は ， 一 つ の
NewsEnvelope 要素及び一つ以上の NewsItem 要素を包含しなければならない。一つの Catalog 要
素及び一つ以上の TopicSet 要素を含むこともできる。
3.3.83 NewsProduct 要素 NewsML 文書内ですべての NewsItem が属する製品に対する識別子を
表す要素。
3.3.84 NewsService 要素 NewsML 文書内ですべての NewsItem が属するサービスに対する識別
子を表す要素。
3.3.85 Notation 要素及び Notation 属性 ContentItem の記法（notation）を表示する要素及び属
性。
備考 Notation 要素は，ContentItem の表面的ではなく最終的に扱う内容の記法を表す。
Notation 属性は，符号化を繰り返した場合の個々の符号化記法を表す。
3.3.86 OfInterestTo 要素 NewsItem が対象とする読者又は視聴者を表示する要素。
3.3.87 Origin 要素
テキストのすべて又は一部を指定する要素。自然言語でここに記述されて
いるものに形式的に一致するデータ項目へのポインタを属性として含む。
3.3.88 Party 要素
ニュース作成及び配布のワークフローで，この NewsItem に対し特別な関係
がある個人，会社又は組織を表示する要素。
3.3.89 PreviousRevision 属性
現在の NewsItem より前の版の RevisionId の値を表す属性。
PreviousRevision 属性の値は，NewsItem に前の版が存在する場合，RevisionId 要素の内容と等し
くなければならない。NewsItem に前の版がなければ 0 とする。
3.3.90 Priority 要素 NewsItem の優先表示を指示する要素。
3.3.91 Property 要素 NewsComponent 又は Topic の特性を表す要素。特性には，名前だけでな
く，簡単な値又は後続の特性の集合から成る複雑な値のいずれかがある。Value 属性は，特性の
値の文字列表現を提供するが，ValueRef 属性は，Topic 内又はデータの他の部分に存在する値を
指定する。AllowedValues 属性が存在する場合，それは，特性に与えられた値の限界を規定する
統制語い(彙)を指定する。
3.3.92 Provider 要素
ニュースオブジェクトを配信する個人，企業又は組織を表す要素。
3.3.93 ProviderId 要素
NewsItem を制作したニュース配信社の固有識別子を表す要素。
NewsIdentifier 要素の DateId 下位要素から識別される日に配信社が保持しているドメイン名，又
は統制語い(彙)から引き出される配信社名でなければならない。
3.3.94 PublicIdentifier 要素
（XML1.0 規定で定義された意味での）NewsItem のための公開識
別子を表す要素。
3.3.95 Rank 属性 NewsComponent の中の BasisForChoice 要素間の優先順位を示す整数を示す
属性。Rank 属性の値が小さい BasisForChoice 要素が，大きい値のものよりも優先される。
3.3.96 Relevance 要素
特定の受信者への NewsItem の関連性を表示する要素。
11
X 7201：2005
3.3.97 Repeat 属性 TransmissionId 要素の属性の一つで，前の伝送と繰返しとを区別する。
3.3.98 Replace 要素 NewsItem 内の指定された要素を置き換える指示を表す要素。
3.3.99 Resource 要素
資源が提供される場所を示し，その資源が，NewsML 文書で現在の部分
木内にある形式名（formal name）の既定語い(彙)として使用されているかどうかを示す要素。
3.3.100 RevisionHistory 要素 NewsItem の改訂履歴が入っているファイルへのポインタを表す
要素。
3.3.101 RevisionId 要素
該当する NewsItem の版数を正整数で示す要素。同じ ProviderId，DateId
及び NewsItemId をもつ二つのデータオブジェクトが同じ内容であることを保証するのは，配信
社の責任とする。わずかな変更であっても，NewsItem を変更して再発行する場合，新しい版に
は，必ずより大きい整数の RevisionId を割り当てなければならない。
3.3.102 RevisionStatus 要素
現在の版にいたる前の版についての状態を示す要素。任意選択の
Revision 属性は，整数であって，該当の版の RevisionId と同じでなければならない。版数が存在
しない場合には，すべての前の版を状態に当てはめる。
3.3.103 RightsHolder 要素 使用権（usage rights）を誰がもっているのかを示す文字列を表す要
素。任意選択として，関係する人，会社又は組織についての更なる情報を，ポインタによって追
加できる。
3.3.104 RightsLine 要素
権利（rights）情報を記述する要素。著作権（copyright）情報の記述と
は異なる。著作権情報は，ニュースオブジェクト所有者について記述するが，権利情報は，使用
許可を与えられた者，その使用方法及び使用環境について示す。
3.3.105RightsMetadata 要素 NewsComponent に関係する権利についてのメタデータを表す要素。
3.3.106 Role 要素 NewsComponent 内で，中の NewsComponent が果たす役割の識別子を表す要
素。
3.3.107 Scheme 属性
統制語い(彙)中に数多く存在可能な命名方式のうち，どれが正当に
FormalName を管理するものかを区別するために使われる属性。
3.3.108 SentFrom 要素 NewsML 文書を送信する個人，企業又は組織を表す要素。
3.3.109 SentTo 要素 NewsML 文書を受信する個人，企業又は組織を表す要素。
3.3.110 SeriesLine 要素
続き物におけるニュースオブジェクトの位置付けに関する情報につい
て，表示用の記述を示す要素。
3.3.111 SizeInBytes 要素 ContentItem の行内データ，又は外部参照データの正確なバイト数を表
す要素。
3.3.112 SlugLine 要素
NewsComponent のスラッグライン（slug line）を表示するために使われ
る文字列を表す要素。ハイパリンクが張られていること，書式設定が施されていることなどの可
能性もある。
（
“スラッグライン” という用語の意味及び使用法については，個々の配信社が，
それぞれのワークフロー及び商慣行の範囲内で定義する問題とする。
）
3.3.113 Source 要素
ニュースオブジェクトの素材を供給した個人，企業，組織又はその組合せ
を表す要素。
3.3.114 StartDate 要素
指定された使用権の効力が発生する日付の自然言語記述を表す要素。
3.3.115 Status 要素 NewsItem の状態を表す要素。
12
X 7201：2005
3.3.116 StatusWillChange 要素
指定された日時に自動実行される状態変更の通知をあらかじめ
記述する要素。
3.3.117 SubHeadLine 要素
表示用の補足見出しを表す要素。
3.3.118 SubjectCode 要 素
IPTCSubjectCode の コ ン テ ナ で あ っ て ， IPTC 情 報 交 換 モ デ ル
（Information Interchange Model，以下 IIM）で定義される NewsItem のテーマの分類を示す要素。
一つ以上の Subject，SubjectMatter，SubjectDetail 又は SubjectQualifier といった下位要素で構成さ
れる。任意選択で一つ以上の SubjectQualifier 要素によって拡充される。
3.3.119 Subject 要素 NewsItem の Subject を示す要素。
3.3.120 SubjectMatter 要素 NewsItem の SubjectMatter を示す要素。
3.3.121 SubjectDetail 要素 NewsItem の SubjectDetail を示す要素。
3.3.122 SubjectQualifier 要素 NewsItem の SubjectQualifier を示す要素。
3.3.123 SystemIdentifier 要素 NewsItem の（XML1.0 規定で定義された意味での）システム識別
子を表す要素。
3.3.124 ThisRevisionCreated 要素 NewsItem の最新版が作成された日付を表す要素。任意選択で
時間が入る。JIS X 0301 の基本形式で表現される。
3.3.125 Topic 要素及び Topic 属性
NewsComponent において，正式に命名された事象（topic）
又はできごとに関する情報を提供する要素及び属性。Topic 要素は，一つ以上の TopicType 下位
要素をもたなければならない。その TopicType 下位要素は，Topic の型を表す。
備考 Topic 属性は，定義された Topic を参照する場合に用いる。
3.3.126 TopicOccurrence 要素 NewsComponent の内容であって，ある Topic が発生することを表
示する要素。
3.3.127 TopicSet 要素及び TopicSet 属性
一つ以上の Topic の収納場所を表す要素及び属性。
備考 TopicSet 要素は，定義する場合に用いる。TopicSet 属性は，参照する場合に用いる。
3.3.128 TopicSetRef 要素
最新のものと併合されることが望ましい TopicSet のポインタを表す要
素。
3.3.129 TopicType 要素 Topic の型を表示する要素。
3.3.130 TopicUse 要素
特定の Topic が NewsML 文書のどこに使われているかを示す要素。
3.3.131 TransmissionId 要素 NewsML 文書伝送のための一意識別子を表す要素。
3.3.132 Update 要素及び Update 属性
既存の NewsItem の修正を表す要素及び属性。挿入，置
換，削除など。
3.3.133 Urgency 要素
NewsItem の緊急性の識別子を表す要素。
3.3.134 Url 要素 Resource の位置特定に使うことができる識別子を表す要素。
3.3.135 Urn 要素
資源に対する大域的な識別子を表す要素。PublicIdentifier での記述と同様に，
これは，一般的に（ただし必ずしもというわけではないが）NewsML の URN となる。
3.3.136 UsageRights 要素 NewsComponent に属する使用権に関する情報を付与する要素。その
UsageType，Geography，RightsHolder，Limitations，StartDate 及び EndDate という下位要素は，自
然言語で書かれたメタデータを追加する。
3.3.137 UsageType 要素
自然言語によって権利が適用される利用の型を示す要素。
13
X 7201：2005
3.3.138 Value 属性 Property 要素の属性。Property の値の文字列表現を表す属性。
3.3.139 ValueRef 属性 Property の値へのポインタを表す属性。TopicSet 中の Topic 又はデータの
他の部分。
3.3.140 Variant 属性 Description 要素の任意選択の属性。同一言語で異なった表現をし，それら
を区別する場合に使用する。
3.3.141 Version 属性 NewsML の任意選択の属性で，文章を識別する DTD 又はスキーマの版を
与える。
3.3.142 Vocabulary 属性 FormalName の意味を解釈するために使用可能な統制語い(彙)である，
現在の文書中の TopicSet を識別する属性。
4.
この規格の状態
原規定の“1 Status of this document”として示される内容を，次に参考と
して示す。
この規格は，NewsML1.2 版の文書型定義（DTD）を自然言語で規定し，補足する。
この規格の修正は，NewsML1.2 版 DTD の注釈よりも優先する。
NewsML の要件（Requirements）文書は，NewsML が与える必要がある機能について示す。こ
の規格は，これらの要件を満たすために採用されてきた技術的手段について示す。要件は，次の
とおりに要約される。括弧の中の R で始まる番号は，NewsML 要件文書の対応する項目の参照
番号とする。要件文書は，www.iptc.org で入手できる。
NewsML は，小形（R900）
，拡張可能及び柔軟な（R700）
，ニュースの構造的枠組みであって，
XML 及び他の適切な規格並びに規定に基づく（R1000）
。NewsML は，電子的なニュース項目，
ニュース項目の集合，ニュース項目間の関係，及びそれらに付随するメタデータの表現を支援し
なければならない（R100）
。同じ情報が様々な表現で供給されることを見越す（R500）必要があ
り，任意のメディア型，フォーマット，言語及び符号化の混在を扱えなければならない（R300，
R400）
。NewsML は，ニュースのライフサイクルのあらゆる段階を支援しなければならず（R600）
，
そのライフサイクルに渡ってニュース項目の修正変更を可能としなければならない（R200）。
NewsML は，メディアに対して独立だが，テキストを扱う特別の機構を提供する（R1100）。
NewsML は，メタデータ及びニュース内容の両方に対する認証及び署名を提供する（R800）
。
14
[附属資料－Ａ．３．１]
XSL Extensions（XSL 拡張要求）
XSL Extensions (Proposal)
Apr 24, 2003
Rev May 14, 2004
Rev Dec 14, 2004
The namespace of XSL Extensions by Antenna House has the URI
http://www.antennahouse.com/names/XSL/Extensions.
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"
xmlns:axf="http://www.antennahouse.com/names/XSL/Extensions">
These extensions are based on XSL 1.0. XSL 1.1 may become different specification from Antenna House
Extensions.
z
z
Extended Elements
1. Document Information
„ axf:document-info
„ axf:outline-group-position
„ axf:output-volume-info
2. Ruby
„ axf:ruby
„ axf:ruby-base
„ axf:ruby-text
„ axf:ruby-base-container
„ axf:ruby-text-container
Extended Properties
1. Bookmark
„ axf:outline-color
„ axf:outline-expand
„ axf:outline-font-style
„ axf:outline-font-weight
„ axf:outline-group
„ axf:outline-level
„ axf:outline-title
2. Link
„ axf:action-type
„ axf:destination-type
„ axf:outline-external-destination
„ axf:outline-internal-destination
3. Multi Separate Volume
„ axf:bookmark-include
„ axf:initial-volume-number
„ axf:output-volume-break
„ axf:output-volume-filename
4. Footnote
„ axf:footnote-align
„ axf:footnote-position
„ axf:suppress-duplicate-footnote
5. Revision Bar
„ axf:revision-bar-color
„ axf:revision-bar-offset
„ axf:revision-bar-position
„ axf:revision-bar-style
„ axf:revision-bar-width
1
6. Column Rule
„ axf:column-rule-align
„ axf:column-rule-color
„ axf:column-rule-length
„ axf:column-rule-style
„ axf:column-rule-width
7. Diagonal Border
„ axf:diagonal-border-color
„ axf:diagonal-border-style
„ axf:diagonal-border-width
„ axf:reverse-diagonal-border-color
„ axf:reverse-diagonal-border-style
„ axf:reverse-diagonal-border-width
8. Border
„ axf:border-radius
„ axf:border-top-left-radius
„ axf:border-top-right-radius
„ axf:border-bottom-left-radius
„ axf:border-bottom-right-radius
„ axf:box-shadow
9. Page Background
„ axf:background-color
„ axf:background-image
10. Page Number
„ axf:assumed-page-number
„ axf:assumed-page-number-prefix
„ axf:origin-id
„ axf:page-number-prefix
„ axf:physical-page-number
„ axf:suppress-duplicate-page-number
11. Text Processing
„ axf:append-non-starter-characters
„ axf:append-non-end-of-line-characters
„ axf:except-non-starter-characters
„ axf:except-non-end-of-line-characters
„ axf:font-emphasize-position
„ axf:font-emphasize-style
„ axf:hanging-punctuation
„ axf:kerning-mode
„ axf:line-break
„ axf:line-break-at-punctuation-in-word
„ axf:overflow-condense
„ axf:overflow-replace
„ axf:punctuation-spacing
„ axf:punctuation-trim
„ axf:text-autospace
„ axf:text-autospace-width
„ axf:text-kashida-space
„ axf:vertical-underline-side
12. Ruby / Text Combine
„ axf:ruby-align
„ axf:ruby-overhang
„ axf:ruby-position
„ axf:ruby-span
„ axf:text-combine
13. List
„ axf:list-style-position
2
z
z
14. Miscellaneous
„ axf:base-uri
„ axf:soft-hyphen-treatment
„ axf:justify-nbsp
Extended Values
{ clear
{ float
{ font-stretch
{ internal-destination
{ overflow
Index
{ Element Index
{ Property Index
{ Value Index
CAUTION: [-] sign means not implemented yet. Other extensions are already implemented on XSL Formatter
V3.2.
Extended Elements
1. Document Information
axf:document-info
Common Usage:
Specifies the document information. The information is not included in the generated areas. For
example, this information is embedded into PDF.
Areas:
None.
Constraints:
The axf:document-info extension property can be placed in any position right under the fo:root and
before fo:page-sequence. Its properties are "name" and "value", which are required. The value of
'name' must be one of the following: "title", "subject", "author" or "keywords".
<!ELEMENT axf:document-info EMPTY>
<!ATTLIST axf:document-info
name
CDATA #REQUIRED
value CDATA #REQUIRED
>
Contents:
EMPTY
Examples:
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"
xmlns:axf="http://www.antennahouse.com/names/XSL/Extensions">
<axf:document-info name="title" value="The document title"/>
3
<axf:document-info name="subject" value="The document subject"/>
<axf:document-info name="author" value="The author"/>
<axf:document-info name="keywords" value="Comma separated keywords list"/>
...
axf:document-info as a child of fo:page-sequence is effective only for PDF output in multi separate
volume. axf:document-info as a child of fo:page-sequence overwrites axf:document-info as a child of
fo:root and is utilized for an information of the document when outputting in separate volume. Therefore
the same document information is embedded in all the separate volumes unless axf:document-info is
specified to fo:page-sequence.
axf:outline-group-position [-]
Common Usage:
Controls the order of the BookMark output. This element does not generate areas.
Areas:
None.
Constraints:
The axf:outline-group-position element is a child of fo:root. If it becomes before fo:page-sequence
appears, it is possible to put it on an arbitrary position under a child of fo:root. The group name is
specified by "outline-group". An empty string indicates the bookmark which is not grouped. "outlinetitle" specifies the strings of the actual display. If the content is specified to "outline-title", it is
adapted. If neither of them are specified, the group name is displayed. "outline-expand" specifies
whether to display the lower hierarchy of bookmark in default. True specifies to display the lower
hierarchy in the expanded state. False specifies to display in the collapsed state.
The bookmark is generated in the appearing order of the elements. When an unspecified group
name appears, it is outputted after these elements.
<!ELEMENT axf:outline-group-position #PCDATA>
<!ATTLIST axf:outline-group-position
outline-expand (true|false) "true"
outline-title CDATA
""
outline-group CDATA
#REQUIRED
>
Contents:
#PCDATA
axf:output-volume-info
Common Usage:
Makes it possible to output PDF in separate volume per fo:page-sequence when outptting the
formatted result.
Areas:
None.
Constraints:
4
The axf:output-volume-info is placed as a child of fo:root. If it comes before fo:page-sequence
appears, it is possible to put it in an arbitrary position under a child of fo:root.
<!ELEMENT axf:output-volume-info EMPTY>
<!ATTLIST axf:output-volume-info
initial-volume-number NUMBER "1"
format
CDATA "1"
bookmark-include (first|all|separate) separate
>
Contents:
EMPTY
Examples:
<axf:output-volume-info
initial-volume-number="2"
format="-1"
bookmark-include="separate"
/>
<fo:page-sequence>
PAGE-SEQUENCE-1
...
</fo:page-sequence>
<fo:page-sequence>
PAGE-SEQUENCE-2
...
</fo:page-sequence>
<fo:page-sequence axf:output-volume-break="true">
PAGE-SEQUENCE-3
...
</fo:page-sequence>
Effective only when outputting to files. It’s not available for printing or stream output. At that time the file
name should be given. The file names of separate volumes are given automatically based on the output
file names. This process is done by inputting the strings formatted by the format property right before the
file extension of the output file name. In the above example, when document.pdf is given to the file name,
PAGE-SEQUENCE-1 and PAGE-SEQUENCE-2 are outputted to document-2.pdf, PAGE-SEQUENCE-3
is outputted to document-3.pdf.
The numeric value applied to the format property can be given by the axf:initial-volume-number property
as the initial value. The format property is the same as "7.24.1. format" in the XSL-FO specification.
The volume is separated by the axf:output-volume-break property specified to fo:page-sequence. If the
axf:output-volume-filename property is specified, only the separated volumes can be outputted with the
specified file name.
The book mark of PDF in multi separate volume can be set by the axf:bookmark-include from the
following options.
z
z
z
Adds a bookmark to the first separate volume only.
Adds bookmarks to all the separate volumes.
Adds each bookmark to each separate volume.
2. Ruby
The Ruby is based on CSS3 Ruby Module.
5
axf:ruby [-]
axf:ruby-base [-]
axf:ruby-text [-]
axf:ruby-base-container [-]
axf:ruby-text-container [-]
CAUTION: Not documented yet.
Extended Properties
1. Bookmark
This is additional information, and it has the meaning in an electronic environment. It is not output to
printed matter usually.
axf:outline-color
The axf:outline-color specifies the color which appears as a title of bookmarks.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<color>
the value of the 'color' property
block-level formatting objects
no
N/A
6
axf:outline-expand
The axf:outline-expand specifies whether to display the lower hierarchy of bookmark items or not.
Value:
Initial:
Applies to:
Inherited:
Percentages:
true | false
true
block-level formatting objects
no
N/A
True specifies to display the lower hierarchy in the expanded state. False specifies to display in the
collapsed state.
axf:outline-font-style
The axf:outline-font-style specifies the font style which appears as a title of bookmarks.
Value:
Initial:
Applies to:
Inherited:
Percentages:
normal | italic
normal
block-level formatting objects
no
N/A
Values have the following meanings.
normal
Specifies normal style.
italic
Specifies italic.
axf:outline-font-weight
The axf:outline-font-weight specifies the font weight which appears as a title of bookmarks.
Value:
Initial:
Applies to:
Inherited:
Percentages:
normal | bold
normal
block-level formatting objects
no
N/A
Values have the following meanings.
normal
Specifies normal weight.
bold
7
Specifies bold weight.
axf:outline-group
The axf:outline-group groups bookmark items, and outputs them collectively.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<string>
empty string
block-level formatting objects
no
N/A
If this property is omitted or specifies empty string, bookmark items are not grouped. If this specifies any
string, the string is used as the name of group. The group with the same name is outputted collectively.
The non-grouped bookmark is outputted as the group without the group name.
axf:outline-level
The axf:outline-level indicates the hierarchy level of bookmark items.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<number>
0
block-level formatting objects
no
N/A
The <number> must be a non-negative integer. Initial value is zero and it means that bookmarks should
not be created. The highest level of bookmarks is 1 and it becomes 2 or more according to the hierarchy
level of the bookmarks.
axf:outline-title
The axf:outline-title specifies the string which appears as a title of bookmarks.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<string>
empty string
block-level formatting objects
no
N/A
If this property is omitted or has an empty string, the text of the object to which the property is added will
become the title. In other words, the following two samples create the same bookmark.
<fo:block axf:outline-level="2" axf:outline-title="1. Introduction">...
<fo:block axf:outline-level="2">1. Introduction</fo:block>
2. Link
This aims at the application to PDF. PDF links can be created easily by using fo:basic-link .
8
PDF links are classified either as an internal link to a specified position in the PDF document, or as a
external link to an external document. The internal-destination property of fo:basic-link indicates a link to a
position in the same document. The external-destination property indicates a link to an external document.
Below are the examples of both.
z
Internal Link
<fo:block>
Answer may be found in <fo:basic-link internal-destination="appendixa">Appendix-A</fo:basic-link>.
</fo:block>
...
<fo:block id="appendix-a">
Appendix-A
</fo:block>
z
External Link
<fo:block>
Here is <fo:basic-link external-destination="http://www.w3.org/">W3C
Home Page</fo:basic-link>.
</fo:block>
The external link specified by the relative address is transformed into either 'Open the file' or 'World Wide
Web link'. The external link specified by the absolute address is always transformed into 'World Wide Web
link'.
Furthermore, it's possible to specify professional links as follows. For further understanding see also PDF
Reference Manual by Adobe Systems Incorporated. The professional links are not available with
XSL Formatter V3.2 Lite.
z
z
z
z
z
z
z
Specifies the following actions for the external link explicitly.
{ Moves the destination inside PDF (GoToR)
{ Opens the file (Launch)
{ World Wide Web link (URI)
Possible to specify ID for the external link in PDF as well as the internal link.
Possible to specify the page number for the expternal link in PDF.
Possible to specify the page number for the internal link.
Possible to specify the type of destination for the external link.
Possible to specify the external link in the bookmark.
Possible to specify the internal link in the bookmark.
The setting of external-destination for the external link in PDF conforms to the following specification of
PDF parameters. Not all the parameters are effective. The invalid parameters are ignored.
z
PDF Open Parameters
This specification provides the following examples.
z
z
z
z
z
z
z
z
http://mydocs/doc.pdf#nameddest=Chapter6
http://mydocs/doc.pdf#page=3
http://mydocs/doc.pdf#page=3&zoom=200,250,100
http://mydocs/doc.pdf#zoom=50
http://mydocs/doc.pdf#page=72&view=fitH,100
http://mydocs/doc.pdf#view=fitb&nameddest=Chapter3
http://mydocs/doc.pdf#pagemode=none
http://mydocs/doc.pdf#pagemode=bookmarks&page=2
9
z
http://mydocs/doc.pdf#page=3&pagemode=thumbs
Only the following parameters are effective. The case sensitivity is ignored.
z
z
z
z
z
nameddest
page
zoom
view
viewrect
For example, it's invalid to specify fitH, fitR and fitBH for the external link. These are effective only with the
internal link. If the required values for the PDF parameters are omitted in fitH, etc., the values are
accounted as 0.
axf:action-type
Specifies the action of external link.
Value:
Initial:
Applies to:
Inherited:
Percentages:
gotor | launch | uri | auto
auto
fo:basic-link, block level formatting object
no
N/A
Values have the following meanings.
gotor
Opens the link destination by the "GoToR" action as PDF. The URI of the destination is regarded as
PDF.
launch
Opens the link destination by the "Launch" action as the file.
uri
Opens the link destination by the "URI" action as URI (World Wide Web).
auto
Dependent on the system setting.
When the link destination is not a local file, such as http:, the action type is "URI" at any time.
axf:destination-type
Specifies the type of destination for the external link. These are the types of destination for PDF as the
external link.
Value:
Initial:
Applies to:
Inherited:
<string>
empty string
block level formatting object
no
10
Percentages:
N/A
The destination type has the following options. If nothing specified, it's accounted as axf:destinationtype="xyz-top". The case sensitivity is ignored.
Destination Type
of PDF
[page /XYZ left top
zoom]
[page /Fit]
How to specify axf:destination-type
The value of left/top is calculated automatically. However it's possible to specify
null or non-null explicitly. The user can specify the arbitrary value for zoom.
axf:destination-type="xyz"
Specifies left and top as null.
Specifies top as null.
axf:destination-type="xyz-left"
axf:destination-type="xyz-top"
Specifies left as null.
axf:destination-type="xyz-left-top"
If nothing is specified t zoom, it's accounted as null. Specifies % value to zoom as
follows.
axf:destination-type="xyz-top 75"
If only the numbers are specified, the value is accounted for xyz-top.
axf:destination-type="75"
axf:destination-type="fit"
[page /FitH top]
The value of top is calculated automatically. Effective only to specify in the
internal link.
axf:destination-type="fith"
[page /FitV left]
The value of left is calculated automatically.
axf:destination-type="fitv"
[page /FitR left
bottom right top]
The value of left/bottom/right/top is calculated automatically. Effective only to
specify in the internal link.
axf:destination-type="fitr"
[page /FitB]
axf:destination-type="fitb"
[page /FitBH top]
The value of top is calculated automatically. Effective only to specify in the
internal link.
axf:destination-type="fitbh"
[page /FitBV left]
The value of left is calculated automatically.
axf:destination-type="fitbv"
axf:outline-external-destination
Sets the external link in the PDF bookmark.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<uri-specification>
empty string
block-level formatting objects
no
N/A
Values have the following meanings.
<uri-specification>
11
Specifies the URI of the link destination.
axf:outline-internal-destination
Sets the internal link in the PDF bookmark.
Value:
Initial:
Applies to:
Inherited:
Percentages:
empty string | <idref> | <number-with-fragment>
empty string
block-level formatting objects
no
N/A
Values have the following meanings.
<idref>
Specifies the ID of the link destination.
<number-with-fragment>
Specifies the page number of the link destination. This string is simpe numeric characters or the
following string that combines numeric characters and fragment with #.
123#string
3. Multi Separate Volume
This aims at the application to PDF.
axf:bookmark-include
Specifies how to include bookmarks in multi separate volume.
Value:
Initial:
Applies to:
Inherited:
Percentages:
first | all | separate
separate
axf:output-volume-info
no
N/A
Values have the following meanings.
first
Adds a bookmark to the first separate volume.
all
Adds bookmarks to all the separate volumes.
separate
12
Adds each bookmark to each separate volume. Bookmarks are added to the volume where
axf:outline-level="1" appears. The bookmark that goes across the volume is added to the previous
volume. For that reason, the external link to the other volume may be included even though
axf:bookmark-include="separate" is specified.
axf:initial-volume-number
Specifies the initial volume number in multi separate volume.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<number>
1
axf:output-volume-info
no
N/A
This value is applied for the format property and utilized for the file name to output.
axf:output-volume-break
Separates the file in multi volume.
Value:
Initial:
Applies to:
Inherited:
Percentages:
true | false
false
fo:page-sequence
no
N/A
Values have the following meanings.
true
Separates the volume newly from this fo:page-sequence.
false
Do not separates the volume newly from this fo:page-sequence.
Specifies axf:output-volume-break="true" to fo:page-sequence where you want to start
separating the volume. The document number increases one by one. When separating the volume,
axf:output-volume-break="true" is regarded as always being specified to the first fo:pagesequence. If axf:output-volume-break="false" is specified explicitly, it is ignored.
axf:output-volume-filename
Specifies the document file name in multi separate volume.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<string>
empty string
fo:page-sequence
no
N/A
13
If nothing specified, the automatic file name using the format property is adopted. If this property is
specified, the specified name is adopted. This property is effective only with the top fo:page-sequence or
with the fo:page-sequence where axf:output-volume-break="true" is specified.
4. Footnote
axf:footnote-align [-]
The axf:footnote-align specifies the method to layout the footnote.
Value:
Initial:
Applies to:
Inherited:
Percentages:
auto | before | after | inline
auto
fo:region-body, fo:footnote
no
N/A
Values have the following meanings.
auto
Footnotes are placed automatically. Footnotes are the usual arrangement. When the text is one
column, side notes are arranged with an anchor position, and in the case of two or more columns,
side notes are arranged near by the before side.
before
Side notes are arranged near by the before side. In the case of usual foot notes which are not side
notes, foot notes are arranged immediately after the text in a page.
after [-]
Side notes are arranged near by the after side. In the case of usual foot notes which are not side
notes, foot notes are arranged at the last of a page.
inline [-]
Side notes are arranged in order in the inline direction. Two or more items can be arranged in one
line. When specified as side notes, it is the same as auto.
Specifies the method of arrangement of footnotes or side notes. When it is side notes (footnote
arrangement into region-start or region-end is specified by axf:footnote-position), it's possible to specify
whether it is arranged automatically, or it is arranged near by the before side, or it is arranged near by the
after side. If inline is specified to the footnote, the footnote is put in order in the inline direction.
axf:footnote-position
The axf:footnote-position specifies the location to layout the footnote.
Value:
Initial:
Applies to:
Inherited:
page | odd-page | start | end | inside | outside | column | inside-column | outsidecolumn | page-sequence | document
page
fo:region-body, fo:footnote
no
14
Percentages:
N/A
Values have the following meanings.
page
Footnotes are placed at the bottom of each page in region-body. This is the standard layout of XSL
1.0 specification.
odd-page [-]
Footnotes are placed at the bottom of each odd-page in region-body.
start [-]
Footnotes are placed at each page in region-start.
end [-]
Footnotes are placed at each page in region-end.
inside [-]
Footnotes are placed at each even-page in region-end and each odd-page in region-start.
outside [-]
Footnotes are placed at each even-page in region-start and each odd-page in region-end.
column
Footnotes are placed at the bottom of each column.
inside-column [-]
Footnotes are placed at the bottom of the last column of even-page or the first column of odd-page.
outside-column [-]
Footnotes are placed at the bottom of the first column of even-page or the last column of odd-page.
page-sequence [-]
Footnotes are placed at the end of page-sequence.
document [-]
Footnotes are placed at the end of the document.
It is possible to arrange footnotes inside the region-start or the region-end (these notes are called side
notes). Besides specifying them to fo:region-body, it is also effective to specify to individual fo:footnote. It
is possible to make several types of notes intermingled by this extension.
axf:suppress-duplicate-footnote [-]
15
Specifies whether to omit the same footnote.
Value:
Initial:
Applies to:
Inherited:
Percentages:
true | false | inherit
false
fo:footnote
yes
N/A
Suppresses the duplicated footnotes in the same footnote area, when the same footnote is allocated in
two or more places.
5. Revision Bar
The revision bar is shown upper than the border or the column rule.
axf:revision-bar-color
The axf:revision-bar-color specifies the color of the revision bar.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<color> | inherit
the value of the 'color' property
all block-level and inline-level formatting objects which are descendants of fo:flow
yes
N/A
axf:revision-bar-offset
The axf:revision-bar-offset specifies the offset of the revision bar.
Value:
Initial:
<space> | inherit
0
16
Applies to:
Inherited:
Percentages:
all block-level and inline-level formatting objects which are descendants of fo:flow
yes
N/A
axf:revision-bar-position
The axf:revision-bar-position specifies the position of the revision bar.
Value:
Initial:
Applies to:
Inherited:
Percentages:
start | end | inside | outside | alternate | both | inherit
start
all block-level and inline-level formatting objects which are descendants of fo:flow
yes
N/A
Values have the following meanings.
start
Places revision bar at start-edge.
end
Places revision bar at end-edge.
inside
Places revision bar at start-edge on odd pages, at end-edge on even pages.
outside
Places revision bar at end-edge on odd pages, at start-edge on even pages.
alternate
Places revision bar at end-edge in the last column of multi-column layout, except for the last
column, places it at start-edge.
both
Places revision bar at start-edge and end-edge.
axf:revision-bar-style
The axf:revision-bar-style specifies the style of the revision bar.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<border-style> | inherit
none
all block-level and inline-level formatting objects which are descendants of fo:flow
yes
N/A
axf:revision-bar-width
17
The axf:revision-bar-width specifies the width of the revision bar.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<border-width> | inherit
medium
all block-level and inline-level formatting objects which are descendants of fo:flow
yes
N/A
6. Column Rule
This property is based on CSS3 Multi-column layout. The column rule is shown upper than the border,
lower than the revision bar.
axf:column-rule-align
The axf:column-rule-align specifies the alignment of the column rule.
Value:
Initial:
Applies to:
Inherited:
Percentages:
top | middle | bottom | inherit
middle
fo:region-body
yes
N/A
These are not present in CSS3 Multi-column layout.
axf:column-rule-color
The axf:column-rule-color specifies the color of the column rule.
Value:
Initial:
<color> | inherit
the value of the 'color' property
18
Applies to:
Inherited:
Percentages:
fo:region-body
no
N/A
See CSS3 Multi-column layout.
axf:column-rule-length
The axf:column-rule-length specifies the length of the column rule.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<length> | inherit
100%
fo:region-body
no
refer to the size of the column
These are not in CSS3 Multi-column layout.
axf:column-rule-style
The axf:column-rule-style specifies the style of the column rule.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<border-style> | inherit
none
fo:region-body
no
N/A
See CSS3 Multi-column layout.
axf:column-rule-width
The axf:column-rule-width specifies the width of the column rule.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<border-width> | inherit
medium
fo:region-body
no
N/A
See CSS3 Multi-column layout.
7. Diagonal Border
These properties draw the diagonal border in the area such as the table cell where the border can be
specified. The diagonal border by axf:diagonal-border-* is drawn from the edge of before-start to the edge
of after-end. The diagonal border by axf:reverse-diagonal-border-* is drawn from the edge of before-end to
the edge of after-start. When the writing-mode="lr-tb" is specified, the diagonal border is drawn as follows.
When the writing-mode="rl-tb" or "tb-rl" is specified, it is drawn in a reverse way.
19
axf:diagonal-border-color
The axf:diagonal-border-color specifies the color of the diagonal border.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<color> | inherit
the value of the 'color' property
all FOs which can have borders
yes
N/A
axf:diagonal-border-style
The axf:diagonal-border-style specifies the style of the diagonal border.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<border-style> | inherit
none
all FOs which can have borders
no
N/A
axf:diagonal-border-width
The axf:diagonal-border-width specifies the width of the diagonal border.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<border-width> | inherit
medium
all FOs which can have borders
yes
N/A
axf:reverse-diagonal-border-color
20
The axf:reverse-diagonal-border-color specifies the color of the reverse diagonal border.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<color> | inherit
the value of the 'color' property
all FOs which can have borders
yes
N/A
axf:reverse-diagonal-border-style
The axf:reverse-diagonal-border-style specifies the style of the reverse diagonal border.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<border-style> | inherit
none
all FOs which can have borders
no
N/A
axf:reverse-diagonal-border-width
The axf:reverse-diagonal-border-width specifies the width of the reverse diagonal border.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<border-width> | inherit
medium
all FOs which can have borders
yes
N/A
8. Border
axf:border-radius [-]
axf:border-top-left-radius [-]
axf:border-top-right-radius [-]
axf:border-bottom-left-radius [-]
axf:border-bottom-right-radius [-]
The radii of quater ellipse are specified. This property is based on CSS3 Border : 3.3 The 'border-radius'
properties.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<length> <length>?
0
all FOs which can have borders
no
N/A
The first value is the horizontal radius (or vertical if the 'writing-mode' is vertical). If the second length is
omitted it is equal to the first. If either length is less or equal zero, the corner is square, not rounded.
See CSS3 Border.
21
axf:box-shadow [-]
The box shadow is specified. This property is based on CSS3 Border : 3.6 The 'box-shadow' property.
Value:
Initial:
Applies to:
Inherited:
Percentages:
none | [ <length> <length> <length>? || <color> ] [ , <length> <length> <length>? ||
<color> ]+
none
all FOs which can have borders
no
N/A
See CSS3 Border.
9. Page Background
axf:background-color
The axf:background-color sets the background color of fo:simple-page-master.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<color> | transparent
transparent
fo:simple-page-master
no
N/A
axf:background-image
The axf:background-image sets the background image of fo:simple-page-master.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<uri-specification> | none
none
fo:simple-page-master
no
N/A
10. Page Number
axf:assumed-page-number
Specifies the assumed page number.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<number>
N/A
all formatting objects
yes
N/A
When <fo:page-number-citation> appears, the reference area is sometimes undecided. In evaluation of
<fo:page-number-citation>, the temporary area is secured first, and when a page number is decided, it is
22
adjusted to the right contents. Since the size of an area may change at this time, the formatted result is
sometimes not desirable. For example, when an area becomes narrow, it seems that there is an
unnecessary line break, and condition that a character will overflow if an area becomes large appears.
axf:assumed-page-number gives the assumed page number at that time.
axf:assumed-page-number-prefix
Specifies the assumed page number prefix.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<string>
N/A
all formatting objects
yes
N/A
When <fo:page-number-citation> appears, the reference area is sometimes undecided. It is unknown at
this time whether the reference area is inside of the same <fo:page-sequence>. When the reference area
is in the different <fo:page-sequence>, the values of axf:page-number-prefix may differ. Then the
temporary area is secured first, and when a reference place appears, it is adjusted to the right contents. If
axf:page-number-prefix is specified to the current <fo:page-sequence>, it will be assumed as a temporary
area. Otherwise, a suitable short character string will be assumed. Since the size of an area may change
at this time, the formatted result is sometimes not desirable. For example, when an area becomes
narrow, it seems that there is an unnecessary line break, and condition that a character will overflow if an
area becomes large appears. axf:assumed-page-number gives the assumed page number prefix at that
time.
Even when axf:page-number-prefix is empty, it's not known whether it is empty at the time of the
temporary formatting. Then a certain amount of the area will be secured. In order to deter this, please
specify axf:assumed-page-number-prefix="" to an suitable element. Since an area is not secured at this
time, the setting of axf:page-number-prefix is ignored.
axf:origin-id
Specifies the origin of the page number.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<idref>
none
fo:page-number-citation
no
N/A
ID for the origin of the page number can be specified in fo:page-number-citation. The output page
number is as follows:
[ref-id page] - [origin-id page] + 1
If the specified Page is after the ref-id page, the value becomes 0.
axf:page-number-prefix
The axf:page-number-prefix sets the prefix of page number.
Value:
<string>
23
Initial:
Applies to:
Inherited:
Percentages:
empty string
fo:page-sequence
no
N/A
Specifies the prefix of page number. Specified string will be outputted befor the page number by fo:pagenumber and fo:page-number-citation.
Also this string will be used as page label in PDF.
The following shows the mapping of the format properties and the style of the page number in PDF.
z
z
z
z
z
z
format="1" : Decimal Latin number (1, 2, 3, 4, ...) (The initial value of the format property)
format="I" : Upper case Roman number (I, II, III, IV, ...)
format="i" : Lower case Roman number (i, ii, iii, iv, ...)
format="A" : Upper case Alphabet (A..Z, AA..ZZ, ...)
format="a" : Lower case Alphabet (a..z, aa..zz, ...)
format="" : No number
When the format property is other than the above, the style of the number in PDF will be decimal Latin
number.
<fo:page-sequence axf:page-number-prefix="A-" format="i" initial-page-number="10">
<fo:static-content ...>
...<fo:page-number/>...
</fo:static-content>
...
</fo:page-sequence>
axf:physical-page-number
The axf:physical-page-number gets physical page number.
Value:
Initial:
Applies to:
Inherited:
Percentages:
true | false | inherit
false
fo:page-number, fo:page-number-citation
no
N/A
The value of initial-page-number property is disregarded and the physical page number that is not
affected by page-sequence is obtained. In order to obtain the total number of pages, ID is given to the
last page, and it is performed as follows.
<fo:page-number-citation ref-id="lastpage" axf:physical-page-number="true"/>
axf:suppress-duplicate-page-number
The axf:suppress-duplicate-page-number specifies to delete the duplicated page numbers.
Value:
Initial:
Applies to:
Inherited:
Percentages:
true | false
false
all formatting objects
yes
N/A
When formatting a index, generally several fo:page-number-citation line up for one index item. In such
case, when fo:page-number-citation refers to the same page number of the index, page numbers are
24
output repeatedly using the standard property.
11. Text Processing
axf:append-non-starter-characters
Specifies the append-non-starter-characters in CJK.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<string>
empty string
fo:page-sequence
no
N/A
When axf:line-break="strict" is specified, the characters included in <string> can be appended to the nonstarter-characters. If the specified characters are also specified in axf:except-non-starter-characters as
well in the same tag, the effect could be wrong. White space, closing parenthesis and punctuations, that
are originally non-starter, are disregarded even though they are specified.
axf:append-non-end-of-line-characters
Specifies the append-non-end-of-characters in CJK.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<string>
empty string
fo:page-sequence
no
N/A
When axf:line-break="strict" is specified, the characters included in <string> can be appended to the nonend-of-line-characters. If the specified characters are also specified to axf:except-non-end-of-linecharacters as well in the same tag, the effect could be wrong. White space, opening parenthesis and
punctuations, that are originally non-end-of-line, are disregarded even though they are specified.
axf:except-non-starter-characters
Specifies the except-non-starter-characters in CJK.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<string>
empty string
fo:page-sequence
no
N/A
When axf:line-break="strict" is specified, the characters included in <string> can be eliminated from the
non-starter-characters. If the specified chararters are also specified to axf:except-non-starter-characters
in the same tag as well, the effect is not guaranteed. White space, closing parenthesis and punctuations,
that are originally non-starter, are disregarded even though they are specified.
axf:except-non-end-of-line-characters
25
Specifies the except-non-end-of-characters in CJK.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<string>
empty string
fo:page-sequence
no
N/A
When axf:line-break="strict" is specified, the characters included in <string> can be eliminated from the
non-end-of-line-characters. If the specified chararters are also specified to axf:except-non-end-of-linecharacters in the same tag as well, the effect is not guaranteed. White space, opening parenthesis and
punctuations, that are originally non-end-of-line, are disregarded even though they are specified.
axf:font-emphasize-position [-]
Specifies the position of font emphasizing. This property is based on CSS3 Font emphasis.
Value:
Initial:
Applies to:
Inherited:
Percentages:
before | after
before
fo:character, fo:inline
yes
N/A
axf:font-emphasize-style [-]
Specifies the style of font emphasis. This property is based on CSS3 Font emphasis.
Value:
Initial:
Applies to:
Inherited:
Percentages:
none | accent | dot | circle | disc
none
fo:character, fo:inline
yes
N/A
axf:hanging-punctuation
The axf:hanging-punctuation specifies whether to hang Japanese punctuation characters or not. This
property is based on CSS3 Text Module: 11.2. Hanging punctuation.
Value:
Initial:
Applies to:
Inherited:
Percentages:
none | end | inherit
none
fo:block
yes
N/A
Values have the following meanings.
none
Punctuation characters are not subject to hang.
end
26
Punctuation characters at end of line can hang.
Punctuation characters to be hanged are four Japanese punctuations (U+3001, U+3002, U+FF0C,
U+FF0E).
axf:kerning-mode
The axf:kerning-mode specifies whether to process the kerning for punctuation. This property is based on
CSS3 Text Module: 8.5. Text kerning.
Value:
Initial:
Applies to:
Inherited:
Percentages:
none | [ pair || contextual ] | auto | inherit
auto
all block-level and inline-level formatting objects
yes
N/A
Values have the following meanings.
none
Adjacent full width punctuation characters are not trimmed.
pair [-]
The pair kerning is processed.
contextual
The space between a full width punctuation and a full width character in Japanese is trimmed.
z
z
z
z
z
z
z
Between full width close parenthesis and full width open parenthesis.
Between full width close parenthesis and full width close parenthesis.
Between full width close parenthesis and full width middle dots.
Between full width close parenthesis and non punctuation characters.
Between full width open parenthesis and full width open parenthesis.
Between full width middle dots and full width open parenthesis.
Between non punctuation character and full width open parenthesis.
Full width punctuation characters are treated the same as full width close parenthesis. By
specifying axf:kerning-mode="contextual" the space between full width close parenthesis and non
punctuation characters is not condensed. The space can be condensed by setting the value of
axf:punctuation-spacing less than the default.
auto
Dependent on the system setting.
Full width punctuation open parenthesis processed by axf:kerning-mode="contextual" are:
2018;QU
201C;QU
3008;OP
300A;OP
300C;OP
300E;OP
3010;OP
#
#
#
#
#
#
#
LEFT
LEFT
LEFT
LEFT
LEFT
LEFT
LEFT
SINGLE QUOTATION MARK
DOUBLE QUOTATION MARK
ANGLE BRACKET
DOUBLE ANGLE BRACKET
CORNER BRACKET
WHITE CORNER BRACKET
BLACK LENTICULAR BRACKET
‘
“
〈
《
「
『
【
27
3014;OP
3016;OP
3018;OP
301A;OP
301D;OP
FF08;OP
FF3B;OP
FF5B;OP
FF5F;OP
#
#
#
#
#
#
#
#
#
LEFT TORTOISE SHELL BRACKET
LEFT WHITE LENTICULAR BRACKET
LEFT WHITE TORTOISE SHELL BRACKET
LEFT WHITE SQUARE BRACKET
REVERSED DOUBLE PRIME QUOTATION MARK
FULLWIDTH LEFT PARENTHESIS
FULLWIDTH LEFT SQUARE BRACKET
FULLWIDTH LEFT CURLY BRACKET
FULLWIDTH LEFT WHITE PARENTHESIS
〔
〖
〝
（
［
｛
Full width punctuation close parenthesis processed by axf:kerning-mode="contextual" are:
2019;QU
201D;QU
3009;CL
300B;CL
300D;CL
300F;CL
3011;CL
3015;CL
3017;CL
3019;CL
301B;CL
FF09;CL
FF3D;CL
FF5D;CL
FF60;CL
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
RIGHT SINGLE QUOTATION MARK
RIGHT DOUBLE QUOTATION MARK
RIGHT ANGLE BRACKET
RIGHT DOUBLE ANGLE BRACKET
RIGHT CORNER BRACKET
RIGHT WHITE CORNER BRACKET
RIGHT BLACK LENTICULAR BRACKET
RIGHT TORTOISE SHELL BRACKET
RIGHT WHITE LENTICULAR BRACKET
RIGHT WHITE TORTOISE SHELL BRACKET
RIGHT WHITE SQUARE BRACKET
FULLWIDTH RIGHT PARENTHESIS
FULLWIDTH RIGHT SQUARE BRACKET
FULLWIDTH RIGHT CURLY BRACKET
FULLWIDTH RIGHT WHITE PARENTHESIS
’
”
〉
》
」
』
】
〕
〖
）
］
｝
Full width punctuations processed by axf:kerning-mode="contextual" are:
3001;CL
3002;CL
FF0C;CL
FF0E;CL
#
#
#
#
IDEOGRAPHIC COMMA
IDEOGRAPHIC FULL STOP
FULLWIDTH COMMA
FULLWIDTH FULL STOP
、
。
，
．
Full width middle dots processed by axf:kerning-mode="contextual" are:
30FB;NS # KATAKANA MIDDLE DOT
FF1A;NS # FULLWIDTH COLON
FF1B;NS # FULLWIDTH SEMICOLON
・
：
；
axf:kerning-pair-threshold [-]
The font size of the pair kerning is specified. This property is based on CSS3 Text Module: 8.5. Text
kerning.
Value:
Initial:
Applies to:
Inherited:
Percentages:
auto | <length> | inherit
auto
all block-level and inline-level formatting objects which are descendants of fo:flow
yes
refer to the font size
When auto is specified, it is pair kerning (axf:kerning-mode="pair") regardless of the size. When "length"
is specified, the pair kerning is done if it is larger than the size.
axf:line-break
The axf:line-break specifies the method of line breaking. This property is based on CSS3 Text Module:
6.2. Line breaking.
28
Value:
Initial:
Applies to:
Inherited:
Percentages:
normal | strict | inherit
normal
all block-level and inline-level formatting objects
yes
N/A
Values have the following meanings.
normal
Nonstarter characters in JIS X 4051 and other small Kana letters in Japanese (U+3095, U+3096,
U+31F0 to U+31FF) are not treated as Nonstarter characters. Also, the properties of axf:appendnon-starter-characters, axf:except-non-starter-characters, axf:append-non-end-of-line-characters,
axf:except-non-end-of-line-characters are disregarded.
strict
Nonstarter character is treated for Japanese. Also, the characters specified to the properties of
axf:append-non-starter-characters, axf:except-non-starter-characters, axf:append-non-end-of-linecharacters, axf:except-non-end-of-line-characters are included.
The Nonstarter character in LineBreak-4.0.0.txt is as follows. [JIS] is classified into the Nonstarter
character in JIS X 4051.
0E5A;NS
0E5B;NS
17D4;NS
17D6;NS
17D7;NS
17D8;NS
17D9;NS
17DA;NS
203C;NS
3005;NS
301C;NS
303B;NS
303C;NS
3041;NS
3043;NS
3045;NS
3047;NS
3049;NS
3063;NS
3083;NS
3085;NS
3087;NS
308E;NS
3095;NS
3096;NS
309B;NS
309C;NS
309D;NS
309E;NS
30A0;NS
30A1;NS
30A3;NS
30A5;NS
30A7;NS
30A9;NS
30C3;NS
30E3;NS
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
THAI CHARACTER ANGKHANKHU
THAI CHARACTER KHOMUT
KHMER SIGN KHAN
KHMER SIGN CAMNUC PII KUUH
KHMER SIGN LEK TOO
KHMER SIGN BEYYAL
KHMER SIGN PHNAEK MUAN
KHMER SIGN KOOMUUT
DOUBLE EXCLAMATION MARK
IDEOGRAPHIC ITERATION MARK
WAVE DASH
VERTICAL IDEOGRAPHIC ITERATION MARK
MASU MARK
HIRAGANA LETTER SMALL A
HIRAGANA LETTER SMALL I
HIRAGANA LETTER SMALL U
HIRAGANA LETTER SMALL E
HIRAGANA LETTER SMALL O
HIRAGANA LETTER SMALL TU
HIRAGANA LETTER SMALL YA
HIRAGANA LETTER SMALL YU
HIRAGANA LETTER SMALL YO
HIRAGANA LETTER SMALL WA
HIRAGANA LETTER SMALL KA
HIRAGANA LETTER SMALL KE
KATAKANA-HIRAGANA VOICED SOUND MARK
KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK
HIRAGANA ITERATION MARK
HIRAGANA VOICED ITERATION MARK
KATAKANA-HIRAGANA DOUBLE HYPHEN
KATAKANA LETTER SMALL A
KATAKANA LETTER SMALL I
KATAKANA LETTER SMALL U
KATAKANA LETTER SMALL E
KATAKANA LETTER SMALL O
KATAKANA LETTER SMALL TU
KATAKANA LETTER SMALL YA
29
々
ぁ
ぃ
ぅ
ぇ
ぉ
っ
ゃ
ゅ
ょ
ゎ
゛
゜
ゝ
ゞ
ァ
ィ
ゥ
ェ
ォ
ッ
ャ
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
30E5;NS
30E7;NS
30EE;NS
30F5;NS
30F6;NS
30FB;NS
30FC;NS
30FD;NS
30FE;NS
31F0;NS
31F1;NS
31F2;NS
31F3;NS
31F4;NS
31F5;NS
31F6;NS
31F7;NS
31F8;NS
31F9;NS
31FA;NS
31FB;NS
31FC;NS
31FD;NS
31FE;NS
31FF;NS
FE54;NS
FE55;NS
FF1A;NS
FF1B;NS
FF65;NS
FF67;NS
FF68;NS
FF69;NS
FF6A;NS
FF6B;NS
FF6C;NS
FF6D;NS
FF6E;NS
FF6F;NS
FF70;NS
FF9E;NS
FF9F;NS
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
KATAKANA LETTER SMALL YU
KATAKANA LETTER SMALL YO
KATAKANA LETTER SMALL WA
KATAKANA LETTER SMALL KA
KATAKANA LETTER SMALL KE
KATAKANA MIDDLE DOT
KATAKANA-HIRAGANA PROLONGED SOUND MARK
KATAKANA ITERATION MARK
KATAKANA VOICED ITERATION MARK
KATAKANA LETTER SMALL KU
KATAKANA LETTER SMALL SI
KATAKANA LETTER SMALL SU
KATAKANA LETTER SMALL TO
KATAKANA LETTER SMALL NU
KATAKANA LETTER SMALL HA
KATAKANA LETTER SMALL HI
KATAKANA LETTER SMALL HU
KATAKANA LETTER SMALL HE
KATAKANA LETTER SMALL HO
KATAKANA LETTER SMALL MU
KATAKANA LETTER SMALL RA
KATAKANA LETTER SMALL RI
KATAKANA LETTER SMALL RU
KATAKANA LETTER SMALL RE
KATAKANA LETTER SMALL RO
SMALL SEMICOLON
SMALL COLON
FULLWIDTH COLON
FULLWIDTH SEMICOLON
HALFWIDTH KATAKANA MIDDLE DOT
HALFWIDTH KATAKANA LETTER SMALL A
HALFWIDTH KATAKANA LETTER SMALL I
HALFWIDTH KATAKANA LETTER SMALL U
HALFWIDTH KATAKANA LETTER SMALL E
HALFWIDTH KATAKANA LETTER SMALL O
HALFWIDTH KATAKANA LETTER SMALL YA
HALFWIDTH KATAKANA LETTER SMALL YU
HALFWIDTH KATAKANA LETTER SMALL YO
HALFWIDTH KATAKANA LETTER SMALL TU
HALFWIDTH KATAKANA-HIRAGANA PROLONGED SOUND MARK
HALFWIDTH KATAKANA VOICED SOUND MARK
HALFWIDTH KATAKANA SEMI-VOICED SOUND MARK
ュ
ョ
ヮ
ヵ
ヶ
・
ー
ヽ
ヾ
〖
〖
：
；
ｧ
ｨ
ｩ
ｪ
ｫ
ｬ
ｭ
ｮ
ｯ
ｰ
ﾞ
ﾟ
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
[JIS]
axf:line-break-at-punctuation-in-word
The axf:line-break-at-punctuation-in-word specifies the controls of the line breaking after the symbols in
the alphanumeric characters.
Value:
Initial:
Applies to:
Inherited:
Percentages:
loose | normal | restrict | strict | auto | inherit
auto
all block-level and inline-level formatting objects
yes
N/A
Values have the following meanings.
loose
This is dependent on UAX#14: Line Breaking Properties.
normal
30
Restricts line breaks between the alphabetic characters and the symbolic characters classified as
IS. The other symbolic characters conform to UAX#14. Originally, the line breaking between the
symbols and the numeric characters is prohibited by UAX#14.
When the alphanumeric string before and after the IS symbolic characters is relatively long and is
not hyphenated, the line breaks after the IS symbolic characters. When the string is short, the line
does not break actively because of the possibility of the abbreviation.
restrict
Restricts line breaks between the symbols and the alphanumeric characters. When the
alphanumeric string before and after the symbols is relatively long and is not hyphenated, the line
breaks after the symbols. When the string is short, the line does not break actively because of the
possibility of the abbreviation.
strict
Prohibits line breaks between symbolic characters and alphanumeric characters.
auto
Dependent on the system setting.
Symbolic characters described here means the characters that belong to the following character class in
UAX#14. Line breaking between the symbolic characters and the PR Prefix (Numeric) is prohibited
according to UAX#14.
IS Infix Separator (Numeric)
002C;IS
002E;IS
003A;IS
003B;IS
0589;IS
060D;IS
2044;IS
#
#
#
#
#
#
#
COMMA
FULL STOP
COLON
SEMICOLON
ARMENIAN FULL STOP
ARABIC DATE SEPARATOR
FRACTION SLASH
,
.
:
;
PO Postfix (Numeric)
0025;PO
00A2;PO
00B0;PO
2030;PO
2031;PO
2032;PO
2033;PO
2034;PO
2035;PO
2036;PO
2037;PO
20A7;PO
2103;PO
2109;PO
2126;PO
FDFC;PO
FE6A;PO
FF05;PO
FFE0;PO
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
PERCENT SIGN
CENT SIGN
DEGREE SIGN
PER MILLE SIGN
PER TEN THOUSAND SIGN
PRIME
DOUBLE PRIME
TRIPLE PRIME
REVERSED PRIME
REVERSED DOUBLE PRIME
REVERSED TRIPLE PRIME
PESETA SIGN
DEGREE CELSIUS
DEGREE FAHRENHEIT
OHM SIGN
RIAL SIGN
SMALL PERCENT SIGN
FULLWIDTH PERCENT SIGN
FULLWIDTH CENT SIGN
%
¢
°
‰
′
″
‵
℃
〖
Ω
〖
％
￠
An alphanumeric character described here means the characters that belong to the following character
class in UAX#14.
AL Ordinary Alphabetic and Symbol
31
NU Numeric
axf:overflow-condense
The axf:overflow-condense specifies how to condense the overflowed text within the region.
Value:
Initial:
Applies to:
Inherited:
Percentages:
[ letter-spacing || word-spacing || font-stretch || font-size || line-height ] | auto | inherit
auto
all block-level formatting objects
yes
N/A
Values have the following meanings.
letter-spacing
Condenses the text by adjusting the letter spacing.
word-spacing [-]
Condenses the text by adjusting the word spacing.
font-stretch
Condenses the text by adjusting the font width.
font-size
Condenses the text by adjusting the font size.
line-height
Condenses the text by adjusting the line height.
auto
Dependent on the system setting.
Condensing the text within the region can be specified with the properties of overflow="condense". The
adjustment for condensing the text includes both the inline progression direction and the block
progression direction. The system will process the specified method by combining the methods
considered as suitable.
axf:overflow-replace
An alternative character string for the specified overflow text.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<string>
depends on system
all block-level formatting objects
yes
N/A
32
When overflow="replace" is specified, the overflow text is replaced by repeating the specified string.
axf:punctuation-spacing
The axf:punctuation-spacing specifies the spacing between a full width punctuation and a full width
character in Japanese.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<length> | inherit
0.5em
all block-level and inline-level formatting objects
yes
refer to the font size
This space is used in axf:kerning-mode="contextual".
axf:punctuation-trim
The axf:punctuation-trim specifies whether to treat full width punctuations as half width. This property is
based on CSS3 Text Module: 8.3. Punctuation trimming.
Value:
Initial:
Applies to:
Inherited:
Percentages:
none | start | end | both | auto | inherit
auto
all block-level and inline-level formatting objects
yes
N/A
Values have the following meanings.
none
Punctuation characters are not trimmed.
start
Punctuation characters (open parenthesis etc.) at start of line are trimmed.
end
Punctuation characters (close parenthesis etc.) at end of line are trimmed.
both
Punctuation characters at start and end of line are trimmed.
auto
Dependent on the system setting.
axf:text-autospace
The axf:text-autospace specifies whether to add space surrounding ideographic glyphs or not. This
property is based on CSS3 Text Module: 8.4. Adding space.
33
Value:
Initial:
Applies to:
Inherited:
Percentages:
none | [ ideograph-numeric || ideograph-alpha ] | auto | inherit
auto
all block-level and inline-level formatting objects
yes
N/A
Values have the following meanings.
none
Space is not added.
ideograph-numeric
Space is added between ideograph character and non-ideographic number character.
ideograph-alpha
Space is added between ideograph character and non-ideographic alphabet character.
auto
Dependent on the system setting.
axf:text-autospace-width
The axf:text-autospace-width specifies the width for axf:text-autospace.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<length> | inherit
0.25em
all block-level and inline-level formatting objects
yes
refer to the font size
This space is used in axf:text-autospace.
axf:text-kashida-space
The axf:text-kashida-space specifies the ratio of the kashida expansion size to the white space
expansion size. This property is based on CSS3 Text Module: 4.6. Kashida effect.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<percentage> | auto
auto
all block-level and inline-level formatting objects
yes
yes
Values have the following meanings.
<percentage>
Indicates the percentage of white space and Kashida. If the value is 0%, Kashida is not inserted
and only the white space expands as well as the normal justification. If the value is 100%, Kashida
34
is inserted as much as possible. The value should be from 0% to 100%.
auto
Dependent on the system setting.
axf:vertical-underline-side
The axf:vertical-underline-side specifies on which side of the text to put underline in vertical writing-mode.
Value:
Initial:
Applies to:
Inherited:
Percentages:
left | right | auto | inherit
auto
all block-level and inline-level formatting objects
yes
N/A
Values have the following meanings.
left
The underline is placed on the left side.
right
The underline is placed on the right side.
auto
Dependent on the system setting.
axf:vertical-underline-side="auto" で、システムの既定値も自動のときは、languageプロパティでの言語が日本
語(ja)または韓国語(ko)のときは右側に、その他の言語では左側に配置されます。
12. Ruby / Text Combine
CAUTION: Not documented yet.
axf:ruby-align [-]
axf:ruby-overhang [-]
axf:ruby-position [-]
axf:ruby-span [-]
axf:text-combine [-]
13. List
axf:list-style-position [-]
35
The position of the marker of the list is specified. This property is based on CSS3 Lists Module: 7. Marker
Position.
Value:
Initial:
Applies to:
Inherited:
Percentages:
inside | outside | inherit
outside
all formatting objects
yes
N/A
Values have the following meanings.
inside
The position of the marker is an inside in the block.
outside
The position of the marker is an outside in the block.
14. Miscellaneous
axf:base-uri
The axf:base-uri specifies the location which becomes the base of relative URI.
Value:
Initial:
Applies to:
Inherited:
Percentages:
<uri-specification>
empty string
all formatting objects
yes
N/A
The axf:base-uri is applied to all relative URI in a document. When making links using fo:basic-link and
specify relative URI, the location that is specified using axf:base-uri is interpreted to be base URI. If this
property is omitted or this has empty string, the base location is interpreted as current XML file.
axf:soft-hyphen-treatment
The axf:soft-hyphen-treatment specifies to output SOFT HYPEN.
Value:
Initial:
Applies to:
Inherited:
Percentages:
auto | preserve | inherit
auto
all formatting objects
yes
N/A
Generally SOFT HYPHEN (U+00AD) is displayed only when the line breaks and not displayed when the
line does not break. However in this processing, it is often the case that the glyph assigned to U+00AD
may not printed when the fonts such as pictographic characters are used. Possible to eliminate this
problem by using the axf:soft-hyphen-treatment property.
Values have the following meanings.
36
auto
SOFT HYPHEN is deleted except when needed for line breaking. (normal)
preserve
SOFT HYPHEN is not deleted and the target glyph is output.
axf:justify-nbsp
The axf;justify-nbsp specifies whether to justify NON-BREAKING SPACE or not.
Value:
Initial:
Applies to:
Inherited:
Percentages:
true | false | inherit
true
all formatting objects
yes
N/A
Generally, NON-BREAKING SPACE (U+00A0) is intended for Justification. The axf:justify-nbsp property
can be used when you want to check off U+00A0 form Justify.
Values have the following meanings.
true
NON-BREAKING SPACE is included for justification.
false
NON-BREAKING SPACE is not included for justification.
Extended Values
clear
Following bold values are extended.
Value:
start | end | left | right | inside | outside | both | none | inherit
Values have the following meanings.
inside
Interpreted as "start" on odd pages, as "end" on even pages.
outside
Interpreted as "end" on odd pages, as "start" on even pages.
37
float
Following bold values are extended.
Value:
before | start | end | left | right | inside | outside | after | in-column | mid-column | none |
inherit
Values have the following meanings.
inside
Places float area at start-edge on odd pages, at end-edge on even pages.
outside
Places float area at end-edge on odd pages, at start-edge on even pages.
after [-]
Places float area at after side of the area.
in-column [-]
The place of float area is put on a full column. This value is based on CSS3 Multi-column layout: 10.
Floating in and between columns.
mid-column [-]
The place of float area is put between columns. This value is based on CSS3 Multi-column layout:
10. Floating in and between columns.
font-stretch
Following bold values are extended.
Value:
normal | wider | narrower | ultra-condensed | extra-condensed | condensed | semi-condensed |
semi-expanded | expanded | extra-expanded | ultra-expanded | <percentage> | <number> |
38
inherit
Values have the following meanings.
<percentage>
Specifies the percentage against the font width.
<number>
Equivalent to <percentage> / 100.
internal-destination
Following bold values are extended.
Value:
empty string | <idref> | <number-with-fragment>
Values have the following meanings.
<number-with-fragment>
Effective for the internal link in PDF. indicates the page number of the link destination. This string is
simpe numeric characters or the following string that combines numeric characters and fragment with
#.
123#string
overflow
Following bold values are extended.
Value:
visible | hidden | scroll | replace | condense | error-if-overflow | auto | inherit
Values have the following meanings.
replace
The string specified by axf:overflow-replace is repeated in a full area. When the specified string is
empty, the string of the area is replaced with an empty string. The original string is discarded.
condense
Condenses the overflowed text within the region. How to condense the text can be specified by
axf:overflow-condense.
Index
39
Element Index
z
z
z
z
z
z
z
z
axf:document-info
axf:outline-group-position
axf:output-volume-info
axf:ruby
axf:ruby-base
axf:ruby-base-container
axf:ruby-text
axf:ruby-text-container
Property Index
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
axf:action-type
axf:append-non-end-of-line-characters
axf:append-non-starter-characters
axf:assumed-page-number
axf:assumed-page-number-prefix
axf:background-color
axf:background-image
axf:base-uri
axf:bookmark-include
axf:border-radius
axf:border-bottom-left-radius
axf:border-bottom-right-radius
axf:border-top-left-radius
axf:border-top-right-radius
axf:box-shadow
axf:column-rule-align
axf:column-rule-color
axf:column-rule-length
axf:column-rule-style
axf:column-rule-width
axf:destination-type
axf:diagonal-border-color
axf:diagonal-border-style
axf:diagonal-border-width
axf:except-non-end-of-line-characters
axf:except-non-starter-characters
axf:font-emphasize-position
axf:font-emphasize-style
axf:footnote-align
axf:footnote-position
axf:hanging-punctuation
axf:initial-volume-number
axf:justify-nbsp
axf:kerning-mode
axf:line-break
axf:line-break-at-punctuation-in-word
axf:list-style-position
axf:origin-id
axf:outline-color
axf:outline-expand
axf:outline-external-destination
axf:outline-font-style
40
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
axf:outline-font-weight
axf:outline-group
axf:outline-internal-destination
axf:outline-level
axf:outline-title
axf:output-volume-break
axf:output-volume-filename
axf:overflow-condense
axf:overflow-replace
axf:page-number-prefix
axf:physical-page-number
axf:punctuation-spacing
axf:punctuation-trim
axf:reverse-diagonal-border-color
axf:reverse-diagonal-border-style
axf:reverse-diagonal-border-width
axf:revision-bar-color
axf:revision-bar-offset
axf:revision-bar-position
axf:revision-bar-style
axf:revision-bar-width
axf:ruby-align
axf:ruby-overhang
axf:ruby-position
axf:ruby-span
axf:soft-hyphen-treatment
axf:suppress-duplicate-footnote
axf:suppress-duplicate-page-number
axf:text-autospace
axf:text-autospace-width
axf:text-combine
axf:text-kashida-space
axf:vertical-underline-side
Value Index
z
z
z
z
z
clear
float
font-stretch
internal-destination
overflow
Copyright © 1999-2004 Antenna House, Inc. All rights reserved.
Antenna House is a trademark of Antenna House, Inc.
41
[附属資料－Ａ．４]
IEC/TC100 への提案
４．１ NP 原案 Conceptual model for multimedia e-publishing
４．２ NP 原案 Generic format for e-publishing
４．３ Reader’s format for e-publishing の検討資料(PDF サブセッ
ト)
４．４ Submission format for e-publishing の検討資料(XML 化 SPML)
[附属資料－Ａ．５]
ISO/IEC JTC1/SC34 への提案(CICC/DocSI I とのリエゾン)
A.5.1 Amd.1 to ISO/IEC TR 19758
A.5.2 Amd.2 to ISO/IEC TR 19758
A.5.3 DAM3 to ISO/IEC TR 19758
この事業は、競輪の補助金を受けて実施したものです。
平成 16 年度
e-Book に関する標準化調査研究
成 果 報 告 書
平成 17 年 3 月
発行
財団法人 日 本 規 格 協 会
〒107-8440 東京都港区赤坂 4-1-24
電話（03）3592-1408
印刷
スタンダード・メンテナンス株式会社
〒107-8440 東京都港区赤坂 4-1-24
日本規格協会ビル内
電話（03）3585-4558
－禁無断転載―

特急はくたかフェスinまつだい - ダイヤ運転のRFC | Railway Fan Club

ラグビースクール開校式 - 釜石シーウェイブスRFC

トップリーグ入替戦 クボタスピアーズ戦のご案内とSWテント受付のお知らせ

NAMUR 2014 - 2015

2014トップチャレンジ1第2節九州電力キューデンヴォルテクス戦のご

NTP バージョン4に準拠しセキュリティ能力を強化した セキュア - 丸文

WordでXMLマニュアルを編集し、XMLを自動組版する

日頃から皆様からの温かいご支援を感謝申し上げます。弊釜石シー

2014トップチャレンジ1 第1節 ホンダヒート戦のご案内とSWテント受付

RFC 2016年活動方針について発表いたします。