リビジョン | baed5d311c9e9d7d3296e1fea36c04e0647a4642 (tree) |
---|---|
日時 | 2011-04-01 16:31:15 |
作者 | akngw <akngw@user...> |
コミッター | akngw |
いろいろ修正。
@@ -39,7 +39,7 @@ software. Copies published by the Free Software Foundation raise | ||
39 | 39 | funds for GNU development.'' |
40 | 40 | @end enumerate |
41 | 41 | |
42 | -Copyright (C) 2008 KINUGAWA Akihito (japanese translation) | |
42 | +Copyright (C) 2008, 2011 KINUGAWA Akihito (japanese translation) | |
43 | 43 | @end copying |
44 | 44 | |
45 | 45 | @ifinfo |
@@ -65,22 +65,22 @@ This file documents the XML processing extension in GNU @command{awk}. | ||
65 | 65 | |
66 | 66 | @dircategory Databases |
67 | 67 | @direntry |
68 | -* xgawk-pgsql: (xmlgawk)PostgreSQL API リファレンス. The xgawk PostgreSQL interface. | |
68 | +* xgawk-pgsql: (xmlgawk)PostgreSQL API Reference. The xgawk PostgreSQL interface. | |
69 | 69 | @end direntry |
70 | 70 | |
71 | 71 | @dircategory Programming |
72 | 72 | @direntry |
73 | -* xgawk-time: (xmlgawk)Time Extension リファレンス. The xgawk time extension. | |
73 | +* xgawk-time: (xmlgawk)Time Extension Reference. The xgawk time extension. | |
74 | 74 | @end direntry |
75 | 75 | |
76 | 76 | @dircategory Programming |
77 | 77 | @direntry |
78 | -* xgawk-gd: (xmlgawk)GD グラフィックス拡張リファレンス. The xgawk graphics extension. | |
78 | +* xgawk-gd: (xmlgawk)GD Graphics Extension Reference. The xgawk graphics extension. | |
79 | 79 | @end direntry |
80 | 80 | |
81 | 81 | @dircategory Programming |
82 | 82 | @direntry |
83 | -* xgawk-mpfr: (xmlgawk)MPFR 拡張リファレンス. The xgawk MPFR extension. | |
83 | +* xgawk-mpfr: (xmlgawk)MPFR Extension Reference. The xgawk MPFR extension. | |
84 | 84 | @end direntry |
85 | 85 | |
86 | 86 | @iftex |
@@ -182,71 +182,80 @@ version 3.2 and later. | ||
182 | 182 | @end ifnottex |
183 | 183 | |
184 | 184 | @menu |
185 | -* 序:: | |
186 | -* AWK と XML の概念:: | |
187 | -* POSIX AWK での XML データの読み込み:: | |
188 | -* gawk の XML コア言語拡張:: | |
189 | -* xmllib ライブラリの利点:: | |
190 | -* xmltree ライブラリを使った DOM ライクアクセス:: | |
191 | -* ニューズグループ comp.text.xml と comp.lang.awk からの問題:: | |
192 | -* いくつかの高度なアプリケーション:: | |
193 | -* XML 機能のリファレンス:: | |
194 | -* 参考書籍とリンク:: | |
195 | -* Extensible Gawk 言語拡張:: | |
196 | -* PostgreSQL API リファレンス:: | |
197 | -* Time Extension リファレンス:: | |
198 | -* GD グラフィックス拡張リファレンス:: | |
199 | -* MPFR 拡張リファレンス:: | |
200 | -* xgawk のインストール:: | |
201 | -* このマニュアルの著作権情報:: | |
185 | +* Preface:: | |
186 | +* AWK and XML Concepts:: | |
187 | +* Reading XML Data with POSIX AWK:: | |
188 | +* XML Core Language Extensions of gawk:: | |
189 | +* Some Convenience with the xmllib library:: | |
190 | +* DOM-like access with the xmltree library:: | |
191 | +* Problems from the newsgroups comp.text.xml and comp.lang.awk:: | |
192 | +* Some Advanced Applications:: | |
193 | +* Reference of XML features:: | |
194 | +* Reference of Books and Links:: | |
195 | +* Extensible Gawk Language Extensions:: | |
196 | +* PostgreSQL API Reference:: | |
197 | +* Time Extension Reference:: | |
198 | +* GD Graphics Extension Reference:: | |
199 | +* MPFR Extension Reference:: | |
200 | +* Installing xgawk:: | |
201 | +* Copying This Manual:: | |
202 | 202 | * Index:: |
203 | 203 | @end menu |
204 | 204 | |
205 | -@c * XMark - XML ベンチマークプロジェクト:: | |
205 | +@c * XMark — An XML Benchmark Project:: | |
206 | + | |
206 | 207 | |
207 | 208 | @node Preface |
208 | 209 | @unnumbered 序 |
209 | 210 | |
210 | -2003 年 6 月、私は XML フォーマットで書かれたある設定ファイルのテキストに直面して、私の好きなツール (@command{grep} と @command{awk}) が、こういったファイルから情報を抽出するのにまるで役立たずだったことに恐れをなしてしまいました。 | |
211 | -AWK の行単位で処理をするやり方は、木のような構造をした XML データのノードをトラバースするやり方へと置き換えなければならないように見えました。 | |
212 | -拡張した @command{gawk} の最初の実装では、XML ファイルの読み込みで私を助けるために、@command{expat} ライブラリを選択しました。 | |
213 | -@pindex Expat、SAX ライクな API を持つ XML パーサ | |
214 | - | |
215 | -私は、Stefan Tramm に少し助けてもらいながら機能の選別を続け、2003 年のクリスマス休暇の間中、今 XMLgawk と呼ばれるものを実装していました。 | |
216 | -2004 年 6 月、Manuel Collado が私達に合流し、この拡張に対する自分の意見や提案をまとめ始めました。 | |
217 | -Manuel は XML ファイルを DOM ライクな構造へ読み込むためのライブラリをも書きました。 | |
218 | -@cindex DOM、ドキュメントオブジェクトモデル | |
219 | - | |
220 | -2004 年 9 月、私は、この @value{DOCUMENT} の初版を書きました。 | |
221 | -Andrew Schorr は、変更に対するパッチや提案で私のメールボックスを溢れさせました。 | |
222 | -また、彼の後押しで SourceForge プロジェクトを始めました。 | |
223 | -これは 2005 年 3 月のことで、以来ソフトウェアの変更は、SourceForge の CVS ソースツリーへ入力しています (このサービスを提供してくれていることに感謝します)。 | |
224 | -Andrew の、ある生産システムへの急な必要から、2005 年初頭に開発が進みました。 | |
211 | +2003年6月、私は、XMLフォーマットで書かれたある設定ファイルのテキストに直面して、こういったファイルから情報を抽出するのに、私の好きなツール(@command{grep}と@command{awk})がまるで役立たずだったことに恐れをなしてしまいました。 | |
212 | +AWKの行単位で処理をするやり方は、木のような構造をしたXMLデータのノードをトラバースするやり方へと置き換えなければならないように思えました。 | |
213 | +拡張した@command{gawk}の最初の実装では、XMLファイルの読み込みを行うのに、@command{expat}ライブラリを利用することを選択しました。 | |
214 | +@pindex Expat, XML parser with SAX-like API | |
215 | + | |
216 | +私は、Stefan Trammに少し助けてもらいながら機能の選別を続け、2003年のクリスマス休暇の間中、XMLgawkと今呼ばれているものを実装していました。 | |
217 | +2004年6月、Manuel Colladoが私達に合流し、この拡張に対する自分の意見や提案をまとめ始めました。 | |
218 | +Manuelは、XMLファイルをDOMライクな構造へ読み込むためのライブラリも書きました。 | |
219 | +@cindex DOM, Document Object Model | |
220 | + | |
221 | +2004年9月、私は、この@value{DOCUMENT}の初版を書きました。 | |
222 | +Andrew Schorrは、修正パッチや修正提案で私のメールボックスを溢れさせました。 | |
223 | +また、彼の後押しで、SourceForgeプロジェクトを始めました。 | |
224 | +これは2005年3月のことです。 | |
225 | +以来、ソフトウェアの変更は、SourceForgeのCVSソースツリーへ入力しています(このサービスを提供してくれていることに感謝します)。 | |
226 | +ある生産システムでAndrewが急に必要としたことから、2005年初頭に開発が進みました。 | |
225 | 227 | 以下の重要な変更が行われました。 |
228 | + | |
226 | 229 | @enumerate |
227 | 230 | @item |
228 | 231 | 構文解析の速度を倍にして、大きなデータベースの読み込みの際の効率を良くしました。 |
232 | + | |
229 | 233 | @item |
230 | -@code{XMLEVENT} や @code{XMLNAME} のようなユーザに見えるパターンにおけるいくつかの単純化を Manuel が提案し、Andrew が実装しました。 | |
234 | +@code{XMLEVENT}や@code{XMLNAME}のようなユーザに見えるパターンにおけるいくつかの単純化をManuelが提案し、Andrewが実装しました。 | |
235 | + | |
231 | 236 | @item |
232 | -Andrew が XMLgawk を、実行時にダイナミックライブラリとして読み込める @command{gawk} 拡張としてカプセル化しました。 | |
233 | -これは XML 拡張無しで @command{gawk} を構築することも考慮したものでした。 | |
234 | -そしてこれが @code{-l} オプションと @code{@@load} が導入されたきっかけです。 | |
237 | +Andrewが、実行時にダイナミックライブラリとして読み込める@command{gawk}拡張としてXMLgawkをカプセル化しました。 | |
238 | +これは、XML拡張無しで@command{gawk}を構築することも考慮したものでした。 | |
239 | +そして、これが、@code{-l}オプションと@code{@@load}を導入したきっかけです。 | |
240 | + | |
235 | 241 | @item |
236 | -Andrew が autotool メカニズム (@code{Makefile.am} etc.) を仕上げ、Arnold の GNU Awk と同じディレクトリに衝突することなく簡単にインストールするためのインストールのメカニズムを見つけました。 | |
237 | -また彼は、@code{-i} オプションを実装して、Arnold の @code{igawk} を obsolete にしました。 | |
238 | -2005 年 4 月、@code{gawk-3.1.4} からのブランチとして @code{xgawk} のアルファリリースを見ました。 | |
242 | +Andrewは、autotoolメカニズム(@code{Makefile.am}など)を仕上げました。 | |
243 | +また、ArnoldのGNU Awkと同じディレクトリに衝突することなく簡単にインストールするためのインストールメカニズムを見つけました。 | |
244 | +また、彼は、@code{-i}オプションを実装して、Arnoldの@code{igawk}をobsoleteにしました。 | |
245 | +2005年4月、@code{gawk-3.1.4}からのブランチとして、@code{xgawk}のアルファリリースを見ました。 | |
239 | 246 | @end enumerate |
240 | 247 | |
241 | -2005 年 8 月、Hirofumi Saito が日本での @uref{http://ll.jus.or.jp/2005/files/lldn_awk_2005.pdf, @emph{Lightweight Language Day and Night}} でプレゼンテーションを行ないました。 | |
242 | -彼は短いスライドショーの中で、モダンなプログラミング言語におけるマルチバイト文字の重要性についてデモンストレーションをしました。 | |
243 | -また、Hirofumi Saito は私たちのソースコードの日本語に対するローカル化も行ないました。 | |
244 | -Kimura Koichi はマルチバイト文字の取り扱いに関する問題のいくつかを報告し、修正しました。 | |
245 | -また彼は、各種の Microsoft Windows 上でこれを全て動作させるやり方を見いだしました。 | |
248 | +2005年8月、Hirofumi Saitoは、日本での@uref{http://ll.jus.or.jp/2005/files/lldn_awk_2005.pdf, @emph{Lightweight Language Day and Night}}でプレゼンテーションを行いました。 | |
249 | +彼は、短いスライドショーの中で、モダンなプログラミング言語におけるマルチバイト文字の重要性についてデモンストレーションをしました。 | |
250 | +また、Hirofumi Saitoは、ソースコードの日本語に対するローカル化も行いました。 | |
251 | +Kimura Koichiは、マルチバイト文字の取り扱いに関する問題のいくつかを報告し、修正しました。 | |
252 | +また、彼は、各種のMicrosoft Windows上でこれを全て動作させるやり方を見出しました。 | |
246 | 253 | @cindex Microsoft Windows |
247 | 254 | |
248 | -2005 年の夏頃 Arnold が @code{gawk-3.1.5} をリリースし、2005 年のクリスマス休暇一杯を使って私はその彼の 219 個のパッチを私たちの CVS ツリーへ適用しました。 | |
249 | -さらに、Andrew が GNU メーリングリストのアーカイブから持ってきたいくつかのバグの修正を行ないましたので、@code{xgawk-3.1.5} の現在のベータリリースは Arnold の @code{gawk-3.1.5} よりも既にちょっとだけ先へ行っています。 | |
255 | +2005年の夏頃、Arnoldは@code{gawk-3.1.5}をリリースしました。 | |
256 | +私は、2005年のクリスマス休暇一杯を使って、その彼の219個のパッチをCVSツリーへ適用しました。 | |
257 | +さらに、Andrewは、GNUメーリングリストのアーカイブから持ってきたいくつかのバグの修正を行いました。 | |
258 | +このため、@code{xgawk-3.1.5}の現在のベータリリースは、Arnoldの@code{gawk-3.1.5}よりもちょっとだけ先へ既に行っています。 | |
250 | 259 | @sp 1 |
251 | 260 | @noindent |
252 | 261 | J@"urgen Kahrs @* |
@@ -254,37 +263,37 @@ Bremen, Germany @* | ||
254 | 263 | April, 2006 |
255 | 264 | |
256 | 265 | @page |
257 | -2006 年 8 月、Arnold と彼をサポートしている人たちは、Arnold のソースツリーのミラーとして、@uref{http://savannah.gnu.org/projects/gawk, Savannah} に CVS リポジトリを用意しました。 | |
258 | -これで今 Arnold のソースツリーの最新の変更を知ることは、私たちにとってかなり容易になっています。 | |
259 | -私たちは、その変更を私たちのソースツリーへすぐに全てマージするよう努めています。 | |
260 | -このマージプロセスは、1週間ごとの @code{cron} ジョブメカニズムでぶっちゃけ簡素化されています (Andrew が実装しました)。 | |
261 | -Arnold のツリーでの変更状況を調査して私たちのメーリングリストへ email を送信するものです。 | |
266 | +2006年8月、Arnoldと彼をサポートしている人たちは、Arnoldのソースツリーのミラーとして、@uref{http://savannah.gnu.org/projects/gawk, Savannah}にCVSリポジトリを用意しました。 | |
267 | +これにより、Arnoldのソースツリーの最新の変更を知ることは、今、かなり容易になっています。 | |
268 | +その変更は、ソースツリーへすぐに全てマージするよう努めています。 | |
269 | +このマージプロセスは、1週間ごとの@code{cron}ジョブメカニズムでぶっちゃけ簡素化されています(Andrewが実装しました)。 | |
270 | +Arnoldのツリーでの変更状況を調査して、メーリングリストへemailを送信するものです。 | |
262 | 271 | |
263 | -日本の支援者たちが Arnold と私たちにマルチバイト文字の取り扱いに関するさらなる問題と修正を報告してくれました。 | |
264 | -例えば、Hirofumi Saito とそのほかの人たちが、ShiftJIS ロケールにおける文字クラスの中の幅が半分のカタカナに対するパッチを送ってきました。 | |
272 | +日本の支援者たちは、Arnoldと私たちにマルチバイト文字の取り扱いに関するさらなる問題と修正を報告してくれました。 | |
273 | +例えば、Hirofumi Saitoとその他の人たちは、ShiftJISロケールにおける文字クラスの中の幅が半分のカタカナに対するパッチを送ってきました。 | |
265 | 274 | |
266 | -2007 年 1 月から @code{Makefile} のトップレベルのターゲットに新しく @code{valgrind} が入っています。 | |
267 | -この機能は、リグレッションのテストケースを実行中のインタプリタのメモリリークを検出するために実装されています。 | |
268 | -この新しい機能で、私たちは @code{time} と @code{mpfr} 拡張の小さなメモリリークを即座に見つけました。 | |
275 | +2007年1月から、@code{Makefile}のトップレベルのターゲットに@code{valgrind}が新しく入っています。 | |
276 | +この機能は、回帰テストケースを実行中のインタプリタのメモリリークを検出するために実装されています。 | |
277 | +この新しい機能で、@code{time}と@code{mpfr}拡張の小さなメモリリークを即座に見つけました。 | |
269 | 278 | |
270 | -2007 年 3 月、多くの作業が行われました。 | |
271 | -まず私たちは、GD ライブラリに対する Victor Paesa の新しい拡張を取り入れました。 | |
272 | -それから、Arnold のソースツリーから Paul Eggert による @file{floatcomp.c} ファイル (浮動小数点/long の比較) をマージしました。 | |
273 | -また、数値計算の振る舞い (無限と非数値) とそれらのフォーマティングの変更による、リグレッションテストケースとドキュメンテーションのマージも行いました。 | |
279 | +2007年3月、多くの作業が行われました。 | |
280 | +まず、GDライブラリに対するVictor Paesaの新しい拡張を取り入れました。 | |
281 | +それから、Arnoldのソースツリーから、Paul Eggertによる@file{floatcomp.c}ファイル(浮動小数点/longの比較)をマージしました。 | |
282 | +また、数値計算の振る舞い(無限と非数値)とそれらのフォーマティングの変更による、回帰テストケースとドキュメントのマージも行いました。 | |
274 | 283 | |
275 | -Stefan Tramm が @uref{http://conferences.oreillynet.com/os2006, OSCON 06} で、5 分間の @uref{http://homepage.mac.com/stefan.tramm/iWiki/XmlGawkOsconLT.html, @emph{Lightning Talk on xgawk}} 行いました。 | |
284 | +Stefan Trammは、@uref{http://conferences.oreillynet.com/os2006, OSCON 06}で、5分間の@uref{http://homepage.mac.com/stefan.tramm/iWiki/XmlGawkOsconLT.html, @emph{Lightning Talk on xgawk}}を行いました。 | |
276 | 285 | |
277 | -Hirofumi Saito が @uref{http://ll.jus.or.jp/2006, @emph{Lightweight Language Conference 2006}} に参加しました。 | |
278 | -Matt Rosin が @uref{http://telebody.net/wordpress/2006/09/05/lightweights-getting-physical, English} でのイベントの内容を要約しました。 | |
286 | +Hirofumi Saitoは、@uref{http://ll.jus.or.jp/2006, @emph{Lightweight Language Conference 2006}}に参加しました。 | |
287 | +Matt Rosinは、@uref{http://telebody.net/wordpress/2006/09/05/lightweights-getting-physical, English}でのイベントの内容を要約しました。 | |
279 | 288 | |
280 | -新しく @ref{POSIX AWK での XML データの読み込み} に、テンプレートスクリプトの @code{getXMLEVENT.awk} について記述しています。 | |
281 | -このスクリプトで XMLgawk API とほとんど互換のサブセットであるやり方でポータブルなスクリプトを書くことができます。 | |
282 | -こういった方法で書かれたスクリプトは、@code{xgawk} ばかりでなく、POSIX 準拠のどんな AWK インタプリタでも実行させることができます。 | |
289 | +別の節(@pxref{Reading XML Data with POSIX AWK})に、テンプレートスクリプトの@code{getXMLEVENT.awk}について記述しています。 | |
290 | +このスクリプトを使うと、XMLgawk APIとほぼ互換のサブセットの方法で、ポータブルなスクリプトを書くことができます。 | |
291 | +こういった方法で書かれたスクリプトは、@code{xgawk}ばかりでなく、POSIX準拠のどんなAWKインタプリタでも実行させることができます。 | |
283 | 292 | |
284 | -新しく @ref{@file{xmlcopy.awk} ライブラリスクリプトを使ったコピーと修正} に、XML データを少し修正したコピーを作成するためのライブラリスクリプトについて記述しています。 | |
293 | +別の節(@pxref{Copying and Modifying with the @file{xmlcopy.awk} library script})に、XMLデータを少し修正したコピーを作成するためのライブラリスクリプトについて記述しています。 | |
285 | 294 | |
286 | -Arnold が彼の @code{gawk-stable} ツリーに適用したパッチをきちんと知らせてくれる Andrew の作った仕組みのおかげで、Andrew と 私は Arnold のソースツリーの最新の変更に追随しました。 | |
287 | -その結果、現在@code{xgawk} は最新の @code{gawk-3.1.6} 公式リリースをベースにしています。 | |
295 | +Arnoldが@code{gawk-stable}ツリーに適用したパッチをきちんと知らせてくれるAndrewの作った仕組みのおかげで、Andrewと私は、Arnoldのソースツリーの最新の変更に追随しました。 | |
296 | +その結果、現在、@code{xgawk}は、最新の@code{gawk-3.1.6}公式リリースをベースにしています。 | |
288 | 297 | @sp 1 |
289 | 298 | @noindent |
290 | 299 | J@"urgen Kahrs @* |
@@ -292,45 +301,48 @@ Bremen, Germany @* | ||
292 | 301 | December, 2007 |
293 | 302 | |
294 | 303 | @page |
295 | -@b{FIXME: このドキュメントは未完成です。 | |
304 | +@b{FIXME:このドキュメントは未完成です。 | |
296 | 305 | 不完全な部分にはこのようなコメントでマークしています。} |
297 | 306 | |
298 | -@b{FIXME: このドキュメントが対象とする範囲について決めなければなりません。 | |
299 | -XMLgawk 拡張についてだけのドキュメントとするか、GNU Awk の全ての拡張についてのドキュメントにするか? | |
300 | -Andrew は PostgreSQL と time 拡張に関する記述を補遺部分に入れました。} | |
307 | +@b{FIXME:このドキュメントが対象とする範囲について決めなければなりません。 | |
308 | +XMLgawk拡張についてだけのドキュメントとするか、GNU Awkの全ての拡張についてのドキュメントにするか。 | |
309 | +Andrewは、PostgreSQLとtime拡張に関する記述を補遺部分に入れました。} | |
310 | + | |
301 | 311 | |
302 | 312 | @node AWK and XML Concepts |
303 | -@chapter AWK と XML の概念 | |
313 | +@chapter AWKとXMLの概念 | |
304 | 314 | |
305 | 315 | @menu |
306 | -* AWK の実行モデルに XML はどのようにフィットするか:: | |
307 | -* gawk で木構造をトラバースする方法:: | |
308 | -* XML ファイルを詳しく見る:: | |
316 | +* How does XML fit into AWK's execution model ?:: | |
317 | +* How to traverse the tree with gawk:: | |
318 | +* Looking closer at the XML file:: | |
309 | 319 | @end menu |
310 | 320 | |
311 | -この @value{CHAPTER} では、XML の概念に関する (必然的に) 短い紹介を行います。 | |
312 | -@command{gawk} で XML 処理をする多くのアプリケーションにはこれで十分だと思っていますが、さらに高度なタスクをこなすには、より深い背景を知る必要があるでしょうし、XSL プロセッサのような他のツールへ移ることも必要となるかもしれません。 | |
321 | +この@value{CHAPTER}では、XMLの概念に関する(必然的に)短い紹介を行います。 | |
322 | +@command{gawk}でXML処理をする多くのアプリケーションにはこれで十分だと思っていますが、さらに高度なタスクをこなすには、より深い背景を知る必要があるでしょうし、XSLプロセッサのような他のツールへ移ることも必要となるかもしれません。 | |
313 | 323 | @cindex XSL |
314 | 324 | |
325 | + | |
315 | 326 | @node How does XML fit into AWK's execution model ?, How to traverse the tree with gawk, AWK and XML Concepts, AWK and XML Concepts |
316 | -@section AWK の実行モデルに XML はどのようにフィットするか | |
317 | -XML について見ていく前に、まず、AWK プログラムの実行がどのように働くか、そしてこのフレームワークの中での XML の処理に必要なものについて繰り返させてください。 | |
318 | -@command{gawk} の man page には AWK の基本的な実行モデルについて次のようにまとめられています。 | |
327 | +@section AWKの実行モデルにXMLはどのようにフィットするか | |
328 | + | |
329 | +XMLについて見ていく前に、まず、AWKプログラムの実行がどのように働くか、そして、このフレームワークの中でのXMLの処理に必要なものについて繰り返させてください。 | |
330 | +@command{gawk}のman pageには、AWKの基本的な実行モデルについて次のようにまとめられています。 | |
319 | 331 | |
320 | 332 | @quotation |
321 | - AWK プログラムはパターン-アクションステートメントの並びとオプショナルな関数定義からなります。 | |
333 | + AWKプログラムは、パターン-アクションステートメントの並びとオプショナルな関数定義からなります。 | |
322 | 334 | @* @emph{pattern @{ action statements @}} |
323 | 335 | @* @emph{function name(parameter list) @{ statements @}} |
324 | 336 | @* |
325 | 337 | @dots{} |
326 | - gawk は、入力されるそれぞれのレコードが AWK プログラム中のどのパターンにマッチするかを調べるためにテストします。 | |
338 | + gawkは、AWKプログラム中のどのパターンに各入力レコードがマッチするかを調べます。 | |
327 | 339 | レコードにマッチした各パターンについて、そのパターンに関連付けられたアクションが実行されます。 |
328 | 340 | パターンはプログラムに現れる順番にテストされます。 |
329 | - 入力を全て使い切れば、最後に、もしあれば、END ブロックの中のコードを実行します (END ブロックが複数個ある場合もあります) 。 | |
341 | + 入力を全て使い切った後は、ENDブロックが存在すれば、ENDブロック中のコードを実行します(ENDブロックが複数ある場合もあります)。 | |
330 | 342 | @end quotation |
331 | 343 | |
332 | -短かくて簡単な例を見てもらうと、この抽象的な説明の効果が明らかになるでしょう。 | |
333 | -次のスクリプトは、Unix ツールの @command{wc} を実装しています (うまく、ほとんど出来ていますが、完全なものではありません) 。 | |
344 | +短い簡単な例を見てもらうと、この抽象的な説明の効果が明らかになるでしょう。 | |
345 | +次のスクリプトは、Unixツールの@command{wc}を実装しています(ほとんど上手く出来ていますが、完全なものではありません)。 | |
334 | 346 | @cindex Unix |
335 | 347 | @cindex Cygwin |
336 | 348 | @cindex Microsoft Windows |
@@ -344,43 +356,43 @@ XML について見ていく前に、まず、AWK プログラムの実行がど | ||
344 | 356 | END @{ print NR, words @} |
345 | 357 | @end example |
346 | 358 | |
347 | -処理するファイルを開く前にワードカウンターを 0 で初期化します。 | |
348 | -次にファイルを開き、それぞれの行に対して、フィールドの数 (ワードの数と等しい数) をその時のワードカウンターに足していきます。 | |
359 | +処理するファイルを開く前にワードカウンターを0で初期化します。 | |
360 | +次に、ファイルを開き、各行ごとに、フィールドの数(ワードの数と等しい数)をその時のワードカウンターに足していきます。 | |
349 | 361 | 入力ファイルの全行を読み終われば、ワードカウンターの結果の値をファイルの行数とともに表示します。 |
350 | 362 | |
351 | -上記の行を @file{wc.awk} と名付けたファイルに格納して、それを次のように起動してください。 | |
363 | +@file{wc.awk}と名付けたファイルに上記の内容を格納して、そのファイルを次のように起動してください。 | |
352 | 364 | @example |
353 | 365 | gawk -f wc.awk datafile.xml |
354 | 366 | @end example |
355 | -このような起動の仕方はすべてのプラットフォームで使えるでしょう。 | |
356 | -Unix 環境 (あるいは Microsoft Windows 上の Cygwin Unix エミュレーション) では、上のスクリプトを実行ファイルにしてしまうのがもっと快適です。 | |
357 | -そうするには、@file{wc.awk} という名前のファイルを書いて、そのファイルの最初の行が | |
367 | +このような起動方法は、全てのプラットフォームで使えるでしょう。 | |
368 | +Unix環境(あるいは、Microsoft Windows上のCygwin Unixエミュレーション)では、上のスクリプトを実行ファイルにしてしまうとさらに快適になります。 | |
369 | +@file{wc.awk}という名前のファイルを記述する際、最初の行が | |
358 | 370 | @example |
359 | 371 | #!/usr/bin/gawk -f |
360 | 372 | @end example |
361 | 373 | となるようにし、前述のスクリプトの内容がそれに続くようにしてください。 |
362 | -次に、@file{wc.awk} ファイルを実行可能にするために次のようにしてください。 | |
374 | +次に、以下のようにして、@file{wc.awk}ファイルを実行可能にしてください。 | |
363 | 375 | @example |
364 | 376 | chmod a+x wc.awk |
365 | 377 | @end example |
366 | -そして次のように起動してください。 | |
378 | +そして、次のように起動してください。 | |
367 | 379 | @example |
368 | 380 | wc.awk datafile.xml |
369 | 381 | @end example |
370 | 382 | |
371 | -@ref{fig:awk_proc} を上から下へと見てもらうと、データファイルの各行がその図の横の列として表わされていることがわかると思います。 | |
372 | -各横の列の左側に @command{NR} (現在行の番号) と、右側にパターン (実行の条件) とそのアクションがあるのが見えます。 | |
373 | -最初と最後の列は、@command{BEGIN} (初期化) と @command{END} (終了処理) を表わしています。 | |
383 | +fig:awk_proc(@pxref{fig:awk_proc})を上から下へと見てもらうと、データファイルの各行がその図の横の列として表わされていることが分かると思います。 | |
384 | +各行の左側に@command{NR}(その時点の行番号)、右側にパターン(実行の条件)とそのアクションがあるのが分かります。 | |
385 | +最初と最後の行は、@command{BEGIN}(初期化)と@command{END}(終了処理)を表わしています。 | |
374 | 386 | |
375 | 387 | @float Figure,fig:awk_proc |
376 | -@image{awk_proc,,,上から下へと進行する、ASCII データでの AWK プログラムの実行モデル,} | |
377 | -@caption{上から下へと進行する、ASCII データでの AWK プログラムの実行モデル} | |
388 | +@image{awk_proc,,,上から下へと進行する、ASCIIデータでのAWKプログラムの実行モデル,} | |
389 | +@caption{上から下へと進行する、ASCIIデータでのAWKプログラムの実行モデル} | |
378 | 390 | @end float |
379 | 391 | |
380 | -このスクリプトを使えば、どのような XML ファイルも処理できるのでしょう。 | |
392 | +このスクリプトを使えば、どのようなXMLファイルも処理できるでしょう。 | |
381 | 393 | しかし、それによって得られる結果は私たちにとってあまり意味あるものではないでしょう。 |
382 | -XML ファイルを処理するのに、行数やワード数にはまったく興味はありません。 | |
383 | -例えば次の XML ファイル、正確に言うと @uref{http://xml.web.cern.ch/XML/goossens/dbatcern/doc-structure.html#exa.dbgeneral, DocBook file} を見てください。 | |
394 | +XMLファイルを処理する場合、行数やワード数にはまったく関心はありません。 | |
395 | +例えば、次のXMLファイル、正確に言うと、@uref{http://xml.web.cern.ch/XML/goossens/dbatcern/doc-structure.html#exa.dbgeneral, DocBook file}を見てください。 | |
384 | 396 | @cindex DocBook |
385 | 397 | |
386 | 398 | @float Figure,fig:dbfile |
@@ -416,37 +428,38 @@ XML ファイルを処理するのに、行数やワード数にはまったく | ||
416 | 428 | </chapter> |
417 | 429 | </book> |
418 | 430 | @end example |
419 | -@caption{ある XML データの例 (DocBook ファイル)} | |
431 | +@caption{あるXMLデータの例(DocBookファイル)} | |
420 | 432 | @end float |
421 | 433 | |
422 | -この山括弧のジャングルを通して読めば、行という概念が、あなたが見ているものを説明するのに相応しい概念ではないということがわかるでしょう。 | |
423 | -AWK の@emph{レコード} と @emph{フィールド} の考え方は、横の列と縦の列の中に収まったテキストデータの四角い世界でしか意味を成しません。 | |
424 | -この概念では、@command{<title>}Introduction</title> のように前後を山括弧でそういうものとしてマークアップされたブロックで構造化されたテキストデータという XML の概念を理解することができません。 | |
425 | -その上、XML のマークアップブロックは他のブロックを内に含むことがあります (@code{title} と @code{para} を含む @code{chapter} のようなものです)。 | |
426 | -XML はテキストデータを、深くネストしたノード (マークアップブロック) でできた木構造としてとらえます。 | |
427 | -木構造はダイナミックなデータ構造です。 | |
428 | -木構造は他の木構造を含み、またその木構造がさらに他の木構造を含むこともあるので、木構造のことを@emph{リカーシブ} 構造と呼ぶ人もいます。 | |
429 | -@cindex リカーシブ | |
430 | -このような下位の木構造というのは行や列のように番号が付けらているわけではありませんが、名前を持っています。 | |
431 | -XML ファイルの構造について大まかに理解できたと思うので、その状況を描くのに十分な方法を選択することができます。 | |
432 | -XML データは木構造を持っていますので、上の @ref{fig:dbfile} にあるファイル例を木構造 (@pxref{fig:docbook_chapter}) として描いてみましょう。 | |
434 | +この山括弧のジャングルを通して読めば、行という概念が、あなたが見ているものを説明するのに相応しい概念ではないということが分かるでしょう。 | |
435 | +AWKにおける@emph{レコード}と@emph{フィールド}の考え方は、行と列の中に収まったテキストデータの四角い世界でしか意味を成しません。 | |
436 | +この概念では、@command{<title>}Introduction</title>のように、それ自体山括弧で前後をマークアップされたブロックで構造化されたテキストデータというXMLの概念を理解することができません。 | |
437 | +その上、XMLのマークアップブロックは他のブロックを内に含むことがあります(@code{title}と@code{para}を含む@code{chapter}のなど)。 | |
438 | +XMLでは、深くネストしたノード(マークアップブロック)でできた木構造としてテキストデータを捉えます。 | |
439 | +木構造は、ダイナミックなデータ構造です。 | |
440 | +木構造は、他の木構造を含み、また、その木構造が他の木構造をさらに含むこともあるので、木構造のことを@emph{リカーシブ}構造と呼ぶ人もいます。 | |
441 | +@cindex recursion | |
442 | +このような下位の木構造というのは、行や列のように番号が付けられているわけではありませんが、名前を持っています。 | |
443 | +XMLファイルの構造について大まかに理解できたと思うので、その状況を描くのに十分な方法を選択することができます。 | |
444 | +XMLデータは木構造を持っていますので、上のfig:dbfile(@pxref{fig:dbfile})にあるファイル例を木構造(@pxref{fig:docbook_chapter})として描いてみましょう。 | |
433 | 445 | |
434 | 446 | @float Figure,fig:docbook_chapter |
435 | -@image{docbook_chapter,,,木構造として XML データ (DocBook ファイル),} | |
436 | -@caption{木構造として XML データ (DocBook ファイル)} | |
447 | +@image{docbook_chapter,,,木構造としてXMLデータ(DocBookファイル),} | |
448 | +@caption{木構造としてXMLデータ(DocBookファイル)} | |
437 | 449 | @end float |
438 | 450 | |
439 | -それぞれのマークアップされたブロックがこの木構造の中でノードとして描かれているのがすぐにわかると思います。 | |
440 | -木構造のエッジ (ノードとノードを結ぶ線) は、テキストで表現するよりももっとわかりやすく、マークアップされたブロックがネスティングしているということを明らかにしています。 | |
451 | +マークアップされたブロックが、この木構造の中でノードとしてそれぞれ描かれているのがすぐに分かると思います。 | |
452 | +木構造のエッジ(ノードとノードを結ぶ線)は、テキストで表現するよりももっと分かりやすく、マークアップされたブロックがネスティングしているということを明らかにしています。 | |
441 | 453 | エッジはそれぞれ、矢印が向いている方向にあるマークアップされたブロックが矢印がやってきた元のマークアップブロックに含まれているということを示しています。 |
442 | -このようなエッジは @emph{"parent-child"} 関係を表わしています。 | |
454 | +このようなエッジは@emph{"parent-child"}関係を表わしています。 | |
455 | + | |
443 | 456 | |
444 | 457 | @node How to traverse the tree with gawk, Looking closer at the XML file, How does XML fit into AWK's execution model ?, AWK and XML Concepts |
445 | -@section gawk で木構造をトラバースする方法 | |
458 | +@section gawkで木構造をトラバースする方法 | |
446 | 459 | |
447 | -さて、マークアップされたこういった木構造を扱う際、@command{wc} コマンドと同等なものとはどのようなものでしょうか。 | |
460 | +さて、マークアップされたこういった木構造を扱う際、@command{wc}コマンドと同等なものとはどのようなものでしょうか。 | |
448 | 461 | 木構造のノードの数を数えることはできるでしょう。 |
449 | -前述のスクリプトで行ったのと同じように次のスクリプトをファイルに保存して起動してみてください。 | |
462 | +前述のスクリプトで行ったのと同じように、次のスクリプトをファイルに保存して起動してみてください。 | |
450 | 463 | |
451 | 464 | @pindex @file{node_count.awk} |
452 | 465 | @cindex @code{XMLSTARTELEM} |
@@ -456,47 +469,52 @@ XMLSTARTELEM @{ nodes ++ @} | ||
456 | 469 | END @{ print nodes @} |
457 | 470 | @end example |
458 | 471 | |
459 | -このスクリプトを @ref{fig:dbfile} のデータファイルで起動すると、すぐにノードの数が表示されます。 | |
472 | +fig:dbfile(@pxref{fig:dbfile})のデータファイルに対してこのスクリプトを起動すると、ノードの数がすぐ表示されます。 | |
460 | 473 | @page |
461 | 474 | @example |
462 | 475 | gawk -l xml -f node_count.awk dbfile.xml |
463 | 476 | 12 |
464 | 477 | @end example |
465 | 478 | |
466 | -この例のスクリプトと、ワードを数える元の @file{wc.awk} の似ている部分に注意してください。 | |
479 | +この例におけるスクリプトと、ワードを数える元の@file{wc.awk}の似ている部分に注意してください。 | |
467 | 480 | 全行を舐めていく代わりに、このスクリプトはツリーをトラバースし、ノードが見つかるたびにノードカウンターをインクリメントします。 |
468 | -もう少しよく見ると、前のスクリプトとこのスクリプトの違いがいくつかわかってくるでしょう。 | |
481 | +もう少しよく見ると、前のスクリプトとこのスクリプトの違いがいくつか分かってくるでしょう。 | |
469 | 482 | |
470 | 483 | @enumerate |
471 | 484 | @item |
472 | -@command{gawk} のコマンドラインのところに、@code{-l xml} というパラメータが追加されています。 | |
473 | -これは、@command{gawk} インタプリタに XML 拡張をロードするのに必要で、これにより、オープンするファイルが XML ファイルで、異なった扱いをしなければならないということを @command{gawk} インタプリタに知らせます。 | |
485 | +@command{gawk}のコマンドラインのところに、@code{-l xml}というパラメータが追加されています。 | |
486 | +これは、@command{gawk}インタプリタにXML拡張をロードするのに必要なものです。 | |
487 | +これにより、オープンするファイルがXMLファイルであって、異なった扱いをしなければならないということを@command{gawk}インタプリタに知らせます。 | |
488 | + | |
474 | 489 | @item |
475 | 490 | パターンが関連付けられているアクションの中でノードカウンタがカウントされます。 |
476 | 491 | @emph{全ての}行でカウントしていた前のスクリプトと異なり、ノードを数えることにだけ関心があります。 |
477 | -ノードの出現 (マークアップされたブロックの始まり) は @code{XMLSTARTELEM} パターンで示されています。 | |
492 | +ノードの出現(マークアップされたブロックの始まり)は@code{XMLSTARTELEM}パターンで示されています。 | |
493 | + | |
478 | 494 | @item |
479 | -ここではワードをカウントするのと同等のものはありません。 | |
480 | -ノードをカウントすることだけです。 | |
495 | +この場合、ワードをカウントするのと同等のものはありません。 | |
496 | +ノードのカウントだけです。 | |
497 | + | |
481 | 498 | @item |
482 | 499 | トラバースされるツリーのノードの出現順というのは明確ではありません。 |
483 | -@code{bookinfo} ノードと @code{chapter} ノードはどちらも @code{book} の直下に位置していますが、どちらが先に数えられるでしょう? | |
484 | -木構造のテキスト表現に立ち戻ればその答えはわかります。 | |
500 | +@code{bookinfo}ノードと@code{chapter}ノードは、どちらも、@code{book}の直下に位置しています。 | |
501 | +どちらが先に数えられるでしょう。 | |
502 | +木構造のテキスト表現に立ち戻れば、その答えは分かります。 | |
485 | 503 | テキストでの順序がツリーをトラバースする順序に影響するのです。 |
486 | 504 | @end enumerate |
487 | 505 | |
488 | -矢印の先の近くに数字が見えるでしょうか? | |
489 | -これらは、トラバースの順序を示しています。 | |
490 | -番号の 1 番がありませんが、ルートノード (太枠) を最初に辿ることは明らかだからです。 | |
491 | -コンピュータサイエンスの専門家は、この順番で辿ることを @uref{http://en.wikipedia.org/wiki/Depth-first, @dfn{depth-first}} と呼びます。 | |
492 | -各ノードについて、同じレベルにあるノードへ行く前に、先にその子ノード (深いノード) を辿るからです。 | |
493 | -他のトラバースの順序に (@uref{http://en.wikipedia.org/wiki/Breadth-first_search, @dfn{breadth-first}}) というのもありますが、@ref{fig:dbfile} のテキストの順序というのが @ref{fig:docbook_chapter} での数字が付けられた順序を強制します。 | |
506 | +矢印の先の近くに数字が見えるでしょうか。 | |
507 | +これは、トラバースの順序を示しています。 | |
508 | +番号の1番がありませんが、ルートノード(太枠)を最初に辿ることは明らかだからです。 | |
509 | +コンピュータサイエンスの専門家は、この順番で辿ることを@uref{http://en.wikipedia.org/wiki/Depth-first, @dfn{depth-first}}と呼びます。 | |
510 | +各ノードについて、同じレベルにあるノードへ行く前に、その子ノード(深いノード)を先に辿るからです。 | |
511 | +トラバースの順序には、他に、(@uref{http://en.wikipedia.org/wiki/Breadth-first_search, @dfn{breadth-first}})というのもありますが、fig:dbfile(@pxref{fig:dbfile})のテキストの順序というのがfig:docbook_chapter(@pxref{fig:docbook_chapter})での数字が付けられた順序を強制します。 | |
494 | 512 | |
495 | -@ref{fig:docbook_chapter} のツリーは平衡ではありません。 | |
496 | -一番最後のノードの部分が深くネストされていて、@ref{fig:docbook_chapter} のかなり右のマージンの部分に表示されています。 | |
513 | +fig:docbook_chapter(@pxref{fig:docbook_chapter})のツリーは平衡ではありません。 | |
514 | +一番最後のノードの部分が深くネストされていて、fig:docbook_chapter(@pxref{fig:docbook_chapter})のかなり右のマージン部分に表示されています。 | |
497 | 515 | 図の上の方の部分はそうではありません。 |
498 | -このようなツリーの最大の深さを知ると便利なことが時々あります。 | |
499 | -次のスクリプトは全てのノードを辿り、そのノードの深さとそこまでの最大の深さを比較し、最も深い深さを見つけて記録するものです。 | |
516 | +このようなツリーの最大の深さが分かると便利なことがあります。 | |
517 | +次のスクリプトは、全てのノードを辿り、そのノードの深さとそこまでの最大の深さを比較し、最も深い所を見つけて記録するものです。 | |
500 | 518 | |
501 | 519 | @pindex @file{max_depth.awk} |
502 | 520 | @cindex @code{XMLENDELEM} |
@@ -511,113 +529,132 @@ XMLSTARTELEM @{ | ||
511 | 529 | XMLENDELEM @{ depth-- @} |
512 | 530 | END @{ print max_depth @} |
513 | 531 | @end example |
514 | -@caption{@file{max_depth.awk} スクリプトを使った XML ファイルのツリー表記の最大深さの探索} | |
532 | +@caption{@file{max_depth.awk}スクリプトを使ったXMLファイルのツリー表記の最大深さの探索} | |
515 | 533 | @end float |
516 | 534 | |
517 | 535 | このスクリプトを前のものと比較すると、いくつかの微妙な違いにまた気が付くと思います。 |
518 | 536 | |
519 | 537 | @enumerate |
520 | 538 | @item |
521 | -@command{@@load xml} というのは、コマンドライン上の @code{-l xml} の代わりです。 | |
522 | -スクリプトのテキストが実行ファイルに格納されているのであれば、全ての拡張をインタプリタにロードした状態でスクリプトを実行すべきです。 | |
523 | -コマンドラインオプションの @code{-l xml} は、ワンラインのコマンドラインの作業をしているときにだけ略記法として使われるべきでしょう。 | |
539 | +@command{@@load xml}というのは、コマンドライン上の@code{-l xml}の代わりです。 | |
540 | +スクリプトのテキストが実行ファイルに格納されているのであれば、インタプリタに拡張を全てロードした状態でスクリプトを実行すべきです。 | |
541 | +コマンドラインオプションの@code{-l xml}は、ワンラインのコマンドラインの作業をしている時にだけ略記法として使われるべきでしょう。 | |
542 | + | |
524 | 543 | @item |
525 | -変数の @command{depth} は初期化されていません。 | |
526 | -@command{gawk} の変数は、前もって初期化しなくても、最初に使用されるときには 0 という値を持っていますので必要ないのです。 | |
544 | +変数の@command{depth}は初期化されていません。 | |
545 | +@command{gawk}の変数は、前もって初期化しなくても、最初に使用される時には0という値を持っていますので初期化は必要ありません。 | |
546 | + | |
527 | 547 | @item |
528 | -最も重要な違いは、@code{XMLENDELEM} という新しく出てきたパターンです。 | |
529 | -これは @code{XMLSTARTELEM} と対になるパターンです。 | |
530 | -片方はノードに入ったときに true となり、他方はノードから離れるときに true となります。 | |
531 | -テキスト表現では、こららのパターンはマークアップされたブロックの最初と最後の部分を示しています。 | |
532 | -スクリプトがマークアップされたブロックに差し掛かるたび @code{depth} カウンタが増やされ、マークアップされたブロックを離れるたび @code{depth} カウンタが減らされます。 | |
548 | +最も重要な違いは、@code{XMLENDELEM}という新しく出てきたパターンです。 | |
549 | +これは、@code{XMLSTARTELEM}と対になるパターンです。 | |
550 | +一つは、ノードに入った時にtrueとなるもので、もう一つは、ノードから離れる時にtrueとなります。 | |
551 | +テキスト表現において、これらのパターンは、マークアップされたブロックの最初と最後の部分を示しています。 | |
552 | +マークアップされたブロックにスクリプトが差し掛かるたび、@code{depth}カウンタが増やされ、マークアップされたブロックを離れるたび@code{depth}カウンタが減らされます。 | |
533 | 553 | @end enumerate |
534 | 554 | |
535 | -@command{XMLDEPTH} という、その時点でのマークアップされたブロックのネストしている深さを保持している組み込み変数を使えば、このスクリプトはもっと短く書けるということを後で学びます。 | |
536 | -この変数を使えば、@ref{fig:max_depth.awk} スクリプトは @command{gawk} での典型的な日常作業に使われるワンライナーの一つとなります。 | |
555 | +@command{XMLDEPTH}という、マークアップされたブロックのその時点でのネストしている深さを保持している組み込み変数を使えば、このスクリプトはもっと短く書けるということを後で学びます。 | |
556 | +この変数を使えば、fig:max_depth.awk(@pxref{fig:max_depth.awk})スクリプトは@command{gawk}での典型的な日常作業に使われるワンライナーの一つとなります。 | |
557 | + | |
537 | 558 | |
538 | 559 | @node Looking closer at the XML file |
539 | -@section XML ファイルを詳しく見る | |
560 | +@section XMLファイルを詳しく見る | |
540 | 561 | |
541 | -XML の基本的な用語について既にご存知であれば、この @value{SECTION} をスキップして、次の @value{CHAPTER} へと進んでも構いません。 | |
542 | -そうでなければ、O'Reilly の本 @uref{http://www.oreilly.com/catalog/xmlnut3/, XML in a Nutshell} の学習をお勧めします。 | |
543 | -この本はチュートリアルとリファレンスがうまく組み合わされています。 | |
544 | -基本的な用語については第 2 章 (XML Fundamentals) に書かれています。 | |
545 | -(フリーの) オンラインチュートリアルが良ければ、 @uref{http://www.w3schools.com/xml/default.asp, w3schools} を推薦します。 | |
546 | -その他の価値ある資料は、@xref{インターネットへのリンク}。 | |
562 | +XMLの基本的な用語について既にご存知であれば、この@value{SECTION}をスキップして、次の@value{CHAPTER}へと進んでも構いません。 | |
563 | +そうでなければ、O'Reillyの本@uref{http://www.oreilly.com/catalog/xmlnut3/, XML in a Nutshell}の学習をお勧めします。 | |
564 | +この本は、チュートリアルとリファレンスがうまく組み合わされています。 | |
565 | +基本的な用語については第2章(XML Fundamentals)に書かれています。 | |
566 | +(フリーの)オンラインチュートリアルが良ければ、@uref{http://www.w3schools.com/xml/default.asp, w3schools}を推薦します。 | |
567 | +その他の価値ある資料は別の節を参照してください(@pxref{Links to the Internet})。 | |
547 | 568 | |
548 | 569 | 先を読み進める前に、次にあげる用語の意味が理解できるか確認したほうがよいでしょう。 |
549 | -あなたをこれらの用語の自習をさせたままにしないで、各用語の、厳密ではない、しかも不十分な説明をしていきたいと思います。 | |
550 | -例としては @ref{fig:dbfile} を常に参照してください。 | |
570 | +これらの用語の自習をさせたままにはしません。 | |
571 | +厳密ではないですし、しかも、不十分ではありますが、各用語を説明していきたいと思います。 | |
572 | +例としては、fig:dbfile(@pxref{fig:dbfile})を常に参照してください。 | |
551 | 573 | そして、上のソースの中でその用語を探すことを考えてください。 |
552 | 574 | |
553 | 575 | @itemize |
554 | 576 | @item タグ: ノードの名前 |
555 | -@cindex タグ | |
556 | -@item アトリビュート: 名前 (@code{lang}) と 値 (@code{en}) を持つ変数 | |
557 | -@cindex アトリビュート | |
558 | -@item エレメント: サブツリー、たとえば、@code{title} を含んだ @code{bookinfo} | |
559 | -@cindex エレメント | |
560 | -@item 整形式: 正しくネストしたファイル; 引用符が付けられ、タグとして明快にアトリビュートが付けられた一つのツリー | |
561 | -@cindex 整形式 | |
562 | -@item DTD: ファイルが含むエレメントとアトリビュートについて形式に従って記述したもの | |
577 | +@cindex Tag | |
578 | + | |
579 | +@item アトリビュート: 名前(@code{lang})と値(@code{en})を持つ変数 | |
580 | +@cindex Attribute | |
581 | + | |
582 | +@item エレメント: サブツリー、例えば、@code{title}を含んだ@code{bookinfo} | |
583 | +@cindex Element | |
584 | + | |
585 | +@item 整形式: 正しくネストしたファイル;引用符が付けられ、タグとして明快にアトリビュートが付けられた一つのツリー | |
586 | +@cindex Well-Formed | |
587 | + | |
588 | +@item DTD: ファイルが含むエレメントとアトリビュートについての正式仕様 | |
563 | 589 | @cindex DTD, Document Type Definition |
564 | -@item スキーマ: DTD と同様に使うが、DTD よりも詳細で、DTD と違い、形式としてはそれ自身も XML である | |
565 | -@cindex スキーマ | |
566 | -@item 妥当: 通常 DTD やスキーマとして与えられる形式仕様に従っていること | |
567 | -@cindex 妥当 | |
568 | -@item プロセッシングインストラクション: ねじ留めされた特別な目的のためのエレメント、"?" という名前を持つ、しばしば最初のデータ行である | |
569 | -@cindex プロセッシングインストラクション | |
590 | + | |
591 | +@item スキーマ: DTDと同様に使用するが、DTDよりも詳細で、DTDと違い、形式としてはそれ自身もXMLである | |
592 | +@cindex Schema | |
593 | + | |
594 | +@item 妥当: DTDやスキーマとして通常指定される形式仕様に従っていること | |
595 | +@cindex Valid | |
596 | + | |
597 | +@item プロセッシングインストラクション: ねじ留めされた特別な目的のためのエレメント、"?"という名前を持つ、しばしば最初のデータ行である | |
598 | +@cindex Processing Instruction | |
599 | + | |
570 | 600 | @example |
571 | 601 | <?xml version="1.0" encoding="ISO-8859-1"?> |
572 | 602 | @end example |
603 | + | |
573 | 604 | @item キャラクタデータ: タグの間にあるエレメント内部のテキストデータ |
574 | -@cindex キャラクタデータ | |
605 | +@cindex Character Data | |
606 | + | |
575 | 607 | @item Mixed Content: 内部にキャラクタデータを持つエレメント |
576 | 608 | @cindex Mixed Content |
577 | -@item エンコーディング: テキストのシンボルとバイト列の間のマッピングの名前 (ISO-8859-1) | |
578 | -@cindex 文字エンコーディング | |
579 | -@item UTF-8: XML のデフォルトのエンコーディング、利用可能な全てのテキストシンボルをカバーする、マルチバイトの場合も | |
609 | + | |
610 | +@item エンコーディング: テキストのシンボルとバイト列の間のマッピングの名前(ISO-8859-1) | |
611 | +@cindex character encoding | |
612 | + | |
613 | +@item UTF-8: XMLのデフォルトのエンコーディング、利用可能な全てのテキストシンボルをカバーする、マルチバイトの場合も | |
580 | 614 | @cindex @code{UTF-8} |
581 | 615 | @end itemize |
582 | 616 | |
583 | -まだ読んでますか? | |
584 | -これらの定義は厳密には正しくないことに注意。 | |
585 | -それらはあなたがいい線を行くことができるように意図しています。 | |
586 | -やる気のあるプロペラヘッドならばそれぞれ、これらの定義を喜んでけちょんけちょんにしてくれるでしょう。 | |
587 | -もしあなたが XML のプロペラヘッドになるために真剣に努力しているのであれば、@uref{http://www.w3.org/TR/2004/REC-xml-20040204/, XML technology} に関するオリジナルの定義ドキュメントを読み忘れるべきではありません。 | |
617 | +まだ読んでますか。 | |
618 | +これらの定義は厳密には正しくないことに注意してください。 | |
619 | +上手くあなたが軌道に乗れるように考えたものです。 | |
620 | +やる気のあるプロペラヘッドならば、それぞれ、これらの定義を喜んでけちょんけちょんにしてくれるでしょう。 | |
621 | +もし、XMLのプロペラヘッドになるためにあなたが真剣に努力しているのであれば、@uref{http://www.w3.org/TR/2004/REC-xml-20040204/, XML technology}に関するオリジナルの定義ドキュメントを読み忘れるべきではありません。 | |
588 | 622 | @cindex XML technology |
589 | -不安を持つ有志に相応わしいプレイグラウンドは、ニューズグループの @uref{news://comp.text.xml, comp.text.xml} です。 | |
590 | -@cindex comp.text.xml, インターネット上のニューズグループ | |
591 | -そのようなプロペラヘッドたちが誰も @code{gawk} の @value{DOCUMENT} を読んでないならば私はうれしいです --- 彼らは私を殺すでしょう。 | |
623 | +不安を持つ有志に相応わしいプレイグラウンドは、ニューズグループの@uref{news://comp.text.xml, comp.text.xml}です。 | |
624 | +@cindex comp.text.xml, newsgroup on the Internet | |
625 | +そのようなプロペラヘッドたちが誰も@code{gawk}の@value{DOCUMENT}を読んでないならば私はうれしいです --- 彼らは私を殺すでしょう。 | |
626 | + | |
592 | 627 | |
593 | 628 | @node Reading XML Data with POSIX AWK |
594 | -@chapter POSIX AWK での XML データの読み込み | |
629 | +@chapter POSIX AWKでのXMLデータの読み込み | |
595 | 630 | |
596 | 631 | @menu |
597 | -* Steve Coile の xmlparse.awk スクリプト:: | |
598 | -* Jan Weber の getXML スクリプト:: | |
599 | -* XMLgawk のポータブルサブセット:: | |
632 | +* Steve Coile's xmlparse.awk script:: | |
633 | +* Jan Weber's getXML script:: | |
634 | +* A portable subset of XMLgawk:: | |
600 | 635 | @end menu |
601 | 636 | |
602 | -初めに述べた新しい言語機能を使うこと避けようとするユーザもいるでしょう。 | |
603 | -そういった人たちはポータブルなスクリプトが書きたいのです。 | |
604 | -彼らは標準化されている @uref{http://www.opengroup.org/onlinepubs/000095399/utilities/awk.html, POSIX AWK} に含まれない機能を使うのを我慢しなければなりません。 | |
637 | +ここまでに述べた新しい言語機能を使うことを避けようとするユーザもいるでしょう。 | |
638 | +そういった人たちは、可搬性のあるスクリプトが書きたいのです。 | |
639 | +彼らは、標準化されている@uref{http://www.opengroup.org/onlinepubs/000095399/utilities/awk.html, POSIX AWK}に含まれない機能を使うのを我慢しなければなりません。 | |
605 | 640 | @cindex POSIX |
606 | -GNU Awk の XML 拡張は POSIX 標準に含まれていませんので、こういったユーザは XML データを読むのに別の方法を探さなければなりません。 | |
641 | +GNU AwkのXML拡張はPOSIX標準に含まれていませんので、こういったユーザは、XMLデータを読むのに別の方法を探さなければなりません。 | |
642 | + | |
607 | 643 | |
608 | 644 | @node Steve Coile's xmlparse.awk script |
609 | -@section Steve Coile の xmlparse.awk スクリプト | |
610 | -POSIX AWK で完全な XML リーダを実装するということは、Unicode エンコーディングの微妙な細かい部分を取り扱わなければならないということを意味しています。 | |
645 | +@section Steve Coileのxmlparse.awkスクリプト | |
646 | + | |
647 | +POSIX AWKで完全なXMLリーダを実装するということは、Unicodeエンコーディングの微妙な細かい部分を処理しなければならないということを意味しています。 | |
611 | 648 | @cindex Unicode |
612 | 649 | @pindex @file{xmlparse.awk} |
613 | -AWK スクリプトでそのような細部に入って行くことは理にかなっていません。 | |
614 | -しかし、2001 年、Steve Coile は、ASCII 文字で、シンプルなタグ付けされたブロックからなるXML データであれば十分処理できるパーサを書きました。 | |
615 | -彼のスクリプトは @uref{ftp://ftp.freefriends.org/arnold/Awkstuff/xmlparser.awk, @code{xmlparse.awk}} としてインターネット上で利用できます。 | |
616 | -@code{xmlparse.awk} のソースコードはドキュメントが十分で、インターネットにアクセスできる人ならすぐに使えます。 | |
617 | - | |
618 | -@code{xmlparse.awk} をダウンロードして、その探検を開始しましょう。 | |
619 | -このパーサで作業を始める前に、2007 年夏の時点で、ファイルに修正しなければならないタイポがあります。 | |
620 | -342 行目のコメントの前にハッシュマーク文字 (@code{#}) を入れてください。 | |
650 | +AWKスクリプトでそのような細部に入って行くことは理にかなっていません。 | |
651 | +しかし、2001年、Steve Coileは、シンプルにタグ付けされたブロックからなるASCII文字のXMLデータであれば十分処理できるパーサを書きました。 | |
652 | +彼のスクリプトは、@uref{ftp://ftp.freefriends.org/arnold/Awkstuff/xmlparser.awk, @code{xmlparse.awk}}としてインターネット上から取得可能です。 | |
653 | +@code{xmlparse.awk}のソースコードでは説明が十分なされており、インターネットにアクセスできる人ならすぐに使えます。 | |
654 | + | |
655 | +@code{xmlparse.awk}をダウンロードして、探検を開始しましょう。 | |
656 | +このパーサで作業を始める前に、2007年夏の時点では、修正しなければならないタイポがファイルにあります。 | |
657 | +342行目のコメントの前にハッシュマーク文字(@code{#})を入れてください。 | |
621 | 658 | @example |
622 | 659 | wget ftp://ftp.freefriends.org/arnold/Awkstuff/xmlparser.awk |
623 | 660 | vi xmlparser.awk |
@@ -627,22 +664,23 @@ AWK スクリプトでそのような細部に入って行くことは理にか | ||
627 | 664 | :wq |
628 | 665 | @end example |
629 | 666 | |
630 | -パーサスクリプトを編集しながら、そのコメントを少し見てください。 | |
631 | -これはドキュメントがよく書かれているスクリプトで、いくつかの使用事例に加えてその実装についても説明がされています。 | |
632 | -例えば、そのヘッダにはユーザが知っておく必要があるであろう詳細についてほとんど全てまとめられています (@pxref{fig:ch2_xmlparser_header})。 | |
633 | -そのヘッダにはささいな矛盾もあります。 | |
634 | -ファイルが、ヘッダに書いてある @code{xmlparse.awk} では無く、実際には @code{xmlparser.awk} と名付けられていますね。 | |
635 | -ユーザの視点から心に留めておくべき最も重要な制限は、この XML パーサが AWK の@emph{モダンな}バリアントを必要とすることです。 | |
636 | -これは POSIX 準拠の AWK を意味します。 | |
637 | -古い Solaris 実装の @code{oawk} は、この XML パーサスクリプトを意図した通りに実行することができないでしょう。 | |
638 | -XML パーサを次のように初起動してください。 | |
667 | +このパーサスクリプトを編集しながら、書かれているコメントを少し見てください。 | |
668 | +これは、ドキュメントがよく書かれているスクリプトです。 | |
669 | +使用事例に加えて、その実装についても説明がされています。 | |
670 | +例えば、ヘッダには、ユーザが知っておく必要があるであろう詳細についてほとんど全てまとめられています(@pxref{fig:ch2_xmlparser_header})。 | |
671 | +ヘッダには、取るに足らないことですが、間違ったことも書いてあります。 | |
672 | +ファイルが、ヘッダに書いてある@code{xmlparse.awk}では無く、実際には、@code{xmlparser.awk}と名付けられていますね。 | |
673 | +ユーザ視点から留意すべき最も重要な制限は、このXMLパーサがAWKの@emph{モダンな}バリアントを必要とすることです。 | |
674 | +つまり、POSIX準拠のAWKを意味しています。 | |
675 | +古いSolaris実装の@code{oawk}は、このXMLパーサスクリプトを意図した通りに実行することができないでしょう。 | |
676 | +最初に、XMLパーサを次のように起動してください。 | |
639 | 677 | |
640 | 678 | @example |
641 | 679 | awk -f xmlparser.awk docbook_chapter.xml |
642 | 680 | @end example |
643 | 681 | |
644 | -出力されたものと、元のファイルの内容 (@pxref{fig:dbfile}) と木構造としての描写 (@pxref{fig:docbook_chapter}) を比較してください。 | |
645 | -出力の最初のカラムには、順番にパースされた通りにアイテムの種類が常に出力されているのがわかるでしょう。 | |
682 | +この出力を、元のファイルの内容(@pxref{fig:dbfile})、あるいは、木構造としての描写(@pxref{fig:docbook_chapter})と比較してください。 | |
683 | +出力の最初のカラムには、順番にパースされた通りにアイテムの種類が常に出力されているのが分かるでしょう。 | |
646 | 684 | |
647 | 685 | @example |
648 | 686 | @b{pi} xml version="1.0" encoding="UTF-8" |
@@ -663,35 +701,46 @@ awk -f xmlparser.awk docbook_chapter.xml | ||
663 | 701 | @end example |
664 | 702 | |
665 | 703 | これは、パーサスクリプトのヘッダで説明されている処理原則と一致します。 |
666 | -注意が必要ですが、@ref{fig:ch2_xmlparser_header} の説明は不完全です。 | |
704 | +注意が必要ですが、fig:ch2_xmlparser_header(@pxref{fig:ch2_xmlparser_header})の説明は不完全です。 | |
667 | 705 | 詳細は以下に示します。 |
668 | 706 | |
669 | -このスクリプトは XML データをパースし、パースされたアイテムを二つの配列に格納します。 | |
707 | +このスクリプトはXMLデータをパースし、パースされたアイテムを二つの配列に格納します。 | |
708 | + | |
670 | 709 | @itemize |
671 | -@item @code{type[3]} はパースされた 3 番目の XML データアイテムの種類を示しています。 | |
672 | -これは次のうちのいずれかになります。 | |
710 | +@item @code{type[3]}は、パースされた3番目のXMLデータアイテムの種類を示しています。 | |
711 | +これは、次のうちのいずれかになります。 | |
712 | + | |
673 | 713 | @itemize |
674 | -@item @code{@b{"error"}}、不正なアイテムがパースされたかその他のエラーが発生したとき。 この場合、@code{item[3]} にはエラーメッセージのテキストが入っています。 | |
675 | -@item @code{@b{"begin"}}、開始タグがパースされたとき。 | |
676 | -@item @code{@b{"end"}}、終了タグがパースされたとき。 | |
677 | -@code{type[3]} が @code{"begin"} か @code{"end"} の場合は @code{item[3]} にはタグの名前が入っています。 | |
678 | -@item @code{@b{"attrib"}}、アトリビュートの名前がパースされたとき。 | |
679 | -@item @code{@b{"value"}}、アトリビュートの値がパースされたとき。 | |
680 | -@code{type[3]} が @code{"attrib"} か @code{"value"} の場合は @code{item[3]} にはアトリビュートの名前か値が入っています。 | |
681 | -@item @code{@b{"data"}}、開始タグと終了タグの間のデータがパースされたとき。 | |
682 | -@item @code{@b{"cdata"}}、 キャラクタデータがパースされたとき。 | |
683 | -@item @code{@b{"comment"}}、 コメントがパースされたとき。 | |
684 | -@item @code{@b{"pi"}}、プロセッシングインストラクションがパースされたとき。 | |
714 | +@item @code{@b{"error"}}、不正なアイテムがパースされたか、その他のエラーが発生した時。この場合、@code{item[3]}にはエラーメッセージのテキストが入っています。 | |
715 | + | |
716 | +@item @code{@b{"begin"}}、開始タグがパースされた時。 | |
717 | + | |
718 | +@item @code{@b{"end"}}、終了タグがパースされた時。 | |
719 | +@code{type[3]}が@code{"begin"}か@code{"end"}の場合は、@code{item[3]}にはタグの名前が入っています。 | |
720 | + | |
721 | +@item @code{@b{"attrib"}}、アトリビュートの名前がパースされた時。 | |
722 | + | |
723 | +@item @code{@b{"value"}}、アトリビュートの値がパースされた時。 | |
724 | +@code{type[3]}が@code{"attrib"}か@code{"value"}の場合は、@code{item[3]}には、アトリビュートの名前か値が入っています。 | |
725 | + | |
726 | +@item @code{@b{"data"}}、開始タグと終了タグの間のデータがパースされた時。 | |
727 | + | |
728 | +@item @code{@b{"cdata"}}、 キャラクタデータがパースされた時。 | |
729 | + | |
730 | +@item @code{@b{"comment"}}、 コメントがパースされた時。 | |
731 | + | |
732 | +@item @code{@b{"pi"}}、プロセッシングインストラクションがパースされた時。 | |
685 | 733 | @end itemize |
686 | -@item @code{item[3]} は、上記のアイテムリストで区別されているように、@code{type[3]} に応じたデータが入っています。 | |
734 | + | |
735 | +@item @code{item[3]}は、上記のアイテムリストで区別されているように、@code{type[3]}に応じたデータが入っています。 | |
687 | 736 | @end itemize |
688 | 737 | |
689 | -この @value{DOCUMENT} を読み進めていくうちに、この基本的な考え方が XMLgawk で行っていることと似ていることにあなたは気付くことでしょう。 | |
690 | -特に、@ref{XMLgawk コア言語インターフェイスの要約} に @emph{Style B - すべてのイベントで共有される、限定された変数の組} のように記述しているアプローチはよく関連しているように見えます。 | |
691 | -このスクリプトはそのままでは、モジュラービルディングブロックとなるようにデザインされていません。 | |
692 | -どのようなアプリケーションも @code{xmlparser.awk} ファイルを単にインクルードする@emph{のではなく}、それをテキストとしてコピーし、そのコピーを修正します。 | |
693 | -元のスクリプトをもう一度のぞいてみて、最後の @code{END} パターンのところをさらに詳しく見てください。 | |
694 | -@code{END} パターンの中に、便利なアプリケーションに関する提案がいくつかあるのがわかるでしょう。 | |
738 | +この@value{DOCUMENT}を読み進めていくうちに、基本的な考え方が、XMLgawkで行っていることと似ていること分かるでしょう。 | |
739 | +特に、別の節(@pxref{XMLgawk Core Language Interface Summary})で@emph{Style B - すべてのイベントで共有される、限定された変数の組}として説明しているアプローチは、よく関連しているように見えます。 | |
740 | +このスクリプトは、そのままでは、モジュラービルディングブロックとなるようにはデザインされていません。 | |
741 | +どのようなアプリケーションでも、@code{xmlparser.awk}ファイルを単にインクルードする@emph{のではなく}、テキストとしてコピーし、そのコピーを修正して使います。 | |
742 | +元のスクリプトをもう一度覗いてみて、最後の@code{END}パターンのところをさらに詳しく見てください。 | |
743 | +@code{END}パターンの中に、便利なアプリケーションに関する提案がいくつかあるのが分かるでしょう。 | |
695 | 744 | |
696 | 745 | @float Figure,fig:ch2_xmlparser_header |
697 | 746 | @example |
@@ -709,50 +758,51 @@ awk -f xmlparser.awk docbook_chapter.xml | ||
709 | 758 | # |
710 | 759 | # Description: |
711 | 760 | # |
712 | -# このスクリプトは AWK (のモダンなバリアント) のためのシンプルな | |
713 | -# XML パーサです。 | |
714 | -# XML 形式で入力すると、二つの配列 "type" と "item" に保存します。 | |
761 | +# このスクリプトは、AWK(のモダンなバリアント)のためのシンプルな | |
762 | +# XMLパーサです。 | |
763 | +# XML形式で入力すると、二つの配列"type"と"item"に保存します。 | |
715 | 764 | # |
716 | -# ここで使う "item" という用語は、タグやアトリビュート名、 | |
717 | -# アトリビュート値、データといった紛れもない XML エレメントを指します。 | |
765 | +# ここで使う"item"という用語は、タグやアトリビュート名、 | |
766 | +# アトリビュート値、データといった紛れもないXMLエレメントを指します。 | |
718 | 767 | # |
719 | 768 | # これらの配列のインデックスは、それぞれのアイテムに遭遇した順番に |
720 | 769 | # なっています。 |
721 | -# 例えば、3 番目のアイテムの種類は type[3] と記述し、その値は、item[3] | |
770 | +# 例えば、3番目のアイテムの種類はtype[3]と記述し、その値は、item[3] | |
722 | 771 | # と記述します。 |
723 | 772 | # |
724 | -# "type" 配列はそれぞれの順番で遭遇したアイテムの種類が入っています。 | |
725 | -# 種類は一つのワードで表記されます: "error" (不正なアイテムもしくは | |
726 | -# その他のエラー)、"begin" (開始タグ)、"attrib" (アトリビュート名)、 | |
727 | -# "value" (アトリビュート値)、"end" (終了タグ)、"data" (タグ間の | |
728 | -# データ)。 | |
773 | +# "type"配列は、それぞれの順番で遭遇したアイテムの種類が入っています。 | |
774 | +# 種類は、一つのワードで表記されます: "error"(不正なアイテムもしくは | |
775 | +# その他のエラー)、"begin"(開始タグ)、"attrib"(アトリビュート名)、 | |
776 | +# "value"(アトリビュート値)、"end"(終了タグ)、"data"(タグ間の | |
777 | +# データ)。 | |
729 | 778 | # |
730 | -# "item" 配列はそれぞれの順番で遭遇したアイテムの値が入っています。 | |
731 | -# "begin" あるいは "end" という種類では、アイテムの値はタグの名前です。 | |
732 | -# "error" の場合、その値はエラーメッセージのテキストです。 | |
733 | -# "attrib" ならば、値はアトリビュート名です。 | |
734 | -# "value" ならば、値はアトリビュート値です。 | |
735 | -# "data" の場合は、生のデータが値です。 | |
779 | +# "item"配列は、それぞれの順番で遭遇したアイテムの値が入っています。 | |
780 | +# "begin"、あるいは、"end"という種類では、アイテムの値はタグの名前です。 | |
781 | +# "error"の場合、その値は、エラーメッセージのテキストです。 | |
782 | +# "attrib"ならば、値は、アトリビュート名です。 | |
783 | +# "value"ならば、値は、アトリビュート値です。 | |
784 | +# "data"の場合は、生のデータが値です。 | |
736 | 785 | # |
737 | -# 警告: data やアトリビュート値の XML での引用形式の値 ("エンティティ") | |
786 | +# 警告: dataやアトリビュート値のXMLでの引用形式の値("エンティティ") | |
738 | 787 | # は、引用形式を元に戻していません。そのまま格納しています。 |
739 | 788 | # |
740 | 789 | ############################################################################### |
741 | 790 | @end example |
742 | -@caption{@code{xmlparser.awk} のヘッダで説明されている使い方} | |
791 | +@caption{@code{xmlparser.awk}のヘッダで説明されている使い方} | |
743 | 792 | @end float |
744 | 793 | |
745 | 794 | @page |
746 | 795 | @enumerate |
747 | -@item 次のようにエラーの発生を検査すれば、XML データが整形式であるかどうかをチェックするスクリプトがかなり簡単に実装できます。 | |
796 | +@item エラーの発生を次のように検査すれば、XMLデータが整形式であるかどうかをチェックするスクリプトがかなり簡単に実装できます。 | |
748 | 797 | @example |
749 | 798 | if (type[idx] == "error") @{ |
750 | 799 | ... |
751 | 800 | @} |
752 | 801 | @end example |
802 | + | |
753 | 803 | @item |
754 | -シェルスクリプトでもっと簡単にパースできる@emph{シンプル}な XML を導入する試みがいくつか行なわれてきました。 | |
755 | -XML の単純化と使いやすい行単位のフォーマットでの出力をするには、@code{END} パターンに次のコードフラグメントを入れることで実装することができます。 | |
804 | +シェルスクリプトでもっと簡単にパースできる@emph{シンプル}なXMLを導入する試みがいくつか行われてきました。 | |
805 | +XMLを単純化し、使いやすい行単位のフォーマットで出力をするには、@code{END}パターンに、次のコードフラグメントを入れることで実装することができます。 | |
756 | 806 | これは、パースしたアイテムを順番に全て通りぬけて、それぞれの種類を適切に処理する方法を示しています。 |
757 | 807 | @example |
758 | 808 | for ( n = 1; n <= idx; n += 1 ) @{ |
@@ -769,11 +819,12 @@ for ( n = 1; n <= idx; n += 1 ) @{ | ||
769 | 819 | @} |
770 | 820 | @} |
771 | 821 | @end example |
822 | + | |
772 | 823 | @item |
773 | -今述べたフレームワークを使ったアプリケーションの一つが、@ref{fig:ch2_outline.awk} のアプリケーションのようなアウトラインスクリプトです。 | |
774 | -@ref{fig:ch2_dbfile} にあるようなアウトライン出力を生成するのは、@code{xmlparser.awk} スクリプトを修正すれば AWK では数行で書ける問題です。 | |
775 | -これは、XML データが完全に読み込まれた後で行なわれるということに注意してください。 | |
776 | -ですので、処理できるデータの大きさに何らかの制限があるものの、処理の時点では、XML の完全なデータが AWK のメモリにとにかく保存されています。 | |
824 | +今述べたフレームワークを使ったアプリケーションの一つが、fig:ch2_outline.awk(@pxref{fig:ch2_outline.awk})のアプリケーションのようなアウトラインスクリプトです。 | |
825 | +fig:ch2_dbfile(@pxref{fig:ch2_dbfile})にあるようなアウトライン出力を生成するのは、@code{xmlparser.awk}スクリプトを修正すればAWKでは数行で書ける問題です。 | |
826 | +これは、XMLデータが完全に読み込まれた後で行われるということに注意してください。 | |
827 | +ですから、処理できるデータの大きさに何らかの制限があるものの、処理の時点では、XMLの完全なデータがAWKのメモリにとにかく保存されています。 | |
777 | 828 | @example |
778 | 829 | XMLDEPTH=0 |
779 | 830 | for (n = 1; n <= idx; n += 1 ) @{ |
@@ -784,104 +835,111 @@ for ( n = 1; n <= idx; n += 1 ) @{ | ||
784 | 835 | @} else if (type[n] == "end" ) @{ XMLDEPTH -- @} |
785 | 836 | @} |
786 | 837 | @end example |
787 | -このアプリケーションの出力と @ref{fig:ch2_dbfile} を比べると、違いが二つだけあることがわかると思います。 | |
788 | -一つめは一番最初のタグの前にある改行文字です。 | |
789 | -二つめはタグの名前です。 | |
790 | -@code{xmlparser.awk} スクリプトは各タグの名前を大文字で保存します。 | |
791 | -正確なタグ名は XML をパースする仕組みの内部を変更しないと取り戻すことはできません。@footnote{訳注: 原文の revovered は revivered の typo ?} | |
838 | +このアプリケーションの出力とfig:ch2_dbfile(@pxref{fig:ch2_dbfile})を比べると、違いが二つだけあることが分かると思います。 | |
839 | +一つは、一番最初のタグの前にある改行文字です。 | |
840 | +もう一つは、タグの名前です。 | |
841 | +@code{xmlparser.awk}スクリプトは、各タグの名前を大文字で保存します。 | |
842 | +正確なタグ名はXMLをパースする仕組みの内部を変更しないと取り戻すことはできません@footnote{訳注:原文のrevoveredはreviveredのtypoでしょうか。}。 | |
792 | 843 | @end enumerate |
793 | 844 | |
794 | 845 | |
795 | - | |
796 | 846 | @node Jan Weber's getXML script |
797 | -@section Jan Weber の getXML スクリプト | |
798 | -2005 年、Jan Weber が類似の XML パーサを @uref{news://comp.lang.awk, comp.lang.awk} ニューズグループに投稿しました。 | |
847 | +@section Jan WeberのgetXMLスクリプト | |
848 | + | |
849 | +2005年、Jan Weberが、類似のXMLパーサを@uref{news://comp.lang.awk, comp.lang.awk}ニューズグループに投稿しました。 | |
799 | 850 | @pindex @file{getXML} |
800 | 851 | @ignore |
801 | 852 | Jan Weber 2005-07-10 comp.lang.awk |
802 | 853 | @end ignore |
803 | -@code{getXML} スクリプトを Google で検索して、そのコピーをファイルにすることができます。 | |
804 | -残念なことですが、Jan はスクリプトを可能な限り短かくしようとしていて、複数のステートメントを 1 行に書くこともしばしばです。 | |
805 | -このスクリプトの読み易さは極端に損なわれているので、スクリプトを解読するのであれば、理解するのに必要かもしれない編集をするつもりでいてください。 | |
806 | -再びですが、このパーサスクリプトを編集しながら、そこに書かれているコメントを少し見てください。 | |
807 | -Jan は、スクリプトの中心となる関数にユーザの視点から以下 (@pxref{fig:ch2_getXML_header}) のようにコメントを書いています。 | |
808 | -基本的なアプローチは @code{xmlparser.awk} スクリプトから引き継いだものでした。 | |
809 | -しかし、Jan が自分の XML パーサを書く上で満足させようとしたいくつかの条件がありました。 | |
854 | +そのスクリプトである@code{getXML}スクリプトは、Googleで検索すれば、そのコピーをファイルにすることができます。 | |
855 | +残念なことですが、Janは、スクリプトを出来るだけ短かくしようと、複数ステートメントを1行に書くことがよくあります。 | |
856 | +このスクリプトは読み易さが極端に損なわれています。 | |
857 | +そのため、このスクリプトを解読するのであれば、スクリプトを理解するのに編集が必要となるかもしれませんので、そのつもりでいてください。 | |
858 | +もう一度、このパーサスクリプトを編集しながら、そこに書かれているコメントを少し見てください。 | |
859 | +Janは、スクリプトの中心となる関数にユーザの視点から以下(@pxref{fig:ch2_getXML_header})のようなコメントを書いています。 | |
860 | +基本的なアプローチは@code{xmlparser.awk}スクリプトから引き継いだものでした。 | |
861 | +しかし、Janには、自分のXMLパーサを書く上で、満足させたい条件がいくつかありました。 | |
810 | 862 | |
811 | 863 | @enumerate |
812 | 864 | @item |
813 | -@code{getXML} 関数は、並行して複数の XML を読み込むことを可能にします。 | |
865 | +@code{getXML}関数は、複数のXMLを並行して読み込むことを可能にします。 | |
866 | + | |
814 | 867 | @item |
815 | -その結果、XML のイベントごとに @code{getXML} 関数からのリターンが起きます。 | |
816 | -これは、AWK の @code{getline} の仕組みと似ています (@pxref{fig:ch2_getXML})。 | |
817 | -その上、ユーザアプリケーションは @code{BEGIN} アクションでファイルを読み込みます。 | |
818 | -@code{END} アクションの中ではありません。 | |
868 | +その結果、XMLのイベントごとに@code{getXML}関数からのリターンが起きます。 | |
869 | +これは、AWKの@code{getline}の仕組みと似ています(@pxref{fig:ch2_getXML})。 | |
870 | +その上、ユーザアプリケーションは@code{BEGIN}アクションでファイルを読み込みます。 | |
871 | +@code{END}アクションの中ではありません。 | |
872 | + | |
819 | 873 | @item |
820 | -タグとアトリビュートの正確な名前を保存します。 | |
821 | -この XML パーサは大文字小文字を変更しません。 | |
874 | +タグとアトリビュートの正確な名前を保存する。 | |
875 | +このXMLパーサは大文字小文字を変更しません。 | |
876 | + | |
822 | 877 | @item |
823 | -パラメータの渡し方は、@ref{XMLgawk コア言語インターフェイスの要約} の中で、@emph{Style B - すべてのイベントで共有される、限定された変数の組} のように記述されているアプローチとずっとよく似ています。 | |
878 | +パラメータの渡し方は、別の節(@pxref{XMLgawk Core Language Interface Summary})の中で@emph{Style B - すべてのイベントで共有される、限定された変数の組}のとして説明されているアプローチとずっとよく似ています。 | |
824 | 879 | 最も重要なことですが、アトリビュートの名前と値は、属しているタグと一緒に渡されます。 |
825 | -ですので、イベントの粒度はもっと粗くて、ユーザフレンドリなものとなっています。 | |
880 | +ですから、イベントの粒度はもっと粗くて、ユーザフレンドリなものとなっています。 | |
881 | + | |
826 | 882 | @item |
827 | -@code{xmlparser.awk} スクリプトがパースする過程の間に二つの配列に完全な XML データを格納するのに対し、@code{getXML.awk} スクリプトは、一回に一つの XML イベントを呼び出したアプリケーションへ渡して戻します。 | |
828 | -これはメモリの無駄遣いを避けるためです。 | |
829 | -すなわち、巨大な XML ファイルのパースが可能になります (あまり意味があるわけではありませんが)。 | |
883 | +@code{xmlparser.awk}スクリプトは、パースする過程の間に、二つの配列に完全なXMLデータを格納します。 | |
884 | +それに対し、@code{getXML.awk}スクリプトは、一回に一つのXMLイベントを、呼び出したアプリケーションへ渡して戻します。 | |
885 | +これは、メモリの無駄遣いを避けるためです。 | |
886 | +すなわち、巨大なXMLファイルのパースが可能になります(あまり意味があるわけではありませんが)。 | |
887 | + | |
830 | 888 | @item |
831 | -この XML パーサは Solaris Operating System 上の AWK 言語実装である @code{nawk} とともに動きます。 | |
832 | -それゆえ、この XML パーサはおそらく、この @value{DOCUMENT} に記載されているパーサの中で最もポータブルなものでしょう。 | |
889 | +このXMLパーサは、Solaris Operating System上のAWK言語実装である@code{nawk}で動作します。 | |
890 | +それゆえ、このXMLパーサはおそらく、この@value{DOCUMENT}に記載されているパーサの中で最も可搬性のあるものでしょう。 | |
833 | 891 | @cindex Solaris |
834 | 892 | @cindex @code{nawk} |
835 | 893 | @end enumerate |
836 | 894 | |
837 | -もう一度、@ref{fig:ch2_outline.awk} のようなアウトラインスクリプトを実装して、この XML パーサの使い方を示しましょう。 | |
838 | -@file{getXML} ファイルを変更して、@ref{fig:ch2_getXML} にあるスクリプトで既存の @code{BEGIN} アクションを置き換えてください。 | |
839 | -次のように新しいアウトラインパーサを初起動してください。 | |
895 | +もう一度、fig:ch2_outline.awk(@pxref{fig:ch2_outline.awk})のようなアウトラインスクリプトを実装して、このXMLパーサの使い方を示しましょう。 | |
896 | +@file{getXML}ファイルを変更して、fig:ch2_getXML(@pxref{fig:ch2_getXML})にあるスクリプトで既存の@code{BEGIN}アクションを置き換えてください。 | |
897 | +まず最初に、次のように、新しいアウトラインパーサを起動してください。 | |
840 | 898 | |
841 | 899 | @example |
842 | 900 | awk -f getXML docbook_chapter.xml |
843 | 901 | @end example |
844 | 902 | |
845 | -元のファイルの内容 (@pxref{fig:dbfile})、木構造としての図 (@pxref{fig:docbook_chapter})、そして @command{expat} パーサに付いてくる元の @code{outline} ツールの出力 (@pxref{fig:ch2_dbfile}) と、このスクリプトの出力を比較してください。 | |
846 | -@pindex Expat, SAX ライクな API を持つ XML パーサ | |
847 | -結果は、ささいな部分を除けば、@ref{fig:ch2_dbfile} とほとんど同じです。 | |
903 | +このスクリプトの出力を、元のファイルの内容(@pxref{fig:dbfile})、および、木構造としての図(@pxref{fig:docbook_chapter})、@command{expat}パーサに付いてくる元の@code{outline}ツールの出力(@pxref{fig:ch2_dbfile})と比較してください。 | |
904 | +@pindex Expat, XML parser with SAX-like API | |
905 | +結果は、ささいな部分を除けば、fig:ch2_dbfile(@pxref{fig:ch2_dbfile})とほとんど同じです。 | |
848 | 906 | ささいな部分とは、一番最初の行がここでは空行となっていることです。 |
849 | 907 | |
850 | 908 | @float Figure,fig:ch2_getXML_header |
851 | 909 | @example |
852 | 910 | ## |
853 | -# getXML( file, skipData ): # 次の XML データを XTYPE,XITEM,XATTR に読み込む | |
911 | +# getXML( file, skipData ): # 次のXMLデータをXTYPE,XITEM,XATTRに読み込む | |
854 | 912 | # パラメータ: |
855 | -# file -- XML ファイルへのパス | |
856 | -# skipData -- フラグ: "DAT" (タグ間のデータ) セクションを読まない | |
913 | +# file -- XMLファイルへのパス | |
914 | +# skipData -- フラグ: "DAT"(タグ間のデータ)セクションを読まない | |
857 | 915 | # 外部変数: |
858 | -# XTYPE -- 読み込んだアイテムの種類、e.g. "TAG"(タグ), "END"(終了タグ), | |
859 | -# "COM"(コメント), "DAT"(データ) | |
860 | -# XITEM -- アイテムの値、e.g. 種類が "TAG" か "END" であればタグ名 | |
861 | -# XATTR -- アトリビュートのマップ、XTYPE=="TAG" のときだけセットされる | |
916 | +# XTYPE -- 読み込んだアイテムの種類、e.g. "TAG"(タグ), "END"(終了タグ), | |
917 | +# "COM"(コメント), "DAT"(データ) | |
918 | +# XITEM -- アイテムの値、e.g. 種類が"TAG"か"END"であればタグ名 | |
919 | +# XATTR -- アトリビュートのマップ、XTYPE=="TAG"の時だけセットされる | |
862 | 920 | # XPATH -- 現在のタグまでのパス, e.g. /TopLevelTag/SubTag1/SubTag2 |
863 | 921 | # XLINE -- 入力ファイルのその時点での行番号 |
864 | -# XNODE -- XTYPE, XITEM, XATTR が一つの文字列に連結されている | |
922 | +# XNODE -- XTYPE, XITEM, XATTRが一つの文字列に連結されている | |
865 | 923 | # XERROR -- エラーテキスト、パースエラーで設定される |
866 | 924 | # 戻り値: |
867 | -# 1 成功裏に読めた: よって XTYPE, XITEM, XATTR がセットされる | |
868 | -# "" ファイルの終わり、またはパースエラー: XERROR がエラーでセット | |
925 | +# 1 成功裏に読めた: よってXTYPE, XITEM, XATTRがセットされる | |
926 | +# "" ファイルの終わり、または、パースエラー: XERRORがエラーでセット | |
869 | 927 | # される |
870 | 928 | # プライベートデータ: |
871 | -# _XMLIO -- ファイルを開いたときのバッファ、XLINE、XPATH | |
929 | +# _XMLIO -- ファイルを開いた時のバッファ、XLINE、XPATH | |
872 | 930 | ## |
873 | 931 | @end example |
874 | -@caption{Jan Weber の getXML パーサ関数の使い方} | |
932 | +@caption{Jan WeberのgetXMLパーサ関数の使い方} | |
875 | 933 | @end float |
876 | 934 | |
877 | 935 | 実装の詳細のいくつかの点は注目する価値があります。 |
878 | -ほら、アイテムの粒度が異なっていますね: | |
879 | -アトリビュートは全部タグのアイテムとともに返されます。 | |
880 | -この結果は、設計の決定から来るものです: | |
881 | -@code{getXML} 関数は、呼び出し元へ、より大量のデータを返すのにいくつかの変数を使います。 | |
936 | +ほら、アイテムの粒度が異なっていますね。 | |
937 | +つまり、アトリビュートが、タグのアイテムとともに全て返されます。 | |
938 | +この結果は、設計意図から来るものです: | |
939 | +@code{getXML}関数は、呼び出し元へ、より大量のデータを返すのにいくつかの変数を使います。 | |
882 | 940 | 最終的に、まだやってないこまかい事はこの例の中で明らかとなります。 |
883 | -@code{getXML} 関数の 2 番目のパラメータに注意してください (@code{skipData})。 | |
884 | -Jan はタグ間にあるテキストデータ (mixed content) をスキップできるオプションを導入しました。 | |
941 | +@code{getXML}関数の2番目のパラメータに注意してください(@code{skipData})。 | |
942 | +Janは、タグ間にあるテキストデータ(mixed content)をスキップできるオプションを導入しました。 | |
885 | 943 | |
886 | 944 | |
887 | 945 | @float Figure,fig:ch2_getXML |
@@ -902,85 +960,95 @@ BEGIN @{ | ||
902 | 960 | @} |
903 | 961 | @} |
904 | 962 | @end example |
905 | -@caption{Jan Weber の @code{getXML} パーサスクリプトを使った XML ファイルのアウトラインの取得} | |
963 | +@caption{Jan Weberの@code{getXML}パーサスクリプトを使った、XMLファイルのアウトラインの取得} | |
906 | 964 | @end float |
907 | 965 | |
908 | 966 | |
909 | 967 | @page |
910 | 968 | @node A portable subset of XMLgawk |
911 | -@section XMLgawk のポータブルサブセット | |
969 | +@section XMLgawkのポータブルサブセット | |
912 | 970 | @pindex @file{getXMLEVENT.awk} |
913 | 971 | |
914 | -前の @value{SECTION} にある Jan Webers のポータブルスクリプトは、Steve Coile のスクリプトから大きく先へ進んだものでした。 | |
915 | -XML のイベント処理は、XMLgawk API で行うものに近い感じがします。 | |
916 | -しかし、このスクリプトで何度か作業した後、このスクリプトと XMLgawk API の間の違いを覚えておくことが少しわずらわしくなりました。 | |
917 | -その結果私たちは、Jan のスクリプトを取り上げ、新しいスクリプトファイルの @file{getXMLEVENT.awk} としてコピーし、その内部の動作を、XMLgawk API と最小の違いとなるように変更しました。 | |
918 | -このスクリプトをあなた自身の作業のテンプレートとして使うつもりでしたら、以下の場所から @file{getXMLEVENT.awk} を探してください: | |
972 | +前の@value{SECTION}にあるJan Webersのポータブルスクリプトは、Steve Coileのスクリプトから大きく先へ進んだものでした。 | |
973 | +XMLのイベント処理は、XMLgawk APIで行うものに近い感じがします。 | |
974 | +しかし、このスクリプトで何度か作業した後、このスクリプトとXMLgawk APIの間の違いを覚えておくことが少し煩わしくなりました。 | |
975 | +その結果、私たちは、Janのスクリプトを取り上げ、新しいスクリプトファイルの@file{getXMLEVENT.awk}としてコピーし、その内部の動作を、XMLgawk APIと最小の違いとなるように変更しました。 | |
976 | +あなた自身の作業のテンプレートとしてこのスクリプトを使うつもりでしたら、以下の場所から@file{getXMLEVENT.awk}を探してください: | |
919 | 977 | |
920 | 978 | @itemize |
921 | -@item @code{xgawk} ディストリビューションファイルの @file{awklib/xml} ディレクトリの中にコピーがあります。 | |
922 | -@item ホストマシンに既に @code{xgawk} がインストールされていれば、共有ソースのディレクトリ (普通は GNU/Linux マシンの @code{/usr/share/awk} のような場所) にコピーがあるはずです。 | |
979 | +@item @code{xgawk}の配布ファイルの@file{awklib/xml}ディレクトリの中にコピーがあります。 | |
980 | + | |
981 | +@item ホストマシンに既に@code{xgawk}がインストールされていれば、共有ソースのディレクトリ(普通はGNU/Linuxマシンの@code{/usr/share/awk}のような場所)にコピーがあるはずです。 | |
923 | 982 | @end itemize |
924 | 983 | |
925 | -ゼロからスクリプトを書き始めたい場合は、@file{getXMLEVENT.awk} ファイルはそのままうまく利用できます。 | |
926 | -スクリプトの @code{BEGIN} パターンには、既に@emph{イベントループ}が入っています。 | |
927 | -その@emph{イベントループ} (@code{while} ループ) の本体のところだけを取って、XML のイベントストリームから入ってくるイベントに対する処理の部分を変更してください。 | |
984 | +スクリプトをゼロから書き始めたい場合は、@file{getXMLEVENT.awk}ファイルはそのままうまく利用できます。 | |
985 | +スクリプトの@code{BEGIN}パターンには、@emph{イベントループ}が既に入っています。 | |
986 | +その@emph{イベントループ}(@code{while}ループ)の本体のところだけを取って来て、XMLのイベントストリームから入ってくるイベントに対する処理の部分を変更してください。 | |
928 | 987 | |
929 | -しかし、この @value{SECTION} の残りの部分は、既にスクリプトが@emph{あって}、それを移植するということを仮定します。 | |
930 | -最も役立つ方法でのアプローチの説明をするために、@file{getXMLEVENT.awk} テンプレートファイルの典型的な使用例を二つ通して見ていきます。 | |
931 | -まず私たちは、XMLgawk 用に書かれた既存のスクリプトを取って、Solaris マシンで使うためにそのスクリプトをポータブルにするために必要なステップについて見ます (単にワーストケースシナリオと呼びます)。 | |
932 | -次に、ぐるっと反対の方向へ行きます: | |
933 | -既存のポータブルなスクリプトを取って、XMLgawk 用のスクリプトへ変換するのに必要なステップを説明します。 | |
988 | +しかし、この@value{SECTION}の残りの部分は、スクリプトが既に@emph{あって}、それを移植するということを仮定します。 | |
989 | +最も役立つ方法でのアプローチの説明をするために、@file{getXMLEVENT.awk}テンプレートファイルの典型的な使用例を二つ通して見ていきます。 | |
990 | +まず、XMLgawk用に書かれた既存のスクリプトを引用し、Solarisマシンで使えるよう、そのスクリプトをポータブルにするために必要なステップについて見ます(単に、ワーストケースシナリオと呼びます)。 | |
991 | +次に、ぐるっと反対の方向へ行きます。 | |
992 | +既存のポータブルなスクリプトを取って、XMLgawk用のスクリプトへ変換するのに必要なステップを説明します。 | |
934 | 993 | |
935 | -@subsection XMLgawk 用のスクリプトのポータブルなサブセットへの変換 | |
994 | +@subsection XMLgawk用のスクリプトのポータブルなサブセットへの変換 | |
936 | 995 | |
937 | -XMLgawk の機能を使っているスクリプトをポータブルなスクリプトへと移植する一般的なアプローチは、いつも同じです。 | |
938 | -オリジナルのアウトラインスクリプト (@pxref{fig:ch2_outline.awk}) を移植するか、あるいは DTD ジェネレータ (@pxref{サンプルファイルからの DTD の生成}) のような非凡なアプリケーションを取り上げるのかは、問題ではありません。 | |
939 | -さあ、私たちは以下の一連のステップをずっと進んでいきますよ。 | |
996 | +XMLgawkの機能を使っているスクリプトを、ポータブルなスクリプトへと移植する一般的なアプローチは、常に同じです。 | |
997 | +オリジナルのアウトラインスクリプト(@pxref{fig:ch2_outline.awk})を移植するか、あるいは、DTDジェネレータ(@pxref{Generating a DTD from a sample file})のような非凡なアプリケーションを取り上げるのかは、問題ではありません。 | |
998 | +さあ、以下の一連のステップをずっと進んでいきますよ。 | |
940 | 999 | |
941 | 1000 | @enumerate |
942 | 1001 | @item |
943 | -私たちは、テンプレートファイルの @file{getXMLEVENT.awk} を新しいファイル (DTD ジェネレータの場合ならば @file{dtdgport.awk}) に先ずコピーすることから常にスタートします。 | |
1002 | +テンプレートファイルの@file{getXMLEVENT.awk}を、新しいファイル(DTDジェネレータの場合ならば@file{dtdgport.awk})に先ずコピーすることから常にスタートします。 | |
1003 | + | |
944 | 1004 | @item |
945 | -新しいスクリプトファイルの先頭近くで、元のイベントループの本体を削除します。 | |
1005 | +新しいスクリプトファイルの先頭近くにある元のイベントループの本体を削除します。 | |
1006 | + | |
946 | 1007 | @item |
947 | -元のイベントループをアプリケーションからのパターンアクションのペアに置き換えます。 | |
948 | -DTD ジェネレータの場合であれば、ソースコード (@ref{fig:dtd_generator.awk}) の最初の部分を見て、イベントループの中に @code{XMLSTARTELEM} アクションを挿入します。 | |
1008 | +元のイベントループを、アプリケーションからのパターンアクションのペアに置き換えます。 | |
1009 | +DTDジェネレータの場合であれば、ソースコード(@pxref{fig:dtd_generator.awk})の最初の部分を見て、イベントループの中に@code{XMLSTARTELEM}アクションを挿入します。 | |
1010 | + | |
949 | 1011 | @item |
950 | -イベントループの後ろに、@ref{fig:dtd_generator.awk} の @code{END} パターンをそのまま追加します。 | |
1012 | +イベントループの後ろに、fig:dtd_generator.awk(@pxref{fig:dtd_generator.awk})の@code{END}パターンをそのまま追加します。 | |
1013 | + | |
951 | 1014 | @item |
952 | -アプリケーションの 2 番目の部分 (@ref{fig:print_elem} の関数定義を含んでいる) をそのまま追加します。 | |
1015 | +アプリケーションの2番目の部分(fig:print_elem(@pxref{fig:print_elem})の関数定義を含んでいる)をそのまま追加します。 | |
1016 | + | |
953 | 1017 | @item |
954 | -出来上がったアプリケーションのソースコードに対して、それが本当に期待通りに動作するか試します。 | |
955 | -スクリプトの出力結果を @ref{fig:dbfile.dtd} と比較してください。 | |
956 | -結果の出力 (DTD になっている) が全く正確に同じであることがわかるでしょう。 | |
1018 | +出来上がったアプリケーションのソースコードに対して、期待通りにそれが本当に動作するか試します。 | |
1019 | +スクリプトの出力結果をfig:dbfile.dtd(@pxref{fig:dbfile.dtd})と比較してください。 | |
1020 | +結果の出力(DTDになっている)が、全く正確に同じであることが分かるでしょう。 | |
1021 | + | |
957 | 1022 | @example |
958 | 1023 | awk -f dtdgport.awk docbook_chapter.xml |
959 | 1024 | @end example |
960 | 1025 | @end enumerate |
961 | 1026 | |
962 | -XMLgawk スクリプトをポータブルなスクリプトへ変換するということの簡単さとその効果は驚くべきものです。 | |
963 | -結局のところやはり、ポータブルなスクリプトの制約について決して忘れるべきではありません。 | |
964 | -このちっちゃな XML パーサは、完全な XML パーサとは程遠いものです。 | |
965 | -最も重大なのは、マルチバイト文字や他の Unicode エンコーディングの細目を使ったファイルの読み込み能力が欠けていることです。 | |
966 | -遅かれ早かれ、特殊な文字 (コピーライトマーク、タイポグラフィックダッシュ、ヨーロピアンアクセント文字、あるいは漢字とか) を含む顧客の XML ファイルに出くわしてしまうだろうことは私たちは経験的に知っています。 | |
967 | -ですので、XML を完全にパースする機能が使える完全な XMLgawk 環境へスクリプトを移植しなおす必要が生じます。 | |
968 | -あなたが結局このポイントまで来るときは、次のサブセクションを続けて読んでください。 | |
969 | -そうすればスクリプトを XMLgawk に書き直すときのアドバイスが得られるでしょう。 | |
970 | - | |
971 | -@subsection ポータブルなサブセットのスクリプトから XMLgawk への変換 | |
972 | -ポータブルなサブセットから完全な XMLgawk へスクリプトを変換するのはさらに簡単です。 | |
973 | -この簡単さは、@ref{XMLgawk コア言語インターフェイスの要約} の中で述べられているように、@emph{Style B - すべてのイベントで共有される、限定された変数の組} の API と、ポータブルなサブセットのイベントループが似ていることから来るものです。 | |
974 | -移植の要点は、@code{getXMLEVENT} の起動を @code{getline} に置き換えることです。 | |
975 | -以下の作業リストを順に進めば、XML データを細かい部分までサポートするアプリケーションへとすぐに到達できるでしょう。 | |
1027 | +XMLgawkスクリプトをポータブルなスクリプトへ変換するということの簡単さとその効果は驚くべきものです。 | |
1028 | +結局のところ、やはり、ポータブルなスクリプトの制約について決して忘れるべきではありません。 | |
1029 | +このちっちゃなXMLパーサは、完全なXMLパーサには程遠いものです。 | |
1030 | +最も重大なのは、マルチバイト文字や他のUnicodeエンコーディングの細目を使ったファイルの読み込み能力が欠けていることです。 | |
1031 | +遅かれ早かれ、特殊な文字(コピーライトマーク、タイポグラフィックダッシュ、ヨーロピアンアクセント文字、漢字など)を含む顧客のXMLファイルに出くわしてしまうだろうことは私たちは経験的に知っています。 | |
1032 | +ですから、XMLを完全にパースする機能が使える完全なXMLgawk環境へスクリプトを移植しなおす必要が生じます。 | |
1033 | +この状況に結局なる時は、次のサブセクションを続けて読んでください。 | |
1034 | +そうすればスクリプトをXMLgawkに書き直す時のアドバイスが得られるでしょう。 | |
1035 | + | |
1036 | +@subsection ポータブルなサブセットのスクリプトからXMLgawkへの変換 | |
1037 | + | |
1038 | +ポータブルなサブセットから完全なXMLgawkへスクリプトを変換するのはさらに簡単です。 | |
1039 | +この簡単さは、別の節(@pxref{XMLgawk Core Language Interface Summary})の中で述べられているように、@emph{Style B - すべてのイベントで共有される、限定された変数の組}のAPIと、ポータブルなサブセットのイベントループが似ていることから来るものです。 | |
1040 | +移植の要点は、@code{getXMLEVENT}の起動を@code{getline}に置き換えることです。 | |
1041 | +以下の作業リストを順に進めば、XMLデータを細かい部分までサポートするアプリケーションへとすぐに到達できるでしょう。 | |
976 | 1042 | |
977 | 1043 | @enumerate |
978 | 1044 | @item |
979 | -アプリケーションのコードが書かれたファイルを新しいソースコードファイルへコピーします。 | |
1045 | +アプリケーションのコードが書かれたファイルを、新しいソースコードファイルへコピーします。 | |
1046 | + | |
980 | 1047 | @item |
981 | -新しいソースコードファイルのファイルの先頭へ @code{@@load xml} と挿入します。 | |
1048 | +新しいソースコードファイルのファイルの先頭へ@code{@@load xml}と挿入します。 | |
1049 | + | |
982 | 1050 | @item |
983 | -@code{BEGIN} パターンの中で、イベントループの @code{while} ステートメントの条件を変換します。 | |
1051 | +@code{BEGIN}パターンの中で、イベントループの@code{while}ステートメントの条件を変換します。 | |
984 | 1052 | @example |
985 | 1053 | while (getXMLEVENT(ARGV[1])) @{ |
986 | 1054 | @end example |
@@ -989,10 +1057,13 @@ XMLgawk スクリプトをポータブルなスクリプトへ変換するとい | ||
989 | 1057 | while (getline > 0) @{ |
990 | 1058 | @end example |
991 | 1059 | に変更します。 |
1060 | + | |
992 | 1061 | @item |
993 | -@code{BEGIN} パターンの残りの部分は、変更されていないイベントループの部分とともにそのままにしておきます。 | |
1062 | +@code{BEGIN}パターンの残りの部分は、変更されていないイベントループの部分とともにそのままにしておきます。 | |
1063 | + | |
994 | 1064 | @item |
995 | -@code{getXMLEVENT}、@code{unescapeXML}、@code{closeXMLEVENT} の各関数を削除します。 | |
1065 | +@code{getXMLEVENT}、@code{unescapeXML}、@code{closeXMLEVENT}の各関数を削除します。 | |
1066 | + | |
996 | 1067 | @item |
997 | 1068 | 出来上がったアプリケーションソースファイルが、期待通りに本当に動作するかを試します。 |
998 | 1069 | 出力結果を比較してください。 |
@@ -1000,26 +1071,28 @@ XMLgawk スクリプトをポータブルなスクリプトへ変換するとい | ||
1000 | 1071 | |
1001 | 1072 | |
1002 | 1073 | @node XML Core Language Extensions of gawk |
1003 | -@chapter gawk の XML コア言語拡張 | |
1074 | +@chapter gawkのXMLコア言語拡張 | |
1004 | 1075 | |
1005 | 1076 | @menu |
1006 | -* 整形式のチェック:: | |
1007 | -* XML ファイルのアウトラインの表示:: | |
1008 | -* XML ファイルからのデータの取り出し:: | |
1009 | -* キャラクタデータと文字セットのエンコーディング:: | |
1010 | -* DTD の取り扱い:: | |
1011 | -* XML ファイルのデータ全種類の処理:: | |
1077 | +* Checking for well-formedness:: | |
1078 | +* Printing an outline of an XML file:: | |
1079 | +* Pulling data out of an XML file:: | |
1080 | +* Character data and encoding of character sets:: | |
1081 | +* Dealing with DTDs:: | |
1082 | +* Sorting out all kinds of data from an XML file:: | |
1012 | 1083 | @end menu |
1013 | 1084 | |
1014 | -@ref{gawk で木構造をトラバースする方法} の中で、@ref{fig:docbook_chapter} の XML ファイルの木構造に注目していました。 | |
1015 | -木構造をトラバースする処理を追い掛けるのを助けてくれる @code{XMLSTARTELEM} と @code{XMLENDELM} という二つのパターンを知りました。 | |
1016 | -この @value{CHAPTER} では、他の XML に特有のパターンがどういうものかを見ていきます。 | |
1085 | +別の節(@pxref{How to traverse the tree with gawk})の中で、fig:docbook_chapter(@pxref{fig:docbook_chapter})のXMLファイルの木構造に注目していました。 | |
1086 | +木構造をトラバースする処理を追い掛けるのを支援する@code{XMLSTARTELEM}と@code{XMLENDELM}という二つのパターンを知りました。 | |
1087 | +この@value{CHAPTER}では、他のXMLに特有のパターンがどういうものかを見ていきます。 | |
1017 | 1088 | それらのパターンは全部例の中で使いますし、その意味を簡単に説明するつもりです。 |
1018 | 1089 | |
1090 | + | |
1019 | 1091 | @node Checking for well-formedness, , , |
1020 | 1092 | @section 整形式のチェック |
1021 | -XML フォーマットをデータの格納に使うことで有利になることの一つは、データの正しさをチェックする正式な手段があるということです。 | |
1022 | -データが手作業で書かれたか、あるいは自動生成されたものかを問わず、新しいデータがあるルール (タグがミススペルしてないか?もうひとつが欠けてないか?3 番目のものが違う場所にないか?) に則っているかどうかを調べるツールがあるということは常に有利なことです。 | |
1093 | + | |
1094 | +XMLフォーマットをデータの格納に使うことで有利になることの一つは、データの正しさをチェックする正式な手段があるということです。 | |
1095 | +データが手作業で書かれたか、あるいは、自動生成されたものかを問わず、新しいデータが、あるルール(タグがミススペルしてないか。もうひとつが欠けてないか。3番目のものが違う場所にないか。)に則っているかどうかを調べるツールがあるということは常に有利なことです。 | |
1023 | 1096 | |
1024 | 1097 | @cindex DTD, Document Type Definition |
1025 | 1098 | @cindex Schema |
@@ -1027,26 +1100,27 @@ XML フォーマットをデータの格納に使うことで有利になるこ | ||
1027 | 1100 | @cindex validation |
1028 | 1101 | @pindex @file{xmllint} |
1029 | 1102 | @pindex @file{xsv} |
1030 | - | |
1031 | 1103 | 正しいかどうかをチェックするこれらの仕組みは、さまざまな段階で適用されます。 |
1032 | 1104 | 最も低い段階は整形式かどうかです。 |
1033 | -正しいかどうかをチェックする次の上の段階は、DTD (@pxref{サンプルファイルからの DTD の生成}) と (より高度ですが、まだ標準では要求されない) スキーマの段階です。 | |
1034 | -XML ファイルに DTD (あるいはスキーマ) による仕様書があるならば、それを@emph{バリデーション}ツールに渡して、仕様書を適用し、その仕様書に則しているかどうかをチェックし、結果を報告してもらうことができます。 | |
1035 | -DTD に対する簡単なバリデーションツールには @uref{http://xmlsoft.org/xmllint.html, @command{xmllint}} があります。 | |
1036 | -このツールは @code{libxml} の一部なので、たいていの GNU/Linux システムにはインストールされています。 | |
1037 | -スキーマに対するバリデーションには、@command{xmllint} の新しいほうのバージョンか、あるいは、@uref{http://www.ltg.ed.ac.uk/~ht/xsv-status.html, @command{xsv}} を使うことができます。 | |
1105 | +正しいかどうかをチェックする次の段階は、DTD(@pxref{Generating a DTD from a sample file})と(より高度ですが、まだ標準では要求されない)スキーマの段階です。 | |
1106 | +DTD(あるいは、スキーマ)による仕様書がXMLファイルにあるならば、@emph{バリデーション}ツールにそれを渡して、仕様書を適用し、その仕様書に則しているかどうかをチェックし、結果を報告してもらうことができます。 | |
1107 | +DTDに対する簡単なバリデーションツールには@uref{http://xmlsoft.org/xmllint.html, @command{xmllint}}があります。 | |
1108 | +このツールは@code{libxml}の一部なので、たいていのGNU/Linuxシステムにはインストールされています。 | |
1109 | +スキーマに対するバリデーションには、@command{xmllint}の新しいほうのバージョンか、あるいは、@uref{http://www.ltg.ed.ac.uk/~ht/xsv-status.html, @command{xsv}}を使うことができます。 | |
1110 | + | |
1111 | +@code{gawk}インタプリタにバリデーションが現在含まれていないのには以下の二つ理由があります。 | |
1038 | 1112 | |
1039 | -@code{gawk} インタプリタにバリデーションが現在含まれていないのには二つ理由があります。 | |
1040 | 1113 | @enumerate |
1041 | -@item バリデーションはささいな事というわけではありませんし、標準化やサポート、安定度が適切なレベルまで達しているのは DTD のバリデーションだけです。 | |
1042 | -@item 私たちは整形式の XML ファイルを全て処理できるツールが欲しいのであって、きれいなデータを処理するツールだけが欲しいのではありません。 | |
1114 | +@item バリデーションはささいな事というわけではありませんし、標準化やサポート、安定度が適切なレベルまで達しているのはDTDのバリデーションだけです。 | |
1115 | + | |
1116 | +@item 整形式のXMLファイルを全て処理できるツールが欲しいのであって、きれいなデータを処理するツールだけが欲しいのではありません。 | |
1043 | 1117 | 良いツールというのは、信頼できて、問題を解決するのに使えるツールです。 |
1044 | -道路がぬかるんでいるとか、お日様が照っていないという理由だけで外を走るのを拒む自動車があったとしたら、あなたはどう思いますか? | |
1118 | +道路がぬかるんでいるとか、お日様が照っていないという理由だけで外を走るのを拒む自動車があったとしたら、あなたはどう思うでしょうか。 | |
1045 | 1119 | @end enumerate |
1046 | 1120 | |
1047 | -ここに、XML データが整形式になっているかどうかをテストするスクリプトがあります。 | |
1048 | -整形式を検査する実際の作業は、@code{gawk} に組込まれた XML パーサが行ないます。 | |
1049 | -私たちはその結果と、エラー診断、エラーからの回復の詳細についてだけ関心があります。 | |
1121 | +ここに、XMLデータが整形式になっているかどうかをテストするスクリプトがあります。 | |
1122 | +整形式を検査する実際の作業は、@code{gawk}に組込まれたXMLパーサが行います。 | |
1123 | +ここでは、その結果と、エラー診断、エラーからの回復の詳細についてだけ関心があります。 | |
1050 | 1124 | |
1051 | 1125 | @pindex @file{well_formed.awk} |
1052 | 1126 | @example |
@@ -1060,19 +1134,21 @@ END @{ | ||
1060 | 1134 | @} |
1061 | 1135 | @end example |
1062 | 1136 | |
1063 | -毎度のことですが、このスクリプトは @code{gawk} を XML モードへ切り替えることで始まります。 | |
1064 | -トラバースされるノードの中身については今は関心がありませんので、ノードを見つけたときに実行されるアクションはありません。 | |
1065 | -その最後の部分 (XML ファイルは既に閉じられている時) で、成功と失敗を報告する変数をいくつか見ているだけです。 | |
1066 | -もし @code{XMLERROR} 変数に 0 や 空文字列以外のものが入っていれば、エラーが発生していて、パーサが、そのエラーの起きた場所でツリーのトラバースを止めています。 | |
1067 | -説明のメッセージが @code{XMLERROR} に入っています (内容は、そのプラットフォームで使われているその特定のパーサに依存します)。 | |
1068 | -そのほかの、例で使われている変数には、その XML ファイルの形式が間違っている場所の行番号とカラム数が入っています。 | |
1137 | +毎度のことですが、このスクリプトは、@code{gawk}をXMLモードへ切り替えることで始まります。 | |
1138 | +トラバースされるノードの中身については今は関心がありませんので、ノードを見つけた時に実行されるアクションはありません。 | |
1139 | +その最後の部分(XMLファイルは既に閉じられている時)で、成功と失敗を報告する変数をいくつか見ているだけです。 | |
1140 | +もし、@code{XMLERROR}変数に0や空文字列以外のものが入っていれば、エラーが発生していて、パーサは、そのエラーの起きた場所で、ツリーのトラバースを止めています。 | |
1141 | +説明のメッセージが@code{XMLERROR}に入っています(内容は、そのプラットフォームで使われているその特定のパーサに依存します)。 | |
1142 | +例で使われているその他の変数には、そのXMLファイルの形式が間違っている場所の行番号とカラム数が入っています。 | |
1143 | + | |
1069 | 1144 | |
1070 | 1145 | @node Printing an outline of an XML file |
1071 | -@section XML ファイルのアウトラインの表示 | |
1146 | +@section XMLファイルのアウトラインの表示 | |
1072 | 1147 | @pindex @file{outline.awk} |
1073 | -XML を処理していると、XML ファイルの構造をある程度管理する必要があります。 | |
1074 | -普通のエディタならば、@ref{fig:dbfile} にあるような表示や、@ref{fig:docbook_chapter} のような冴えないツリー表示を突き出してきます。 | |
1075 | -ソフトウェア開発者たちは、@ref{fig:ch2_dbfile} にあるような適切にインデントされた状態でテキストファイルを読むことに慣れています。 | |
1148 | + | |
1149 | +XMLを使って作業していると、XMLファイルの構造をある程度注意して見る必要があります。 | |
1150 | +普通のエディタならば、fig:dbfile(@pxref{fig:dbfile})にあるような表示や、fig:docbook_chapter(@pxref{fig:docbook_chapter})のような冴えないツリー表示を突き出してきます。 | |
1151 | +ソフトウェア開発者たちは、fig:ch2_dbfile(@pxref{fig:ch2_dbfile})にあるような適切にインデントされた状態でテキストファイルを読むことに慣れています。 | |
1076 | 1152 | |
1077 | 1153 | @float Figure,fig:ch2_dbfile |
1078 | 1154 | @example |
@@ -1089,17 +1165,17 @@ book lang='en' id='hello-world' | ||
1089 | 1165 | title |
1090 | 1166 | para |
1091 | 1167 | @end example |
1092 | -@caption{適切にインデントされたツリーとしての XML データ (DocBook ファイル)} | |
1168 | +@caption{適切にインデントされたツリーとしてのXMLデータ(DocBookファイル)} | |
1093 | 1169 | @end float |
1094 | 1170 | |
1095 | 1171 | ここで、ノード間の階層的な依存関係を把握するのはわずかに難しくなっています。 |
1096 | -しかし、正しくインデントされていると、100 を超えるエレメントを持つファイルを管理することもできるようになります (そういった大きなファイルを純粋にグラフィカルな表示にしてしまうと耐えられないです)。 | |
1097 | -@ref{fig:ch2_dbfile} は、XML パーサの @uref{http://expat.sourceforge.net, Expat}に付属する @code{outline} ツールに影響されたものです。 | |
1098 | -@code{outline} ツールはそういったインデントされた出力を生成します。 | |
1099 | -今からこの種の出力をまねたスクリプトを書きましょう。 | |
1100 | -@pindex outline, Expat アプリケーション | |
1101 | -@pindex Expat, SAX ライクな API を持つ XML パーサ | |
1102 | -@cindex SAX, XML のシンプルな API | |
1172 | +しかし、正しくインデントされていると、100を超えるエレメントを持つファイルを管理することもできるようになります(そういった大きなファイルを純粋にグラフィカルな表示にしてしまうのは耐えられません)。 | |
1173 | +fig:ch2_dbfile(@pxref{fig:ch2_dbfile})は、XMLパーサの@uref{http://expat.sourceforge.net, Expat}に付属する@code{outline}ツールに影響されたものです。 | |
1174 | +この@code{outline}ツールはそういったインデントされた出力を生成します。 | |
1175 | +ここで、この種の出力をまねたスクリプトを書きましょう。 | |
1176 | +@pindex outline, Expat application | |
1177 | +@pindex Expat, XML parser with SAX-like API | |
1178 | +@cindex SAX, Simple API for XML | |
1103 | 1179 | @cindex @code{XMLATTR} |
1104 | 1180 | |
1105 | 1181 | @float Figure,fig:ch2_outline.awk |
@@ -1112,74 +1188,84 @@ XMLSTARTELEM @{ | ||
1112 | 1188 | print "" |
1113 | 1189 | @} |
1114 | 1190 | @end example |
1115 | -@caption{XML データのツリーのようなアウトラインを生成する @file{outline.awk}} | |
1191 | +@caption{XMLデータのツリーのようなアウトラインを生成する@file{outline.awk}} | |
1116 | 1192 | @end float |
1117 | 1193 | |
1118 | -@ref{fig:ch2_outline.awk} にある @file{outline.awk} ファイルは私たちがこれまで書いてきた他のスクリプトと非常によく似ているように見えます。 | |
1119 | -特に、@file{max_depth.awk} に似ていますね。 | |
1194 | +fig:ch2_outline.awk(@pxref{fig:ch2_outline.awk})にある@file{outline.awk}ファイルは、これまで書いてきた他のスクリプトと非常によく似ているように見えます。 | |
1195 | +特に、@file{max_depth.awk}に似ていますね。 | |
1120 | 1196 | これもノードをトラバースして、トラバースしながらツリーの深さを記憶するものでした。 |
1121 | -最も大きな違いは、@code{print} ステートメントの書いてある行です。 | |
1122 | -最初の時は、@code{XMLSTARTELEM} 変数にタグ名が入っているかどうかまったく調べませんでしたが、ここでは、@code{printf} フォーマットステートメントを使って正しくインデントしながらタグの名前も出力しています (インデントレベルごとに二つの空白を出力しています)。 | |
1197 | +最も大きな違いは、@code{print}ステートメントの書いてある行です。 | |
1198 | +最初の時は、@code{XMLSTARTELEM}変数にタグ名が入っているかどうかまったく調べませんでした。 | |
1199 | +ここでは、@code{printf}フォーマットステートメントを使って、正しくインデントしながらタグの名前も出力しています(インデントレベルごとに二つの空白を出力しています)。 | |
1123 | 1200 | |
1124 | -@file{max_depth.awk} スクリプトの説明の最後で、既に @code{XMLDEPTH} 変数について言及しました。 | |
1125 | -そこで使われていた @code{depth} 変数の代わりにここで使っています。 | |
1126 | -その結果、@code{XMLENDELEM} の後ろのアクションで使われていた @code{depth} の記帳処理はもう必要ではありません。 | |
1127 | -私たちのスクリプトは短くなって、読み易くなりました。 | |
1201 | +@file{max_depth.awk}スクリプトの説明の最後で、@code{XMLDEPTH}変数について既に言及しました。 | |
1202 | +そこで使われていた@code{depth}変数の代わりにここで使っています。 | |
1203 | +その結果、@code{XMLENDELEM}の後ろのアクションで使われていた@code{depth}の記帳処理はもう必要ではありません。 | |
1204 | +スクリプトが短くなって、読み易くなりました。 | |
1128 | 1205 | |
1129 | 1206 | @cindex @code{XMLATTR} |
1130 | -このスクリプトのもう一つの新しい事柄は、@code{XMLATTR} という連想配列です。 | |
1131 | -マークアップされたブロックに入る場合 (そして、@code{XMLSTARTELEM} が空でないとき) はいつでも、@code{XMLATTR} 配列には対象となったタグのアトリビュートが全て入っています。 | |
1207 | +このスクリプトのもう一つの新しい事柄は、@code{XMLATTR}という連想配列です。 | |
1208 | +マークアップされたブロックに入る場合(そして、@code{XMLSTARTELEM}が空でない時)はいつでも、@code{XMLATTR}配列に、対象となったタグのアトリビュートが全て入っています。 | |
1132 | 1209 | 配列のインデックスとしてアトリビュートの名前を指定して配列にアクセスすれば、そのアトリビュートの値を調べることができます。 |
1133 | -整形式の XML ファイルであれば、一つのタグに付けられているアトリビュートの名前は全て異なっていますので、各アトリビュートが配列の中にそれぞれの場所を確保していることは確実なはずです。 | |
1134 | -やり残しているただ一つのことは、この配列のエントリを全てイタレートして、その名前と値をフォーマットして表示することです。 | |
1135 | -このスクリプトの初期のバージョンでは、@command{for (i in XMLATTR)} ループを使ってこの連想配列を本当にイタレートしていました。 | |
1136 | -そうするのは今でも選択肢の一つですが、今回は、元の XML データに出てくるのと全く同じ順序でアトリビュートを確実に表示したいと思いました。 | |
1137 | -アトリビュートの正確な順序は、@code{$1 .. $NF} というフィールドで再生成できます。 | |
1138 | -ですので、この @code{for} ループは @code{$1 .. $NF} というフィールドでアトリビュートの@emph{名前}をイタレートし、アトリビュートの@emph{値} @code{XMLATTR[$i]} を表示することができます。 | |
1210 | +整形式のXMLファイルであれば、一つのタグに付けられているアトリビュートの名前は全て異なっています。 | |
1211 | +そのため、各アトリビュートが、配列の中にそれぞれの場所を確保していることは確実なはずです。 | |
1212 | +ただ一つやり残していることは、この配列のエントリを全てイタレートして、その名前と値をフォーマットして表示することです。 | |
1213 | +このスクリプトの初期バージョンでは、@command{for (i in XMLATTR)}ループを使って、この連想配列を本当にイタレートしていました。 | |
1214 | +そうするのは今でも選択肢としてありますが、今回は、元のXMLデータに出てくるのと全く同じ順序でアトリビュートを確実に表示したいと思いました。 | |
1215 | +アトリビュートの正確な順序は、@code{$1 .. $NF}というフィールドで再生成できます。 | |
1216 | +ですから、この@code{for}ループは、@code{$1 .. $NF}というフィールドでアトリビュートの@emph{名前}をイタレートし、アトリビュートの@emph{値}@code{XMLATTR[$i]}を表示することができます。 | |
1217 | + | |
1139 | 1218 | |
1140 | 1219 | @node Pulling data out of an XML file |
1141 | -@section XML ファイルからのデータの取り出し | |
1220 | +@section XMLファイルからのデータの取り出し | |
1142 | 1221 | @pindex @file{outline_puller.awk} |
1143 | -この @value{SECTION} で私たちが分析するスクリプトは、前の @value{SECTION} のスクリプトと全く同じ出力を生成します。 | |
1144 | -では、二つ目のものが必要なほど何が違うのでしょうか。 | |
1222 | + | |
1223 | +この@value{SECTION}で分析するスクリプトは、前の@value{SECTION}のスクリプトと全く同じ出力を生成します。 | |
1224 | +それでは、二つ目のものが必要なほど何が違うのでしょうか。 | |
1145 | 1225 | それは、目前にあるこの問題を解くのに使われているプログラミングスタイルです。 |
1146 | -前のスクリプトは、@code{XMLSTARTELEM} パターンがその@emph{パターン}の内部に位置するように書かれていました。 | |
1147 | -これは、AWK プログラミングの典型的なスタイルです。 | |
1226 | +前のスクリプトは、@code{XMLSTARTELEM}パターンがその@emph{パターン}の内部に位置するように書かれていました。 | |
1227 | +これは、AWKプログラミングの典型的なスタイルです。 | |
1148 | 1228 | しかし、それは他言語のユーザが育てられた方法ではありません。 |
1149 | -手続型の言語では、ソフトウェアの開発者は、プログラムの内部のコントロールフローを自分自身で決めたいと思っています。 | |
1229 | +手続き型の言語では、ソフトウェアの開発者は、プログラムの内部のコントロールフローを自分自身で決めたいと思っています。 | |
1150 | 1230 | 最初に何をするか、次にどうするか、またその次になどなど、というふうに書きます。 |
1151 | -AWK の@emph{パターンアクション}モデルの場合、まだ慣れていないソフトウェア開発者は、以下のような耐えがたい感覚をよく抱きます。 | |
1231 | +AWKの@emph{パターンアクション}モデルの場合、まだ慣れていないソフトウェア開発者は、以下のような耐えがたい感覚をよく抱きます。 | |
1152 | 1232 | @itemize |
1153 | -@item 自分が@emph{支配}していない | |
1154 | -@item イベントがどこからともなくパチパチと自分に降り掛かるようにみえる | |
1155 | -@item データフローが混沌として見え、不変なものが無い | |
1156 | -@item アサーションが不可能にみえる | |
1233 | +@item 自分が@emph{支配}していない。 | |
1234 | +@item イベントがどこからともなくパチパチと自分に降り掛かるように見える。 | |
1235 | +@item データフローが混沌として見え、不変なものが無い。 | |
1236 | +@item アサーションが不可能に見える。 | |
1157 | 1237 | @end itemize |
1158 | 1238 | |
1159 | -この感覚は、プログラミング環境の種類丸ごとの特徴を示しています。 | |
1160 | -ほとんどの人が、以下のプログラミング環境に何か共通するものがあるとは決して考えないでしょう。 | |
1161 | -しかし共通点があります。 | |
1162 | -それは、これらの環境を一つの屋根の下に結び付ける、静的コントロールフローの不在です。 | |
1239 | +この感覚は、プログラミング環境の種類全体の特徴を示しています。 | |
1240 | +ほとんどの人が、次のプログラミング環境に何か共通するものがあるとは決して考えないでしょう。 | |
1241 | +しかし、共通点があります。 | |
1242 | +これらの環境を一つ屋根の下に結び付ける静的コントロールフローの不在です。 | |
1163 | 1243 | |
1164 | 1244 | @itemize |
1165 | 1245 | @item |
1166 | -X Window System のような GUI フレームワークでは、メインプログラムは小さな@emph{イベントループ}です -- メインプログラムはイベントを待ってイベントハンドラを起動する以外は何もしません。 | |
1246 | +X Window SystemのようなGUIフレームワークでは、メインプログラムは小さな@emph{イベントループ}です。 | |
1247 | +イベントを待ってイベントハンドラを起動する以外はメインプログラムは何もしません。 | |
1248 | + | |
1167 | 1249 | @item |
1168 | -Prolog プログラミング言語では、メインプログラムは@emph{問い合わせ}の式です -- そして Prolog インタプリタは適用するルールを決定して、その問い合わせを解決します。 | |
1250 | +Prologプログラミング言語では、メインプログラムは@emph{問い合わせ}の式です。 | |
1251 | +そして、Prologインタプリタは適用するルールを決定し、その問い合わせを解決します。 | |
1252 | + | |
1169 | 1253 | @item |
1170 | -@code{lex} ツールと @code{yacc} ツールを使ってコンパイラを書く場合、メインプログラムは @code{yyparse()} 関数を起動するだけであって、正確なコントロールフローは、一定のルールの起動を制御する入力ソースに依存します。 | |
1254 | +@code{lex}ツールと@code{yacc}ツールを使ってコンパイラを書く場合、メインプログラムは@code{yyparse()}関数を起動するだけであって、正確なコントロールフローは、特定ルールの起動を制御する入力ソースに依存します。 | |
1255 | + | |
1171 | 1256 | @item |
1172 | -@pindex Expat, SAX ライクな API を持つ XML パーサ | |
1173 | -@uref{http://expat.sourceforge.net, Expat} XML パーサで XML パーサを書く場合、メインプログラムはコールバックハンドラ関数をいくつか登録し、XML ソースを Expat パーサへ渡します。 | |
1174 | -コールバック関数の具体的な起動は XML ソースに依存します。 | |
1257 | +@pindex Expat, XML parser with SAX-like API | |
1258 | +@uref{http://expat.sourceforge.net, Expat} XMLパーサでXMLパーサを書く場合、メインプログラムはコールバックハンドラ関数をいくつか登録し、XMLソースをExpatパーサへ渡します。 | |
1259 | +コールバック関数の具体的な起動はXMLソースに依存します。 | |
1260 | + | |
1175 | 1261 | @item |
1176 | -最後に、AWK の@emph{パターンアクション} はメインプログラムが全く無いスクリプトを書くことを奨励しています。 | |
1262 | +最後に、AWKの@emph{パターンアクション}は、メインプログラムが全く無いスクリプトを書くことを奨励しています。 | |
1177 | 1263 | @end itemize |
1178 | 1264 | |
1179 | -XML のコンテキストの内部で、イベント駆動の@emph{プッシュ}スタイルと手続型の@emph{プル}スタイルを区別する用語が発明されました。 | |
1180 | -前の @value{SECTION} のスクリプトは@emph{プッシュ}型のスクリプトの一例でした。 | |
1181 | -開発者は普通、自分のプログラムのコントロールフローがあれこれ指図されるのを好まないので、ここで一つスクリプトをプレゼントします。 | |
1182 | -このスクリプトは、XML ファイルから一つアイテムを取り出した後また一つ取り出して, | |
1265 | +XMLの脈絡の中で、イベント駆動の@emph{プッシュ}スタイルと手続き型の@emph{プル}スタイルを区別する用語が発明されました。 | |
1266 | +前の@value{SECTION}のスクリプトは、@emph{プッシュ}型のスクリプトの一例でした。 | |
1267 | +開発者は、普通、自分のプログラムのコントロールフローがあれこれ指図されるのを好まないので、ここで一つスクリプトをプレゼントします。 | |
1268 | +このスクリプトは、XMLファイルから一つアイテムを取り出した後、また一つ取り出して, | |
1183 | 1269 | 次にすることをもっと明快に決定するものです。 |
1184 | 1270 | |
1185 | 1271 | @cindex @code{XMLATTR} |
@@ -1200,34 +1286,35 @@ BEGIN @{ | ||
1200 | 1286 | @end example |
1201 | 1287 | |
1202 | 1288 | @cindex @code{XMLEVENT} |
1203 | -@command{getline} コマンドで得たデータから、前のイベントの次の XML イベントが一つ引き出されます。 | |
1289 | +@command{getline}コマンドで得たデータから、前のイベントの次のXMLイベントが一つ引き出されます。 | |
1204 | 1290 | 指の間から砂粒がどんどんこぼれ落ちるような感じです。 |
1205 | -このスタイルの入力の読み方を好むユーザは、もう一つの目新しいものも価値があると思うでしょう。 | |
1206 | -変数 @code{XMLEVENT} です。 | |
1207 | -@ref{fig:ch2_outline.awk} の@emph{プッシュスタイル}のスクリプトがイベント特有の変数 @command{XMLSTARTELEM} を新しい (次の) XML エレメントの存在を検出するのに使うのに対し、この@emph{プルスタイル} のスクリプトはいつも同じ普遍的変数の @code{XMLEVENT} を見て、新しい XML エレメントを検出します。 | |
1208 | -私たちは、@ref{fig:testxml2pgsql.awk.2} のもっと詳細な例を詳しく見ていきます。 | |
1291 | +このスタイルの入力の読み方を好むユーザは、もう一つのノベルティにも価値があると思うでしょう。 | |
1292 | +変数@code{XMLEVENT}です。 | |
1293 | +fig:ch2_outline.awk(@pxref{fig:ch2_outline.awk})の@emph{プッシュスタイル}のスクリプトでは、イベント特有の変数@command{XMLSTARTELEM}を新しい(次の) XMLエレメントの存在を検出するのに使います。 | |
1294 | +それに対し、この@emph{プルスタイル}のスクリプトは、いつも同じ普遍的変数の@code{XMLEVENT}を見て、新しいXMLエレメントを検出します。 | |
1295 | +fig:testxml2pgsql.awk.2(@pxref{fig:testxml2pgsql.awk.2})にあるさらに詳細な例を見ていきます。 | |
1296 | + | |
1297 | +形の上では、必ず起動されるアクションを伴った@code{BEGIN}パターン一つから構成されるスクリプトです。 | |
1298 | +これは、その本質が見えなくなるほど広範に切り詰められた@emph{パターンアクション}モデルのコーナーケースです。 | |
1299 | +(アイテム単位でファイルを読むために、)パターンの代わりに、@code{while}ループに埋めこまれた@command{switch}ステートメントのcaseがあるのが分かります。 | |
1300 | +明かに、前に使った暗黙の条件の代わりに、条件文を今度は明示しています。 | |
1301 | +@code{case}条件の中で起動されるアクションは@emph{プッシュ}のアプローチで見たものと同じです。 | |
1209 | 1302 | |
1210 | -形の上では、必ず起動されるアクションを伴った @code{BEGIN} パターン一つから構成されるスクリプトです。 | |
1211 | -えっと、これはその本質が見えなくなるほど広い範囲で切り詰められた、@emph{パターンアクション}モデルのコーナーケースです。 | |
1212 | -パターンの代わりに、(アイテム単位でファイルを読むために) @code{while} ループに埋めこまれた @command{switch} ステートメントの case があるのがわかります。 | |
1213 | -明かに、前の私たちが使った暗黙のやり方の代わりに、今は条件文を明示的にしています。 | |
1214 | -@code{case} 条件の中で起動されるアクションは@emph{プッシュ}のアプローチで見たものと同じです。 | |
1215 | 1303 | |
1216 | 1304 | @node Character data and encoding of character sets |
1217 | 1305 | @section キャラクタデータと文字セットのエンコーディング |
1218 | -@cindex キャラクタデータ | |
1219 | -@cindex 文字エンコーディング | |
1306 | +@cindex Character Data | |
1307 | +@cindex character encoding | |
1220 | 1308 | |
1221 | -私たちがこれまで見てきた例示したスクリプトには全て共通することがあります。 | |
1222 | -それらは、XML データの木構造にだけ着目していました。 | |
1223 | -タグの間にあるワードを取り扱うものはその中にはありませんでした。 | |
1224 | -@ref{fig:dbfile} にあるもののようなファイルで作業するとき、@ref{fig:docbook_chapter} のノードに埋め込まれたワードにもっと関心がある場合がときどきあります。 | |
1225 | -XML の専門用語では、これらのワードのことを@dfn{キャラクタデータ}と呼びます。 | |
1226 | -DocBook | |
1227 | 1309 | @cindex DocBook |
1228 | -ファイルの場合であれば、タグの間に点々と存在するこれらのワードのことをドキュメント全体の@emph{ペイロード}と呼ぶことができるでしょう。 | |
1229 | -時々、山括弧で括られた役に立たないもの全てからこのペイロードを自由にして、ファイルからキャラクタデータを抜き出すことに関心があることがあります。 | |
1230 | -ドキュメントの構造は失なわれるかもしれませんが、ASCII で書かれた生のテキスト内容が露になって、XML を解しないアプリケーションソフトウェアにそれをインポートする準備ができます。 | |
1310 | +これまで見てきた例示スクリプト全てには共通することがあります。 | |
1311 | +それらは、XMLデータの木構造にだけ着目していました。 | |
1312 | +タグの間にあるワードを取り扱うものはその中にはありませんでした。 | |
1313 | +fig:dbfile(@pxref{fig:dbfile})にあるようなファイルで作業する場合、fig:docbook_chapter(@pxref{fig:docbook_chapter})のノードに埋め込まれたワードの方に関心があることもあります。 | |
1314 | +XMLの専門用語では、これらのワードのことを@dfn{キャラクタデータ}と呼びます。 | |
1315 | +DocBookファイルの場合であれば、タグの間に点々と存在するこれらのワードのことをドキュメント全体の@emph{ペイロード}と呼ぶことができるでしょう。 | |
1316 | +山括弧で括られた役に立たないもの全てからこのペイロードを自由にして、ファイルからキャラクタデータを抜き出すことに関心がある場合があります。 | |
1317 | +ドキュメントの構造は失なわれるかもしれませんが、ASCIIで書かれた生のテキスト内容が露になって、XMLを解しないアプリケーションソフトウェアにそれをインポートする準備ができます。 | |
1231 | 1318 | |
1232 | 1319 | @float Figure,fig:ch2_dbcharacters |
1233 | 1320 | @smallexample |
@@ -1251,12 +1338,12 @@ Warning | ||
1251 | 1338 | |
1252 | 1339 | This is still under construction. |
1253 | 1340 | @end smallexample |
1254 | -@caption{DocBook ファイルから取り出したテキストデータの例} | |
1341 | +@caption{DocBookファイルから取り出したテキストデータの例} | |
1255 | 1342 | @end float |
1256 | 1343 | |
1257 | 1344 | テキストが書かれている行の間にある空行がどこから来たものなのか不思議に思うかもしれません。 |
1258 | -これらはその XML ファイルの一部です。 | |
1259 | -XML の、タグの外にある各改行は (タグの閉じ山括弧の後のものですら) キャラクタデータです。 | |
1345 | +これらの空行はXMLファイルの一部です。 | |
1346 | +XMLにおいて、タグの外にある各改行は、タグの閉じ山括弧の後のものであっても、キャラクタデータです。 | |
1260 | 1347 | このような出力を生成するスクリプトは極めて簡単です。 |
1261 | 1348 | |
1262 | 1349 | @pindex @file{extract_characters.awk} |
@@ -1266,149 +1353,160 @@ XML の、タグの外にある各改行は (タグの閉じ山括弧の後の | ||
1266 | 1353 | XMLCHARDATA @{ printf $0 @} |
1267 | 1354 | @end example |
1268 | 1355 | @cindex @code{XMLCHARSET} |
1269 | -@caption{XML ファイルからテキストデータを抽出する @file{extract_characters.awk}} | |
1356 | +@caption{XMLファイルからテキストデータを抽出する@file{extract_characters.awk}} | |
1270 | 1357 | @end float |
1271 | 1358 | |
1272 | -キャラクタデータがパースされる毎に、@code{XMLCHARDATA} パターンが 1 にセットされ、キャラクタデータそのものは変数 @code{$0} に格納されます。 | |
1273 | -少し独特なのは、そのテキストは @code{$0} に格納されるのであって、@code{XMLCHARDATA} の中では無いということです。 | |
1274 | -テキスト処理をするとき、インタプリタが XML モードでないときに AWK がするように、テキストをフィールドに分割する必要がしばしば出てきます。 | |
1275 | -@code{$1} @dots{} @code{$NF} というフィールドに格納されているワードで、分割されたワードを再び参照する方法を今は知っています。 | |
1276 | -上のスクリプトを拡張して、ワードを、@file{wc.awk} スクリプトでしたように数えるようにするのは簡単でしょう。 | |
1359 | +キャラクタデータがパースされる毎に、@code{XMLCHARDATA}パターンが1にセットされ、キャラクタデータそのものは変数@code{$0}に格納されます。 | |
1360 | +少し独特なのは、そのテキストは@code{$0}に格納されるのであって、@code{XMLCHARDATA}の中では無いということです。 | |
1361 | +テキスト処理をする時、インタプリタがXMLモードでない時にAWKがするように、テキストをフィールドに分割する必要があることもあります。 | |
1362 | +@code{$1} @dots{} @code{$NF}というフィールドに格納されているワードを使えば、分割されたワードを再び参照できることがここで分かりました。 | |
1363 | +上のスクリプトを拡張して、@file{wc.awk}スクリプトで行ったようにワードを数えるようにするのは簡単でしょう。 | |
1277 | 1364 | |
1278 | -ほとんどのテキストが、@ref{fig:ch2_dbcharacters} ほど単純というわけではありません。 | |
1279 | -コンピュータにおけるテキストデータというのは 26 文字に限られているわけでなく、さらに区切り記号もいくつかあります。 | |
1280 | -あらゆるキーボードには様々な種類の括弧 (< とか [、@{) があって、また、ヨーロッパでは、合字 (@AE{}) やウムラウト (@"u) のようなものが数世紀に渡って使われてきました。 | |
1281 | -記号が何千もあるということ自体は問題ではありませんが、ソフトウェアアプリケーションがこういった記号を異なったバイト (またはバイト列でも) で表現しはじめると問題となりました。 | |
1282 | -今日、世界中の全ての記号をバイト列で表現するスタンダードがあります。 | |
1283 | -@uref{http://www.unicode.org/versions/Unicode4.0.0, Unicode} です。 | |
1284 | 1365 | @cindex Unicode |
1285 | -@cindex 文字セット | |
1286 | -残念なことに、この受け入れられたスタンダードはやって来るのが遅すぎました。 | |
1287 | -早い段階の標準化の努力で、完全なシンボルセットのサブセットを表現する方法が複数作られました。 | |
1288 | -それぞれのサブセットは 1 バイトで表現できる 256 個のシンボルを含んでいました。 | |
1289 | -こういったサブセットには、現在も使われている名前が付けられました (ISO-8859-1 や IBM-852、ISO-2022-JP のように)。 | |
1290 | -それから、1 文字 16 ビットの @code{char} データ型を持つプログラミング言語 Java が登場しました。 | |
1291 | -しかし、16 ビットでも全ての記号を表現するのに十分ではないことがわかりました。 | |
1292 | -16 ビットで固定された文字は失敗だとわかったので、標準化団体は最後に、現在の Unicode スタンダードを規定しました。 | |
1293 | -現在の Unicode 文字セットは素晴しい記号のカタログを持っています -- 上述の本は、文字記号をすべて一覧するの 1000 ページ以上を要しています。 | |
1294 | - | |
1295 | -さて、Unicode の不恰好なところです。 | |
1366 | +@cindex character set | |
1367 | +ほとんどのテキストが、fig:ch2_dbcharacters(@pxref{fig:ch2_dbcharacters})ほど単純というわけではありません。 | |
1368 | +コンピュータにおけるテキストデータというのは26文字に限られているわけでなく、さらに区切り記号もいくつかあります。 | |
1369 | +どのキーボードにも様々な種類の括弧(<とか[、@{)があって、また、ヨーロッパでは、合字(@AE{})やウムラウト(@"u)のようなものが数世紀に渡って使われてきました。 | |
1370 | +記号が何千もあるということ自体は問題ではありませんが、ソフトウェアアプリケーションがこういった記号を違うバイト(または、バイト列)で表現しはじめると問題となりました。 | |
1371 | +今日、世界中の全ての記号をバイト列で表現するスタンダードがあります。 | |
1372 | +@uref{http://www.unicode.org/versions/Unicode4.0.0, Unicode}です。 | |
1373 | +残念ですが、この認められたスタンダードは登場するのが遅すぎました。 | |
1374 | +それ以前の標準化の努力によって、完全なシンボルセットのサブセットを表現する方法が複数作られました。 | |
1375 | +それぞれのサブセットは1バイトで表現できる256個のシンボルを含んでいました。 | |
1376 | +こういったサブセットに付けられた名前は現在も使われています(ISO-8859-1やIBM-852、ISO-2022-JPのように)。 | |
1377 | +それから、1文字16ビットの@code{char}データ型を持つプログラミング言語Javaが登場しました。 | |
1378 | +しかし、16ビットでも全ての記号を表現するのに十分ではないことが分かりました。 | |
1379 | +16ビットで固定された文字は失敗だと分かったので、標準化団体は、最後に、現在のUnicodeスタンダードを規定しました。 | |
1380 | +現在のUnicode文字セットは素晴しい記号カタログを備えています。 | |
1381 | +上述の本の場合、文字記号をすべて一覧するのに1000ページ以上を要しています。 | |
1382 | + | |
1383 | +さて、以下は、Unicodeの不恰好なところです。 | |
1384 | + | |
1296 | 1385 | @itemize |
1297 | 1386 | @item |
1298 | -8 ビットの文字セットの名前がまだ使われていて、XML パーサやその XML パーサを利用したソフトウェアでサポートしなければなりません。 | |
1387 | +8ビットの文字セットの名前がまだ使われていて、XMLパーサやそのXMLパーサを利用したソフトウェアでサポートしなければなりません。 | |
1388 | + | |
1299 | 1389 | @item |
1300 | -Unicode のカタログにある文字記号ははっきりした数値を持っていますが、その数値は、一文字当りのバイト数が変わる多くのやり方でエンコードされることがあります。 | |
1390 | +Unicodeのカタログにある文字記号は明確な数値を持っています。 | |
1391 | +しかし、その数値をエンコードする場合、多くの方法があって、一文字当りのバイト数が変わってしまうことがあります。 | |
1392 | + | |
1301 | 1393 | @item |
1302 | -テキストを表示するとき、どのエンコーディングを使用するか決めないといけません。 | |
1394 | +テキストを表示する時、どのエンコーディングを使用するか決めないといけません。 | |
1303 | 1395 | もしテキストに違うエンコードがなされていれば、夢にも思わない奇妙なシンボルを見ることになるでしょう。 |
1304 | 1396 | @end itemize |
1305 | -@cindex 文字セット | |
1306 | 1397 | |
1307 | -注意が必要ですが、@emph{文字セット}と@emph{文字エンコーディング}はまったく異なる概念です。 | |
1308 | -前者は数学的な概念で言う集合で、後者は、文字が持つ数値を可変長のバイト列へマッピングする方法です。 | |
1398 | +@cindex character encoding | |
1399 | +注意が必要ですが、@emph{文字セット}と@emph{文字エンコーディング}は全く異なる概念です。 | |
1400 | +前者は、数学的な概念で言う集合のことです。 | |
1401 | +後者は、文字が持つ数値を、可変長のバイト列へマッピングする方法です。 | |
1309 | 1402 | 悪いことに、これらの用語の使い方は首尾一貫していません。 |
1310 | -XML の仕様書でも紹介した文献でもこれらの用語は明確に区別されてはいません。 | |
1311 | -たとえば、O'Reilly の素晴しい本 @uref{http://www.oreilly.com/catalog/xmlnut3/, XML in a Nutshell} の @uref{ http://safari.oreilly.com/0596002920/xmlnut2-CHP-5-SECT-2, chapter 5.2} を引用しますので見てください。 | |
1312 | - | |
1403 | +XMLの仕様書でも、紹介した文献でも、これらの用語は明確に区別されてはいません。 | |
1404 | +例えば、O'Reillyの素晴しい本@uref{http://www.oreilly.com/catalog/xmlnut3/, XML in a Nutshell}の@uref{ http://safari.oreilly.com/0596002920/xmlnut2-CHP-5-SECT-2, chapter 5.2}を以下に引用しますので見てください。 | |
1313 | 1405 | |
1314 | 1406 | @quotation |
1315 | 1407 | 5.2 エンコーディング宣言 |
1316 | 1408 | |
1317 | -XML ドキュメントはすべて、XML 宣言の一部として、@emph{エンコーディング宣言}を持つべきです。 | |
1409 | +XMLドキュメントは、XML宣言の一部として、@emph{エンコーディング宣言}を全て持つべきです。 | |
1318 | 1410 | エンコーディング宣言は、そのドキュメントがどの文字セットで書かれているかをパーサに知らせるものです。 |
1319 | 1411 | そのファイル外部の他のメタデータが利用できない場合にだけ使われます。 |
1320 | -例えば、次の XML 宣言は、ドキュメントが US-ASCII 文字エンコーディングを使うということを言っています。 | |
1412 | +例えば、次のXML宣言は、ドキュメントがUS-ASCII文字エンコーディングを使うということを言っています。 | |
1321 | 1413 | |
1322 | 1414 | @code{<?xml version="1.0" encoding="US-ASCII" standalone="yes"?>} |
1323 | 1415 | |
1324 | -次のものは、ドキュメントが Latin-1 文字セットを使っていることを述べています。 | |
1325 | -もっとも、より公式な名前の ISO-8859-1 を使っていますが。 | |
1416 | +次のものは、ドキュメントがLatin-1文字セットを使っていることを述べています。 | |
1417 | +もっとも、より公式な名前のISO-8859-1を使っていますが。 | |
1326 | 1418 | |
1327 | 1419 | @code{<?xml version="1.0" encoding="ISO-8859-1"?>} |
1328 | 1420 | |
1329 | 1421 | @cindex @code{UTF-8} |
1330 | 1422 | @cindex @code{UTF-16} |
1331 | -メタデータが利用できなくても、ドキュメントが Unicode | |
1332 | 1423 | @cindex Unicode |
1333 | -の UTF-8 エンコーディングか UTF-16 エンコーディングで書かれていれば、エンコーディング宣言を省略することができます。 | |
1334 | -UTF-8 というのは ASCII の厳密なスーパーセットですので、ASCII ファイルは、エンコーディング宣言が無くても規則に則った XML ドキュメントです。 | |
1335 | - | |
1424 | +メタデータが利用できなくても、UnicodeのUTF-8エンコーディングか、UTF-16エンコーディングでドキュメントが書かれていれば、エンコーディング宣言を省略することができます。 | |
1425 | +UTF-8というのはASCIIの厳密なスーパーセットですので、ASCIIファイルは、エンコーディング宣言が無くても、規則に則ったXMLドキュメントです。 | |
1336 | 1426 | @end quotation |
1337 | 1427 | |
1338 | -何度か、文字セットの名前がエンコーディング宣言に当てがわれています。 | |
1339 | -この本がそのようにしていますし、XML のサンプルもそうしています。 | |
1340 | -最後の段落だけ用語の使い方がきれいです。 | |
1341 | -UTF-8 は、文字をバイト列へエンコーディングするデフォルトの方法です。 | |
1428 | +何度か、文字セットの名前がエンコーディング宣言に割り当てられています。 | |
1429 | +この本がそのようにしていますし、XMLのサンプルもそのようになっています。 | |
1430 | +最後の段落だけ用語の使い方がきちんとしています。 | |
1431 | +UTF-8は、文字をバイト列へエンコーディングするデフォルトの方法です。 | |
1342 | 1432 | |
1343 | -西洋社会におけるテキストデータの文化史へのこの不愉快な逸脱の後は、@code{gawk} へ戻って、エンコーディングと文字セットの概念がこの言語の中にどのように取り入れられているかを見てみましょう。 | |
1433 | +西洋社会におけるテキストデータの文化史の話へと不愉快にも脱線してしまいました。 | |
1434 | +@code{gawk}へ戻って、エンコーディングと文字セットの概念が、この言語の中にどのように取り入れられているかを見てみましょう。 | |
1344 | 1435 | @cindex @code{XMLATTR["ENCODING"]} |
1345 | 1436 | @cindex @code{XMLDECLARATION} |
1346 | 1437 | @cindex @code{XMLCHARSET} |
1347 | -@cindex @code{LANG}, 環境変数 | |
1348 | -知っておく必要があるのは三つの変数で全てですが、それらの変数はそれぞれ別々のコンテキストから来ています。 | |
1349 | -XML ドキュメントと、@code{gawk} 内部のデータの扱いと、@emph{ロケール}を設定するシェル環境の影響、この三者の間の違いについての認識に注意してください。 | |
1438 | +@cindex @code{LANG}, environment variable | |
1439 | +知っておく必要があるのは三つの変数で全てです。 | |
1440 | +変数は、別々のコンテキストからそれぞれ来ています。 | |
1441 | +XMLドキュメント、@code{gawk}内部のデータ処理、@emph{ロケール}を設定するシェル環境の影響、この三者の間の違いについての認識に注意するようにしてください。 | |
1350 | 1442 | |
1351 | 1443 | @itemize |
1352 | 1444 | @item |
1353 | -@code{XMLATTR["ENCODING"]} はパターン変数で、(空で無く、@code{XMLDECLARATION} がトリガーされているとき) その XML ファイルがエンコードされている元の文字エンコーディングの名前が入っています。 | |
1354 | -この情報は、(通常の XML ヘッダがあれば) XML ファイルの最初の行から得られます。 | |
1445 | +@code{XMLATTR["ENCODING"]}はパターン変数です。 | |
1446 | +(空で無く、@code{XMLDECLARATION}がトリガーされている時、)XMLファイルがエンコードされている元の文字エンコーディングの名前が入っています。 | |
1447 | +この情報は、通常のXMLヘッダがあれば、XMLファイルの最初の行から得られます。 | |
1355 | 1448 | この変数を上書きしても役に立ちません。 |
1356 | -この変数は、XML データに何が入っているのかを示すもので、@code{XMLATTR["ENCODING"]} を変更しても何も起きません。 | |
1449 | +この変数は、XMLデータに何が入っているのかを示すもので、@code{XMLATTR["ENCODING"]}を変更しても何も起きません。 | |
1450 | + | |
1357 | 1451 | @item |
1358 | -@code{XMLCHARSET} は、あなた自身が選んだ文字セットへ変換された XML データを見たい場合に変更する変数です。 | |
1359 | -この変数をセットすると、@code{gawk} インタプリタが選択した文字コードを記憶します。 | |
1360 | -しかし、こうして選択したものは次のファイルを開くときにだけ効果を持つでしょう。 | |
1361 | -@code{XMLCHARSET} を変更しても、その前に読み込みのために既に開いていたファイルの XML データには影響しません。 | |
1452 | +@code{XMLCHARSET}は、選択した文字セットへ変換されたXMLデータを見たい場合に変更する変数です。 | |
1453 | +この変数をセットすると、@code{gawk}インタプリタが選択した文字コードを記憶します。 | |
1454 | +しかし、こうして選択したものは、次のファイルを開く時にだけ効果を持ちます。 | |
1455 | +@code{XMLCHARSET}を変更しても、その前に読み込みのために既に開いていたファイルのXMLデータには影響しません。 | |
1456 | + | |
1362 | 1457 | @item |
1363 | -@code{LANG} は、オペレーティングシステムの環境変数です。 | |
1364 | -ユーザスクリプトの中で何も指定していない場合、起動時の @code{XMLCHARSET} の値として @code{gawk} インタプリタに通知されるものです。 | |
1365 | -@code{LANG} に対する設定が無い場合は、@code{US-ASCII} がデフォルトエンコーディングとして使用されます。 | |
1366 | -ここまでずっと、処理されるデータのエンコーディングと文字セットについて話してきました。 | |
1458 | +@code{LANG}は、オペレーティングシステムの環境変数です。 | |
1459 | +ユーザスクリプトの中で何も指定していない場合、起動時の@code{XMLCHARSET}の値として@code{gawk}インタプリタに通知されるものです。 | |
1460 | +@code{LANG}に対する設定が無い場合は、デフォルトエンコーディングとして@code{US-ASCII}が使用されます。 | |
1461 | +ここまで、処理されるデータのエンコーディングと文字セットについてずっと話してきました。 | |
1367 | 1462 | ここで、プログラムのソースも何らかの文字セットで書かれるということを思い出してください。 |
1368 | -プログラムを書くのに使われるのは通常、@code{LANG} の文字セットです。 | |
1369 | -あなたのネイティブキャラクタセットの文字を含んだプログラムがあった場合何が起きるかを想像してみてください。 | |
1370 | -そのために、実行時に使うキャラクタセットにエンコーディングがありません。 | |
1371 | -注意深い読者ならば、文字エンコーディングと文字セットを混同する Unicode | |
1463 | +通常、プログラムを書くのに使われるのは@code{LANG}の文字セットです。 | |
1464 | +ユーザのネイティブ文字セットの文字を含んだプログラムがあった場合、何が起きるかを想像してみてください。 | |
1465 | +そのために、実行時に使われる文字セットにはエンコーディングがありません。 | |
1372 | 1466 | @cindex Unicode |
1373 | -の伝統に従って、@code{gawk} がどういう結果を生じさせるか気が付くでしょう。 | |
1467 | +注意深い読者ならば、文字エンコーディングと文字セットを混同するUnicodeの伝統に従って、@code{gawk}がどういう結果を生じさせるか分かるでしょう。 | |
1374 | 1468 | @end itemize |
1375 | 1469 | |
1376 | -非常に多くの学者的な推理をしたあと、(まごまごしている初心者を除けば) 文字セットとエンコーディングが実生活ではほとんど役立たないというふうに考えるほうに気持ちが傾くかもしれません。 | |
1377 | -次の例はあなたの持つ疑問を払拭するはずです。 | |
1378 | -実生活では、良識的な推理を超越した状況によって、@ref{fig:ch2_dbcharacters} にあるテキストを Microsoft Windows のアプリケーションにインポートするよう強いられるかもしれません。 | |
1470 | +非常に多くの学者的な推理をした後ならば、(まごまごしている初心者を除けば)文字セットとエンコーディングが実生活ではほとんど役立たないというふうに考えるほうに気持ちが傾くかもしれません。 | |
1471 | +次の例は疑念を払拭するはずです。 | |
1472 | +実生活では、良識的な推理を超越した状況によって、fig:ch2_dbcharacters(@pxref{fig:ch2_dbcharacters})のテキストを、Microsoft Windowsのアプリケーションにインポートするよう強いられるようなことがあるかもしれません。 | |
1379 | 1473 | @cindex Microsoft Windows |
1380 | 1474 | @cindex @code{UTF-16} |
1381 | 1475 | @cindex @code{US-ASCII} |
1382 | -今の各種の Microsoft Windows は、@code{UTF-16} でテキストデータを格納するのを優先しています。 | |
1383 | -ですので、テキストを @code{UTF-16} へ変換するスクリプトは、持っているとナイスなツールとなるでしょう。 | |
1384 | -そして、既にあなたはそのようなツールを持っています。 | |
1385 | -DocBook ファイルを読む際に、@code{UTF-16} エンコーディングを使うように @code{gawk} インタプリタに指示すれば、@ref{fig:extract_characters.awk} にある @file{extract_characters.awk} スクリプトがそのような仕事をします。 | |
1386 | -この目標に達するのに取り得る手段が二つあります。 | |
1476 | +現在の各Microsoft Windowsは、@code{UTF-16}でテキストデータを格納するのを優先しています。 | |
1477 | +ですから、テキストを@code{UTF-16}へ変換するスクリプトは、持っているとナイスなツールとなるでしょう。 | |
1478 | +そして、そのようなツールは既にあります。 | |
1479 | +DocBookファイルを読む際に、@code{UTF-16}エンコーディングを使うように@code{gawk}インタプリタに指示すれば、fig:extract_characters.awk(@pxref{fig:extract_characters.awk})の@file{extract_characters.awk}スクリプトがそのような仕事をします。 | |
1480 | +この目標を達成するには、取り得る手段が次のように二つあります。 | |
1481 | + | |
1387 | 1482 | @itemize |
1388 | 1483 | @item |
1389 | -スクリプトを変更して、@code{XMLCHARSET} を @code{UTF-16} へセットする行を挿入します。 | |
1390 | -起動後、@code{gawk} インタプリタは、 @ref{fig:ch2_dbcharacters} にあるのと同じデータではあるが、@code{UTF-16} に変換されたものを表示します。 | |
1391 | -to @code{UTF-16}. | |
1484 | +スクリプトを変更して、@code{XMLCHARSET}を@code{UTF-16}へセットする行を挿入します。 | |
1485 | +起動後、@code{gawk}インタプリタは、fig:ch2_dbcharacters(@pxref{fig:ch2_dbcharacters})にあるのと同じデータですれども、@code{UTF-16}に変換されたものを表示します。 | |
1486 | + | |
1392 | 1487 | @example |
1393 | 1488 | BEGIN @{ XMLCHARSET="utf-16" @} |
1394 | 1489 | @end example |
1490 | + | |
1395 | 1491 | @item |
1396 | -スクリプトは変更せずに、@code{gawk} インタプリタを起動する前に、@code{LANG} 環境変数を @code{UTF-16} にセットします。 | |
1492 | +スクリプトは変更せずに、@code{gawk}インタプリタを起動する前に、@code{LANG}環境変数を@code{UTF-16}にセットします。 | |
1397 | 1493 | @end itemize |
1398 | -オペレーティングシステムがこれらの文字セットとエンコーディングをサポートしていれば、どちらの場合も結果は同じです。 | |
1399 | -コマンドラインシェルのレベルでの変更が必要なので (しかも副作用の可能性もあるので)、実際には恐らく、これらのうち 2 番目のアプローチは避けるほうが良いです。 | |
1494 | + | |
1495 | +オペレーティングシステムが、これらの文字セットとエンコーディングをサポートしていれば、どちらの場合も結果は同じです。 | |
1496 | +コマンドラインシェルのレベルでの変更が必要なので(しかも、副作用の可能性もあるので)、実際には、恐らく、これらのうち2番目のアプローチは避けたほうが良いです。 | |
1497 | + | |
1400 | 1498 | |
1401 | 1499 | @node Dealing with DTDs |
1402 | -@section DTD の取り扱い | |
1500 | +@section DTDの取り扱い | |
1403 | 1501 | @cindex DTD, Document Type Definition |
1404 | 1502 | |
1405 | -この @value{CHAPTER} の最初の方で、@code{gawk} は DTD に対して XML データの妥当性を検証しないということを見ました。 | |
1406 | -XML ファイルのヘッダにあるドキュメントタイプの宣言は、データの中のあっても無くても良い部分で、強制的なものではありません。 | |
1407 | -(@ref{fig:dbfile} にあるように) もしそのような宣言が存在している場合、その DTD への参照は解決されず、その内容はパースされないでしょう。 | |
1408 | -しかしながら、宣言の存在は @code{gawk} によって報告されます。 | |
1409 | -宣言が始まると、@code{XMLSTARTDOCT} 変数にルートエレメントのタグの名前が入ります。 | |
1410 | -そしてその後、宣言が終了するとき、@code{XMLENDDOCT} 変数が 1 にセットされます。 | |
1411 | -その間、@code{XMLATTR} 配列変数には、(もしあれば) DTD の public 識別子の値と、(もしあれば) DTD の SYSTEM の識別子の値が投入されます。 | |
1503 | +この@value{CHAPTER}の最初の方で、@code{gawk}は、DTDに対してXMLデータの妥当性を検証しないということを見ました。 | |
1504 | +XMLファイルのヘッダにあるドキュメントタイプの宣言は、データの中のあっても無くても良い部分であって、強制的なものではありません。 | |
1505 | +fig:dbfile(@pxref{fig:dbfile})にあるように、そのような宣言が存在している場合、そのDTDへの参照は解決されず、その内容はパースされないでしょう。 | |
1506 | +しかしながら、宣言の存在は@code{gawk}によって報告されます。 | |
1507 | +宣言が始まると、@code{XMLSTARTDOCT}変数にルートエレメントのタグの名前が入ります。 | |
1508 | +そして、その後、宣言が終了する時、@code{XMLENDDOCT}変数が1にセットされます。 | |
1509 | +その間、@code{XMLATTR}配列変数には、(もしあれば)DTDのpublic識別子の値と(もしあれば)DTDのSYSTEMの識別子の値が入れられます。 | |
1412 | 1510 | @cindex @code{XMLATTR} |
1413 | 1511 | @cindex @code{XMLATTR["VERSION"]} |
1414 | 1512 | @cindex @code{XMLATTR["ENCODING"]} |
@@ -1416,7 +1514,7 @@ XML ファイルのヘッダにあるドキュメントタイプの宣言は、 | ||
1416 | 1514 | @cindex @code{XMLATTR["PUBLIC"]} |
1417 | 1515 | @cindex @code{XMLATTR["SYSTEM"]} |
1418 | 1516 | @cindex @code{XMLATTR["INTERNAL_SUBSET"]} |
1419 | -宣言の他の部分 (エレメントやアトリビュート、実体) はレポートされません。 | |
1517 | +宣言の他の部分(エレメント、アトリビュート、実体)はレポートされません。 | |
1420 | 1518 | |
1421 | 1519 | @pindex @file{db_version.awk} |
1422 | 1520 | @float Figure,fig:db_version.awk |
@@ -1447,25 +1545,26 @@ XMLENDDOCT @{ | ||
1447 | 1545 | root = pub_id = sys_id = intsubset "" |
1448 | 1546 | @} |
1449 | 1547 | @end example |
1450 | -@caption{XML ファイルの DTD に関する詳細を抽出する @file{db_version.awk}} | |
1548 | +@caption{XMLファイルのDTDに関する詳細を抽出する@file{db_version.awk}} | |
1451 | 1549 | @end float |
1452 | 1550 | |
1453 | -データそのものに関心があるだけであれば、ほとんどのユーザはこれらの変数を安全に無視することができます。 | |
1454 | -しかし、XML データの要求をチェックするためにこの変数を利用するユーザもいるかもしれません。 | |
1455 | -出所がさまざまな何千もの XML ファイルでデータベースが構成されていた場合、それらのファイルの DTD の public 識別子が、処理しなければならないデータの種類を監視し、起こり得るバージョンの競合を監視する助けとなるでしょう。 | |
1456 | -@ref{fig:db_version.awk} のスクリプトは、データファイルを解析するのを助けます。 | |
1457 | -上で述べた変数を探して、その内容を評価するものです。 | |
1458 | -DTD の最初で、ルートエレメントのタグ名を保存します。 | |
1459 | -識別子もまた保存し、最後にそれらの値を、解析されたファイルの名前とともに表示します。 | |
1460 | -DTD それぞれが終わるたび、次のファイルの DTD が表われるまで、記憶された値は空文字列へとセットされます。 | |
1461 | - | |
1462 | -@ref{fig:ch2_DTD_details} には @ref{fig:db_version.awk} のスクリプトの出力例があります。 | |
1463 | -出力の最初のエントリは、既に私たちが知っている @ref{fig:dbfile} のファイルです。 | |
1464 | -もちろん、スイスの CERN にある DTD のローカルコピーに対して妥当性を検証しなければならない @code{book} エレメントを含む DocBook ファイル (English version 4.2) が最初のエントリです。 | |
1551 | +データそのものに関心があるだけであれば、ほとんどのユーザは、これらの変数を安全に無視することができます。 | |
1552 | +しかし、XMLデータの要求をチェックするためにこの変数を利用するユーザもいるかもしれません。 | |
1553 | +出所がさまざまな何千ものXMLファイルでデータベースが構成されていた場合、それらのファイルのDTDのpublic識別子が、処理しなければならないデータの種類を監視し、起こり得るバージョンの競合を監視する助けとなるでしょう。 | |
1554 | +fig:db_version.awk(@pxref{fig:db_version.awk})のスクリプトは、データファイルを解析するのを助けます。 | |
1555 | +このスクリプトは、上で述べた変数を探して、その内容を評価するものです。 | |
1556 | +DTDの最初で、ルートエレメントのタグ名を保存します。 | |
1557 | +識別子もまた保存し、最後に、それらの値を、解析されたファイルの名前とともに表示します。 | |
1558 | +DTDがそれぞれ終わるたび、次のファイルのDTDが現われるまで、記憶された値は空文字列へとセットされます。 | |
1559 | + | |
1560 | +fig:ch2_DTD_details(@pxref{fig:ch2_DTD_details})には、fig:db_version.awk(@pxref{fig:db_version.awk})のスクリプトの出力例があります。 | |
1561 | +出力の最初のエントリは、既知のfig:dbfile(@pxref{fig:dbfile})のファイルです。 | |
1465 | 1562 | @cindex DocBook |
1466 | -2 番目のファイルは、インターネット上の DTD に対して妥当性を検証される、DocBook (English version 4.1.2) の @code{chapter} エレメントです。 | |
1467 | -最後に、3 番目のエントリは、GanttProject アプリケーションのプロジェクトを説明するファイルです。 | |
1468 | -ルートエレメントを指定するためのタグ名があるだけで、DTD が存在するようには見えません。 | |
1563 | +もちろん、最初のエントリは@code{book}エレメントを含むDocBookファイル(English version 4.2)です。 | |
1564 | +このエレメントは、スイスのCERNにあるDTDのローカルコピーに対して妥当性を検証しなければなりません。 | |
1565 | +2番目のファイルは、DocBook(English version 4.1.2)の@code{chapter}エレメントで、インターネット上のDTDに対して妥当性を検証されます。 | |
1566 | +最後に、3番目のエントリは、GanttProjectアプリケーションのプロジェクトを説明するファイルです。 | |
1567 | +ルートエレメントを指定するためのタグ名があるだけで、DTDが存在するようには見えません。 | |
1469 | 1568 | |
1470 | 1569 | @float Figure,fig:ch2_DTD_details |
1471 | 1570 | @smallexample |
@@ -1496,51 +1595,59 @@ data/exampleGantt.gan | ||
1496 | 1595 | system id '' |
1497 | 1596 | intsubset '' |
1498 | 1597 | @end smallexample |
1499 | -@caption{いくつかの XML における DTD に関する詳細} | |
1598 | +@caption{いくつかのXMLにおけるDTDに関する詳細} | |
1500 | 1599 | @end float |
1501 | 1600 | |
1502 | -日々の作業で必要である場合、このスクリプトを変更したいと思うかもしれません。 | |
1503 | -例えば、このスクリプトは現在、DTD の宣言を持たないファイルについて何も報告しません。 | |
1504 | -@code{root} 変数、@code{pub_id} 変数、@code{sys_id} 変数が全て空である場合に報告する @code{END} ルールにアクションを追加すれば、変更は容易です。 | |
1505 | -また、DTD というのは XML ファイルの常に先頭で、ルートエレメントの前にあるものなんですけれども、このスクリプトは、そのままであれば XML ファイル全体をパースします。 | |
1506 | -ルートエレメントのパースは不要で、最初のエレメント (ルートエレメント) が出現したときにパースするのを止めるよう指示すれば、このスクリプトの速度をかなり改善することができます。 | |
1601 | +日々の作業で必要であれば、このスクリプトを変更したいと思うでしょう。 | |
1602 | +例えば、このスクリプトは、現在、DTDの宣言を持たないファイルについて何も報告しません。 | |
1603 | +この変更は容易です。 | |
1604 | +@code{root}変数、@code{pub_id}変数、@code{sys_id}変数が全て空の場合にそれを報告する@code{END}ルールに対し、アクションを追加するようにします。 | |
1605 | +また、DTDというのは、XMLファイルの先頭で、ルートエレメントの前に常にあるものです。 | |
1606 | +このスクリプトは、そのままであれば、XMLファイル全体をパースします。 | |
1607 | +ルートエレメントのパースは不要です。 | |
1608 | +最初のエレメント(ルートエレメント)が出現した時に、パースするのを止めるよう指示すれば、このスクリプトの速度をかなり改善することができます。 | |
1609 | + | |
1507 | 1610 | @example |
1508 | 1611 | @code{ XMLSTARTELEM @{ nextfile @} } |
1509 | 1612 | @end example |
1510 | 1613 | |
1614 | + | |
1511 | 1615 | @page |
1512 | 1616 | @node Sorting out all kinds of data from an XML file |
1513 | -@section XML ファイルのデータ全種類の処理 | |
1514 | - | |
1515 | -あなたがここまでこの @value{DOCUMENT} を順に読んでこられたのでしたら、XML ファイルの読み方と木構造としての扱い方を理解しています。 | |
1516 | -また、さまざまな文字エンコーディングと DTD 宣言の処理の仕方も知っています。 | |
1517 | -この @value{SECTION} では、XML ファイルで作業するときのほかのパターンについて概要を示すことにしています。 | |
1518 | -この概要は、出てくる全てのパターンの名前と使い方の例を示すという意味で完全なものにすることにしています。 | |
1519 | -概念的には多くの新しい材料があるわけではないです。 | |
1520 | -新しいものというのは、XML ファイルから情報を渡すためのいくつかの新しい変数に関するものだけです。 | |
1617 | +@section XMLファイルのデータ全種類の処理 | |
1618 | + | |
1619 | +この@value{DOCUMENT}をここまで順に読んでこられたのでしたら、XMLファイルの読み方と木構造としての扱い方を理解していることになります。 | |
1620 | +また、さまざまな文字エンコーディングとDTD宣言の処理の仕方も分かっています。 | |
1621 | +この@value{SECTION}では、XMLファイルを使って作業する時の他のパターンについて概要を示すことにします。 | |
1622 | +この概要では、登場する全パターンの名前と、その使い方の例を示すという点で完全なものにするつもりです。 | |
1623 | +概念的に新しい材料が沢山出てくるわけではありません。 | |
1624 | +新しいのは、XMLファイルから情報を渡すためのいくつかの新しい変数に関するものだけです。 | |
1521 | 1625 | さて、その新しいパターンです。 |
1522 | 1626 | |
1523 | 1627 | @itemize |
1524 | 1628 | @item |
1525 | 1629 | @cindex @code{XMLPROCINST} |
1526 | -XMLPROCINST にはプロセッシングインストラクションの名前が入っています。 | |
1527 | -また、$0 にはその内容が入っています。 | |
1630 | +XMLPROCINSTにはプロセッシングインストラクションの名前が入っています。 | |
1631 | +また、$0にはその内容が入っています。 | |
1632 | + | |
1528 | 1633 | @item |
1529 | 1634 | @cindex @code{XMLCOMMENT} |
1530 | -XMLCOMMENT は XML のコメントを示すものです。 | |
1531 | -コメント自体は $0 の中にあります。 | |
1635 | +XMLCOMMENTは、XMLのコメントを示すものです。 | |
1636 | +コメント自体は$0の中にあります。 | |
1637 | + | |
1532 | 1638 | @item |
1533 | 1639 | @cindex @code{XMLDECLARATION} |
1534 | 1640 | @cindex @code{XMLATTR} |
1535 | -XMLDECLARATION は、@code{XMLATTR["VERSION"]} から読み出せる、XML ファイルの最初の行からの XML のバージョン番号を表わします。 | |
1641 | +XMLDECLARATIONは、@code{XMLATTR["VERSION"]}から読み出せる、XMLファイルの最初の行にあるXMLのバージョン番号を表わします。 | |
1642 | + | |
1536 | 1643 | @item |
1537 | 1644 | @cindex @code{XMLUNPARSED} |
1538 | -XMLUNPARSED は他のカテゴリに当てはまらないかったテキストを表わします。 | |
1539 | -その内容は $0 の中にあります。 | |
1645 | +XMLUNPARSEDは、他のカテゴリに当てはまらなかったテキストを表わします。 | |
1646 | +その内容は$0の中にあります。 | |
1540 | 1647 | @end itemize |
1541 | 1648 | |
1542 | -次のスクリプトは、全ての XML のパターンと変数をデモンストレーションするためのものです。 | |
1543 | -このスクリプトで、XML ファイル中にある全てのものと、そしてそれが @code{gawk} でどのように読み込まれるかを表示することができますので、他のスクリプトをデバッグする際あなたを助けることができます。 | |
1649 | +次のスクリプトは、全てのXMLのパターンと変数をデモンストレーションするためのものです。 | |
1650 | +このスクリプトで、XMLファイル中にある全てのものと、そして、それが@code{gawk}でどのように読み込まれるかを示すことができますので、他のスクリプトをデバッグする際、便利に使えるでしょう。 | |
1544 | 1651 | |
1545 | 1652 | @pindex @file{demo_pusher.awk} |
1546 | 1653 | @cindex @code{XMLMODE} |
@@ -1576,8 +1683,8 @@ XMLUNPARSED は他のカテゴリに当てはまらないかったテキスト | ||
1576 | 1683 | @float Figure,fig:demo_pusher.awk |
1577 | 1684 | @example |
1578 | 1685 | @@load xml |
1579 | -# コンプライアントな XML データを厳格に XML パーサで読み込むために | |
1580 | -# XMLMODE をセットする | |
1686 | +# 仕様に適合したXMLデータをXMLパーサで厳密に読み込むため | |
1687 | +# XMLMODEをセットする | |
1581 | 1688 | BEGIN @{ XMLMODE=1 ; XMLCHARSET = "ISO-8859-1" @} |
1582 | 1689 | # ネストしたタグとアトリビュートのアウトラインを表示 |
1583 | 1690 | XMLSTARTELEM @{ |
@@ -1586,18 +1693,18 @@ XMLSTARTELEM @{ | ||
1586 | 1693 | printf(" %s='%s'", $i, XMLATTR[$i]) |
1587 | 1694 | print "" |
1588 | 1695 | @} |
1589 | -# タグを閉じる際、XMLPATH はタグ名を保持したまま。 | |
1696 | +# タグを閉じる際、XMLPATHはタグ名を保持したまま。 | |
1590 | 1697 | XMLENDELEM @{ printf("%s %s\n", "XMLENDELEM", XMLPATH) @} |
1591 | -# XMLEVENT は処理中のイベントの名前を保持。 | |
1698 | +# XMLEVENTは処理中のイベントの名前を保持。 | |
1592 | 1699 | XMLEVENT @{ print "XMLEVENT", XMLEVENT, XMLNAME, $0 @} |
1593 | 1700 | # キャラクタデータは失なわれない。 |
1594 | 1701 | XMLCHARDATA @{ print "XMLCHARDATA", $0 @} |
1595 | 1702 | # プロセッシングインストラクションとコメントが報告される。 |
1596 | 1703 | XMLPROCINST @{ print "XMLPROCINST", XMLPROCINST, $0 @} |
1597 | 1704 | XMLCOMMENT @{ print "XMLCOMMENT", $0 @} |
1598 | -# CDATA セクションは引用する字面そのままのテキストに利用される。 | |
1705 | +# CDATAセクションは引用する字面そのままのテキストに利用される。 | |
1599 | 1706 | XMLSTARTCDATA @{ print "XMLSTARTCDATA" @} |
1600 | -# CDATA ブロックは終了時に報告される。 | |
1707 | +# CDATAブロックは終了時に報告される。 | |
1601 | 1708 | XMLENDCDATA @{ print "XMLENDCDATA" @} |
1602 | 1709 | # 一番最初のイベントはバージョン情報を保持する。 |
1603 | 1710 | XMLDECLARATION @{ |
@@ -1605,19 +1712,19 @@ XMLDECLARATION @{ | ||
1605 | 1712 | encoding = XMLATTR["ENCODING" ] |
1606 | 1713 | standalone = XMLATTR["STANDALONE"] |
1607 | 1714 | @} |
1608 | -# 存在すれば、DTD 自体が表示される。 | |
1715 | +# 存在すれば、DTD自体が表示される。 | |
1609 | 1716 | XMLSTARTDOCT @{ |
1610 | 1717 | root = XMLSTARTDOCT |
1611 | 1718 | print "XMLATTR[PUBLIC]", XMLATTR["PUBLIC"] |
1612 | 1719 | print "XMLATTR[SYSTEM]", XMLATTR["SYSTEM"] |
1613 | 1720 | print "XMLATTR[INTERNAL_SUBSET]", XMLATTR["INTERNAL_SUBSET"] |
1614 | 1721 | @} |
1615 | -# DTD の終了でも表示される。 | |
1722 | +# DTDの終了でも表示される。 | |
1616 | 1723 | XMLENDDOCT @{ print "root", root @} |
1617 | 1724 | # 未パースのテキストがまれにある。 |
1618 | 1725 | XMLUNPARSED @{ print "XMLUNPARSED", $0 @} |
1619 | -# XMLENDDOCUMENT は、標準に厳密に従っていない XML データのときだけ | |
1620 | -# 起きる (ルートエレメントが複数ある)。 | |
1726 | +# XMLENDDOCUMENTは、標準に厳密に従っていないXMLデータの時だけ | |
1727 | +# 起きる(ルートエレメントが複数ある)。 | |
1621 | 1728 | XMLENDDOCUMENT @{ print "XMLENDDOCUMENT" @} |
1622 | 1729 | # ファイルの終わりで、エラーが起きたかどうかチェックできる。 |
1623 | 1730 | END @{ if (XMLERROR) |
@@ -1625,79 +1732,87 @@ END @{ if (XMLERROR) | ||
1625 | 1732 | XMLERROR, XMLROW, XMLCOL, XMLLEN) |
1626 | 1733 | @} |
1627 | 1734 | @end example |
1628 | -@caption{XMLgawk の全変数をデモンストレーションするスクリプト @file{demo_pusher.awk}} | |
1735 | +@caption{XMLgawkの全変数をデモンストレーションするスクリプト@file{demo_pusher.awk}} | |
1629 | 1736 | @end float |
1630 | 1737 | |
1738 | + | |
1631 | 1739 | @node Some Convenience with the xmllib library |
1632 | -@chapter xmllib ライブラリの利点 | |
1633 | -XML ファイルを読むために AWK 言語に追加された変数は、一度に一つのイベントを示します。 | |
1634 | -いくつかのノードからデータを再度整理したいような場合、木構造のトラバースの間に必要なデータを集めねばなりません。 | |
1635 | -こういう状況の一例が、@ref{いくつかの高度なアプリケーション}の例の中で何度か必要となる親ノードの名前です。 | |
1740 | +@chapter xmllibライブラリの利点 | |
1741 | + | |
1742 | +XMLファイルを読めるようにするためAWK言語に追加された変数は、一度に一つのイベントを示します。 | |
1743 | +複数ノードから得たデータを再編したいような場合、木構造のトラバースの間に必要なデータを集めねばなりません。 | |
1744 | +こういう状況の一例が、別の節(@pxref{Some Advanced Applications})の例の中で何度か必要とされる親ノードの名前です。 | |
1636 | 1745 | |
1637 | -Stefan Tramm は、コマンドラインでの @code{gawk} の使い方 (ワンライナー) を簡単にしたいがために、@file{xmllib} ライブラリを書きました。 | |
1638 | -彼のライブラリは、AWK コードの普通のスクリプトとして書かれていて、@command{xmlgawk} の起動によって自動的にインクルードされます。 | |
1746 | +Stefan Trammは、コマンドラインで@code{gawk}を簡単に使いたいために(ワンライナー)、@file{xmllib}ライブラリを書きました。 | |
1747 | +このライブラリは、AWKコードの普通のスクリプトとして書かれていて、@command{xmlgawk}の起動によって自動的にインクルードされます。 | |
1639 | 1748 | キャラクタデータやタグのネストを簡単に扱うための変数が導入されています。 |
1640 | -Stefan は @command{xmlgawk} ラッパスクリプトと同じくこのライブラリも提供してくれました。 | |
1749 | +Stefanは、@command{xmlgawk}ラッパスクリプトと同じく、このライブラリも提供してくれました。 | |
1641 | 1750 | |
1642 | 1751 | @b{FIXME: This chapter has not been written yet}. |
1643 | 1752 | |
1753 | + | |
1644 | 1754 | @node DOM-like access with the xmltree library |
1645 | -@chapter xmltree ライブラリを使った DOM ライクアクセス | |
1755 | +@chapter xmltreeライブラリを使ったDOMライクアクセス | |
1646 | 1756 | @cindex DOM, Document Object Model |
1647 | -@file{xmllib} を使ってさえも、木構造の中のノードへランダムにアクセスすることはできません。 | |
1648 | -親エレメントや子エレメントへアクセスして、ときどきツリーの中の離れた場所へもアクセスしなければならないアプリケーションは少しばかりあります。 | |
1649 | -これが、Manuel Collado が @file{xmltree} ライブラリを書いた理由です。 | |
1650 | - | |
1651 | -Manuel の @file{xmltree} は一度に XML ファイルを読み込んで、まるごと保持してしまいます。 | |
1652 | -このアプローチのことを DOM アプローチと呼びます。 | |
1653 | -XSL のような言語は本質的に、スクリプトを実行する際、DOM が存在していると仮定しています。 | |
1654 | -これは、同時に、こういった言語の強さ (ランダムアクセス) でもあり、弱さ (メモリにファイルを丸ごと保持する事) でもあります。 | |
1757 | + | |
1758 | +@file{xmllib}を使ってさえも、木構造の中のノードへ、ランダムにアクセスすることはできません。 | |
1759 | +親エレメントや子エレメントへアクセスして、ツリーの中の離れた場所へもアクセスしなければならないアプリケーションが少しばかりあります。 | |
1760 | +これが、Manuel Colladoが、@file{xmltree}ライブラリを書いた理由です。 | |
1761 | + | |
1762 | +Manuelの@file{xmltree}は一度にXMLファイルを読み込み、丸ごと保持します。 | |
1763 | +このアプローチのことをDOMアプローチと呼びます。 | |
1764 | +XSLのような言語は、本質的に、スクリプトを実行する際、DOMが存在していると仮定しています。 | |
1765 | +同時に、これは、こういった言語の強さ(ランダムアクセス)でもあり、弱さ(メモリにファイルを丸ごと保持する事)でもあります。 | |
1655 | 1766 | @cindex XSL |
1656 | 1767 | |
1657 | -Manuel は @file{xmltree} ライブラリを提供してくれました。 | |
1768 | +Manuelは、@file{xmltree}ライブラリを提供してくれました。 | |
1658 | 1769 | |
1659 | 1770 | @b{FIXME: This chapter has not been written yet}. |
1660 | 1771 | |
1661 | 1772 | |
1662 | - | |
1663 | 1773 | @node Problems from the newsgroups comp.text.xml and comp.lang.awk |
1664 | -@chapter ニューズグループ comp.text.xml と comp.lang.awk からの問題 | |
1665 | -@cindex comp.text.xml, インターネット上のニューズグループ | |
1666 | -@cindex comp.lang.awk, インターネット上のニューズグループ | |
1774 | +@chapter ニューズグループcomp.text.xmlとcomp.lang.awkからの問題 | |
1775 | +@cindex comp.text.xml, newsgroup on the Internet | |
1776 | +@cindex comp.lang.awk, newsgroup on the Internet | |
1667 | 1777 | |
1668 | 1778 | @menu |
1669 | -* i="Y" のエレメントの抽出:: | |
1670 | -* XMLTV ファイルからタブ付き ASCII への変換:: | |
1671 | -* 一組のデータの最小値の探索:: | |
1672 | -* ドキュメントでの使われ方に適合する DTD のアップデート:: | |
1673 | -* XML パスを使った操作:: | |
1779 | +* Extract the elements where i="Y":: | |
1780 | +* Convert XMLTV file to tabbed ASCII:: | |
1781 | +* Finding the minimum value of a set of data:: | |
1782 | +* Updating DTD to agree with its use in doc's:: | |
1783 | +* Working with XML paths:: | |
1674 | 1784 | @end menu |
1675 | 1785 | |
1676 | 1786 | |
1677 | -この @value{CHAPTER} はインターネット上のニューズグループに投稿された XML に関係する問題を集めたものです。 | |
1678 | -元の投稿を引用して問題の要点を短かく紹介したあと、それぞれの問題について XMLgawk での解決をしていきます。 | |
1679 | -元の問題を正しく解決できるように注意しましたが、実際のところ、これらの問題のいずれの詳細にも関心はありません。 | |
1680 | -関心が@emph{ある}ことは、この種の問題に取り掛かるための一般的な方法のデモンストレーションです。 | |
1681 | -この @value{CHAPTER} の@emph{レゾンデートル}は多岐にわたります。 | |
1787 | +この@value{CHAPTER}は、インターネット上のニューズグループに投稿されたXMLに関係する問題を集めたものです。 | |
1788 | +元の投稿を引用して問題の要点を短かく紹介した後、それぞれの問題についてXMLgawkでの解決をしていきます。 | |
1789 | +元の問題を正しく解決できるように注意しましたが、実際のところ、これらの問題のいずれについても、その細部には関心がありません。 | |
1790 | +関心が@emph{ある}ことは、この種の問題に取り掛かるための一般的な方法をデモンストレーションすることです。 | |
1791 | +この@value{CHAPTER}の@emph{レゾンデートル}は次のように多岐にわたります。 | |
1792 | + | |
1682 | 1793 | @itemize |
1683 | 1794 | @item |
1684 | -ニューズグループに投稿される問題はしばしば、学校のテキストブックの例題というよりも、日常の作業というものをよく表わしています。 | |
1795 | +ニューズグループに投稿される問題は、学校のテキストブックの例題というよりも、日常の作業というものをよく表わしていることがあります。 | |
1796 | + | |
1685 | 1797 | @item |
1686 | 1798 | オープンソースソフトウェアの開発は、実生活の中で起きる要求によって動かされています。 |
1687 | -ツールをユーザのニーズに適応させることは、観念的な基準に適応させることよりも得るところが大きいものです。 | |
1799 | +ユーザのニーズにツールを適応させることは、観念的な基準に適応させることよりも得るところが大きいものです。 | |
1800 | + | |
1688 | 1801 | @item |
1689 | 1802 | こういった問題というのは、ツールの充実度を測るための歓迎すべき試験台です。 |
1690 | -私たちは、XMLgawk の輝いている面と同時にそれほど輝いていない面について学んでいきます。 | |
1803 | +XMLgawkの輝いている面と同時に、それほど輝いていない面について学んでいきます。 | |
1804 | + | |
1691 | 1805 | @item |
1692 | -問題を解決するツールのそれぞれは、ユーザがそれを使うための基本的なスキルとテクニックをいくらか会得したときにだけ、その実用性が証明されます。 | |
1693 | -ついでに、こういったことのいくつかもデモンストレーションするつもりです。 | |
1806 | +問題を解決するツールは、それぞれ、ユーザがそれを使うための基本的なスキルとテクニックをいくらか会得した時にだけ、実用性が証明されます。 | |
1807 | +ついでに、こういったことについても、いくつかデモンストレーションするつもりです。 | |
1694 | 1808 | @end itemize |
1695 | 1809 | |
1696 | 1810 | |
1697 | 1811 | @node Extract the elements where i="Y" |
1698 | -@section i="Y" のエレメントの抽出 | |
1699 | -この問題の元の投稿者は、特定の種類 (@code{i="Y"}) のアトリビュートを持つタグを全て見つけだし、出力として別のアトリビュートの値を生成したいというものでした。 | |
1700 | -彼はこの問題を、入出力の関係を使って次のように説明しました。 | |
1812 | +@section i="Y"のエレメントの抽出 | |
1813 | + | |
1814 | +この問題の元の投稿者は、特定の種類(@code{i="Y"})のアトリビュートを持つタグを全て見つけだし、出力として、別のアトリビュートの値を生成したいというものでした。 | |
1815 | +彼は、この問題を、入出力の関係を使って次のように説明しました。 | |
1701 | 1816 | |
1702 | 1817 | @example |
1703 | 1818 | 次のものがあるとします。 |
@@ -1711,7 +1826,7 @@ Manuel は @file{xmltree} ライブラリを提供してくれました。 | ||
1711 | 1826 | <g i="Y" j="ffff"/> |
1712 | 1827 | </a> |
1713 | 1828 | |
1714 | -そして以下のようなものを得られるように、i="Y" であるエレメントを抽出し | |
1829 | +そして、以下のようなものを得られるように、i="Y"であるエレメントを抽出し | |
1715 | 1830 | たいのです。 |
1716 | 1831 | <x> |
1717 | 1832 | <y>1. aaaa</y> |
@@ -1723,11 +1838,11 @@ Manuel は @file{xmltree} ライブラリを提供してくれました。 | ||
1723 | 1838 | うか。 |
1724 | 1839 | @end example |
1725 | 1840 | |
1726 | -彼はおそらく、二つのフィールドを持つ入力フォームから XML データを得たのでしょう。 | |
1727 | -最初のフィールドには選択肢 (Y/N) に対する答えが入っていて、2 番目のフィールドには何か説明が入っています。 | |
1728 | -問題のゴールは、全てのポジティブな答え (@code{i="Y"}) に応じた説明の部分を抽出することでした。 | |
1729 | -出力データはすべて、ネストされたタグ (@code{x} と @code{y}) の中に埋め込まなければなりませんでした。 | |
1730 | -このタグのネスティングが、以下の解決方法の @code{BEGIN} パターンと @code{END} パターンの中の @code{print} コマンドの理由です。 | |
1841 | +彼は、恐らく、二つのフィールドを持つ入力フォームからXMLデータを得たのでしょう。 | |
1842 | +最初のフィールドには選択肢(Y/N)に対する答えが入っていて、2番目のフィールドには何か説明が入っています。 | |
1843 | +問題のゴールは、ポジティブな答え(@code{i="Y"})に応じた説明の部分を全て抽出することでした。 | |
1844 | +出力データは、ネストされたタグ(@code{x}と@code{y})の中に全て埋め込まなければなりませんでした。 | |
1845 | +このタグのネスティングが、以下の解決方法の@code{BEGIN}パターンと@code{END}パターンの中にある@code{print}コマンドの理由です。 | |
1731 | 1846 | |
1732 | 1847 | @cindex @code{XMLATTR} |
1733 | 1848 | @example |
@@ -1740,35 +1855,36 @@ XMLSTARTELEM @{ | ||
1740 | 1855 | END @{ print "</x>" @} |
1741 | 1856 | @end example |
1742 | 1857 | |
1743 | -@code{XMLSTARTELEM} パターンは、@code{y} の出力タグの表示をトリガーします。 | |
1744 | -しかし、@code{i} アトリビュートが @code{Y} という値を持つときだけ出力が表示されます。 | |
1745 | -出力自体は、@code{j} アトリビュートの値で構成され、@code{y} タグの間に埋めこまれます。 | |
1858 | +@code{XMLSTARTELEM}パターンは、@code{y}の出力タグの表示をトリガーします。 | |
1859 | +しかし、@code{i}アトリビュートが@code{Y}という値を持つ時だけ出力が表示されます。 | |
1860 | +出力自体は、@code{j}アトリビュートの値で構成され、@code{y}タグの間に埋めこまれます。 | |
1746 | 1861 | |
1747 | -元の投稿者による入力データで、上のスクリプトを試してみると、前に示された期待される出力から少し違う出力が得られることがわかるでしょう。 | |
1748 | -出力の 3 番目のアイテムが明らかにタイポです (@code{ffff} の代わりに @code{gggg})。 | |
1862 | +元の投稿者による入力データで上のスクリプトを試してみると、期待される上述の出力から少し違う出力が得られることが分かるでしょう。 | |
1863 | +出力の3番目のアイテムが明らかにタイポです(@code{ffff}の代わりに@code{gggg})。 | |
1749 | 1864 | |
1750 | 1865 | @cindex XSL |
1751 | -この種の問題 (入力データも出力データも XML) は通常 XSL 言語で解決されます。 | |
1752 | -この例で、XMLgawk が (XML の) 入力データを読み込むのには十分なツールであることを学びました。 | |
1753 | -しかし、出力データのタグ構造を (単に @code{print} コマンドで) 生成することが、それを好む人がいるというほど洗練されているわけではありません。 | |
1866 | +この種の問題(入力データも、出力データもXML)は、通常、XSL言語で解決します。 | |
1867 | +この例で、XMLgawkが(XMLの)入力データを読み込むのに十分なツールであることを学びました。 | |
1868 | +しかし、出力データのタグ構造を(単に、@code{print}コマンドで)生成することが、それを好む人がいるというほど洗練されているわけではありません。 | |
1754 | 1869 | |
1870 | + | |
1755 | 1871 | @node Convert XMLTV file to tabbed ASCII |
1756 | -@section XMLTV ファイルからタブ付き ASCII への変換 | |
1757 | -@cindex ASCII, タブ付き | |
1872 | +@section XMLTVファイルからタブ付きASCIIへの変換 | |
1873 | +@cindex ASCII, tabbed | |
1758 | 1874 | @cindex XMLTV |
1759 | 1875 | |
1760 | -この問題は、前の問題とは生成する出力データの種類の点で異なります。 | |
1761 | -ここでは、XML の入力ファイルからタブ区切りの ASCII データの出力を生成します。 | |
1762 | -この疑問の元の投稿者は、@uref{http://xml.coverpages.org/xmltv.html, XMLTV format} にある XML データを使いました。 | |
1763 | -XMLTV というのは、いつ、どのチャンネルで、どの TV program (米語ではなく英語では TV program@emph{me}) が放送されるのかという情報を格納するためのフォーマットです。 | |
1764 | -元の投稿者が例となるデータをいくつか示しています (非常に読み易い形式というわけではないということは確か)。 | |
1876 | +この問題は、前の問題とは、生成する出力データの種類の点で異なります。 | |
1877 | +ここでは、XMLの入力ファイルから、タブ区切りのASCIIデータの出力を生成します。 | |
1878 | +この問題の元の投稿者は、@uref{http://xml.coverpages.org/xmltv.html, XMLTV format}にあるXMLデータを使いました。 | |
1879 | +XMLTVというのは、いつ、どのチャンネルで、どのTV program(米語ではなく、英語の場合だとTV program@emph{me})が放送されるのかという情報を格納するためのフォーマットです。 | |
1880 | +元の投稿者が、例となるデータをいくつか示しています(非常に読み易い形式というわけではないことは確かです)。 | |
1765 | 1881 | |
1766 | 1882 | @example |
1767 | -誰か以下を解決して、私が XMLGAWK を理解する手助けをしてもらえませんか? | |
1768 | -XMLTV のデータファイルがありまして、そこからあるデータを取り出して、タブ区切 | |
1883 | +誰か以下を解決して、私がXMLGAWKを理解する手助けをしてもらえませんか。 | |
1884 | +XMLTVのデータファイルがありまして、そこからあるデータを取り出して、タブ区切 | |
1769 | 1885 | りのフラットなファイルに書き出したいのです。 |
1770 | 1886 | |
1771 | -当の XMLTV データは次のようなものです。 | |
1887 | +当のXMLTVデータは次のようなものです。 | |
1772 | 1888 | |
1773 | 1889 | <?xml version="1.0" encoding="UTF-8"?> |
1774 | 1890 | <tv><programme start="20041218204000 +1000" stop="20041218225000 |
@@ -1786,12 +1902,12 @@ worst enemies!</desc><rating | ||
1786 | 1902 | system="ABA"><value>C</value></rating><length |
1787 | 1903 | units="minutes">30</length><category>Children</category></programme></tv> |
1788 | 1904 | |
1789 | -フラットなファイルというのは次のようなものである必要があります。 | |
1905 | +フラットなファイルというのは、次のようなものである必要があります。 | |
1790 | 1906 | |
1791 | 1907 | channel<tab>programme |
1792 | 1908 | start<tab>length<tab>title<tab>description<tab>rating value |
1793 | 1909 | |
1794 | -で、最初のレコードは次のように読めるでしょう。 | |
1910 | +最初のレコードは次のように読めるでしょう。 | |
1795 | 1911 | |
1796 | 1912 | Network TEN Brisbane<tab>2004-12-18 hh:mm<tab>130<tab>The |
1797 | 1913 | Frighteners<tab>A psychic private detective, who consorts with |
@@ -1799,8 +1915,8 @@ deceased souls, becomes engaged in a mystery as members of the town | ||
1799 | 1915 | community begin dying mysteriously.<tab>M |
1800 | 1916 | @end example |
1801 | 1917 | |
1802 | -で、彼は、@code{programme} という種類のノードそれぞれにつき、一つの ASCII 出力行を得たいようです。 | |
1803 | -彼の例の入力の正しいアウトラインは以下のように見えます。 | |
1918 | +彼は、@code{programme}という種類のノードそれぞれにつき、一つのASCII出力行を得たいようです。 | |
1919 | +例にある入力の正しいアウトラインは次のような感じです。 | |
1804 | 1920 | |
1805 | 1921 | @example |
1806 | 1922 | tv |
@@ -1822,23 +1938,23 @@ tv | ||
1822 | 1938 | category |
1823 | 1939 | @end example |
1824 | 1940 | |
1825 | -期待する出力を表示するのは、前の @value{SECTION} ほど簡単ではありません。 | |
1941 | +期待する出力を表示するのは、前の@value{SECTION}ほど簡単ではありません。 | |
1826 | 1942 | ここには、ノードのキャラクタデータとして格納されているたくさんのデータと、アトリビュートとして格納されている少しのデータがあります。 |
1827 | -XMLgawk では、キャラクタデータよりもアトリビュートに対して作業することのほうがかなり簡単です。 | |
1828 | -このことは XMLgawk が XSL | |
1943 | +XMLgawkでは、キャラクタデータよりもアトリビュートに対して作業することの方がかなり簡単です。 | |
1829 | 1944 | @cindex XSL |
1830 | -とは大きく違うところです。 | |
1831 | -XSL は、どちらの種類のデータももっと統一的な方法で扱うことができます。 | |
1832 | - | |
1833 | -@code{BEGIN} パターンの後ろのアクション部分では、タブ区切りの ASCII 出力を生成するのがいかに簡単かがわかります (すなわち、出力する各フィールドを @code{TAB} 文字で区切ります)。 | |
1834 | -@code{OFS} 変数を @code{"\t"} に設定するだけです。 | |
1835 | -もう一つ簡単な作業がありますが、それは、チャンネルに関する情報とテレビ番組の開始時刻に関する情報を集めることです。 | |
1836 | -それらは、@code{programme} ノードのアトリビュートに格納されています。 | |
1837 | -ですので、@code{programme} ノードに入ると、アトリビュートが読み出され、後の作業のためにその内容が保存されます。 | |
1838 | -ノードに入ってすぐに出力行を表示できないのはなぜでしょうか? | |
1839 | -それは、それ以外のデータビット (length と title、description) が後からネストしたノードに入って現われるからです。 | |
1840 | -この結果、データの収集は、@code{programme} ノードから離れるときにだけ完了します。 | |
1841 | -ですので、タブ付きの出力表示は @code{XMLENDELEM == "programme"} パターンの後ろのアクション部分で行なわれます。 | |
1945 | +このことは、XMLgawkがXSLとは大きく違うところです。 | |
1946 | +XSLは、どちらの種類のデータももっと統一的な方法で扱うことができます。 | |
1947 | + | |
1948 | +@code{BEGIN}パターンの後ろのアクション部分では、タブ区切りのASCII出力を生成するのがいかに簡単かが分かります(すなわち、出力する各フィールドを@code{TAB}文字で区切ります)。 | |
1949 | +@code{OFS}変数を@code{"\t"}に設定するだけです。 | |
1950 | +もう一つ簡単な作業があります。 | |
1951 | +チャンネルに関する情報とテレビ番組の開始時刻に関する情報を集めることです。 | |
1952 | +それらの情報は、@code{programme}ノードのアトリビュートに格納されています。 | |
1953 | +ですから、@code{programme}ノードに入ると、アトリビュートを読み出し、後の作業のためにその内容を保存します。 | |
1954 | +ノードに入って、出力行をすぐに表示できないのはなぜでしょうか。 | |
1955 | +それ以外のデータビット(length、title、description)が、後からネストしたノードに入って現われるからです。 | |
1956 | +この結果、データの収集は、@code{programme}ノードから離れる時にだけ完了します。 | |
1957 | +ですから、タブ付きの出力表示は@code{XMLENDELEM == "programme"}パターンの後ろのアクション部分で行われます。 | |
1842 | 1958 | |
1843 | 1959 | @cindex @code{XMLATTR} |
1844 | 1960 | @example |
@@ -1862,35 +1978,36 @@ XMLENDELEM == "programme" @{ | ||
1862 | 1978 | @end example |
1863 | 1979 | |
1864 | 1980 | やり残していることはキャラクタデータを集めることです。 |
1865 | -キャラクタデータに遭遇するたびに、後でまた取り出すため、@code{data} 変数にそのキャラクタデータを保存します。 | |
1866 | -この時点では、どのような種類のキャラクタデータなのかまだわかりません。 | |
1867 | -後になって (@code{desc} や @code{length}、@code{title}、@code{value} ノードを離れるときに) ようやく、そのデータを正しい配置先へと割り当てることができます。 | |
1868 | -この種の、キャラクタデータの遅延配置は、@emph{ストリーミング}アプローチに従う XML パーサにとって特徴的なことです。 | |
1869 | -そういう XML パーサだと、一度に一つのデータアイテムしか見ず、後で必要になるデータビットを保存する処理をしなければなりません。 | |
1870 | -XSL のような XML を変換する言語は、この欠点に煩わされることがありません。 | |
1871 | -XSL では、XML データのあらゆる情報にランダムにアクセスします。 | |
1872 | -目前の問題を、(XMLgawk のような) ストリーミングパーサで解決するべきか、あるいは、(XSL のような) @uref{http://www.w3.org/TR/REC-DOM-Level-1/, DOM parser} で解決するべきかの決定は、ユーザ次第です。 | |
1873 | -XMLgawk を使いたくて、しかも、キャラクタデータを簡単に取り扱うことの快適さをさらに楽しみたいのであれば、別に説明している @code{xmllib} (@pxref{xmllib ライブラリの利点}) ライブラリか、@code{xmltree} (@pxref{xmltree ライブラリを使った DOM ライクアクセス}) ライブラリを使うべきです。 | |
1981 | +キャラクタデータに遭遇するたびに、後でまた取り出すため、そのキャラクタデータを@code{data}変数に保存します。 | |
1982 | +この時点では、どのような種類のキャラクタデータなのかまだ分かりません。 | |
1983 | +後になって(@code{desc}や@code{length}、@code{title}、@code{value}ノードを離れる時に)、ようやく、正しい配置先へとそのデータを割り当てることができます。 | |
1984 | +キャラクタデータのこの種の遅延配置は、@emph{ストリーミング}アプローチに従うXMLパーサにとって特徴的なことです。 | |
1985 | +そういうXMLパーサだと、一度に一つのデータアイテムしか見ず、後で必要になるデータビットを保存する処理をしなければなりません。 | |
1986 | +XSLのようなXMLを変換する言語は、この欠点に煩わされることがありません。 | |
1987 | +XSLでは、XMLデータのあらゆる情報にランダムにアクセスします。 | |
1988 | +目前の問題を、(XMLgawkのような)ストリーミングパーサで解決するべきか、あるいは、(XSLのような) @uref{http://www.w3.org/TR/REC-DOM-Level-1/, DOM parser}で解決するべきかの決定はユーザ次第です。 | |
1989 | +XMLgawkを使いたくて、しかも、キャラクタデータを簡単に取り扱うことの快適さをさらに楽しみたいのであれば、別に説明している@code{xmllib}(@pxref{Some Convenience with the xmllib library})ライブラリか、@code{xmltree}(@pxref{DOM-like access with the xmltree library})ライブラリを使うべきです。 | |
1990 | + | |
1874 | 1991 | |
1875 | 1992 | @node Finding the minimum value of a set of data |
1876 | 1993 | @section 一組のデータの最小値の探索 |
1877 | 1994 | |
1878 | -これまで、XML の入力データの探索や再整形が主たる関心事の事例を見てきました。 | |
1879 | -しかし、読み込みや表示というのがときどき十分ではありません。 | |
1880 | -次の事例の元の投稿者は、全ての @code{month} タグの @code{value} アトリビュートの最も短かい値を必要としています。 | |
1881 | -彼は、自分で試みた XSL による解決について、XSL テンプレートで起きた典型的な問題を述べながら、明確に言及しています。 | |
1995 | +これまで、XMLの入力データの探索や再整形が主たる関心事の事例を見てきました。 | |
1996 | +しかし、読み込みや表示というのが十分でないことがあります。 | |
1997 | +次の事例の元の投稿者は、全ての@code{month}タグの中で、@code{value}アトリビュートの最短値を必要としています。 | |
1998 | +彼は、自分で試みたXSLによる解決について、XSLテンプレートで起きた典型的な問題を述べながら、明確に言及しています。 | |
1882 | 1999 | |
1883 | 2000 | @example |
1884 | -私は、一連のデータ (後述) から最小値を見つけようと試みています。アトリ | |
2001 | +私は、一連のデータ(後述)から最小値を見つけようと試みています。アトリ | |
1885 | 2002 | ビュートの値の長さを比較して、一番短いものを表示したいのです。 |
1886 | 2003 | |
1887 | -変数へ値を割り当て直すことができれば、簡単なことでしょうけれども、私の | |
1888 | -推測では、そうすることはできないようです。ループを繰り返しているときに | |
1889 | -最小の値を保持しておくにはどうすればよいのでしょうか?私の XSL ドキュ | |
1890 | -メントは、各文字列の長さを調べ、それを (とりあえず) 表示するだけです。 | |
1891 | -私は、再帰的なコールを行なうテンプレートを書くことはできますが、各ルー | |
1892 | -プを通り抜けている間、最小値をすぐ利用できるように保持しておくにはどう | |
1893 | -すれば良いかわかりません。 | |
2004 | +変数へ値を割り当て直すことができれば簡単なことでしょうけれども、私の推測 | |
2005 | +では、そうすることはできないようです。ループを繰り返している時に最小の値 | |
2006 | +を保持しておくにはどうすればよいのでしょうか。私のXSLドキュメントは、各 | |
2007 | +文字列の長さを調べ、それを(とりあえず)表示するだけです。私は、再帰的な | |
2008 | +コールを行うテンプレートを書くことはできますが、各ループを通り抜けてい | |
2009 | +る間、最小値をすぐ利用できるように保持しておくにはどうすれば良いか分かり | |
2010 | +ません。 | |
1894 | 2011 | |
1895 | 2012 | どうぞよろしく。 |
1896 | 2013 |
@@ -1913,12 +2030,12 @@ XML Document | ||
1913 | 2030 | <month value="December"/> |
1914 | 2031 | </calendar> |
1915 | 2032 | @end example |
1916 | -@cindex 再帰 | |
2033 | +@cindex recursion | |
1917 | 2034 | |
1918 | -彼が探している答えというのは、@code{May} という値です。 | |
1919 | -私たちのような単純な思考だと、そこまでに見つかった最短の値を常に記憶しておいて、@code{month} タグのリストを上から下へ通り抜けます。 | |
1920 | -そして、リストを終了するとその時記憶していた値が答えです。 | |
1921 | -以下のスクリプトを見てもらえば、それが、私たちの単純思考のアプローチの経路を辿っていることがわかるでしょう。 | |
2035 | +彼が探している答えというのは、@code{May}という値です。 | |
2036 | +私たちのような単純な思考だと、そこまでに見つかった最短の値を常に記憶しておいて、@code{month}タグのリストを上から下へ通り抜けます。 | |
2037 | +そして、リスト終了時、記憶していた値が答えです。 | |
2038 | +以下のスクリプトを見てもらえば、スクリプトが、単純思考のアプローチの経路を辿っていることが分かるでしょう。 | |
1922 | 2039 | |
1923 | 2040 | @cindex @code{XMLATTR} |
1924 | 2041 | @example |
@@ -1935,75 +2052,81 @@ END @{ print shortest @} | ||
1935 | 2052 | @end example |
1936 | 2053 | |
1937 | 2054 | @cindex XSL |
1938 | -XSL での解決は、この場合ほど簡単というわけではありません。 | |
1939 | -XSL は関数型言語の一つで、それ自体、@emph{変数}のようなプログラミング概念が普通はありません。 | |
1940 | -また、普通は副作用が無いというのが関数型言語の強みの一つとなっていて、値を入れる大域変数というのは (概念的に言えば) 副作用です。 | |
1941 | -ですので、XSL での解決では、いわゆる@emph{テンプレート}の、再帰的にお互いを呼び出し合う使い方を必要となります。 | |
1942 | - | |
1943 | -このような事例は、XSL が他の言語と非常に違っていて、その結果、私たちのほとんどにとって学ぶのがさらに難しくなっているというのは何故なのかという疑問に光を当てるものです。 | |
1944 | -この簡単な例を見てもわかるように、XSL において再帰の使用は避けられないものです。 | |
1945 | -全てのタスクのうち最も簡単なものと考えてもです。っ | |
1946 | -実のところ、再帰的な思考というのは、大抵のソフトウェア開発者が日常的な仕事としてしたいと思うような方法ではありません。 | |
2055 | +XSLでの解決は、この場合ほど簡単というわけではありません。 | |
2056 | +XSLは、関数型言語の一つです。 | |
2057 | +それ自体、@emph{変数}のようなプログラミング概念がほとんどありません。 | |
2058 | +また、副作用がまず無いというのが関数型言語の強みの一つとなっています。 | |
2059 | +値を入れる大域変数というのは(概念的に言えば)副作用です。 | |
2060 | +ですから、XSLで解決するには、相互再帰的に呼び出しを行ういわゆる@emph{テンプレート}を使う必要があります。 | |
2061 | + | |
2062 | +このような事例は、XSLが他の言語と非常に違っていて、その結果、ほとんどの人にとって学ぶのがさらに難しくなっているというのは何故なのかという疑問に光を当てるものです。 | |
2063 | +この簡単な例を見ても分かるように、XSLにおいて再帰の使用は避けられないものです。 | |
2064 | +全タスクの中で最も簡単なものを考えたとしてもです。 | |
2065 | +実際のところ、再帰的な思考というのは、大抵のソフトウェア開発者が日常的な仕事としてしたいと思うような方法ではありません。 | |
1947 | 2066 | 彼らに尋いてみてください。 |
1948 | -C や C++、あるいは AWK プログラムで、@emph{あなた}が最後に再帰を使ったのはいつですか? | |
2067 | +CやC++、あるいは、AWKプログラムで、@emph{あなた}が最後に再帰を使ったのはいつでしょうか。 | |
2068 | + | |
1949 | 2069 | |
1950 | 2070 | @node Updating DTD to agree with its use in doc's |
1951 | -@section ドキュメントでの使われ方に適合する DTD のアップデート | |
2071 | +@section ドキュメントでの使われ方に適合するDTDのアップデート | |
1952 | 2072 | @cindex DTD, Document Type Definition |
1953 | -私が @ref{サンプルファイルからの DTD の生成} を書いてから数ヶ月経って、誰かが @uref{news://comp.text.xml, comp.text.xml} ニューズグループに似たようなツールのリクエストを投稿しました。 | |
2073 | + | |
2074 | +私が、別の節(@pxref{Generating a DTD from a sample file})を書いてから数ヶ月後、@uref{news://comp.text.xml, comp.text.xml}ニューズグループに、似たようなツールのリクエストを誰かが投稿しました。 | |
1954 | 2075 | |
1955 | 2076 | @example |
1956 | -数年前、提案されたドキュメントのクラスに対する DTD を私の所属部門が定 | |
1957 | -義しました。合衆国憲法のように、この DTD には実際に使われないような項 | |
1958 | -目が並んでいて、私はそれを整理したいのです。既存のドキュメントを見て、 | |
1959 | -それらが使用している DTD と比較するようなツールが何かないでしょうか? | |
2077 | +数年前、提案されたドキュメントのクラスに対するDTDを、私の所属部門が | |
2078 | +定義しました。合衆国憲法のように、実際に使われないような項目がこのD | |
2079 | +TDには並んでいて、私は、それを整理したいのです。既存のドキュメントを | |
2080 | +見て、それらが使用しているDTDと比較するようなツールが何かないでしょ | |
2081 | +うか。 | |
1960 | 2082 | |
1961 | 2083 | [私は、そのようなツールを何かで代用する他の可能性について考えることも |
1962 | 2084 | できますので、誰かがそういうものを発明しているかもしれないと考えました。 |
1963 | -私は XML Spy を持っていますが、こういうことをしてくれるような機能は見 | |
2085 | +私はXML Spyを持っていますが、こういうことをしてくれるような機能は見 | |
1964 | 2086 | 当たりません。] |
1965 | 2087 | @end example |
1966 | 2088 | |
1967 | -元の投稿者が必要としているものは、DTD を読み込んで、サンプルとなっているファイルが、その DTD の全ての部分を実際に使っているのかどうかを調べるツールです。 | |
1968 | -これは @ref{サンプルファイルからの DTD の生成} にある DTD ジェネレータがやっていることでは必ずしもありません。 | |
1969 | -しかし、DTD ジェネレータでサンプルファイルの DTD を生成し、その生成された DTD と元の DTD を比較することは実用的な解決法となるでしょう。 | |
2089 | +元の投稿者が必要としているものは、DTDを読み込んで、サンプルとなっているファイルが、そのDTDの全ての部分を実際に使っているのかどうか調べるツールです。 | |
2090 | +これは、別の節(@pxref{Generating a DTD from a sample file})にあるDTDジェネレータがやっていることでは必ずしもありません。 | |
2091 | +しかし、DTDジェネレータでサンプルファイルのDTDを生成し、その生成されたDTDと元のDTDを比較することは実用的な解決法となるでしょう。 | |
1970 | 2092 | |
1971 | -誰かほかの人が、Unix ツールセットのいくつかのツールを寄せ集めて利用する、代わりの解決法を投稿しました。 | |
2093 | +誰か他の人が、Unixツールセットのいくつかのツールを寄せ集めて利用する代わりの解決法を投稿しました。 | |
1972 | 2094 | |
1973 | 2095 | @example |
1974 | -私は、TEI SGML から XML への移行の一部としてこれを行ないました。要する | |
2096 | +私は、TEI SGMLからXMLへの移行の一部としてこれを行いました。要する | |
1975 | 2097 | に次のようになります。 |
1976 | 2098 | |
1977 | -a) nsgmls をドキュメント全部に実行し、ESIS を作る。 | |
1978 | -b) awk を使ってエレメントの型の名前を抽出する。 | |
1979 | -c) それを sort して uniq する。 | |
1980 | -d) Perl::SGML を使って DTD を読み込み、エレメントの型の名前をリストに | |
2099 | +a) nsgmlsをドキュメント全部に実行し、ESISを作る。 | |
2100 | +b) awkを使ってエレメントの型の名前を抽出する。 | |
2101 | +c) それをsortしてuniqする。 | |
2102 | +d) Perl::SGMLを使ってDTDを読み込み、エレメントの型の名前をリストに | |
1981 | 2103 | する。 |
1982 | -e) それを sort する。 | |
1983 | -f) 大文字小文字を区別せず二つのリストを -a 付きで join して、一致しな | |
2104 | +e) それをsortする。 | |
2105 | +f) 大文字小文字を区別せず二つのリストを-a付きでjoinして、一致しな | |
1984 | 2106 | いものを吐き出す。 |
1985 | 2107 | |
1986 | -Unix ベースのシステムを使っていないのでしたら、Cygwin でこういったツー | |
2108 | +Unixベースのシステムを使っていないのでしたら、Cygwinでこういったツー | |
1987 | 2109 | ルが使えると思います。 |
1988 | 2110 | @cindex Cygwin |
1989 | 2111 | @end example |
1990 | 2112 | |
1991 | -あなたが望む解決法が何であっても、最も一般的なプラットフォームが利用できれば、これらのツールはユーザにとって十分役立ちます。 | |
2113 | +選択する解決法が何であっても、最も一般的なプラットフォームが利用できれば、これらのツールはユーザにとって十分役立ちます。 | |
2114 | + | |
1992 | 2115 | |
1993 | 2116 | @node Working with XML paths |
1994 | -@section XML パスを使った操作 | |
1995 | - | |
1996 | -現在のプログラミング言語のほとんどは、XML ファイルを読むための何らかのサポートを提供しています。 | |
1997 | -しかし XMLgawk とは違い、その他の言語のほとんどは、XML ファイルを、メモリに常駐する、木構造をしたデータ構造へ写します。 | |
1998 | -こうすることで、XML ファイルのあらゆるエレメントへ、望んだ順番で簡単にアクセスできるようになります。 | |
1999 | -XMLgawk でするような、一度に一つ順番にアクセスするというだけではありません。 | |
2000 | -@uref{news://comp.text.xml, comp.text.xml} ニューズグループの中で、そういった言語のユーザの一人がよくある問題を思い付き、その解決法を求めました。 | |
2001 | -以下に示す XML データを読む際、構造的に似ているサブエレメントを運んでいる二つの @code{item} エレメントを報告してください。 | |
2002 | -@code{item} にはそれぞれ、@code{PPrice} と @code{BCQuant} というサブエレメントがあって、@code{item} の価格と数量が入っています。 | |
2117 | +@section XMLパスを使った操作 | |
2118 | + | |
2119 | +現在のプログラミング言語の大部分は、XMLファイルを読むための何らかのサポートを提供しています。 | |
2120 | +しかし、XMLgawkとは違って、他言語の大半では、木構造をしたデータ構造へXMLファイルを写し、メモリに常駐させます。 | |
2121 | +こうすることで、XMLファイルのあらゆるエレメントに対し望んだ順番で簡単にアクセスできるようになります。 | |
2122 | +XMLgawkで行うような一度に一つずつ単に順番にアクセスする方法ではありません。 | |
2123 | +@uref{news://comp.text.xml, comp.text.xml}ニューズグループにおいて、そういった言語のユーザの一人が、よくある問題を思い付き、その解決法を求めました。 | |
2124 | +以下に示すXMLデータを読む際、構造的に似ているサブエレメントを運んでいる二つの@code{item}エレメントを報告してください。 | |
2125 | +各@code{item}には、@code{PPrice}と@code{BCQuant}というサブエレメントがあって、@code{item}の価格と数量が入っています。 | |
2003 | 2126 | そのユーザは次のように尋ねました。 |
2004 | 2127 | |
2005 | 2128 | @example |
2006 | -次のような XML があります。 | |
2129 | +次のようなXMLがあります。 | |
2007 | 2130 | |
2008 | 2131 | <?xml version="1.0" encoding="UTF-8"?> |
2009 | 2132 | <invoice> |
@@ -2037,22 +2160,24 @@ XMLgawk でするような、一度に一つ順番にアクセスするという | ||
2037 | 2160 | @end example |
2038 | 2161 | |
2039 | 2162 | 彼の最後のセンテンスが全てを要約しています。 |
2040 | -彼は、@code{PPrice} と @code{BCQuant} とを掛けたものの足し算を実行して、@code{item} 全部の合計の費用を知りたいのです。 | |
2041 | -彼はかけ算をする変数を Unix ファイルシステムでのファイル名に似た@emph{パス}を使って識別しています。 | |
2163 | +彼は、@code{PPrice}と@code{BCQuant}を掛けたものの足し算を実行して、@code{item}全部の合計の費用を知りたいのです。 | |
2164 | +彼は、Unixファイルシステムでのファイル名のような@emph{パス}を使って掛け算を行う変数を識別しています。 | |
2165 | + | |
2042 | 2166 | @example |
2043 | 2167 | /invoice/billitems/item/BCQuant * /invoice/billitems/item/PPrice |
2044 | 2168 | @end example |
2045 | -これは、XML ドキュメントにおける変数の位置を示す方法としてかなり便利な方法です。 | |
2046 | -プログラミング言語の中には、変数の位置を示すためにこの表記を直接ユーザに利用させるものもあります。 | |
2047 | -こういった言語のユーザにとっては、XMLgawk での問題を取り組む方法へ、彼らの習慣を合わせることはしばしば難しいことです。 | |
2048 | -XMLgawk では、変数へ直接アクセスするためにそのようなパスを使うことは@emph{できません}。 | |
2049 | -しかし、XML ドキュメントの中でのその時点での位置をマッチするのに AWK のパターンの中でそのようなパスを使うことはできます。 | |
2050 | -以下に示す解決策を見れば、XMLgawk でパスをどのように使うかが理解できるでしょう。 | |
2051 | -理解するための重要なポイントは、現在注視している場所へのパスを常に保持している @code{XMLPATH} 変数が予め定義してあるということです。 | |
2052 | -この解決策の一番最初の行は、@code{PPrice} 変数と @code{BCQuant}変数へのアクセスの基礎です。 | |
2053 | -このスクリプトは、何らかのキャラクタデータが読み込まれるたびに、その内容を連想配列の @code{data} に置きます。 | |
2054 | -このとき、その変数の@emph{パス}名を配列のインデックスとして利用します。 | |
2055 | -この結果、この連想配列 @code{data} は、変数名 (@code{/invoice/billitems/item/BCQuant}) をその値 (@code{15}) へマップするようになりますが、それは、XML エレメントの @code{item} が一つ読まれている間の短い間だけのことです。 | |
2169 | + | |
2170 | +これは、XMLドキュメントにおける変数の位置を示す方法としてかなり便利な方法です。 | |
2171 | +プログラミング言語の中には、変数の位置を示すのに、この表記をユーザに直接利用させるものもあります。 | |
2172 | +こういった言語のユーザにとっては、XMLgawkにおける問題を取り組む方法へと習慣を合わせるのは大抵難しいことです。 | |
2173 | +XMLgawkでは、変数へ直接アクセスするのに上記のようなパスを使うことは@emph{できません}。 | |
2174 | +しかし、XMLドキュメントの中でのその時点での位置をマッチするのに、AWKのパターンの中でそのようなパスを使うことはできます。 | |
2175 | +以下に示す解決策を見れば、XMLgawkでパスを利用する方法が理解できるでしょう。 | |
2176 | +理解するための重要なポイントは、現在注視している場所へのパスを常に保持している@code{XMLPATH}変数が予め定義してあるということです。 | |
2177 | +この解決策の一番最初の行は、@code{PPrice}変数と@code{BCQuant}変数へのアクセスの基礎です。 | |
2178 | +このスクリプトは、何らかのキャラクタデータが読み込まれるたびに、その内容を連想配列の@code{data}に置きます。 | |
2179 | +この時、その変数の@emph{パス}名を、配列のインデックスとして利用します。 | |
2180 | +この結果、この連想配列@code{data}は、変数名(@code{/invoice/billitems/item/BCQuant})をその値(@code{15})へマップするようになりますが、それは、XMLエレメントの@code{item}が一つ読まれている間の短い間だけのことです。 | |
2056 | 2181 | |
2057 | 2182 | @example |
2058 | 2183 | @@load xml |
@@ -2064,64 +2189,70 @@ XMLENDELEM == "item" @{ | ||
2064 | 2189 | END @{ printf "Sum = %.3f\n",sum @} |
2065 | 2190 | @end example |
2066 | 2191 | |
2067 | -足し算は、@code{item} エレメントが一つ完全に読み込まれたときに毎回行なわれます。 | |
2068 | -すなわち、@code{XMLENDELEM == "item" のときです。 | |
2069 | -この時点で、数量と価格は @code{data} 配列の中に確実に保存されています。 | |
2070 | -XML ドキュメントが完了すれば合計処理は終了し、やり残したことはその結果の表示だけになります。 | |
2192 | +足し算は、@code{item}エレメントが一つ完全に読み込まれた時に毎回行われます。 | |
2193 | +すなわち、@code{XMLENDELEM == "item"の時です。 | |
2194 | +この時点で、数量と価格は、@code{data}配列の中に確実に保存されています。 | |
2195 | +XMLドキュメントが完了すれば、合計処理は終了し、やり残したことはその結果の表示だけになります。 | |
2071 | 2196 | |
2072 | 2197 | @cindex DOM, Document Object Model |
2073 | 2198 | @cindex XSL |
2074 | -この単純なテクニック (ある値へのパスを @code{data[XMLPATH] = $0} でマッピングすること) は、@emph{木構造のどこかほかの場所にある}データへ@emph{後で}アクセスするための鍵となります。 | |
2075 | -丸ごとの XML ドキュメントを木構造 (@uref{http://www.w3.org/TR/REC-DOM-Level-1/, DOM}) の中に格納してしまう XSL のような言語と、XMLgawk との微妙な違いに注意してください。 | |
2076 | -XMLgawk では、ツリーの、ランダムアクセスに本当に必要な部分だけが高価なメモリに読み込まれます。 | |
2077 | -ユーザが自分でそういう部分を識別して、明示的にデータを格納しないといけないということだけがこれの不便な点です。 | |
2078 | -他の言語では、そういうデータの格納を (なんらコードを書くことなく) 暗黙のうちにやりますが、ユーザは、データストレージの粒度を管理することを放棄しました。 | |
2079 | - | |
2080 | -詳細に分析すれば、このシンプルなアプローチに重大な制限があることをわかってしまうかもしれません。 | |
2081 | -マークアップされたブロックの内部に他のタグが無いとき、そのブロック内のキャラクタデータに対してだけ働きます。 | |
2082 | -言いかえれば、XML ツリーのノードが終端のノード (@ref{fig:docbook_chapter} と @ref{fig:dbfile} における 3、5、6、8、9、11、12 番のようなリーフノード) ときだけ、期待通りに @code{XMLPATH} の中に格納されます。 | |
2083 | -XML ツリーの (2、4、7、10 番のような) @emph{非終端}のノードのキャラクタデータへのアクセスにも関心があれば、もう少し洗練されたアプローチが必要となります。 | |
2199 | +この単純なテクニック(ある値へのパスを@code{data[XMLPATH] = $0}でマッピングすること)は、@emph{木構造のどこか他の場所にある}データへ@emph{後で}アクセスするための鍵となります。 | |
2200 | +丸ごとのXMLドキュメントを木構造(@uref{http://www.w3.org/TR/REC-DOM-Level-1/, DOM})の中に格納してしまうXSLのような言語とXMLgawkとの微妙な違いに注意してください。 | |
2201 | +XMLgawkでは、そのツリーのうち、ランダムアクセスに本当に必要な部分だけが高価なメモリに読み込まれます。 | |
2202 | +そういう部分をユーザが自分で識別して、明示的にデータを格納しないといけないということだけがこれの不便な点です。 | |
2203 | +他の言語においては、そういうデータの格納を(何等コードを書くことなく)暗黙のうちにやりますが、ユーザは、データストレージの粒度を管理することを放棄することになりました。 | |
2204 | + | |
2205 | +詳細に分析すれば、このシンプルなアプローチに重大な制限があることが分かってしまうかもしれません。 | |
2206 | +このアプローチは、マークアップされたブロック内部に他のタグが無い場合のそのブロック内のキャラクタデータに対してだけ働きます。 | |
2207 | +言いかえれば、XMLツリーのノードが終端ノード(fig:docbook_chapter(@pxref{fig:docbook_chapter})とfig:dbfile(@pxref{fig:dbfile})における3、5、6、8、9、11、12番のようなリーフノード)の時だけ、期待通りに@code{XMLPATH}の中に格納されます。 | |
2208 | +XMLツリーの(2、4、7、10番のような)@emph{非終端}ノードのキャラクタデータへのアクセスにも関心があるならば、もう少し洗練されたアプローチが必要となります。 | |
2209 | + | |
2084 | 2210 | @example |
2085 | 2211 | @@load xml |
2086 | 2212 | XMLSTARTELEM @{ delete data[XMLPATH] @} |
2087 | 2213 | XMLCHARDATA @{ data[XMLPATH] = data[XMLPATH] $0 @} |
2088 | 2214 | @end example |
2089 | -重要な違いは、XML ツリーを通り抜けていく間、各非終端のノードのキャラクタデータブロックを連続して蓄積する最後の行です。 | |
2090 | -同じ種類の別のノード (同じタグ名、@emph{兄弟ノード}) を読み始めた後だけ、蓄積されたキャラクタデータがクリアされます。 | |
2091 | -クリアすることは実際必要ですが、さもなければ、同じ種類で同じ深さのノード全部のキャラクタデータが蓄積されてしまうでしょう。 | |
2215 | + | |
2216 | +重要な違いは、XMLツリーを通り抜けていく間、各非終端のノードのキャラクタデータブロックを連続して蓄積する最後の行です。 | |
2217 | +同じ種類の別のノード(同じタグ名、@emph{兄弟ノード})を読み始めた後だけ、蓄積されたキャラクタデータがクリアされます。 | |
2218 | +クリアは実際必要です。 | |
2219 | +そうしなければ、同じ種類で同じ深さのノード全部のキャラクタデータが蓄積されてしまうでしょう。 | |
2092 | 2220 | このような蓄積は望ましくないです。 |
2093 | -なぜなら、一つの @code{data[XMLPATH]} のキャラクタデータの内容が、一つのノードのテキストだけであることを期待しているのであって、同じネストレベルの他のノードのテキストは要らないからです。 | |
2221 | +なぜなら、一つの@code{data[XMLPATH]}のキャラクタデータの内容が、一つのノードのテキストだけであることを期待しているのであって、同じネストレベルの他のノードのテキストは要らないからです。 | |
2094 | 2222 | しかし、もちろん、必要に応じてこの振舞いを変更するのは自由です。 |
2095 | 2223 | |
2224 | + | |
2096 | 2225 | @node Some Advanced Applications |
2097 | 2226 | @chapter いくつかの高度なアプリケーション |
2098 | 2227 | |
2099 | 2228 | @menu |
2100 | -* @file{xmlcopy.awk} ライブラリスクリプトを使ったコピーと修正:: | |
2101 | -* RSS ニュースフィードの読み込み:: | |
2102 | -* SOAP を経由したサービスの利用:: | |
2103 | -* PostgreSQL への XML データのロード:: | |
2104 | -* XML データからツリー図への変換:: | |
2105 | -* サンプルファイルからの DTD の生成:: | |
2106 | -* サンプルファイルからの再帰下降パーサの生成:: | |
2107 | -* Microsoft Excel の XML ファイルに対するパーサ:: | |
2229 | +* Copying and Modifying with the @file{xmlcopy.awk} library script:: | |
2230 | +* Reading an RSS news feed:: | |
2231 | +* Using a service via SOAP:: | |
2232 | +* Loading XML data into PostgreSQL:: | |
2233 | +* Converting XML data into tree drawings:: | |
2234 | +* Generating a DTD from a sample file:: | |
2235 | +* Generating a recursive descent parser from a sample file:: | |
2236 | +* A parser for Microsoft Excel's XML file format:: | |
2108 | 2237 | @end menu |
2109 | 2238 | |
2110 | -前の @value{CHAPTER} とは異なり、この @value{CHAPTER} では、小さくない仕事をする完全なアプリケーションプログラムを実際に提供します。 | |
2111 | -これらのタスクの複雑になった性質にも関わらず、これらのアプリケーションのいくつかのソースコードは 1 ページにまだ収まります。 | |
2112 | -しかし、そのソースコードの大半は、二つ三つの部分に分けねばなりませんでした。 | |
2239 | +前の@value{CHAPTER}とは異なり、この@value{CHAPTER}では、小さくない仕事をする完全なアプリケーションプログラムを実際に提供します。 | |
2240 | +これらのタスクが複雑な性質を持つにも関わらず、こういったアプリケーションのソースコードには1ページに収まるものがまだあります。 | |
2241 | +しかし、ソースコードの大半は、二三の部分に分けねばなりませんでした。 | |
2242 | + | |
2113 | 2243 | |
2114 | 2244 | @node Copying and Modifying with the @file{xmlcopy.awk} library script |
2115 | -@section @file{xmlcopy.awk} ライブラリスクリプトを使ったコピーと修正 | |
2116 | - | |
2117 | -XML データは、インターネットで使用される HTML データと良く似ているように見えますので、伝統的に、インターネットアプリケーションと結びつけて考えられます。 | |
2118 | -しかし、10 年以上使われた後、XML データのフォーマットというのが、それぞれさまざまな要求があるもっと多くの領域で便利であるということがわかってきました。 | |
2119 | -たとえば、離れた場所で定期的に計測されるデータは、今日では、よく XML データとしてエンコードされています。 | |
2120 | -それは、XML データによる読み易さの改善 (プロプライエタリのバイナリフォーマットとは対照的) だけでなく、ユーザにとって非常に快いタグ付けされた XML データの木構造ということもあります。 | |
2121 | -もし、フォーマットにもう一つ計測値のデータタイプを加えたいならば、計測装置では、単に、 XML アトリビュートかもう一つのタグを XML データのツリーに追加するだけです。 | |
2122 | -このデータを読み込むアプリケーションソフトウェアは、追加されたデータタイプを安全に無視することができ、@emph{新しい}データフォーマットをなお読み込むことができます。 | |
2245 | +@section @file{xmlcopy.awk}ライブラリスクリプトを使ったコピーと修正 | |
2246 | + | |
2247 | +XMLデータは、インターネットで使用されるHTMLデータと良く似ているように見えます。そのため、伝統的に、インターネットアプリケーションと結びつけて考えられます。 | |
2248 | +しかし、10年以上使われた結果、XMLデータのフォーマットというのがさらに多くの領域で有用であるということが分かってきました。 | |
2249 | +そういった領域には様々なニーズがあります。 | |
2250 | +例えば、離れた場所で定期的に計測されるデータは、今日では、よくXMLデータとしてエンコードされています。 | |
2251 | +それは、XMLデータによる読み易さの改善(プロプライエタリのバイナリフォーマットとは対照的)だけでなく、ユーザにとって非常に快いタグ付けされたXMLデータの木構造ということもあります。 | |
2252 | +もし、計測値のデータタイプをフォーマットにもう一つ加えたいならば、計測装置で、XMLアトリビュートか別のタグをXMLデータのツリーに追加するだけです。 | |
2253 | +このデータを読み込むアプリケーションソフトウェアは、追加されたデータタイプを安全に無視できますし、それでもなお、@emph{新しい}データフォーマットを読み込むことができます。 | |
2123 | 2254 | ここまでは良いのです。 |
2124 | -しかし、時には、ある装置が @ref{fig:remote_data.xml} にあるようなデータを私たちに送信してきます。 | |
2255 | +しかし、時には、ある装置がfig:remote_data.xml(@pxref{fig:remote_data.xml})にあるようなデータを私たちに送信してきます。 | |
2125 | 2256 | |
2126 | 2257 | @float Figure,fig:remote_data.xml |
2127 | 2258 | @pindex @file{remote_data.xml} |
@@ -2143,36 +2274,39 @@ XML データは、インターネットで使用される HTML データと良 | ||
2143 | 2274 | </MONITORINGSTATION> |
2144 | 2275 | </MONITORINGSTATIONS> |
2145 | 2276 | @end example |
2146 | -@caption{遠隔地で計測されたデータが入った @file{remote_data.xml} ファイル} | |
2277 | +@caption{遠隔地で計測されたデータが入った@file{remote_data.xml}ファイル} | |
2147 | 2278 | @end float |
2148 | 2279 | |
2149 | -このデータをざっと読んでみれば、異常に見えるところが 3 箇所見つかるかもしれません。 | |
2280 | +このデータをざっと読んでみれば、異常に見えるところが3箇所見つかるでしょう。 | |
2281 | + | |
2150 | 2282 | @itemize |
2151 | -@item @b{NAME} タグの内部、CATALU@math{\tilde{N}}A の中のチルダが付いた大文字の N。 | |
2152 | -@item @b{LON} タグの内部、浮動小数点数で小数点として使われるカンマ。 | |
2153 | -@item @b{PARAMETER} タグの内部、@emph{µ} としてエンコードされている @math{\mu} シンボル。 | |
2283 | +@item @b{NAME}タグの内部、CATALU@math{\tilde{N}}Aの中のチルダが付いた大文字のN。 | |
2284 | +@item @b{LON}タグの内部、浮動小数点数で小数点として使われるカンマ。 | |
2285 | +@item @b{PARAMETER}タグの内部、@emph{µ}としてエンコードされている@math{\mu}シンボル。 | |
2154 | 2286 | @end itemize |
2155 | 2287 | |
2156 | -私たちに必要なのは、木構造には触れないまま、この XML データのこういった奇抜な部分を修正するスクリプトです。 | |
2288 | +私たちに必要なのは、木構造には触れないまま、このXMLデータのこういった奇抜な部分を修正するスクリプトです。 | |
2157 | 2289 | 正確に言うと、次のようなスクリプトが必要です。 |
2290 | + | |
2158 | 2291 | @itemize |
2159 | 2292 | @item ファニーな@emph{特殊文字}を全部、必要な文字エンコーディングへ変換する。 |
2160 | -@item @b{LON} タグの内側の数値だけ、カンマを小数点に置き換える。 | |
2161 | -@item その他すべては、元の XML データにあった字面通りコピーする。 | |
2293 | +@item @b{LON}タグの内側の数値だけ、カンマを小数点に置き換える。 | |
2294 | +@item その他すべては、元のXMLデータにあった字面通りコピーする。 | |
2162 | 2295 | @end itemize |
2163 | -@cindex 文字エンコーディング | |
2164 | - | |
2165 | -@ref{fig:modify.awk} に解決策の一つを見ることができます。 | |
2166 | -それは、@file{xmlcopy.awk} という名前のライブラリスクリプトをインクルードする include ステートメントで始まります。 | |
2167 | -2 行目では、データを読み始める前に望ましい文字エンコーディングを設定します。 | |
2168 | -これは見てすぐわかります。 | |
2169 | -しかし、なぜ、エンコーディング名 (@command{"ISO-8859-1"}) が @command{XMLATTR["ENCODING"]} 変数の中にコピーされるのでしょうか? | |
2170 | -@command{XMLATTR["ENCODING"]} が@emph{入力}データのエンコーディングを反映していることと、この読み取り専用の変数をオーバーライトしても無駄だということは、@ref{キャラクタデータと文字セットのエンコーディング}で学びませんでしたか? | |
2171 | -そのことは真実で、@command{xgawk} インタプリタは、@command{XMLATTR["ENCODING"]} の中に書き込んだものを単に無視します。 | |
2172 | -しかし、すぐ、ライブラリスクリプト内部の関数がこの@emph{偽エンコーディング}の変数を評価することがわかるでしょう。 | |
2173 | -スクリプトの 4 行目は、またもや見てすぐわかります。 | |
2174 | -@b{LON} タグのキャラクタデータの内部で、カンマが小数点に置き換えられます。 | |
2175 | -そして最後、一番下の行には @command{XmlCopy()} 関数の起動が書かれています。 | |
2296 | +@cindex character encoding | |
2297 | + | |
2298 | +fig:modify.awk(@pxref{fig:modify.awk})に解決策の一つがあります。 | |
2299 | +このスクリプトは、@file{xmlcopy.awk}という名前のライブラリスクリプトをインクルードするincludeステートメントで始まります。 | |
2300 | +2行目では、データを読み始める前に、望ましい文字エンコーディングを設定します。 | |
2301 | +これは見てすぐ分かります。 | |
2302 | +しかし、なぜ、エンコーディング名(@command{"ISO-8859-1"})が@command{XMLATTR["ENCODING"]}変数の中にコピーされるのでしょうか。 | |
2303 | +@command{XMLATTR["ENCODING"]}が@emph{入力}データのエンコーディングを反映していることと、この読み取り専用の変数をオーバーライトしても無駄だということは、別の節(@pxref{Character data and encoding of character sets})で学んだと思います。 | |
2304 | +そのことは真実です。 | |
2305 | +@command{xgawk}インタプリタは、@command{XMLATTR["ENCODING"]}の中に書き込んだものを単に無視します。 | |
2306 | +しかし、すぐ、ライブラリスクリプト内部の関数が、この@emph{偽エンコーディング}の変数を評価することが分かるでしょう。 | |
2307 | +スクリプトの4行目は、またもや見てすぐ分かります。 | |
2308 | +@b{LON}タグのキャラクタデータの内部で、カンマが小数点に置き換えられます。 | |
2309 | +そして、最後、一番下の行には@command{XmlCopy()}関数の起動が書かれています。 | |
2176 | 2310 | |
2177 | 2311 | @float Figure,fig:modify.awk |
2178 | 2312 | @pindex @file{modify.awk} |
@@ -2184,22 +2318,23 @@ XMLATTR["VERSION"] @{ XMLATTR["ENCODING"] = XMLCHARSET @} | ||
2184 | 2318 | XMLCHARDATA && XMLPATH ~ /\/LON$/ @{ gsub(",", ".") @} |
2185 | 2319 | @{ XmlCopy() @} |
2186 | 2320 | @end example |
2187 | -@caption{XML データを少し修正する @file{modify.awk} スクリプト} | |
2321 | +@caption{XMLデータを少し修正する@file{modify.awk}スクリプト} | |
2188 | 2322 | @end float |
2189 | 2323 | |
2190 | -偽エンコーディング名の評価し全部をコピーするというマジックは、全てライブラリスクリプトの内部で行なわれます。 | |
2191 | -ちょうど@ref{XMLgawk のポータブルサブセット}で説明した @file{getXMLEVENT.awk} のように、このライブラリスクリプトは以下の場所のいずれかで見つけることができるでしょう。 | |
2324 | +偽エンコーディング名の評価し全部をコピーするというマジックは、全てライブラリスクリプトの内部で行われます。 | |
2325 | +ちょうど別の節(@pxref{A portable subset of XMLgawk})で説明した@file{getXMLEVENT.awk}のように、このライブラリスクリプトは以下の場所のいずれかで見つけることができるでしょう。 | |
2192 | 2326 | |
2193 | 2327 | @itemize |
2194 | -@item @code{xgawk} の配布ファイルの @file{awklib/xml} ディレクトリの中にコピーがあります。 | |
2195 | -@item ホストマシンに @code{xgawk} が既にインストールされていれば、共有ソースのディレクトリの中にファイルのコピーがあるはずです (GNU/Linux マシンの @code{/usr/share/awk} のような場所に普通あります)。 | |
2328 | +@item @code{xgawk}の配布ファイルの@file{awklib/xml}ディレクトリの中にコピーがあります。 | |
2329 | + | |
2330 | +@item ホストマシンに@code{xgawk}が既にインストールされていれば、共有ソースのディレクトリの中にファイルのコピーがあるはずです(GNU/Linuxマシンの@code{/usr/share/awk}のような場所に普通あります)。 | |
2196 | 2331 | @end itemize |
2197 | 2332 | |
2198 | -@file{xmlcopy.awk} ライブラリスクリプトのコピーを少し見てみてください。 | |
2199 | -このスクリプトは @command{XmlCopy()} 関数の宣言以外は何も入っていないことに注意してください。 | |
2333 | +@file{xmlcopy.awk}ライブラリスクリプトのコピーを少し見てみてください。 | |
2334 | +このスクリプトは、@command{XmlCopy()}関数の宣言以外は何も入っていないことに注意してください。 | |
2200 | 2335 | また、この関数は、データに対する全ての操作が終了したあとにだけ呼びだされることにも注意してください。 |
2201 | -実行が成功したときの結果は、@ref{fig:modify.xml} で見ることができます。 | |
2202 | -入力ファイルがオープンされた直後、@code{DECLARATION} 型の @code{XMLEVENT} が起動しますが、入力データに宣言が含まれていないために @code{XMLATTR["ENCODING"]} 変数はセットされていません。 | |
2336 | +実行が成功した時の結果は、fig:modify.xml(@pxref{fig:modify.xml})で見ることができます。 | |
2337 | +入力ファイルがオープンされた直後、@code{DECLARATION}型の@code{XMLEVENT}が起動しますが、入力データに宣言が含まれていないために@code{XMLATTR["ENCODING"]}変数はセットされていません。 | |
2203 | 2338 | [未翻訳] |
2204 | 2339 | That's the place where our script in @ref{fig:modify.awk} comes in and sets |
2205 | 2340 | the declaration in the right moment. So, the @command{XmlCopy()} function |
@@ -2229,48 +2364,51 @@ gawk -f modify.awk remote_data.xml | ||
2229 | 2364 | @caption{The output data of @file{modify.awk} is slightly modified} |
2230 | 2365 | @end float |
2231 | 2366 | |
2367 | + | |
2232 | 2368 | @node Reading an RSS news feed |
2233 | -@section RSS ニュースフィードの読み込み | |
2369 | +@section RSSニュースフィードの読み込み | |
2370 | + | |
2234 | 2371 | インターネットはニュースデータの便利なソースです。 |
2235 | -ほとんど常に、私たちは、HTTP プロトコルで転送されてきた HTML ファイルを読むためにブラウザを使っています。 | |
2236 | -しかし時々、手元にブラウザが無いことがあったり、すぐにニュースデータを見える状態にする必要が無かったりということがあります。 | |
2372 | +HTTPプロトコルで転送されてきたHTMLファイルを読むため、ほとんど常に私たちはブラウザを使っています。 | |
2373 | +しかし、手元にブラウザが無いことがあったり、ニュースデータを見える状態にすぐにする必要が無かったりということがあります。 | |
2237 | 2374 | 非常に小さいウィンドウでニュース見出しを表示するニュースティッカーというのが一例です。 |
2238 | 2375 | こういう場合のため、ニュース専用のフォーマットが作られました。 |
2239 | -@uref{http://www.rss-specifications.com, RSS format} です。 | |
2240 | -このデータを転送するプロトコルは HTTP のままですが、その内容はもはや HTML ではありません。 | |
2241 | -しかし、単純な構造の XML です (例 @pxref{fig:rss_inq})。 | |
2242 | -この例のルートノードは、RSS 仕様書のバージョン 0.91 に従ったデータ構造であることを示しています。 | |
2243 | -ノード番号の 2 は、このニュースのチャンネルを識別します。 | |
2244 | -また、子ノードの 3、4、5 番で拡張されていて、その子ノードにはニュースソースのタイトル、リンク、説明が入っています。 | |
2376 | +@uref{http://www.rss-specifications.com, RSS format}です。 | |
2377 | +このデータを転送するためのプロトコルはHTTPのままですが、転送する内容はもはやHTMLではありません。 | |
2378 | +しかし、単純な構造のXMLです(一例がfig:rss_inq(@pxref{fig:rss_inq})です)。 | |
2379 | +この例におけるルートノードは、RSS仕様書のバージョン0.91に従ったデータ構造であることを示しています。 | |
2380 | +ノード番号の2は、このニュースのチャンネルを識別します。 | |
2381 | +また、子ノードの3、4、5番で拡張されていて、そのノードにはニュースソースのタイトル、リンク、説明が入っています。 | |
2245 | 2382 | しかし、私たちはこれらには関心が無くて、各ニュースアイテムのタイトルに関心があります。 |
2246 | -そして、そのタイトルは、ノード 6 のようなノードが並んだものの中に入っています (ここでは一つしか描かれていませんけれども)。 | |
2383 | +そして、そのタイトルは、ノード6のようなノードが並んだものの中に入っています(ここでは一つしか描かれていませんけれども)。 | |
2247 | 2384 | |
2248 | 2385 | @cindex HTTP |
2249 | 2386 | @cindex HTML |
2250 | 2387 | @cindex RSS, Really Simple Syndication or Rich Site Summary |
2251 | 2388 | テキストの出力として欲しいものは、ニュースタイトルの短かいリストです。 |
2252 | -すなわち、@ref{fig:table_inq} にあるように、それは番号付けがされ、タイトルがあって、リンクがあるものです。 | |
2253 | -全ノードをトラバースしながら、それぞれのニュースアイテムのデータを収集するのはどうすればいいでしょうか? | |
2254 | -そして、一つのデータを拾い終わって、表示する準備ができるのはいつか、ということを知るにはどうすればいいでしょうか? | |
2255 | -考え方は、ノード 6 のようなアイテムが終るのを待つことです。 | |
2256 | -ツリーは深さ優先でパースされるので、(@code{XMLENDELEM == "item"} というパターンが (アクションを) トリガーする時、ノード 6 の子ノードである ノード 7 と 8 は既にパースされてしまっていることに注意してください。 | |
2257 | -ノード 7 と 8 の中の最新のデータは、表示すべきタイトルとリンクが入っています。 | |
2258 | -@emph{もっと早い段階で既にトラバースされてしまったノードのデータにアクセスするにはどうするのか?}と尋ねられるかもしれません。 | |
2259 | -その答えは、前もってテキストデータを保存しておくということです (XMLCHARDATA がトリガーする時にです)。 | |
2260 | -その時、保存されているデータがタイトルなのかリンクなのかについてはまだわかりません。 | |
2261 | -しかし、@code{XMLENDELEM == "title"} がトリガーすれば、そのときのそのデータがタイトルであることがわかりますので、それをそのように記憶することができます。 | |
2262 | -これが複雑に感じられるということと、AWK あるいはイベントベースのプログラミングにおけるもっと重要な知識を、あなたが理解する必要が明らかにあるということを私はわかっています。 | |
2263 | - | |
2264 | -これらの説明で混乱してしまっているのならば、今ぶつぶつ述べたことが全部、たった 4 行のコード (@code{while} ループの内側) の中に収まっているということを見れば愉快な気持になれるでしょう。 | |
2265 | -この 4 行がツリーからニュースアイテムを全て選択して、しかもノード 3、4、5 を無視するのに十分だということに少し驚きます。 | |
2266 | -ノード 3、4、5 番を無視することをどうやって実現しているのでしょうか? | |
2389 | +すなわち、fig:table_inq(@pxref{fig:table_inq})にあるように、番号付けがされ、タイトルがあって、リンクがあるものです。 | |
2390 | +全ノードをトラバースしながら、それぞれのニュースアイテムのデータを収集するのはどうすればいいでしょうか。 | |
2391 | +そして、一つのデータを拾い終わって、表示する準備ができるのはいつか、ということを知るにはどうすればいいでしょうか。 | |
2392 | +考え方としては、ノード6のようなアイテムが終るのを待つことです。 | |
2393 | +ツリーは深さ優先でパースされるので、(@code{XMLENDELEM == "item"}というパターンが(アクションを)トリガーする時、)ノード6の子ノードであるノード7とノード8は既にパースされてしまっていることに注意してください。 | |
2394 | +ノード7とノード8の中の最新のデータは、表示すべきタイトルとリンクが入っています。 | |
2395 | +@emph{それ以前の段階で既にトラバースされてしまったノードのデータにアクセスするにはどうするのか、}と思うかもしれません。 | |
2396 | +その答えは、テキストデータを前もって保存しておくということです(XMLCHARDATAがトリガーする時にです)。 | |
2397 | +その時、保存されているデータがタイトルなのかリンクなのかについてはまだ分かりません。 | |
2398 | +しかし、@code{XMLENDELEM == "title"}がトリガーすれば、その時のそのデータがタイトルであることが分かりますので、そのように記憶することができます。 | |
2399 | +これが複雑に感じられるということは分かります。 | |
2400 | +また、理解するのに、AWK、あるいは、イベントベースのプログラミングにおける先行経験が確実に必要であるということも分かります。 | |
2401 | + | |
2402 | +これらの説明で混乱してしまっているのならば、今ぶつぶつ述べたこと全部が、たった4行のコード(@code{while}ループの内側)の中に収まっているということを見れば、愉快な気持になれるでしょう。 | |
2403 | +ツリーからニュースアイテムを全て選択して、しかもノード3、4、5を無視するのに、この4行で十分だということに少し驚きます。 | |
2404 | +ノード3、4、5番を無視することをどうやって実現しているのでしょうか。 | |
2267 | 2405 | そうですね、実のところ無視しているわけではありません。 |
2268 | -@code{title} ノードと @code{link} ノードですが、その内容は @code{data} 変数へ保存されます。 | |
2269 | -しかし、表示は @code{item} タイプのノードを離れるときにだけ発生しますので、ノード 3 と 4 の内容は決して表示されません。 | |
2406 | +@code{title}ノードと@code{link}ノードですが、その内容は@code{data}変数へ保存されます。 | |
2407 | +しかし、@code{item}タイプのノードを離れる時にだけ表示が発生しますので、ノード3と4の内容は決して表示されません。 | |
2270 | 2408 | |
2271 | 2409 | @float Figure,fig:rss_inq |
2272 | -@image{rss_inq,,,RSS ニューズフィードの XML データのノード構造の例,} | |
2273 | -@caption{RSS ニューズフィードの XML データのノード構造の例} | |
2410 | +@image{rss_inq,,,RSSニューズフィードのXMLデータのノード構造の例,} | |
2411 | +@caption{RSSニューズフィードのXMLデータのノード構造の例} | |
2274 | 2412 | @end float |
2275 | 2413 | |
2276 | 2414 | @float Figure,fig:table_inq |
@@ -2282,17 +2420,18 @@ gawk -f modify.awk remote_data.xml | ||
2282 | 2420 | 5. US to take over the entire Internet http://www.theinquirer.net/?article=18975 |
2283 | 2421 | 6. AMD 90 nano shipments 50% by year end http://www.theinquirer.net/?article=18974 |
2284 | 2422 | @end smallexample |
2285 | -@caption{RSS ニュースフィードのニュースタイトル} | |
2423 | +@caption{RSSニュースフィードのニュースタイトル} | |
2286 | 2424 | @end float |
2287 | 2425 | |
2288 | -結局、この XML ファイルのトラバースが最も簡単な部分であるということがわかります。 | |
2289 | -インターネットからこのファイルを取得することは、もう少し複雑です。 | |
2290 | -インターネットから取得するニュースデータが、@uref{http://www.theinquirer.net/inquirer.rss, rumour mill} を離れて流れて来たホヤホヤの時点で XML データとして扱うことができたら素晴しかったでしょう。 | |
2291 | -しかし残念ながら、この XML データにはヘッダが付いてきます。 | |
2292 | -そのヘッダは XML の規則に従っていません -- つまり HTTP ヘッダです。 | |
2293 | -ですので、まずその HTTP ヘッダを飲み込んでしまわないといけません。 | |
2294 | -それから、ASCII の行としてそのニュースフィードから行を全て読み込んで、一時ファイルに保存しなければいけません。 | |
2295 | -その一時ファイルをクローズした後は、そのファイルを XML ファイルとして再オープンして、前述したようにニュースのノードをトラバースすることができます。 | |
2426 | +結局、XMLファイルのトラバースが最も簡単な部分であるということが分かります。 | |
2427 | +インターネットからこのファイルを取得するのはもう少し複雑です。 | |
2428 | +インターネットから取得するニュースデータが、@uref{http://www.theinquirer.net/inquirer.rss, rumour mill}を離れて流れて来たホヤホヤの時点でXMLデータとして扱うことができたら素晴しかったでしょう。 | |
2429 | +しかし、残念ながら、このXMLデータにはヘッダが付いてきます。 | |
2430 | +そのヘッダはXMLの規則に従っていません。 | |
2431 | +つまり、HTTPヘッダです。 | |
2432 | +ですから、まず、そのHTTPヘッダを飲み込んでしまわないといけません。 | |
2433 | +それから、ニュースフィードからASCIIの行として行を全て読み込んで、一時ファイルに保存しなければいけません。 | |
2434 | +その一時ファイルをクローズした後は、そのファイルをXMLファイルとして再オープンして、前述したように、ニュースのノードをトラバースすることができます。 | |
2296 | 2435 | |
2297 | 2436 | @pindex @file{get_rss_feed.awk} |
2298 | 2437 | @example |
@@ -2340,91 +2479,93 @@ BEGIN @{ | ||
2340 | 2479 | @} |
2341 | 2480 | @end example |
2342 | 2481 | |
2343 | -RSS ニュースフィードからのデータについてもっと詳しい情報は、@uref{http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html, @emph{What is RSS}} という素晴しい記事がありますので、そこで読むことができます。 | |
2344 | -詳細について深く掘り下げていくと、いずれも RSS と自らのことを呼ぶがその内容は異なっている似たような構造定義が多数存在することがわかるでしょう。 | |
2345 | -上記の私たちのスクリプトは、このスクリプトが種々の RSS リソースを全て理解できるということが確実になるように書きましたが、これは細かい部分を無視するという犠牲を払ってやっと達成することができました。 | |
2482 | +RSSニュースフィードのデータについてもっと詳しい情報は、@uref{http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html, @emph{What is RSS}}という素晴しい記事がありますので、そこで読むことができます。 | |
2483 | +詳細について深く掘り下げていくと、いずれもRSSと自称するが、その内容が異なっている似たような構造定義が多数存在することが分かるでしょう。 | |
2484 | +上記のスクリプトは、種々のRSSリソースを確実に全て解釈できるように書きましたが、これは、細かい部分を無視するという犠牲を払ってやっと達成することができました。 | |
2346 | 2485 | |
2347 | -RSS フィードにはもう一つ問題があります。 | |
2486 | +RSSフィードにはもう一つ問題があります。 | |
2348 | 2487 | @cindex Yahoo |
2349 | -たとえば、Yahoo も RSS のニュースフィードを提供しています。 | |
2350 | -しかし、これを取得するために上記のスクリプトを使った場合、Yahoo は正しい XML データではなく HTML データを送信します。 | |
2351 | -これは、RSS の標準が正しく定義されていなくて、Yahoo の HTTP サーバが RSS データに対するリクエストを理解していないために起こることです。 | |
2488 | +例えば、Yahooも、RSSのニュースフィードを提供しています。 | |
2489 | +しかし、これを取得するために上記のスクリプトを使った場合、Yahooは正しいXMLデータではなくHTMLデータを送信します。 | |
2490 | +これは、RSSの標準が正しく定義されていなくて、YahooのHTTPサーバがRSSデータに対するリクエストを理解していないために起こることです。 | |
2491 | + | |
2352 | 2492 | |
2353 | 2493 | @node Using a service via SOAP |
2354 | -@section SOAP を経由したサービスの利用 | |
2494 | +@section SOAPを経由したサービスの利用 | |
2355 | 2495 | @cindex SOAP, Simple Object Access Protocol |
2356 | 2496 | @cindex HTTP |
2357 | 2497 | |
2358 | -@ref{RSS ニュースフィードの読み込み}で、インターネット上のシンプルなサービスをどのように使うことができるかを見ました。 | |
2359 | -そのサービスに対するリクエストは、サービスの名前をともなった一つの行でした。 | |
2360 | -サーバからのレスポンスだけが XML データで出来ていました。 | |
2361 | -リクエスト自体に、改行を含むテキストデータとか外国の文字記号を含んだりして、様々なタイプの複数のパラメータが入っているとしたらどうでしょうか? | |
2362 | -Yahoo の株式相場のような古典的なサービスの場合は、HTTP リクエストの @code{GET} 行にパラメータを追加することで多数のパラメータを渡す方法を見つけました。 | |
2363 | -実践により、過度に長い @code{GET} 行は (容認できるような) @emph{awk} 風では無いだけでなく、オブジェクト指向サービスが必要とされた時には不十分であるということがわかっています。 | |
2364 | -オブジェクト指向サービスのクリーンな実装の必要性は、@uref{http://www.w3.org/TR/soap, SOAP protocol} の考案の背後にある動機でした。 | |
2365 | -一行の中にリクエストパラメータを押し込めてしまう代わりに、XML エンコードされたデータを、SOAP サービスへパラメータを渡す方法として利用します。 | |
2366 | -SOAP でも、転送には HTTP を依然使いますが、そのパラメータは、HTTP の @code{POST} メソッドで転送されます (@code{POST} メソッドは、@code{GET} とは異なり、リクエストの本体部分を使ってデータを渡すことができます)。 | |
2367 | - | |
2368 | -この @value{SECTION} では SOAP サービスのクライアントを書きます。 | |
2369 | -インターネット上では、@uref{http://xmethods.net/ve2/ViewClient.po?clientid=261249, Barnes & Noble Price Quote service} の非常に短い正式な説明を見ることができます。 | |
2498 | +前節(@pxref{Reading an RSS news feed})で、インターネット上のシンプルなサービスをどのように使うことができるかを見ました。 | |
2499 | +そのサービスに対するリクエストは、サービスの名前を伴った一つの行でした。 | |
2500 | +サーバからのレスポンスだけがXMLデータで出来ていました。 | |
2501 | +リクエスト自体に、改行を含むテキストデータとか外国の文字記号を含んだりして、様々なタイプの複数のパラメータが入っているとしたらどうでしょうか。 | |
2502 | +Yahooの株式相場のような古典的なサービスの場合は、HTTPリクエストの@code{GET}行にパラメータを追加することで多数のパラメータを渡す方法を見つけました。 | |
2503 | +過度に長い@code{GET}行は(容認できるような)@emph{awk}風では無いだけでなく、オブジェクト指向サービスが必要とされた時には不十分であるということが実践により分かっています。 | |
2504 | +オブジェクト指向サービスのクリーンな実装の必要性は、@uref{http://www.w3.org/TR/soap, SOAP protocol}の考案の背後にある動機でした。 | |
2505 | +リクエストパラメータを一行に押し込めてしまう代わりに、XMLエンコードされたデータを、SOAPサービスへパラメータを渡す方法として利用します。 | |
2506 | +SOAPでも転送にはHTTPを依然使いますが、そのパラメータは、HTTPの@code{POST}メソッドで転送されます(@code{POST}メソッドは、@code{GET}とは異なり、リクエストの本体部分を使ってデータを渡すことができます)。 | |
2507 | + | |
2508 | +この@value{SECTION}ではSOAPサービスのクライアントを記述します。 | |
2509 | +インターネット上では、@uref{http://xmethods.net/ve2/ViewClient.po?clientid=261249, Barnes & Noble Price Quote service}の非常に短い正式な説明を見ることができます。 | |
2370 | 2510 | @cindex Barnes & Noble Price Quote |
2371 | -ユーザは、このサービスに対して書籍の ISBN コードを送信することができます。 | |
2372 | -そして、サービスはその本の価格が記載された何らかの XML データを返します。 | |
2373 | -この事例のサービスは、パラメータが一つだけ必要で、それゆえ、SOAP と XML 無しで実装すべきであるという主張をされるかもしれません。 | |
2374 | -それはその通りなのですが、この SOAP の実装は、操作の基本的な原則を示すには十分良いのです。 | |
2375 | -もしあなたが納得していなくて、リクエストとともに構造化したデータを渡すことができる SOAP の能力を乱用するサービスを選ぶというのであれば、インターネット上のリストを一つ見てみるとよいでしょう。 | |
2376 | -そこには多くの @uref{http://xmethods.net, publicly available SOAP services} が存在しています。 | |
2511 | +ユーザは、このサービスに対して書籍のISBNコードを送信することができます。 | |
2512 | +そして、サービスは、その本の価格が記載された何らかのXMLデータを返します。 | |
2513 | +この事例のサービスは、パラメータが一つだけ必要で、それゆえ、SOAPとXML無しで実装すべきであるという主張をされるかもしれません。 | |
2514 | +それはその通りなのですが、このSOAPの実装は、操作の基本的な原則を示すには十分良いのです。 | |
2515 | +もし、納得できなくて、リクエストとともに構造化したデータを渡すことができるSOAPの能力を乱用するサービスを選ぶというのであれば、インターネット上のリストを一つ見てみるとよいでしょう。 | |
2516 | +そこには、多くの@uref{http://xmethods.net, publicly available SOAP services}が存在しています。 | |
2377 | 2517 | このページを訪問することをお勧めします。 |
2378 | -そこで見ることができるものには、本当に啓発されます。 | |
2379 | -もっと複雑なサービスの内部動作に関心がある人は、リストにある実例のサービスの @emph{Try It} というリンクをクリックしてみるべきでしょう。 | |
2380 | -@emph{Try It} リンクの向こうには、SOAP リクエストのためのある種のデバッガがあって、リクエストとレスポンスの内容が、疑似コードや生データ、ツリー、あるいは対話的な XML 表示で示されています。 | |
2381 | -私はこの @emph{SOAPscope} で多くのことを学びました。 | |
2518 | +そこで見ることができるものには、本当に教えられます。 | |
2519 | +もっと複雑なサービスの内部動作に関心がある人は、リストにある実例サービスの@emph{Try It}というリンクをクリックしてみるべきでしょう。 | |
2520 | +@emph{Try It}リンクの向こうには、SOAPリクエストのためのある種のデバッガがあって、リクエストとレスポンスの内容が、疑似コードや生データ、ツリー、あるいは、対話的なXML表示で示されています。 | |
2521 | +私は、この@emph{SOAPscope}で多くのことを学びました。 | |
2382 | 2522 | @cindex SOAPscope. |
2383 | 2523 | |
2384 | -Barnes & Noble Price Quote サービスの作者 (Mustafa Basgun) は、この彼のサービスのクライアントも書きました。 | |
2385 | -インターネット上のある素晴しい記事の中で、この作者は、@emph{Flash MX} を活用しながら、どのように @uref{http://www.devmx.com/articles.cfm?Mode=Article&c=6&a=8, GUI-based client interface} を実装したのかを説明しています。 | |
2524 | +Barnes & Noble Price Quoteサービスの作者(Mustafa Basgun)は、このサービスのクライアントも書きました。 | |
2525 | +インターネット上のある素晴しい記事の中で、この作者は、@emph{Flash MX}を活用しながら、どのように@uref{http://www.devmx.com/articles.cfm?Mode=Article&c=6&a=8, GUI-based client interface}を実装したのかを説明しています。 | |
2386 | 2526 | この記事から以下を引用します。 |
2387 | -これは、SOAP とは何であるかについて幾分か詳しく説明しています。 | |
2527 | +これは、SOAPとは何であるかについて幾分か詳しく説明しています。 | |
2388 | 2528 | |
2389 | 2529 | @quotation |
2390 | -Simple Object Access Protocol (SOAP) は非集中分散環境での情報交換のための軽量プロトコルです。 | |
2391 | -XML ベースのプロトコルで、三つの部分から構成されます。 | |
2392 | -一つめは、メッセージの中にあるものは何なのか、そしてそれをどう処理するのかを記述するためのフレームワークを定義するエンベロープ。 | |
2393 | -二つめは、アプリケーションが定義したデータタイプのインスタンスを表現するエンコーディングの規則のセット。 | |
2530 | +Simple Object Access Protocol(SOAP)は、非集中分散環境での情報交換のための軽量プロトコルです。 | |
2531 | +XMLベースのプロトコルで、三つの部分から構成されます。 | |
2532 | +一つ目の部分は、メッセージの中にあるものは何なのか、そして、それをどう処理するのかを記述するためのフレームワークを定義するエンベロープです。 | |
2533 | +二つ目の部分は、アプリケーションが定義したデータタイプのインスタンスを表現するエンコーディングの規則のセットです。 | |
2394 | 2534 | 最後は、リモートプロシージャの呼び出しとレスポンスのための取り決めです。 |
2395 | 2535 | @end quotation |
2396 | 2536 | |
2397 | 2537 | @cindex Schema |
2398 | -彼が述べている部分は全て @ref{fig:soap_request} にある例の中に見ることができます。 | |
2399 | -この例は、XML フォーマットの SOAP リクエストを (縮退させたツリーとして) 図示したものを示しています。 | |
2400 | -ルートノードが引用の中で述べられているエンベロープです。 | |
2401 | -この XML データ (スキーマとエンコーディング) をどのように処理するかについての詳細は、ルートノードのアトリビュートに宣言されています。 | |
2402 | -ノードの 4 番のキャラクタデータにある ISBN コードを持つ本の価格を取得するのに使うリモートプロシージャコールの @code{getPrice} がノードの 3 番に入っています。 | |
2403 | -ノードの 4 番は、ISBN 自体が入っているだけでなく、リモートプロシージャの @code{getPrice} へ渡されるパラメータ (ISBN であるもの) のデータ型 @code{xs:string} も宣言しています。 | |
2538 | +彼が述べている部分は、fig:soap_request(@pxref{fig:soap_request})にある例の中に全て見ることができます。 | |
2539 | +この例は、XMLフォーマットのSOAPリクエストを(縮退させたツリーとして)図示したものを示しています。 | |
2540 | +ルートノードが、引用の中で述べられているエンベロープです。 | |
2541 | +このXMLデータ(スキーマとエンコーディング)をどのように処理するかについての詳細は、ルートノードのアトリビュートに宣言されています。 | |
2542 | +ノードの4番のキャラクタデータにあるISBNコードを持つ本の価格を取得するのに使うリモートプロシージャコールの@code{getPrice}がノードの3番に入っています。 | |
2543 | +ノードの4番は、ISBN自体が入っているだけでなく、リモートプロシージャの@code{getPrice}へ渡されるパラメータ(ISBNであるもの)のデータ型@code{xs:string}も宣言しています。 | |
2404 | 2544 | |
2405 | 2545 | @float Figure,fig:soap_request |
2406 | -@image{soap_request,,,SOAP フォーマットでの本の価格のリクエスト,} | |
2407 | -@caption{SOAP フォーマットでの本の価格のリクエスト} | |
2546 | +@image{soap_request,,,SOAPフォーマットでの本の価格のリクエスト,} | |
2547 | +@caption{SOAPフォーマットでの本の価格のリクエスト} | |
2408 | 2548 | @end float |
2409 | 2549 | |
2410 | -SOAP クライアントのコーディングを始める前に、このリクエストに対するレスポンスがどのように見えるのかを調べなければなりません。 | |
2411 | -@ref{fig:soap_reply} にあるツリーは、レスポンスとして来る XML データで、本の価格を探すときにトラバースしなければならないものです。 | |
2412 | -正しいクライアントは完全にツリーを解析して、出てきたノードの型に対して注意を払うでしょう。 | |
2413 | -@ref{fig:soap_reply} の構造は、リクエストが成功した時にだけ返されるでしょう。 | |
2414 | -もしリクエストが失敗していたならば、失敗を示す違う種類のノードに直面することになるでしょう。 | |
2415 | -レスポンスが静的な数字や文字列ではなく、内容が変化するツリーであるということは SOAP の利点の一つです。 | |
2416 | -エラーメッセージは、わけのわからないやり方でただ番号付けされるのでは無く、特定のタグ名と、何が問題なのかを説明するキャラクタデータを含む XML エレメントとしてやってきます。 | |
2417 | -しかし、私たちは今、ノードの 4 番 (@code{return} タグ) が @code{xsd:float} という型で、キャラクタデータとして本の価格が入っているという成功のケースだけに関心があります。 | |
2550 | +SOAPクライアントのコーディングを始める前に、このリクエストに対するレスポンスがどのように見えるのかを調べなければなりません。 | |
2551 | +fig:soap_reply(@pxref{fig:soap_reply})にあるツリーはレスポンスとして来るXMLデータです。 | |
2552 | +本の価格を探す時にトラバースしなければならないものです。 | |
2553 | +正しいクライアントならば、完全にツリーを解析して、出てきたノードの型に対して注意を払います。 | |
2554 | +fig:soap_reply(@pxref{fig:soap_reply})の構造は、リクエストが成功した時にだけ返されます。 | |
2555 | +もし、リクエストが失敗していたならば、失敗を示す違う種類のノードに直面することになるでしょう。 | |
2556 | +レスポンスが静的な数字や文字列ではなく、内容が変化するツリーであるということはSOAPの利点の一つです。 | |
2557 | +エラーメッセージは、訳の分からないやり方でただ番号付けされるのでは無く、特定のタグ名と、何が問題なのかを説明するキャラクタデータを含むXMLエレメントとしてやってきます。 | |
2558 | +しかし、今は、ノードの4番(@code{return}タグ)が@code{xsd:float}という型で、キャラクタデータとして本の価格が入っているという成功のケースだけに関心があります。 | |
2418 | 2559 | |
2419 | 2560 | @float Figure,fig:soap_reply |
2420 | -@image{soap_reply,,,SOAP フォーマットでの本の価格のリクエストに対するレスポンス,} | |
2421 | -@caption{SOAP フォーマットでの本の価格のリクエストに対するレスポンス} | |
2561 | +@image{soap_reply,,,SOAPフォーマットでの本の価格のリクエストに対するレスポンス,} | |
2562 | +@caption{SOAPフォーマットでの本の価格のリクエストに対するレスポンス} | |
2422 | 2563 | @end float |
2423 | 2564 | |
2424 | -@ref{fig:soap_book_price_quote.awk} にある SOAP クライアントの最初の部分は、先の RSS クライアントと非常によく似ています。 | |
2425 | -@code{isbn} はコマンドラインからパラメータとして渡される一方、@code{host} 名とサービス識別子の @code{soap} は固定されています。 | |
2426 | -@code{response} 変数を見れば、@ref{fig:soap_request} からのツリーがわかります。 | |
2427 | -@code{isbn} だけ固定されていませんが、SOAP サーバへ後で送信される XML データの中に変数として挿入されます。 | |
2565 | +fig:soap_book_price_quote.awk(@pxref{fig:soap_book_price_quote.awk})にあるSOAPクライアントの最初の部分は、先のRSSクライアントと非常によく似ています。 | |
2566 | +@code{isbn}が、コマンドラインからパラメータとして渡される一方、@code{host}名とサービス識別子の@code{soap}は固定されています。 | |
2567 | +@code{response}変数を見れば、fig:soap_request(@pxref{fig:soap_request})からのツリーが分かります。 | |
2568 | +@code{isbn}だけ固定されていませんが、SOAPサーバへ後で送信されるXMLデータの中に変数として挿入されます。 | |
2428 | 2569 | |
2429 | 2570 | @float Figure,fig:soap_book_price_quote.awk |
2430 | 2571 | @pindex @file{soap_book_price_quote.awk} |
@@ -2459,22 +2600,25 @@ BEGIN @{ | ||
2459 | 2600 | </soap:Body> \ |
2460 | 2601 | </soap:Envelope>" |
2461 | 2602 | @end example |
2462 | -@caption{SOAP リクエストを組み立てる @file{soap_book_price_quote.awk} の最初の部分} | |
2603 | +@caption{SOAPリクエストを組み立てる@file{soap_book_price_quote.awk}の最初の部分} | |
2463 | 2604 | @end float |
2464 | 2605 | |
2465 | -SOAP クライアントの 2 番目と 3 番目の部分は、さらに RSS クライアントと似ています。 | |
2606 | +SOAPクライアントの2番目と3番目の部分は、RSSクライアントとさらに似ています。 | |
2466 | 2607 | しかし、もっと念入りに比べてみれば、いくつか興味深い違いが見つかるでしょう。 |
2467 | 2608 | 次のようなものです。 |
2609 | + | |
2468 | 2610 | @itemize |
2469 | 2611 | @item |
2470 | -@code{ORS} 変数がもう使われていません。 | |
2471 | -ここではヘッダ行を違うやり方で処理している。 | |
2612 | +@code{ORS}変数がもう使われていません。 | |
2613 | +ここでは、ヘッダ行を違うやり方で処理しています。 | |
2614 | + | |
2472 | 2615 | @item |
2473 | -ヘッダそのものは今は HTTP の @code{POST} メソッドで始まっていて、@code{GET} メソッドではありません。 | |
2616 | +ヘッダそのものは、今は、HTTPの@code{POST}メソッドで始まっていて、@code{GET}メソッドではありません。 | |
2617 | + | |
2474 | 2618 | @item |
2475 | 2619 | 送信されるヘッダが多くなっています。 |
2476 | -たいていの SOAP サービスは、クライアントがコンテントタイプとコンテント長を指定するように求めています。 | |
2477 | -そういったサービスをホスティングしている HTTP サーバが、この種の情報を受信し慣れているからです。 | |
2620 | +たいていのSOAPサービスは、コンテントタイプとコンテント長をクライアントが指定するように求めています。 | |
2621 | +そういったサービスをホスティングしているHTTPサーバはこの種の情報を受信し慣れているからです。 | |
2478 | 2622 | @end itemize |
2479 | 2623 | |
2480 | 2624 | @float Figure,fig:soap_book_price_quote.awk.2 |
@@ -2492,13 +2636,13 @@ SOAP クライアントの 2 番目と 3 番目の部分は、さらに RSS ク | ||
2492 | 2636 | print "" |& HttpService |
2493 | 2637 | print request |& HttpService |
2494 | 2638 | @end example |
2495 | -@caption{SOAP リクエストを送信する @file{soap_book_price_quote.awk} の 2 番目の部分} | |
2639 | +@caption{SOAPリクエストを送信する@file{soap_book_price_quote.awk}の2番目の部分} | |
2496 | 2640 | @end float |
2497 | 2641 | |
2498 | -リクエストを送信すれば、やらなければならないのはレスポンスの受信とその XML ツリーのトラバースです。 | |
2499 | -ちょうど例の RSS クライアントのように、この SOAP クライアントは一時ファイルに XML のレスポンスを保存し、このファイルを XML ファイルとしてオープンします。 | |
2500 | -XML ツリーをトラバースしている間、このクライアントは非常に単純に振舞います。 | |
2501 | -すなわち、キャラクタデータを記憶し、@code{return} というタグ名のノードが来るとすぐ表示します。 | |
2642 | +リクエストを送信すれば、やらなければならないのはレスポンスの受信とそのXMLツリーのトラバースです。 | |
2643 | +例示したRSSクライアントとちょうど同じように、このSOAPクライアントは一時ファイルにXMLのレスポンスを保存し、このファイルをXMLファイルとしてオープンします。 | |
2644 | +XMLツリーをトラバースしている間、このクライアントは非常に単純に振舞います。 | |
2645 | +すなわち、キャラクタデータを記憶し、@code{return}というタグ名のノードが来るとすぐ表示します。 | |
2502 | 2646 | |
2503 | 2647 | @float Figure,fig:soap_book_price_quote.awk.3 |
2504 | 2648 | @example |
@@ -2522,7 +2666,7 @@ XML ツリーをトラバースしている間、このクライアントは非 | ||
2522 | 2666 | @} |
2523 | 2667 | @} |
2524 | 2668 | @end example |
2525 | -@caption{SOAP レスポンスを読み取る @file{soap_book_price_quote.awk} の最後の 3 番目の部分} | |
2669 | +@caption{SOAPレスポンスを読み取る@file{soap_book_price_quote.awk}の最後の3番目の部分} | |
2526 | 2670 | @end float |
2527 | 2671 | |
2528 | 2672 | @float Figure,fig:soap_error |
@@ -2530,25 +2674,29 @@ XML ツリーをトラバースしている間、このクライアントは非 | ||
2530 | 2674 | @caption{Response to a SOAP request in case of an error} |
2531 | 2675 | @end float |
2532 | 2676 | |
2533 | -エラーの場合は何が起きるでしょうか? | |
2534 | -以下に述べるそれぞれのケースは、正しく SOAP クライアントを書く場合にはもっと丁寧に処理しなければならないでしょう。 | |
2677 | +エラーの場合は何が起きるでしょうか。 | |
2678 | +以下に述べる各ケースは、正しくSOAPクライアントを書く場合にはもっと丁寧に処理しなければならないでしょう。 | |
2535 | 2679 | |
2536 | 2680 | @itemize |
2537 | 2681 | @item |
2538 | -サービスが、指定された ISBN を知らない時は、価格として @code{-1.0} を返します。 | |
2539 | -これは私たちの SOAP クライアントにとっては問題とならないですが、ユーザは負の価格を検査することを忘れないようにしなければなりません。 | |
2682 | +指定されたISBNをサービスが知らない時は、価格として@code{-1.0}を返します。 | |
2683 | +私たちのSOAPクライアントにとってはこれは問題とならないですが、負の価格を検査するのをユーザは忘れないようにしなければなりません。 | |
2684 | + | |
2540 | 2685 | @item |
2541 | -SOAP サービスへのネットワーク接続が確立できなかった時は、その時はクライアントがかなり長い時間@emph{ハング}するかもしれません。 | |
2542 | -そして何も起きず、最終的にエラーで終了しますが、テキスト的な反応はありません。 | |
2543 | -あるいは、例えばファイヤウォールがリクエストを拒絶したような場合には、クライアントはすぐに終了します。 | |
2686 | +SOAPサービスへのネットワーク接続が確立できなかった時は、クライアントがかなり長い時間@emph{ハング}するかもしれません。 | |
2687 | +そして、何も起きず、最終的にエラーで終了しますが、テキスト的な反応はありません。 | |
2688 | +あるいは、例えば、ファイアウォールがリクエストを拒絶したような場合には、クライアントはすぐに終了します。 | |
2689 | + | |
2544 | 2690 | @item |
2545 | -HTTP リクエストのヘッダに何か不足しているか、あるいは、リクエストの XML ツリーが不完全な時は、正しい SOAP レスポンスを受信することになるでしょう。 | |
2546 | -しかし、そのレスポンスには @code{return} ノードは見つけられないでしょう (それゆえクライアントは何も表示しません)。 | |
2547 | -代わりに、そのレスポンスには @code{SOAP-ENV:Fault}、@code{faultcode}、@code{faultstring}、@code{faultactor} という型のノードが入っています。 | |
2548 | -この状況は @ref{fig:soap_error} に図示しています。 | |
2691 | +HTTPリクエストのヘッダに何か不足しているか、あるいは、リクエストのXMLツリーが不完全な時は、正しいSOAPレスポンスを受信します。 | |
2692 | +しかし、そのレスポンスには@code{return}ノードは見つけられないでしょう(それゆえクライアントは何も表示しません)。 | |
2693 | +代わりに、そのレスポンスには@code{SOAP-ENV:Fault}、@code{faultcode}、@code{faultstring}、@code{faultactor}という型のノードが入っています。 | |
2694 | +この状況はfig:soap_error(@pxref{fig:soap_error})に図示しています。 | |
2695 | + | |
2549 | 2696 | @item |
2550 | -サービスが異常終了する時、正しい XML メッセージでレスポンスすることは不可能です。 | |
2551 | -この場合、ホスティングしている HTTP サーバが、よく独特の言い回しでメッセージを入れます (たいてい HTML でのつぶやきです)。 | |
2697 | +サービスが異常終了する時は、正しいXMLメッセージでレスポンスすることは不可能です。 | |
2698 | +この場合、ホスティングしているHTTPサーバは、よく、独特の言い回しでメッセージを入れます(たいていHTMLでのつぶやきです)。 | |
2699 | + | |
2552 | 2700 | @example |
2553 | 2701 | <h1>Error: 400</h1> |
2554 | 2702 | Error unmarshalling envelope: SOAP-ENV:VersionMismatch: |
@@ -2557,20 +2705,21 @@ Envelope element must be associated with the | ||
2557 | 2705 | @end example |
2558 | 2706 | @end itemize |
2559 | 2707 | |
2560 | -私は上記の各ケースを@emph{~の時は}という条件を付けて書きました。 | |
2708 | +上記の各ケースを、@emph{~の時は}という条件を付けて書きました。 | |
2561 | 2709 | というのは、そのようなケースがいつか@emph{起きるのかどうか}という問題ではなく、@emph{いつ}起きるだろうかというだけの問題だからです。 |
2562 | -ソフトウェアを書く時、起こり得るケースを場合分けするということは常に重要なことです (例えば、リターンコードを評価したり、例外をキャッチしたりです)。 | |
2710 | +ソフトウェアを書く時、起こり得るケースを場合分けするということは常に重要なことです(例えば、リターンコードを評価したり、例外を捕捉したりということです)。 | |
2563 | 2711 | しかし、ネットワークへ接続するソフトウェアを書いている時は、そのようにすることは不可避なことです。 |
2564 | 2712 | そうでなければ、そのネットワーキングソフトウェアは信頼のおけないものになるでしょう。 |
2565 | -ですので、実世界のクライアントは普通、この @value{SECTION} で書いたクライアントよりももっと長いものとなります。 | |
2566 | -しかし多くの場合、エラー条件を取り扱うことは実際には複雑ではありません。 | |
2567 | -たとえば、@code{while} ループ本体の最後のところに以下の一行を入れると、正しいエラー処理への第一段階を行うことができます。 | |
2713 | +ですから、実世界のクライアントは、普通、この@value{SECTION}で書いたクライアントよりももっと長いものとなります。 | |
2714 | +しかし、多くの場合、エラー条件を取り扱うことは実際には複雑ではありません。 | |
2715 | +例えば、@code{while}ループ本体の最後のところに以下の一行を入れると、正しいエラー処理への第一段階を行うことができます。 | |
2568 | 2716 | |
2569 | 2717 | @example |
2570 | 2718 | if (XMLENDELEM ~ /^fault/) @{ print XMLENDELEM ":", price @} |
2571 | 2719 | @end example |
2572 | 2720 | |
2573 | -このクライアントが @ref{fig:soap_error} にあるようなレスポンスを受け取ることがあればいつでも、ノード 4、5、6 が入った検出メッセージが表示されるでしょう。 | |
2721 | +fig:soap_error(@pxref{fig:soap_error})にあるようなレスポンスをこのクライアントが受け取ることがあれば、必ず、ノード4、5、6が入った検出メッセージが表示されます。 | |
2722 | + | |
2574 | 2723 | @example |
2575 | 2724 | faultcode: SOAP-ENV:Protocol |
2576 | 2725 | faultstring: Content length must be specified. |
@@ -2579,30 +2728,32 @@ faultactor: /soap/servlet/rpcrouter | ||
2579 | 2728 | |
2580 | 2729 | |
2581 | 2730 | @node Loading XML data into PostgreSQL |
2582 | -@section PostgreSQL への XML データのロード | |
2731 | +@section PostgreSQLへのXMLデータのロード | |
2583 | 2732 | @pindex PostgreSQL |
2584 | -@cindex データベース | |
2585 | -前の @value{SECTION} では、データベースの照会の間のデータ交換用フォーマットとしてどのように XML が利用できるかを見てきました。 | |
2586 | -そのようなデータベースの検索における XML の利用は、今日ではかなりありふれたことです。 | |
2587 | -しかし、背後にある巨大なデータベースの実際の格納フォーマットは、普通は XML ではありません。 | |
2588 | -プロプライエタリのデータベースソリューションの多くは、この数十年の間に自分たちのニッチマーケットを確立してきました。 | |
2589 | -XML のような妙な新しいフォーマットが突然登場したというだけで、それらのデータベースソリューションが姿を消すことは間違いなく無いでしょう。 | |
2590 | -その結果、従来のデータベースと XML の間のデータ変換のニーズが、商用アプリケーションの内外で繰り返し生じてきます。 | |
2591 | -幸運にも、問い合わせ言語の SQL が問い合わせを表現する標準として広く認められています。 | |
2733 | +@cindex database | |
2734 | + | |
2735 | +前の@value{SECTION}では、データベースの照会の間のデータ交換用フォーマットとしてどのようにXMLが利用できるかを見てきました。 | |
2736 | +そのようなデータベースの検索におけるXMLの利用は、今日ではかなりありふれたことです。 | |
2737 | +しかし、背後にある巨大なデータベースの実際の格納フォーマットは、普通、XMLではありません。 | |
2738 | +プロプライエタリのデータベースソリューションの多くは、この数十年の間に、自分たちのニッチマーケットを確立してきました。 | |
2739 | +XMLのような妙な新しいフォーマットが突然登場したというだけで、それらのデータベースソリューションが姿を消すことはまず無いでしょう。 | |
2740 | +その結果、従来のデータベースとXMLの間のデータ変換のニーズが、商用アプリケーションの内外で繰り返し生じてきます。 | |
2592 | 2741 | @pindex SQL |
2593 | -しかし、残念ながら、リクエストと、問い合わせの受け渡し、その結果の受け渡しに関する実際のインターフェイス (転送のメカニズム) はまったく標準化されていません。 | |
2594 | -この @value{SECTION} の残りの部分では、特定のデータベース PostgreSQL に対する GNU Awk 拡張を作成することによって、こういった問題をどのように解決するかを説明します。 | |
2595 | -独自のアクセス機構はすべて拡張の中に隠蔽され、アプリケーションスクリプトはこの拡張を利用します。 | |
2596 | -手近な問題は、小さな連絡用データベースファイル (XML、@ref{fig:sample.xml}) を読み込んで、GNU Awk の以下の二つの拡張を利用しながら PostgreSQL データベースへそのデータを書き込むことです。 | |
2742 | +幸運にも、問い合わせ言語のSQLが、問い合わせを表現する標準として広く認められています。 | |
2743 | +しかし、残念ながら、リクエストと問い合わせの受け渡し、その結果の受け渡しに関する実際のインターフェイス(転送のメカニズム)は全く標準化されていません。 | |
2744 | +この@value{SECTION}の残りの部分では、特定のデータベースPostgreSQLに対するGNU Awk拡張を作成することによって、こういった問題をどのように解決するかを説明します。 | |
2745 | +独自のアクセス機構は全て拡張の中に隠蔽され、アプリケーションスクリプトはこの拡張を利用します。 | |
2746 | +目前に置く問題は、小さな連絡用データベースファイル(XML, @pxref{fig:sample.xml})を読み込んで、GNU Awkの以下の二つの拡張を利用しながら、PostgreSQLデータベースへそのデータを書き込むことです。 | |
2747 | + | |
2597 | 2748 | @table @samp |
2598 | 2749 | @item xml |
2599 | -XML ファイルからデータを読み込む | |
2750 | +XMLファイルのデータを読み込むためのもの | |
2600 | 2751 | @item pgsql |
2601 | -PostgreSQL のデータベースインターフェイスに接続する | |
2752 | +PostgreSQLのデータベースインターフェイスに接続するためのもの | |
2602 | 2753 | @end table |
2603 | 2754 | |
2604 | -それで、@ref{fig:testxml2pgsql.awk} のアプリケーションスクリプトがこの拡張を両方ロードすることで始まるのは驚くことではありません。 | |
2605 | -@code{pgsql} のような GNU Awk 拡張は通常、基礎となっている @uref{http://www.postgresql.org/docs/8.0/interactive/libpq.html, C interface} をアプリケーションスクリプトの作者に使いやすくするために実装されています。 | |
2755 | +fig:testxml2pgsql.awk(@pxref{fig:testxml2pgsql.awk})のアプリケーションスクリプトがこの拡張を両方ロードすることで始まるのは驚くことではありません。 | |
2756 | +@code{pgsql}のようなGNU Awk拡張は、通常、基礎となっている@uref{http://www.postgresql.org/docs/8.0/interactive/libpq.html, C interface}を、アプリケーションスクリプトの作者が使いやすくなるように実装されています。 | |
2606 | 2757 | |
2607 | 2758 | @float Figure,fig:testxml2pgsql.awk |
2608 | 2759 | @pindex @file{testxml2pgsql.awk} |
@@ -2611,13 +2762,13 @@ PostgreSQL のデータベースインターフェイスに接続する | ||
2611 | 2762 | @@load pgsql |
2612 | 2763 | |
2613 | 2764 | BEGIN @{ |
2614 | - # 注意: 以下のところで議論されているように、PQconnectdb オプションを含めて | |
2615 | - # pg_connect へ引数を渡すべき。 | |
2765 | + # 注意: 以下のところで議論されているように、PQconnectdbオプションを含めて | |
2766 | + # pg_connectへ引数を渡すべき。 | |
2616 | 2767 | # http://www.postgresql.org/docs/8.0/interactive/libpq.html#LIBPQ-CONNECT |
2617 | 2768 | # でなければ、以下で議論されているように、環境によってパラメータが |
2618 | 2769 | # セットされ得る |
2619 | 2770 | # http://www.postgresql.org/docs/8.0/interactive/libpq-envars.html |
2620 | - # たとえば、コールの典型は次のようになるでしょう。 | |
2771 | + # 例えば、コールの典型は次のようになるでしょう。 | |
2621 | 2772 | # pg_connect("host=pgsql_server dbname=my_database") |
2622 | 2773 | if ((dbconn = pg_connect()) == "") @{ |
2623 | 2774 | printf "pg_connect failed: %s\n", ERRNO > "/dev/stderr" |
@@ -2641,7 +2792,7 @@ BEGIN @{ | ||
2641 | 2792 | exit 1 |
2642 | 2793 | @} |
2643 | 2794 | |
2644 | - # insert ステートメントを前もって作成 | |
2795 | + # insertステートメントを前もって作成 | |
2645 | 2796 | sql = ("INSERT INTO tmp ("col[1]) |
2646 | 2797 | for (i = 2; i <= ncols; i++) |
2647 | 2798 | sql = (sql", "col[i]) |
@@ -2655,20 +2806,20 @@ BEGIN @{ | ||
2655 | 2806 | @} |
2656 | 2807 | @} |
2657 | 2808 | @end example |
2658 | -@caption{PostgreSQL へ接続する @file{testxml2pgsql.awk} の最初の部分} | |
2809 | +@caption{PostgreSQLへ接続する@file{testxml2pgsql.awk}の最初の部分} | |
2659 | 2810 | @end float |
2660 | 2811 | |
2661 | -たとえば、@code{pg_connect} 関数は、ほぼ同じ名前の C 関数のだたのラッパーです。 | |
2812 | +例えば、@code{pg_connect}関数は、ほぼ同じ名前のC関数のだたのラッパーです。 | |
2662 | 2813 | この透過性は良い習慣ですが、強制的なものではありません。 |
2663 | -他の GNU Awk 拡張は、インターフェイスのデザインにおいて、不透明さの実装を選択することもできます。 | |
2814 | +他のGNU Awk拡張は、インターフェイスのデザインにおいて、不透過な実装を選択することもできます。 | |
2664 | 2815 | |
2665 | 2816 | 接続の試みが失敗した場合は、終了の前に、アプリケーションスクリプトのユーザに対して報告されます。 |
2666 | -(@code{pg_connect} で) 接続が成功すれば、このデータベースの構造についてスクリプトが PostgreSQL に指示します。 | |
2667 | -この構造はもちろん、@ref{fig:sample.xml} にある連絡用データベースのフォーマットに影響されています。 | |
2668 | -データベースの各フィールド (name, email, work, cell, company address) は PostgresQL で実行される SQL ステートメントで宣言されています。 | |
2669 | -このテーブルが作成されると、PostgreSQL は @code{OK} メッセージで応答することが期待されています。 | |
2817 | +(@code{pg_connect}で)接続が成功すれば、このデータベースの構造についてスクリプトがPostgreSQLに指示します。 | |
2818 | +この構造は、もちろん、fig:sample.xml(@pxref{fig:sample.xml})にある連絡用データベースのフォーマットに影響されています。 | |
2819 | +データベースの各フィールド(name・email・work・cell・company address)は、PostgresQLで実行されるSQLステートメントで宣言されています。 | |
2820 | +このテーブルが作成されると、PostgreSQLは、@code{OK}メッセージで応答することが期待されています。 | |
2670 | 2821 | そうでなければ、テーブルを作成する試みは中断して終了しなければなりません。 |
2671 | -最後に、前もって用意された insert ステートメントが PostgreSQL にデータベースの詳細 (fieldwidths) について指示します。 | |
2822 | +最後に、前もって用意されたinsertステートメントが、PostgreSQLにデータベースの詳細(fieldwidths)について指示します。 | |
2672 | 2823 | |
2673 | 2824 | @float Figure,fig:sample.xml |
2674 | 2825 | @pindex @file{sample.xml} |
@@ -2703,11 +2854,11 @@ BEGIN @{ | ||
2703 | 2854 | |
2704 | 2855 | </contact_database> |
2705 | 2856 | @end example |
2706 | -@caption{PostgreSQL に格納される連絡用データベース} | |
2857 | +@caption{PostgreSQLに格納される連絡用データベース} | |
2707 | 2858 | @end float |
2708 | 2859 | |
2709 | -今や、PostgreSQL はデータベースの構造について知りましたので、実際のデータを読み込む準備ができました。 | |
2710 | -@file{testxml2pgsql.awk} ファイルの中にスクリプトが格納されていて、XML データは @file{sample.xml} にあるとしますと、アプリケーションは次のように起動することができます。 | |
2860 | +これで、PostgreSQLはデータベースの構造について知りましたので、実際のデータを読み込む準備ができました。 | |
2861 | +@file{testxml2pgsql.awk}ファイルの中にスクリプトが格納されていて、XMLデータは@file{sample.xml}にあるとしますと、アプリケーションは次のように起動することができます。 | |
2711 | 2862 | |
2712 | 2863 | @example |
2713 | 2864 | gawk -f testxml2pgsql.awk < sample.xml |
@@ -2717,10 +2868,10 @@ Ellen Jones|ellen.jones@@widget.com|1-310-555-1212|<NULL>|Widget Inc.|137 Main S | ||
2717 | 2868 | Ralph Simpson|<NULL>|1-312-555-1212|1-773-555-1212|General Motors|13 Elm St., Chicago, IL |
2718 | 2869 | @end example |
2719 | 2870 | |
2720 | -このデータファイルはインタプリタにパラメータとして渡されず、インタプリタの標準入力にリダイレクトされている (@code{< sample.xml}) ことに注意してください。 | |
2721 | -こういう起動の方法だと、アプリケーションにはファイルの名前が見えないようになりますが、このスクリプトは、@ref{fig:testxml2pgsql.awk.2} の波括弧内部で AWK の@emph{パターンアクション}モデルに従いながら、入力される XML データを都合良く処理することもできます。 | |
2722 | -この XML ファイルの空であったフィールドがスクリプトの出力では @code{<NULL>} フィールドとして表われるということもわかります。 | |
2723 | -明らかに、XML ファイルを読み込んでいる間、@ref{fig:testxml2pgsql.awk.2} のアプリケーションスクリプトは、データレコードの中のデータが入っているフィールドと空のフィールドに注意を向けています。 | |
2871 | +このデータファイルはインタプリタにパラメータとして渡されず、インタプリタの標準入力にリダイレクトされている(@code{< sample.xml})ことに注意してください。 | |
2872 | +こういう起動の方法だと、アプリケーションにはファイルの名前が見えないようになりますが、このスクリプトは、fig:testxml2pgsql.awk.2(@pxref{fig:testxml2pgsql.awk.2})の波括弧内部でAWKの@emph{パターンアクション}モデルに従いながら、入力されるXMLデータを都合良く処理することができます。 | |
2873 | +このXMLファイルの空であったフィールドが、スクリプトの出力では@code{<NULL>}フィールドとして表われるということも分かります。 | |
2874 | +当然、XMLファイルを読み込んでいる間、fig:testxml2pgsql.awk.2(@pxref{fig:testxml2pgsql.awk.2})のアプリケーションスクリプトは、データレコードの中のデータが入っているフィールドと空のフィールドに注意を向けています。 | |
2724 | 2875 | |
2725 | 2876 | @cindex @code{XMLATTR} |
2726 | 2877 | @float Figure,fig:testxml2pgsql.awk.2 |
@@ -2758,20 +2909,20 @@ Ralph Simpson|<NULL>|1-312-555-1212|1-773-555-1212|General Motors|13 Elm St., Ch | ||
2758 | 2909 | @} |
2759 | 2910 | @} |
2760 | 2911 | @end example |
2761 | -@caption{PostgreSQL へデータを送る @file{testxml2pgsql.awk} の 2 番目の部分} | |
2912 | +@caption{PostgreSQLへデータを送る@file{testxml2pgsql.awk}の2番目の部分} | |
2762 | 2913 | @end float |
2763 | 2914 | |
2764 | 2915 | @cindex @code{XMLEVENT} |
2765 | -ここまで見てきたスクリプトの大半は、@ref{XMLgawk コア言語インターフェイスの要約} の中で @emph{Style A} として説明したやり方で AWK の@emph{パターンアクション}モデルに従っています。 | |
2766 | -@ref{fig:testxml2pgsql.awk.2} のスクリプトは、@emph{Style B} を使っている点で異なっています。 | |
2767 | -@emph{Style A} がアクションの前の @code{XMLSTARTELEM} パターンを求めているとしたら、@emph{Style B} は @code{XMLEVENT} の内容を見て、行なわれるべきアクションに対する @code{STARTELEM} case へ切り替えています。 | |
2768 | -(データをアトリビュートの @code{type} やタグ名から集める) アクション自体は両方のスタイルで同じままです。 | |
2769 | -@code{CHARDATA} の case は、末端の XML ノードからデータを集める考え方を説明している @ref{XML パスを使った操作}を見ていなければ、理解するのが難しいままでしょう。 | |
2770 | -@ref{fig:sample.xml} にあるデータの大部分はキャラクタデータとして末端の XML ノードに格納されているということは覚えておいてください。 | |
2771 | -@code{contact} ノードが終了すればいつでも、収集したデータを PostgreSQL へ保存する時です。 | |
2772 | -そして、変数は次の @code{contact} のデータを収集するために空にされなければなりません。 | |
2773 | -このデータの収集と保存は、XML イベントがこれ以上無くなってしまうまで繰り返されます。 | |
2774 | -その時までには、PostgreSQL には完全なデータベースが入っているでしょう。 | |
2916 | +ここまで見てきたスクリプトの大半は、別の節(@pxref{XMLgawk Core Language Interface Summary})の中で@emph{Style A}として説明したやり方でAWKの@emph{パターンアクション}モデルに従っています。 | |
2917 | +fig:testxml2pgsql.awk.2(@pxref{fig:testxml2pgsql.awk.2})のスクリプトは、@emph{Style B}を使っている点で異なっています。 | |
2918 | +@emph{Style A}が、アクションの前の@code{XMLSTARTELEM}パターンを求めているとしたら、@emph{Style B}では、@code{XMLEVENT}の内容を見て、行われるべきアクションに対する@code{STARTELEM} caseへ切り替えています。 | |
2919 | +(アトリビュートの@code{type}やタグ名からデータを集める)アクション自体は両方のスタイルで同じままです。 | |
2920 | +@code{CHARDATA}のcaseは、末端のXMLノードからデータを集める考え方を説明している節(@pxref{Working with XML paths})を見ていなければ、理解するのが難しいままでしょう。 | |
2921 | +fig:sample.xml(@pxref{fig:sample.xml})にあるデータの大部分は、キャラクタデータとして末端のXMLノードに格納されているということは覚えておいてください。 | |
2922 | +@code{contact}ノードが終了すれば、いつでも、収集したデータをPostgreSQLへ保存する時です。 | |
2923 | +そして、変数は、次の@code{contact}のデータを収集するために空にされなければなりません。 | |
2924 | +このデータの収集と保存は、XMLイベントがこれ以上無くなってしまうまで繰り返されます。 | |
2925 | +その時までには、PostgreSQLには完全なデータベースが入っていることになります。 | |
2775 | 2926 | |
2776 | 2927 | @float Figure,fig:testxml2pgsql.awk.3 |
2777 | 2928 | @example |
@@ -2804,49 +2955,51 @@ END @{ | ||
2804 | 2955 | @} |
2805 | 2956 | @} |
2806 | 2957 | @end example |
2807 | -@caption{PostgreSQL から再度データを読み出す @file{testxml2pgsql.awk} の最後の部分L} | |
2958 | +@caption{PostgreSQLから再度データを読み出す@file{testxml2pgsql.awk}の最後の部分L} | |
2808 | 2959 | @end float |
2809 | 2960 | |
2810 | -私たちのアプリケーションスクリプトの最後の 3 番目の部分は @ref{fig:testxml2pgsql.awk.3} にありますが、全てのものが正しく保存されたか確かめるのを支援してくれます。 | |
2811 | -それを行なうには、私たちのスクリプトから PostgreSQL データベースを読み出すにはどうすればよいかということも見ましょう。 | |
2812 | -スクリプトに @code{END} パターンがあるときはいつも、全てのデータを読み終わったあとで、パターンに続くアクションが実行されます。 | |
2813 | -それは、最初に実行された初期化が成功したかどうかは関係ありません。 | |
2814 | -この状況は、比較的重要でないプログラミング言語の例外処理で使う @code{try (...) catch} シーケンスと似ています。 | |
2961 | +このアプリケーションスクリプトの最後の3番目の部分はfig:testxml2pgsql.awk.3(@pxref{fig:testxml2pgsql.awk.3})にありますが、全てのものが正しく保存されたか確かめるのを支援してくれます。 | |
2962 | +それを行うため、このスクリプトによってPostgreSQLデータベースを読み出すにはどうすればよいかということも見ていきます。 | |
2963 | +スクリプトに@code{END}パターンがある時は、全てのデータを読み終わったあとで、このパターンに続くアクションが必ず実行されます。 | |
2964 | +最初に実行された初期化が成功したかどうかは関係ありません。 | |
2965 | +この状況は、比較的重要でないプログラミング言語の例外処理で使う@code{try (...) catch}シーケンスと似ています。 | |
2815 | 2966 | そういった「例外ハンドラ」では、当てになる変数の状態についてほとんどアサーションができません。 |
2816 | -なので、変数を使う前にそれが有効かどうか確認しなければなりません。 | |
2817 | -それが、@ref{fig:testxml2pgsql.awk.3} で最初にやっていることです。 | |
2818 | -データベースを読むのは、それが実際にオープンされた時にしか意味がありません。 | |
2819 | -実際にオープン@emph{された}場合に PostgreSQL へ SQL ステートメントを送る意味があります。 | |
2820 | -ステートメントを送るのが成功したあと (しかもその時だけ)、返された結果を各フィールドへ分割することができます。 | |
2967 | +ですから、変数を使う前に、変数が有効かどうか確認しなければなりません。 | |
2968 | +それが、fig:testxml2pgsql.awk.3(@pxref{fig:testxml2pgsql.awk.3})で最初にやっていることです。 | |
2969 | +データベースを読むためには、データベースが実際にオープンされないことには始まりません。 | |
2970 | +実際に@emph{オープンされた}場合には、PostgreSQLへSQLステートメントを送る意味が出て来ます。 | |
2971 | +ステートメントを送るのに成功した後、(しかも、その時だけ、)返された結果を各フィールドへ分割することができます。 | |
2821 | 2972 | 全行の全フィールドが表示されますが、空でないフィールドだけです。 |
2822 | 2973 | |
2974 | + | |
2823 | 2975 | @node Converting XML data into tree drawings |
2824 | -@section XML データからツリー図への変換 | |
2825 | -@ref{AWK と XML の概念} を読んでいる間、@ref{fig:dbfile} の DocBook ファイルを、@ref{fig:docbook_chapter} にあるツリーの図にどうやって変換しているのか不思議に思ったかもしれません。 | |
2976 | +@section XMLデータからツリー図への変換 | |
2977 | + | |
2978 | +別の節(@pxref{AWK and XML Concepts})を読んでいる間、fig:dbfile(@pxref{fig:dbfile})のDocBookファイルを、fig:docbook_chapter(@pxref{fig:docbook_chapter})にあるツリーの図にどうやって変換しているのか不思議に思ったかもしれません。 | |
2826 | 2979 | @cindex DocBook |
2827 | -この図は手作業ではなく変換ツールを使って作りました。 | |
2828 | -それは @code{gawk} スクリプトとして実装されています。 | |
2829 | -画像の取り扱いに関する問題の良い解決策を見つけるこつは、必ず適切なツールを見つけるということです。 | |
2830 | -AT&T Labs には、グラフを描くためのオープンソースソフトウェアパッケージの @uref{http://www.research.att.com/sw/tools/graphviz/, GraphViz} に関する作業をするプロジェクトグループがあります。 | |
2831 | -グラフはツリーをもっと一般化したデータ構造ですので、ツリーは、グラフの特殊な場合としてそこに含まれます。 | |
2832 | -それで、@uref{http://www.research.att.com/sw/tools/graphviz/dotguide.pdf, @code{dot} tool} で、@ref{fig:docbook_chapter} にあるようなナイスな図を生成することができます。 | |
2833 | -@code{dot} のソースコードをダウンロードしに行く前に、あなたのオペレーティングシステムの配布メディアを見てください。 | |
2834 | -@code{dot} はたいていの GNU/Linux ディストリビューションに無料で付いてきます。 | |
2835 | -@cindex Graphviz, オープンソースのグラフ描画ソフトウェア | |
2980 | +この図は、手作業ではなく変換ツールを使って作りました。 | |
2981 | +ツールは、@code{gawk}スクリプトとして実装されています。 | |
2982 | +画像の取り扱いに関する問題の良い解決策を見つけるコツは、必ず、適切なツールを見つけるということです。 | |
2983 | +AT&T Labsには、グラフを描くためのオープンソースソフトウェアパッケージの@uref{http://www.research.att.com/sw/tools/graphviz/, GraphViz}に関する作業をするプロジェクトグループがあります。 | |
2984 | +ツリーをもっと一般化したデータ構造がグラフですので、ツリーは、グラフの特殊な場合としてそこに含まれます。 | |
2985 | +それで、@uref{http://www.research.att.com/sw/tools/graphviz/dotguide.pdf, @code{dot} tool}で、fig:docbook_chapter(@pxref{fig:docbook_chapter})にあるようなナイスな図を生成することができます。 | |
2986 | +@code{dot}のソースコードをダウンロードしに行く前に、オペレーティングシステムの配布メディアを見てください。 | |
2987 | +@code{dot}は、たいていのGNU/Linuxディストリビューションに無料で付いてきます。 | |
2988 | +@cindex Graphviz, open source graph drawing software | |
2836 | 2989 | @pindex dot |
2837 | 2990 | |
2838 | -しかし、まだ疑問は残っています。 | |
2839 | -どのように XML ファイルをグラフの画像に変換するのか? | |
2991 | +しかし、疑問はまだ残っています。 | |
2992 | +どのようにXMLファイルをグラフの画像に変換するのでしょうか。 | |
2840 | 2993 | @cindex PostScript |
2841 | -@code{dot} は、グラフの@uref{http://www.research.att.com/~erg/graphviz/info/lang.html, テキストによる記述}を読み込んで、Encapsulated PostScript のファイルを生成します。 | |
2842 | -このテキストによる記述は @ref{fig:source_dot} のように見えます。 | |
2843 | -@ref{fig:source_dot} には、@ref{fig:docbook_chapter} のツリーに対する @code{dot} ソースコードが記述されています。 | |
2844 | -さて、そうすると、@ref{fig:dbfile} を @ref{fig:source_dot} に変換するのはどうするのかという疑問が改めて出てきます。 | |
2845 | -少し比べてみれば、@ref{fig:source_dot} には基本的に、各ノード毎に一つの @code{struct} 行 (ノード名すなわちマークアップブロックのタグを含む) と、ツリーの各エッジ毎に一つの @code{struct} 行 (それが指し示すノードの番号を含む) があることに気付きます。 | |
2846 | -一番最初の @code{struct1} は少し違います。 | |
2847 | -@code{struct1} は XML ファイルのルートノードが入っています。 | |
2848 | -このツリーの中で、このノードは番号を持っていませんが、太枠が付けられています。 | |
2849 | -この @value{SECTION} の残りの部分では、@ref{fig:outline_dot.awk} にある @file{outline_dot.awk} スクリプトが XML ファイルを、@code{dot} ツールで読めるグラフ表現にどのように変換するのかということを明らかにします。 | |
2994 | +@code{dot}は、グラフの@uref{http://www.research.att.com/~erg/graphviz/info/lang.html, テキスト表記}を読み込んで、Encapsulated PostScriptのファイルを生成します。 | |
2995 | +このテキスト表記は、fig:source_dot(@pxref{fig:source_dot})のようなものです。 | |
2996 | +fig:source_dot(@pxref{fig:source_dot})には、fig:docbook_chapter(@pxref{fig:docbook_chapter})のツリーに対する@code{dot}ソースコードが記述されています。 | |
2997 | +さて、そうすると、fig:dbfile(@pxref{fig:dbfile})をfig:source_dot(@pxref{fig:source_dot})に変換するのはどうするのかという疑問が改めて出てきます。 | |
2998 | +少し比べてみれば、fig:source_dot(@pxref{fig:source_dot})には、基本的に、各ノード毎に一つの@code{struct}行(ノード名すなわちマークアップブロックのタグを含む)と、ツリーの各エッジ毎に一つの@code{struct}行(それが指し示すノードの番号を含む)があることに気付きます。 | |
2999 | +一番最初の@code{struct1}は少し違います。 | |
3000 | +@code{struct1}は、XMLファイルのルートノードが入っています。 | |
3001 | +このツリーの中でこのノードは番号を持っていませんが、太枠が付けられています。 | |
3002 | +この@value{SECTION}の残りの部分では、fig:outline_dot.awk(@pxref{fig:outline_dot.awk})にある@file{outline_dot.awk}スクリプトが、XMLファイルを、@code{dot}ツールで読めるグラフ表現にどのように変換するのかということを明らかにします。 | |
2850 | 3003 | |
2851 | 3004 | @float Figure,fig:source_dot |
2852 | 3005 | @example |
@@ -2879,33 +3032,36 @@ digraph G @{ | ||
2879 | 3032 | struct10 -> struct12:f0 [headlabel="12\n\n"] |
2880 | 3033 | @} |
2881 | 3034 | @end example |
2882 | -@caption{@code{dot} ツールのためのツリー表現の例} | |
3035 | +@caption{@code{dot}ツールのためのツリー表現の例} | |
2883 | 3036 | @end float |
2884 | 3037 | |
2885 | -@ref{fig:outline_dot.awk} の細かいところを追求する前に、少しの間だけ後ろへ下がってみて、この @code{gawk} スクリプトと @ref{fig:ch2_outline.awk} のスクリプトの間の構造の類似に注意してみてください。 | |
2886 | -どちらもツリーのトラバースの間に各ノードの深さを測定しています。 | |
2887 | -@ref{fig:outline_dot.awk} の @code{BEGIN} セクションには、三つの @code{print} 行が追加されただけです。 | |
2888 | -その追加された行が @ref{fig:source_dot} の最初の 3 行を生成します。 | |
2889 | -同じことが @ref{fig:outline_dot.awk} の @code{END} セクションにある一つの @code{print} 行にも言えます。 | |
2890 | -これは @ref{fig:source_dot} の木構造のテキスト表記を終了させるだけのものです。 | |
2891 | -その結果、@ref{fig:source_dot} の @code{struct} 行は全部、@ref{fig:outline_dot.awk} の @code{XMLSTARTELEM} セクションで木構造をトラバースする間に生成されます。 | |
3038 | +fig:outline_dot.awk(@pxref{fig:outline_dot.awk})の細かいところを追求する前に、少しの間だけ元へ戻ってみて、この@code{gawk}スクリプトとfig:ch2_outline.awk(@pxref{fig:ch2_outline.awk})のスクリプトの間の構造の類似に注意してみてください。 | |
3039 | +どちらも、ツリーのトラバースの間に、各ノードの深さを測定しています。 | |
3040 | +fig:outline_dot.awk(@pxref{fig:outline_dot.awk})の@code{BEGIN}セクションには、三つの@code{print}行が追加されただけです。 | |
3041 | +その追加された行によって、fig:source_dot(@pxref{fig:source_dot})の最初の3行を生成します。 | |
3042 | +同じことがfig:outline_dot.awk(@pxref{fig:outline_dot.awk})の@code{END}セクションにある一つの@code{print}行にも言えます。 | |
3043 | +これは、fig:source_dot(@pxref{fig:source_dot})の木構造のテキスト表記を終了させるだけのものです。 | |
3044 | +その結果、fig:source_dot(@pxref{fig:source_dot})の@code{struct}行は、fig:outline_dot.awk(@pxref{fig:outline_dot.awk})の@code{XMLSTARTELEM}セクションで木構造をトラバースする間に全部生成されます。 | |
3045 | + | |
3046 | +ノードに会うたび、以下の二つのことを行わなければなりません。 | |
2892 | 3047 | |
2893 | -ノードにぶつかるたびに以下の二つのことを行なわなければなりません。 | |
2894 | 3048 | @enumerate |
2895 | -@item 図にそのノードを入れる。 | |
3049 | +@item 図に、そのノードを入れる。 | |
2896 | 3050 | @item 図に、そのノードの親からそのノード自身へ向かうエッジを入れる。 |
2897 | 3051 | @end enumerate |
2898 | 3052 | |
2899 | -ノードの識別を簡単にするために、ノードカウンタ @code{n} がインクリメントされます。 | |
2900 | -それから @code{n} は @code{struct} に追加され、各ノードを名前で識別できるようにします。 | |
2901 | -タグ名というのは一つしかないというわけではありませんので、マークアップグロックのタグ名でノードを識別することはできません。 | |
2902 | -この段階で、以下のような行を表示して図にノードを挿入する準備が整います。 | |
3053 | +ノードの識別を簡単にするために、ノードカウンタ@code{n}がインクリメントされます。 | |
3054 | +それから、@code{n}が、@code{struct}に追加され、各ノードを名前で識別できるようにします。 | |
3055 | +タグ名というのは一つしかないというわけではありません。 | |
3056 | +そのため、マークアップグロックのタグ名でノードを識別することはできません。 | |
3057 | +この段階で、以下のような行を表示してノードを図に挿入する準備が整います。 | |
3058 | + | |
2903 | 3059 | @example |
2904 | 3060 | struct3[label="<f0>title "]; |
2905 | 3061 | @end example |
2906 | 3062 | |
2907 | -ノードのラベルはマークアップブロックのタグ名を入れるのに適した場所です (@code{XMLSTARTELEM})。 | |
2908 | -もしノードにアトリビュートがあれば、区切り文字を付けてラベルに追加されます。 | |
3063 | +ノードのラベルは、マークアップブロックのタグ名を入れるのに適した場所です(@code{XMLSTARTELEM})。 | |
3064 | +もし、ノードにアトリビュートがあれば、区切り文字を付けてラベルに追加されます。 | |
2909 | 3065 | |
2910 | 3066 | @float Figure,fig:outline_dot.awk |
2911 | 3067 | @pindex @file{outline_dot.awk} |
@@ -2932,67 +3088,76 @@ XMLSTARTELEM @{ | ||
2932 | 3088 | @} |
2933 | 3089 | END @{ print "@}" @} |
2934 | 3090 | @end example |
2935 | -@caption{XML ファイルを @code{dot} ツール用のツリー表現に変換する @file{outline_dot.awk}} | |
3091 | +@caption{XMLファイルを@code{dot}ツール用のツリー表現に変換する@file{outline_dot.awk}} | |
2936 | 3092 | @end float |
2937 | 3093 | |
2938 | 3094 | 現時点でノードには名前が付いていますので、その親ノードからノード自身までエッジを描くことができます。 |
2939 | -@code{name} 配列には指定された深さにおいて最も最近トラバースされたノードの識別子が常に入っています。 | |
3095 | +@code{name}配列には、指定された深さにおいて最も最近トラバースされたノードの識別子が常に入っています。 | |
2940 | 3096 | @emph{深さ優先}で木構造をトラバースしているため、一つ浅い深さで最も最近トラバースされたノードが親ノードであるということはいつも確実です。 |
2941 | 3097 | このアサーションを考慮すれば、名前で簡単に親を特定し、親ノードからそのノードに線を表示することができます。 |
3098 | + | |
2942 | 3099 | @example |
2943 | 3100 | struct2 -> struct3:f0 [headlabel="3\n\n"] |
2944 | 3101 | @end example |
2945 | 3102 | |
2946 | -ルートノード (@code{XMLDEPTH==1}) は処理がさらに簡単な特殊なケースです。 | |
2947 | -ルートノードには親がありませんのでエッジを描く必要はありませんが、ルートノードは太枠で囲むことによって特別な認識をされています。 | |
3103 | +ルートノード(@code{XMLDEPTH==1})は、処理がさらに簡単な特殊ケースです。 | |
3104 | +ルートノードには親がありません。 | |
3105 | +そのため、エッジを描く必要はありませんが、ルートノードは、太枠で囲むことによって特別な認識をされています。 | |
2948 | 3106 | |
2949 | 3107 | さて、スクリプトをファイルへ保存して、起動してください。 |
2950 | -@code{gawk} の出力は @code{dot} へ直接パイプされます。 | |
2951 | -@code{dot} は、@file{tree.eps} というファイルへ Encapsulated PostScript 出力を保存するよう指示されます。 | |
2952 | -@code{dot} は、この出力の記述を、PostScript 形式の素晴しいグラフィカルな画像へと変換します。 | |
3108 | +@code{gawk}の出力は@code{dot}へ直接パイプされます。 | |
3109 | +@code{dot}は、@file{tree.eps}というファイルへ、Encapsulated PostScript出力を保存するよう指示されます。 | |
3110 | +@code{dot}は、この出力の記述を、PostScript形式の素晴しいグラフィカルな画像へと変換します。 | |
3111 | + | |
2953 | 3112 | @example |
2954 | 3113 | gawk -f outline_dot.awk dbfile.xml | dot -Tps2 -o tree.eps |
2955 | 3114 | @end example |
2956 | 3115 | |
3116 | + | |
2957 | 3117 | @page |
2958 | 3118 | @node Generating a DTD from a sample file |
2959 | -@section サンプルファイルからの DTD の生成 | |
3119 | +@section サンプルファイルからのDTDの生成 | |
2960 | 3120 | @cindex DTD, Document Type Definition |
2961 | -@cindex 妥当性の検証 | |
2962 | -@ref{整形式のチェック}の中で妥当性の検証についてすでにお話ししました。 | |
2963 | -そこでは、@code{gawk} は DTD に対して XML ファイルの妥当性を検証することはしないというように学びました。 | |
2964 | -じゃあ、このトピックは全く無視しなければならないということなんでしょうか? | |
2965 | -いいえ、DTD の利用は非常に広範囲なので、XML ファイルで作業している全員が少なくとも DTD を読む能力を持つべきでしょう。 | |
2966 | -DTD をまじめに取り上げるべき良い理由が少くとも以下の二つあります。 | |
3121 | +@cindex validation | |
3122 | + | |
3123 | +別の節(@pxref{Checking for well-formedness})の中で、妥当性の検証については既にお話ししました。 | |
3124 | +そこでは、@code{gawk}は、DTDに対して、XMLファイルの妥当性を検証することはしないというように学びました。 | |
3125 | +じゃあ、このトピックは全く無視しなければならないということなんでしょうか。 | |
3126 | +否、DTDの利用は非常に広範囲に渡ります。 | |
3127 | +XMLファイルで作業している人全てが、少なくとも、DTDを読む能力を持つべきでしょう。 | |
3128 | +DTDを真面目に取り上げるべき良い理由が少くとも以下の二つあります。 | |
3129 | + | |
2967 | 3130 | @enumerate |
2968 | 3131 | @item |
2969 | -オリジナルの DTD が与えられていた (そしてその DTD が上手く書けていた) 場合には、妥当な XML の見本ファイルをブラウジングすることからよりも、DTD を見ることからのほうがより多くのことを学ぶことができます。 | |
3132 | +オリジナルのDTDが与えられていた(そして、そのDTDが上手く書けていた)場合、妥当なXMLの見本ファイルをブラウジングするよりも、DTDを見るほうが、より多くのことを学ぶことができます。 | |
3133 | + | |
2970 | 3134 | @item |
2971 | -現実には、いつか DTD を作らなければならなくなる人は私たちの中にはほとんどいません。 | |
2972 | -しかし、(@uref{http://lists.w3.org/Archives/Public/www-archive/2004Mar/0169.html, この投稿}に添付されているもののような) 巨大な XML ファイルと対峙して、DTD を@emph{持ってない}時、その XML ファイルの意味を理解するのは困難となるでしょう。 | |
3135 | +現実には、今後、DTDを作らなければならなくなる人は私たちの中にはほとんどいません。 | |
3136 | +しかし、(@uref{http://lists.w3.org/Archives/Public/www-archive/2004Mar/0169.html, この投稿}に添付されているもののような)巨大なXMLファイルと対峙していて、DTDを@emph{持ってない}場合、そのXMLファイルの意味を理解するのは難しいものとなるでしょう。 | |
2973 | 3137 | @end enumerate |
2974 | 3138 | |
2975 | -そういう場合、@uref{http://saxon.sourceforge.net/dtdgen.html, DTDGenerator -- A tool to generate XML DTDs} のようなツールがあったらよいのにと思うでしょう。 | |
2976 | -このツールは、整形式の XML ファイルを取り、そこから DTD を生成します (ですので、もちろんその DTD に対して XML ファイルは妥当性を持ちます)。 | |
2977 | -例として @ref{fig:dbfile} を見てみましょう。 | |
2978 | -これは DocBook | |
3139 | +そういう場合、@uref{http://saxon.sourceforge.net/dtdgen.html, DTDGenerator -- A tool to generate XML DTDs}のようなツールがあったら良いのにと思うでしょう。 | |
3140 | +このツールは、整形式のXMLファイルを受け取り、そこからDTDを生成します(ですから、もちろん、そのDTDに対してXMLファイルは妥当性を持ちます)。 | |
3141 | +例として、fig:dbfile(@pxref{fig:dbfile})を見てみましょう。 | |
2979 | 3142 | @cindex DocBook |
2980 | -ファイルで、そのヘッダで指定されている DTD はよく作られています。 | |
2981 | -この DocBook ファイルがもっと長くて、このファイルを読んで処理することを要するアプリケーションがあったと想像してみてください。 | |
2982 | -あなたは、完全な DocBook DTD を取りにいって、その DocBook DTD の細かい部分を全て処理するようにアプリケーションを仕立てますか? | |
2983 | -恐らくそうはしないでしょう。 | |
2984 | -手元にあるファイルを記述するのには十分良い DTD のサブセットで始めるのはより現実的です。 | |
2985 | -DTD ジェネレータはスタート地点としてはよく役立つ DTD を生成します。 | |
2986 | -たとえば、@ref{fig:dbfile} の DocBook ファイルは @ref{fig:dbfile.dtd} の DTD で記述することができます。 | |
2987 | -野生で見つけるであろう DTD の大部分とは違い、この DTD は 構造を強調するためにインデンテーションが使われています。 | |
2988 | -アトリビュートは常にそのエレメント名の直後にリストされ、あるエレメントの中に表われるサブエレメントは、親エレメントの直下にインデントして続きます。 | |
2989 | - | |
2990 | -少し時間を使って、@ref{fig:dbfile.dtd} にリストされているエレメントとアトリビュートの関係と、@ref{fig:dbfile} の例示ファイルを理解してみると良いでしょう。 | |
2991 | -たとえば、 @ref{fig:dbfile.dtd} の最初の行は、@code{book} が一連のエレメントから構成され、その一連のエレメントとは @code{chapter} か @code{bookinfo} のどちらかであるということ示しています。 | |
2992 | -@ref{fig:docbook_chapter} の図を見てこれを検証することができます。 | |
2993 | -次の 2 行は、@code{book} が必須のアトリビュートを二つ、@code{lang} と @code{id} を持っているということを示しています。 | |
2994 | -@ref{fig:dbfile.dtd} の残りの部分には同様にその他のエレメントとアトリビュート全てについてインデントしながら記述されています。 | |
2995 | -他のエレメントをその中に持たないエレメントは中に @code{#PCDATA} があります。 | |
3143 | +これはDocBookファイルです。 | |
3144 | +ヘッダで指定されているDTDはよく作られています。 | |
3145 | +このDocBookファイルがもっと長くて、このファイルを読んで処理することを要するアプリケーションがあると想像してみてください。 | |
3146 | +完全なDocBook DTDを入手しにいって、そのDocBook DTDの細かい部分を全て処理するようにアプリケーションを作り上げるでしょうか。 | |
3147 | +恐らく、そうはしないでしょう。 | |
3148 | +手元のファイルを説明するのに足るDTDのサブセットがあれば、そのDTDを使って作業を始めるのが、より現実的です。 | |
3149 | +DTDジェネレータは、スタート地点としては十分使えるDTDを生成します。 | |
3150 | +例えば、fig:dbfile(@pxref{fig:dbfile})のDocBookファイルは、fig:dbfile.dtd(@pxref{fig:dbfile.dtd})のDTDで記述することができます。 | |
3151 | +野良で見つかるDTDの大部分とは違い、このDTDは、構造を強調するために字下げが行われています。 | |
3152 | +アトリビュートはそのエレメント名の直後に常にリストされ、あるエレメントの中に表われるサブエレメントは、親エレメントの直下に字下げして続きます。 | |
3153 | + | |
3154 | +少し時間を使って、fig:dbfile.dtd(@pxref{fig:dbfile.dtd})にリストされているエレメントとアトリビュートの関係と、fig:dbfile(@pxref{fig:dbfile})の例示ファイルを理解してみると良いでしょう。 | |
3155 | +例えば、fig:dbfile.dtd(@pxref{fig:dbfile.dtd})の最初の行は、一連のエレメントから@code{book}が構成され、その一連のエレメントとは、@code{chapter}か@code{bookinfo}のどちらかであるということ示しています。 | |
3156 | +fig:docbook_chapter(@pxref{fig:docbook_chapter})の図を見れば、これを検証することができます。 | |
3157 | +次の2行は、@code{book}が、必須のアトリビュートを二つ持っていることを示しています。 | |
3158 | +@code{lang}と@code{id}です。 | |
3159 | +fig:dbfile.dtd(@pxref{fig:dbfile.dtd})の残りの部分には、その他のエレメントとアトリビュート全てについて、字下げしながら同様に記述されています。 | |
3160 | +他のエレメントを中に持たないエレメントは、@code{#PCDATA}が中にあります。 | |
2996 | 3161 | |
2997 | 3162 | @float Figure,fig:dbfile.dtd |
2998 | 3163 | @example |
@@ -3007,24 +3172,27 @@ DTD ジェネレータはスタート地点としてはよく役立つ DTD を | ||
3007 | 3172 | <!ELEMENT title ( #PCDATA ) > |
3008 | 3173 | <!ELEMENT bookinfo ( title )* > |
3009 | 3174 | @end example |
3010 | -@caption{ネスト構造を強調するようにアレンジされた DTD の例} | |
3175 | +@caption{ネスト構造を強調するようにアレンジされたDTDの例} | |
3011 | 3176 | @end float |
3012 | 3177 | |
3013 | -この @value{SECTION} の残りの部分では、@ref{fig:dbfile.dtd} の DTD を生成するスクリプトの説明をします。 | |
3014 | -このスクリプトの最初の部分は @ref{fig:outline_dot.awk} にかなり似ているように見えます。 | |
3015 | -どちらのスクリプトも、XML ファイルのノードツリーをトラバースし、非常によく似たやり方で情報を集めていきます (たとえば @code{name} 配列と @code{XMLDEPTH} 変数)。 | |
3016 | -@ref{fig:dtd_generator.awk} には配列変数が三つ追加され、後で DTD を生成するのに必要な情報を保持する役目を負っています。 | |
3017 | -以下が追加された配列変数です。 | |
3178 | +この@value{SECTION}の残りの部分では、fig:dbfile.dtd(@pxref{fig:dbfile.dtd})のDTDを生成するスクリプトの説明をします。 | |
3179 | +このスクリプトの最初の部分は、fig:outline_dot.awk(@pxref{fig:outline_dot.awk})にかなり似ているように見えます。 | |
3180 | +どちらのスクリプトも、XMLファイルのノードツリーをトラバースし、非常によく似たやり方で情報を集めていきます(例えば、@code{name}配列と@code{XMLDEPTH}変数)。 | |
3181 | +fig:dtd_generator.awk(@pxref{fig:dtd_generator.awk})には配列変数が三つ追加され、DTDを後で生成するのに必要な情報を保持する役目を負っています。 | |
3182 | +以下は、追加された配列変数です。 | |
3183 | + | |
3018 | 3184 | @enumerate |
3019 | 3185 | @item |
3020 | -@code{elem[e]} は全てのエレメントの名前を覚えて、各エレメントが現われた回数を数えます。 | |
3021 | -これは、名前を確認して、あるエレメントがあるアトリビュートを必ず伴って現われるかどうかを決定するのに必要です。 | |
3186 | +@code{elem[e]}は、全てのエレメントの名前を記憶し、各エレメントが現われた回数を数えます。 | |
3187 | +これは、名前を確認して、あるエレメントが、あるアトリビュートを必ず伴って現われるかどうかを決定するのに必要です。 | |
3188 | + | |
3022 | 3189 | @item |
3023 | -@code{child[ep,ec]} は、どのエレメントが他のエレメントの子であるかを覚えます。 | |
3024 | -これは、@ref{fig:dbfile.dtd} の @code{<!ELEMENT @dots{}>} という行の細部を生成するのに必要です。 | |
3190 | +@code{child[ep,ec]}は、どのエレメントが他のエレメントの子であるかを記憶します。 | |
3191 | +これは、fig:dbfile.dtd(@pxref{fig:dbfile.dtd})の@code{<!ELEMENT @dots{}>}という行の細部を生成するのに必要です。 | |
3192 | + | |
3025 | 3193 | @item |
3026 | -@code{attr[e,a]} はどのエレメントにどのアトリビュートがあるかを記憶します。 | |
3027 | -これは、@ref{fig:dbfile.dtd} の @code{<!ATTLIST @dots{}>} の細部を生成するのに必要です。 | |
3194 | +@code{attr[e,a]}は、どのエレメントに、どのアトリビュートがあるかを記憶します。 | |
3195 | +これは、fig:dbfile.dtd(@pxref{fig:dbfile.dtd})の@code{<!ATTLIST @dots{}>}の細部を生成するのに必要です。 | |
3028 | 3196 | @end enumerate |
3029 | 3197 | |
3030 | 3198 | @float Figure,fig:dtd_generator.awk |
@@ -3049,17 +3217,17 @@ XMLSTARTELEM @{ | ||
3049 | 3217 | |
3050 | 3218 | END @{ print_elem(1, name[1]) @} # name[1] is the root |
3051 | 3219 | @end example |
3052 | -@caption{@file{dtd_generator.awk} の最初の部分 --- 情報収集 } | |
3220 | +@caption{@file{dtd_generator.awk}の最初の部分 --- 情報収集} | |
3053 | 3221 | @end float |
3054 | 3222 | |
3055 | -ツリーのトラバースを完了して、エレメントとアトリビュートの名前とそのネスティングの構造を全て把握すれば、あとは @code{END} パターンのアクションが関数を一つ起動するだけです。 | |
3056 | -この関数は、エレメントとアトリビュートの関係の決定を開始して、正しい DTD の形式でそれを表示します。 | |
3057 | -@code{name[1]} にはツリーのルートノードの名前が入っていることに注意してください。 | |
3058 | -これは、DTD の記述が、@ref{fig:dbfile.dtd} の最初の行に見えるように、XML ファイルのトップレベルのエレメントから始まるということを示しています。 | |
3223 | +ツリーのトラバースを完了して、エレメントとアトリビュートの名前とそのネスティングの構造を全て把握すれば、後は、@code{END}パターンのアクションが関数を一つ起動するだけです。 | |
3224 | +この関数は、エレメントとアトリビュートの関係の解決を開始して、正しいDTDの形式でそれを表示します。 | |
3225 | +@code{name[1]}には、ツリーのルートノードの名前が入っていることに注意してください。 | |
3226 | +これは、DTDの記述が、(fig:dbfile.dtd(@pxref{fig:dbfile.dtd})の最初の行にあるような)XMLファイルのトップレベルのエレメントから始まるという意味です。 | |
3059 | 3227 | |
3060 | 3228 | @float Figure,fig:print_elem |
3061 | 3229 | @smallexample |
3062 | -# エレメントを一つ (サブエレメントを含めて)、一度だけ表示する。 | |
3230 | +# エレメントを一つ(サブエレメントを含めて)、一度だけ表示する。 | |
3063 | 3231 | function print_elem(depth, element, c, atn, chl, n, i, myChildren) @{ |
3064 | 3232 | if (already_printed[element]++) |
3065 | 3233 | return |
@@ -3100,29 +3268,31 @@ function print_elem(depth, element, c, atn, chl, n, i, myChildren) @{ | ||
3100 | 3268 | @} |
3101 | 3269 | @} |
3102 | 3270 | @end smallexample |
3103 | -@caption{@file{dtd_generator.awk} の 2 番目の部分 --- DTD の表示 } | |
3271 | +@caption{@file{dtd_generator.awk}の2番目の部分 --- DTDの表示} | |
3104 | 3272 | @end float |
3105 | 3273 | |
3106 | -この関数が最初に行なう事は、エレメントが既に表示されたものかどうかを判断することです (もし既に表示されているなら二度目は表示されません)。 | |
3107 | -正しいインデントは、何個かの空白 (インデントのレベル毎に二つの空白) で表示される行を始めることによって行ないます。 | |
3108 | -次に現在のエレメントの子ノードを全部収集して @code{myChildren} という文字列に入れます。 | |
3109 | -AWK の @code{split} 関数は、連想配列のインデックスを構成しているエレメントの組 (親と子) を分割するのに使われます。 | |
3110 | -子ノードを全て見つければ、このエレメントに対する DTD の @code{<!ELEMENT @dots{} >} という行を表示する準備が整います。 | |
3111 | -もしエレメントが子ノードを持たないのであれば、それはツリーの葉なので、DTD の中にそのように記述されます。 | |
3112 | -そうでなく、子ノードを持つのであれば、見つけた子ノードが全てエレメントに属しているように表示されます。 | |
3274 | +この関数が最初に行う事は、エレメントが既に表示されたものかどうかを判断することです(既に表示されているなら、二度目は表示されません)。 | |
3275 | +何個かの空白(インデントレベル毎に二つの空白)を使って表示される行を開始することによって、正しいインデントが行われます。 | |
3276 | +次に、現在のエレメントの子ノードを全部収集して、@code{myChildren}という文字列に入れます。 | |
3277 | +AWKの@code{split}関数は、連想配列のインデックスを構成しているエレメントの組(親と子)を分割するのに使われます。 | |
3278 | +子ノードを全て見つければ、このエレメントに対するDTDの@code{<!ELEMENT @dots{} >}という行を表示する準備が整います。 | |
3279 | +もし、エレメントが子ノードを持たないのであれば、それはツリーの葉なので、DTDの中にそのように記述されます。 | |
3280 | +そうでなく、子ノードを持つのであれば、見つけた子ノードがエレメントに全て属しているように表示されます。 | |
3113 | 3281 | |
3114 | -正しく @code{<!ATTLIST @dots{} >} の行を見つけ出すのには、似たようなやり方でコーディングされています。 | |
3115 | -各アトリビュートは、そのエレメントの中で常に現われるかということがチェックされ、もしそうならばそれが表示されます。 | |
3116 | -そのエレメントに対して常に現われるアトリビュートと、常にではなく時折現れるアトリビュートとの区別は、このジェネレータにおいて最初の段階の工夫です。 | |
3117 | -しかし、生成された DTD を少し解析すれば、この DTD がかなり大雑把で気前の良い DTD であることに気付くでしょう。 | |
3282 | +正しく@code{<!ATTLIST @dots{} >}の行を見つけ出すのは、似たような方法でコーディングされています。 | |
3283 | +各アトリビュートは、そのエレメントの中で常に現われるかということがチェックされ、もし、そうならば、それが表示されます。 | |
3284 | +そのエレメントに対して常に現われるアトリビュートと、常にではなく、時折現れるアトリビュートとの区別は、このジェネレータにおいて最初の段階の工夫です。 | |
3285 | +しかし、生成されたDTDを少し解析すれば、このDTDが、かなり大雑把で気前の良いDTDであることに気付くでしょう。 | |
3118 | 3286 | |
3119 | 3287 | @itemize |
3120 | 3288 | @item |
3121 | -子エレメントがどういう順序で現われても良いというようにエレメントが宣言されている。 | |
3289 | +子エレメントがどういう順序で現われても良いようにエレメントが宣言されている。 | |
3290 | + | |
3122 | 3291 | @item |
3123 | -ツリーの葉であるエレメントがいつも @code{#PCDATA} であるように宣言されている。 | |
3292 | +ツリーの葉であるエレメントが@code{#PCDATA}であるように常に宣言されている。 | |
3293 | + | |
3124 | 3294 | @item |
3125 | -アトリビュートが常に @code{CDATA} であるように宣言されている。 | |
3295 | +アトリビュートが@code{CDATA}であるように常に宣言されている。 | |
3126 | 3296 | @end itemize |
3127 | 3297 | |
3128 | 3298 | @cindex Schema |
@@ -3130,52 +3300,53 @@ Using the XSD Inference Utility | ||
3130 | 3300 | http://msdn2.microsoft.com/en-us/library/aa302302.aspx |
3131 | 3301 | |
3132 | 3302 | ニーズに合わせてこのジェネレータを改良するのは自由にしてください。 |
3133 | -ひょっとしたら、Microsoft の @emph{XSD Inference Utility} の出力行の通りにスキーマファイルを生成することすらできます。 | |
3134 | -@uref{http://msdn2.microsoft.com/en-us/library/aa302302.aspx, Using the XSD Inference Utility} を見てください。 | |
3135 | -@code{print_elem()} 関数の残りの部分は、さらなる拡張に対して十分であるはずです。 | |
3136 | -(最初の段階で集められた) エレメントの子ノードを取って、子ノードをそれぞれ表示するために、この関数を再帰的に使います。 | |
3137 | -@cindex 再帰 | |
3303 | +ひょっとしたら、Microsoftの@emph{XSD Inference Utility}の出力行の通りにスキーマファイルを生成することすらできます。 | |
3304 | +@uref{http://msdn2.microsoft.com/en-us/library/aa302302.aspx, Using the XSD Inference Utility}を見てください。 | |
3305 | +@code{print_elem()}関数の残りの部分は、さらなる拡張に対して十分であるはずです。 | |
3306 | +@cindex recursion | |
3307 | +この関数は、(最初の段階で集められた)エレメントの子ノードを取って、子ノードをそれぞれ表示するために、再帰的に呼び出されます。 | |
3308 | + | |
3138 | 3309 | |
3139 | 3310 | @node Generating a recursive descent parser from a sample file |
3140 | 3311 | @section サンプルファイルからの再帰下降パーサの生成 |
3141 | 3312 | @cindex parser, recursive descent |
3142 | 3313 | @cindex recursion |
3143 | 3314 | |
3144 | -XML ファイルをタグ毎に読み取って、タグの前後関係や、その中に埋まっているキャラクタデータを非常に注意深く見ていくプログラムを書かなければならないことは、滅多に無いわけではなく時々あります。 | |
3145 | -そういったプログラムはタグの並び、インデント、前後関係を検出して、アプリケーションに応じたやり方で、これを全て評価します。 | |
3315 | +XMLファイルをタグ毎に読み取って、タグの前後関係や、その中に埋まっているキャラクタデータを非常に注意深く見ていくプログラムを書かなければならないことは、滅多に無いわけではなく、時々あります。 | |
3316 | +そういったプログラムは、タグの並び・インデント・前後関係を検出して、アプリケーションに応じたやり方で、これを全て評価します。 | |
3146 | 3317 | コンパイラやインタプリタがやっていることとほとんど同じです。 |
3147 | 3318 | こういったプログラムのことはパーサと呼びます。 |
3148 | -パーサの作成というのは簡単なことではなく、いつかパーサを書かなければならなくなった場合、見本のファイルからパーサの最初の段階を自動的に生成する方法がわかったならばあなたはありがたいと思うでしょう。 | |
3149 | -極めて当然ですが、あなたのためにパーサを生成してくれそうな商用ツールがいくつかあります。 | |
3150 | -たとえば、XMLBooster @uref{http://www.xmlbooster.com, XMLBooster} プロダクトは (C、C++、C#、COBOL、Delphi、Java、Ada のうちのいずれかの言語で書かれたあらゆる言語の) パーサを生成するだけでなく、構造化された便利なドキュメンテーションと、あなた独自の XML ファイルを編集する GUI も生成します。 | |
3151 | -XMLBooster は既存の DTD ファイルやスキーマファイルを用いてそういったものを全て作り出します。 | |
3152 | -XMLBooster とは異なり、私たちの場合、指定された XML データに DTD ファイルやスキーマファイルが存在しているとは仮定しません。 | |
3153 | -私たちは、特定の XML データを入力し、そのようなデータのパーサを作り出すパーサジェネレータが欲しいと思っています。 | |
3319 | +パーサの作成というのは簡単なことではなく、いつかパーサを書かなければならなくなった場合、見本のファイルからパーサの最初の段階を自動的に生成する方法が分かったならば、ありがたいと思うでしょう。 | |
3320 | +極めて当然ですが、ユーザのためにパーサを生成してくれそうな商用ツールがいくつかあります。 | |
3321 | +例えば、XMLBooster @uref{http://www.xmlbooster.com, XMLBooster}プロダクトは(C、C++、C#、COBOL、Delphi、Java、Adaのいずれかの言語で記述されたあらゆる言語の)パーサを生成するだけではありません。 | |
3322 | +構造化された便利なドキュメントと、ユーザ独自のXMLファイルを編集するGUIも生成します。 | |
3323 | +XMLBoosterは、既存のDTDファイルやスキーマファイルを用いて、そういったものを全て作り出します。 | |
3324 | +XMLBoosterとは異なり、ここでは、指定されたXMLデータにDTDファイルやスキーマファイルが存在しているとは仮定しません。 | |
3325 | +特定のXMLデータを入力し、そのようなデータのパーサを作り出すパーサジェネレータが欲しいのです。 | |
3154 | 3326 | @pindex XMLBooster |
3155 | 3327 | |
3156 | -前の @value{SECTION} の @ref{サンプルファイルからの DTD の生成} では、 | |
3157 | -XML ファイルがどのように解析されて、さまざまな種類のタグの間の文法的な関係を記述した別のファイルをどのように作るかということを既に見ました。 | |
3158 | -後で見るように、パーサというのはそれと非常によく似た方法で作ることができます。 | |
3159 | -それでは、この @value{SECTION} では、前の @value{SECTION} のプログラムを変更してみましょう。 | |
3160 | -その際、@code{print_elem()} 関数以外は何も変更せずにそのままにしておきます。 | |
3328 | +前の@value{SECTION}(@pxref{Generating a DTD from a sample file})では、XMLファイルがどのように解析されて、さまざまな種類のタグの間の文法的な関係を記述した別のファイルをどのように作るかということを既に見ました。 | |
3329 | +後で見るように、パーサというのは、それと非常によく似た方法で作ることができます。 | |
3330 | +それでは、この@value{SECTION}では、前の@value{SECTION}のプログラムを変更してみましょう。 | |
3331 | +その際、@code{print_elem()}関数以外は何も変更せずにそのままにしておきます。 | |
3161 | 3332 | |
3162 | -またしても、例として @ref{fig:dbfile} (DocBook ファイル) を使いましょう。 | |
3163 | -この種の DocBook ファイルのパーサは、@ref{fig:parser_dbfile} にあるプログラムのように始めることができるでしょう。 | |
3333 | +またしても、例としてfig:dbfile(@pxref{fig:dbfile})(DocBookファイル)を使いましょう。 | |
3334 | +この種のDocBookファイルのパーサは、fig:parser_dbfile(@pxref{fig:parser_dbfile})にあるプログラムのように始めることができます。 | |
3164 | 3335 | @cindex DocBook |
3165 | -このパーサの @code{BEGIN} 部分では、一番最初のタグが @code{NextElement()} 関数 (後述) によって読み込まれます。 | |
3166 | -この一番最初のタグが @code{book} タグであれば、このタグにちなんで名付けられた関数へと実行が移されます。 | |
3167 | -そうでなければ、パーサは XML ファイルのルートタグが期待されたものではないとみなし、エラーメッセージと共に終了します。 | |
3168 | -@code{parse_book} 関数にはループがあって、@code{book} の閉じタグが読み込まれるまでタグを一つ一つ読んでいきます。 | |
3169 | -その合間には、下位の各タグを存在が許されているタグの組と照合し、そのタグを処理する別の関数を起動します。 | |
3336 | +このパーサの@code{BEGIN}部分では、一番最初のタグが@code{NextElement()}関数(後述)によって読み込まれます。 | |
3337 | +この一番最初のタグが@code{book}タグであれば、このタグにちなんで名付けられた関数へと実行が移されます。 | |
3338 | +そうでなければ、パーサは、XMLファイルのルートタグが期待されたものではないとみなし、エラーメッセージと共に終了します。 | |
3339 | +@code{parse_book}関数にはループがあって、@code{book}の閉じタグが読み込まれるまでタグを一つ一つ読んでいきます。 | |
3340 | +その合間には、下位の各タグを、存在が許されているタグの組と照合し、そのタグを処理する別の関数を起動します。 | |
3170 | 3341 | 思わぬタグの名前が現われると警告メッセージが出されますが、パーサは終了しません。 |
3171 | 3342 | |
3172 | 3343 | このパーサにおける最も重要な原則は、@b{タグの名前毎に、その種のタグを解析する関数が一つ存在する}ということです。 |
3173 | -XML ファイルを解析している間、こういった関数が互いに起動されます (XML のマークアップブロックが再帰的に構成されていれば、恐らく再帰的に関数が呼び出されます)。 | |
3174 | -これらの関数はそれぞれ、その中の冒頭にコメントが付いていて、この名前を持つタグに付けられるアトリビュートが宣言されています。 | |
3175 | -さて、@code{parse_book} 関数を見てください。 | |
3344 | +XMLファイルを解析している間、こういった関数が互いに起動されます(XMLのマークアップブロックが再帰的に構成されていれば、恐らく、再帰的に関数が呼び出されます)。 | |
3345 | +これらの関数は、その中の冒頭にコメントがそれぞれ付いていて、この名前を持つタグに付けられるアトリビュートが宣言されています。 | |
3346 | +さて、@code{parse_book}関数を見てください。 | |
3176 | 3347 | そして、このような関数を生成しなければならなかったらと想像してみてください。 |
3177 | -DTD ジェネレータを書いた際、各種のタグに関する情報をどのように保存したか思い出してください。 | |
3178 | -タグに関して必要な情報は既に全て利用可能で、ここでは違う種類の出力を作らなければならないだけであることがわかるでしょう。 | |
3348 | +DTDジェネレータを書いた際、各種のタグに関する情報をどのように保存したか思い出してください。 | |
3349 | +タグに関して必要な情報は既に全て利用可能で、ここでは違う種類の出力を作らなければならないだけであることが分かるでしょう。 | |
3179 | 3350 | |
3180 | 3351 | @float Figure,fig:parser_dbfile |
3181 | 3352 | @example |
@@ -3203,41 +3374,43 @@ function parse_book() @{ | ||
3203 | 3374 | @} |
3204 | 3375 | @} |
3205 | 3376 | @end example |
3206 | -@caption{大変シンプルな DocBook ファイルのための生成されたパーサの冒頭} | |
3377 | +@caption{大変シンプルなDocBookファイルのための生成されたパーサの冒頭} | |
3207 | 3378 | @end float |
3208 | 3379 | |
3209 | -さて、沿うべき原則 (下向き再帰) は明確ですので、細部に取り掛かることができます。 | |
3210 | -パーサジェネレータを理解する上で最も難しい問題は、関係するテキストやデータの種類をかき混ぜてしまうことの危険性であることがわかります。 | |
3211 | -何が起きているのかを理解しようとしてぐるぐる巡ってしまうときはいつでも、考えているデータの種類のことを思い出してください。 | |
3380 | +さて、沿うべき原則(下向き再帰)は明確ですので、細部に取り掛かることができます。 | |
3381 | +パーサジェネレータを理解する上で最も難しい問題は、関係するテキストやデータの種類をかき混ぜてしまうことの危険性であることが分かります。 | |
3382 | +何が起きているのかを理解しようとして、ぐるぐる巡ってしまう時は、いつでも、考えているデータの種類のことを思い出してください。 | |
3383 | + | |
3212 | 3384 | @itemize |
3213 | -@item @b{XML データ}、これは@emph{生成された}パーサでパースされるべきもの。 | |
3214 | -@item @b{AWK のデータ構造}、これはタグの関係を保存するためもの。 | |
3215 | -@item @b{パーサ}@emph{ジェネレータ}、今実際に書いているもの。 | |
3385 | +@item @b{XMLデータ}、これは、@emph{生成された}パーサでパースされるべきもの。 | |
3386 | +@item @b{AWKのデータ構造}、これは、タグの関係を保存するためもの。 | |
3387 | +@item @b{パーサ}@emph{ジェネレータ}、実際に今書いているもの。 | |
3216 | 3388 | @item @b{パーサ}、ジェネレータで@emph{生成される}もの。 |
3217 | 3389 | @end itemize |
3218 | 3390 | |
3219 | 3391 | 従来の言語パーサは入力テキストをトークン単位で読みます。 |
3220 | 3392 | この仕事は、低レベルの文字リーダと高レベルの文法チェッカに振り分けられます。 |
3221 | -最も低レベルのところでは@emph{スキャナ}がトークンを取り出します。 | |
3222 | -スキャナはこのトークンをパーサ自体にリターンします。 | |
3223 | -@emph{生成された} XML データのパーサでは、私たちが使う XML リーダの中にスキャナが隠れていますので、独自のスキャナは必要ありません。 | |
3224 | -生成しなければならないもののうちまだ残っているものは、呼び出す毎に次のトークンを読む関数です。 | |
3225 | -@ref{fig:parser_generated_next_element} にあるトークン単位のリーダは、以前に見たことのある@emph{プルパーサ}スタイルで実装されています。 | |
3226 | -このリーダを実装している @code{NextElement()} 関数は、生成された各パーサで同じもののままであることに注意してください。 | |
3227 | -@code{getline} で XML ファイルを読んでいる間、このトークンリーダは、トークンストリームの以下のイベントを待ち受けています。 | |
3393 | +最も低レベルのところでは、@emph{スキャナ}がトークンを取り出します。 | |
3394 | +スキャナは、このトークンをパーサ自体にリターンします。 | |
3395 | +@emph{生成された}XMLデータのパーサでは、使用するXMLリーダの中にスキャナが隠れていますので、独自のスキャナは必要ありません。 | |
3396 | +生成しなければならないものの中でまだ残っているものは、呼び出すたびに次のトークンを読む関数です。 | |
3397 | +fig:parser_generated_next_element(@pxref{fig:parser_generated_next_element})にあるトークン単位のリーダは、以前に見たことのある@emph{プルパーサ}スタイルで実装されています。 | |
3398 | +このリーダを実装している@code{NextElement()}関数は、生成された各パーサで同じもののままであることに注意してください。 | |
3399 | +@code{getline}でXMLファイルを読んでいる間、このトークンリーダは、トークンストリームの以下のイベントを待ち受けています。 | |
3400 | + | |
3228 | 3401 | @itemize |
3229 | -@item @code{XMLSTARTELEM} はリターンする新しいタグ。 | |
3230 | -@item @code{XMLENDELEM} はリターンするマークアップブロックの終わり。 | |
3231 | -@item @code{XMLCHARDATA} はマークアップブロックに埋め込まれたテキスト。 | |
3232 | -@item @code{XMLERROR} はエラーを表示するもので、終了処理が発生します。 | |
3402 | +@item @code{XMLSTARTELEM}は、リターンされる新しいタグです。 | |
3403 | +@item @code{XMLENDELEM}は、リターンされるマークアップブロックの終わりです。 | |
3404 | +@item @code{XMLCHARDATA}は、マークアップブロックに埋め込まれたテキストです。 | |
3405 | +@item @code{XMLERROR}は、エラーを表示するもので、終了処理を発生します。 | |
3233 | 3406 | @end itemize |
3234 | 3407 | |
3235 | -マークアップブロックに埋め込まれたテキストは関数の戻り値としては返されませんが、大域変数の @code{data} に格納されます。 | |
3236 | -この関数はタグの名前を返すためのものです。 | |
3408 | +マークアップブロックに埋め込まれたテキストは、関数の戻り値としては返されませんが、大域変数の@code{data}に格納されます。 | |
3409 | +この関数は、タグの名前を返すためのものです。 | |
3237 | 3410 | マークアップブロックの開始でも終了でも問題ありません。 |
3238 | -呼び出し側がマークアップブロックの開始あるいは終了を区別したいような場合は、@code{XMLSTARTELEM} あるいは @code{XMLENDELEM} にセットされているかどうかを見ればそうすることが可能です。 | |
3239 | -XML ファイルの終わりに到達したときだけ空文字列をリターンします。 | |
3240 | -トークンストリームが終わりに達したときにそれを検出するかどうかは呼び出し側にまかされています。 | |
3411 | +マークアップブロックの開始、あるいは、終了を、呼び出し側で区別したいような場合は、@code{XMLSTARTELEM}、あるいは、@code{XMLENDELEM}がセットされているかどうかを見れば可能です。 | |
3412 | +XMLファイルの終わりに到達した時だけ空文字列をリターンします。 | |
3413 | +トークンストリームが終わりに達した時にそれを検出するかどうかは呼び出し側にまかされています。 | |
3241 | 3414 | |
3242 | 3415 | @float Figure,fig:parser_generated_next_element |
3243 | 3416 | @example |
@@ -3255,18 +3428,19 @@ function NextElement() @{ | ||
3255 | 3428 | @caption{プルスタイルトークンリーダ、生成されたパーサすべてで同一のもの} |
3256 | 3429 | @end float |
3257 | 3430 | |
3258 | -ここまでこの @value{SECTION} で見てきたコードは全て@emph{生成される}コードでした。 | |
3259 | -あなた自身のプログラムにこのコードをコピーする意味はありません。 | |
3260 | -今からが@emph{ジェネレータ}自体になります。 | |
3261 | -前に述べたように、このジェネレータは、前の @value{SECTION} の @code{dtd_generator.awk} と同一のものです。 | |
3262 | -あなたは、@code{print_elem()} 関数を、@ref{fig:parser_generator1} と @ref{fig:parser_generator2} にあるバージョンと置き換えることだけはしなくてはなりません。 | |
3263 | -@code{print_elem()} 関数の冒頭は理解するのが簡単です。 | |
3264 | -@code{NextElement()} 関数を生成しますが、この関数は @ref{fig:parser_generated_next_element} で見た関数です。 | |
3265 | -@code{NextElement()} 関数は一度だけ生成する必要がありますので、ルートタグ (@code{depth == 1}) が処理された時にだけ生成します。 | |
3266 | -@code{NextElement()} のように、@ref{fig:parser_dbfile} の @code{BEGIN} パターンも一度だけ必要ですので、@code{NextElement()} の直後に生成します。 | |
3267 | -その次は、@ref{fig:parser_dbfile} で見たような XML アトリビュートに関するコメントの生成です。 | |
3268 | -このコーディングスタイルは、@ref{fig:dtd_generator.awk} を学習したのであれば、初めて見るものではないはずです。 | |
3269 | -ルートではない (@code{depth > 1}) タグに対する @code{print_elem()} の呼び出し毎に一つの関数が生成されることに注意してください (生成される関数はタグにちなんで名付けられます)。 | |
3431 | +ここまで、この@value{SECTION}で見てきたコードは、全て、@emph{生成される}コードでした。 | |
3432 | +ユーザ自身のプログラムにこのコードをコピーする意味はありません。 | |
3433 | +今からは、@emph{ジェネレータ}自体になります。 | |
3434 | +前に述べたように、このジェネレータは、前の@value{SECTION}の@code{dtd_generator.awk}と同一のものです。 | |
3435 | +ユーザは、@code{print_elem()}関数を、fig:parser_generator1(@pxref{fig:parser_generator1})とfig:parser_generator2(@pxref{fig:parser_generator2})にあるバージョンと置き換えることだけはしなくてはなりません。 | |
3436 | +@code{print_elem()}関数の冒頭部分は理解しやすいです。 | |
3437 | +@code{NextElement()}関数を生成します。 | |
3438 | +この関数はfig:parser_generated_next_element(@pxref{fig:parser_generated_next_element})で見た関数です。 | |
3439 | +@code{NextElement()}関数は一度だけ生成する必要がありますので、ルートタグ(@code{depth == 1})が処理される時にだけ生成します。 | |
3440 | +@code{NextElement()}と同様、fig:parser_dbfile(@pxref{fig:parser_dbfile})の@code{BEGIN}パターンも一度だけ必要ですので、@code{NextElement()}の直後に生成します。 | |
3441 | +その次は、fig:parser_dbfile(@pxref{fig:parser_dbfile})で見たようなXMLアトリビュートに関するコメントの生成です。 | |
3442 | +このコーディングスタイルは、fig:dtd_generator.awk(@pxref{fig:dtd_generator.awk})を学習したのであれば、初めて見るものではないはずです。 | |
3443 | +ルートではない(@code{depth > 1})タグに対する@code{print_elem()}の呼び出し毎に一つの関数が生成されることに注意してください(生成される関数はタグにちなんで名付けられます)。 | |
3270 | 3444 | |
3271 | 3445 | @float Figure,fig:parser_generator1 |
3272 | 3446 | @example |
@@ -3308,16 +3482,18 @@ function print_elem(depth, element, c, atn, chl, n, i, myChildren) @{ | ||
3308 | 3482 | @} |
3309 | 3483 | print "" |
3310 | 3484 | @end example |
3311 | -@caption{@file{parser_generator.awk} にある @code{print_elem()} の最初の部分} | |
3485 | +@caption{@file{parser_generator.awk}にある@code{print_elem()}の最初の部分} | |
3312 | 3486 | @end float |
3313 | 3487 | |
3314 | -これが @code{print_elem()} の最初の部分でした。 | |
3315 | -@ref{fig:parser_generator2} にあるのが 2 番目の部分で、関数の本体を作りだすものです (生成された例として、@ref{fig:parser_dbfile} にある @code{parse_book()} を見てください)。 | |
3316 | -新しく生成された関数の本体には @code{while} ループがあって、このループは、現在読んでいるマークアップブロックが閉じタグで終了するまでトークンを読み続けます。 | |
3317 | -またその間、埋め込まれたマークアップブロックがそれぞれ検出され、他の関数で完全に読み取られます。 | |
3318 | -埋め込まれたマークアップブロックのタグは、それがそこに存在することが可能なタグの中に入っている時だけ受け付けられます。 | |
3319 | -この関数の残りの部分は初めてみるものではないはずで、埋め込まれているマークアップブロックのツリーをより深く再帰的に降りていって、そのタグの種類毎に一つの関数を生成します。 | |
3320 | -@cindex 再帰 | |
3488 | +これが、@code{print_elem()}の最初の部分でした。 | |
3489 | +fig:parser_generator2(@pxref{fig:parser_generator2})にあるのが2番目の部分で、関数の本体を作りだすものです(生成された例としては、fig:parser_dbfile(@pxref{fig:parser_dbfile})にある@code{parse_book()}を見てください)。 | |
3490 | +新しく生成された関数の本体には@code{while}ループがあります。 | |
3491 | +このループは、現在読んでいるマークアップブロックが閉じタグで終了するまでトークンを読み続けます。 | |
3492 | +また、その間、埋め込まれたマークアップブロックがそれぞれ検出され、他の関数で完全に読み取られます。 | |
3493 | +埋め込まれたマークアップブロックのタグは、そのタグが、そこに存在することが可能なタグの中に入っている時だけ受け付けられます。 | |
3494 | +この関数の残りの部分は初めてみるものではないはずです。 | |
3495 | +埋め込まれているマークアップブロックのツリーを、より深く再帰的に降りていって、そのタグの種類毎に一つの関数を生成します。 | |
3496 | +@cindex recursion | |
3321 | 3497 | |
3322 | 3498 | @float Figure,fig:parser_generator2 |
3323 | 3499 | @example |
@@ -3356,67 +3532,74 @@ function print_elem(depth, element, c, atn, chl, n, i, myChildren) @{ | ||
3356 | 3532 | @} |
3357 | 3533 | @} |
3358 | 3534 | @end example |
3359 | -@caption{@file{parser_generator.awk} にある @code{print_elem()} の 2 番目の部分} | |
3535 | +@caption{@file{parser_generator.awk}にある@code{print_elem()}の2番目の部分} | |
3360 | 3536 | @end float |
3361 | 3537 | |
3362 | -見本のファイルから完全なパーサが生成される時、さらなる改良のためのスタート地点としてよく役立つコメントが付けられたパーサをあなたは手にしています。 | |
3363 | -最も重要な事ですが、XML アトリビュートを評価する部分と、結果を表示する部分にあなたはコードを追加するでしょう。 | |
3364 | -これで、パーシングビジネスを簡単に始められるように見えるかもしれませんが、このアプローチにはいくらか制限があることに気付くはずです。 | |
3538 | +見本ファイルから完全なパーサが生成された時点で、コメント付きのパーサを手にしていることになります。 | |
3539 | +このパーサは、さらに改良するためのスタート地点として有用です。 | |
3540 | +最も重要な事ですが、XMLアトリビュートを評価する部分と、結果を表示する部分にコードを追加することになるでしょう。 | |
3541 | +これで、パーシングビジネスを簡単に始められるように思えるかもしれませんが、このアプローチにはいくらか制限があることに気付くはずです。 | |
3542 | + | |
3365 | 3543 | @itemize |
3366 | -@item XML における@b{タグ名}は、有効な Unicode であればどんな名前でも構いません。 | |
3544 | +@item XMLにおける@b{タグ名}は、有効なUnicodeであればどんな名前でも構いません。 | |
3367 | 3545 | @cindex Unicode |
3368 | -この名前は、生成される AWK のソースコードの中で関数名として使われますので、たとえば、タグ名にウムラウトの文字を含んでいると問題が発生するでしょう。 | |
3369 | -ウムラウトの文字は AWK の関数名としては許されていません。 | |
3546 | +この名前は、生成されるAWKのソースコードの中で関数名として使われますので、例えば、タグ名にウムラウト文字を含んでいると問題が発生します。 | |
3547 | +ウムラウト文字は、AWKの関数名としては許されていません。 | |
3370 | 3548 | 生成されるコードの中でタグ名を使うのを止めて、元のタグ名から、列挙/生成された名前にマッピングする方法を代わりに使わなければなりません。 |
3549 | + | |
3371 | 3550 | @item コード生成フレームワークにとって@b{ラウンドトリップエンジニアリング}というのは問題となります。 |
3372 | -パーサを生成したあと、別の見本ファイルで使われている新しいタグを追加したいと思った場合何が起きるでしょうか? | |
3551 | +パーサを生成したあと、別の見本ファイルで使われている新しいタグを追加したいと思った場合、何が起きるでしょうか。 | |
3373 | 3552 | これは難しい問題です。 |
3374 | -多分一番良い解決策は、生成されたパーサに対する手作業の修正を、生成されたパーサ自体でなく、その見本ファイルの PI (プロセッシングインストラクション) に挿入することによってコード生成処理を変更してしまうことです。 | |
3375 | -パーサジェネレータはこの PI を取り上げて、その内容を生成したコードにコピーしなければなりません。 | |
3553 | +多分一番良い解決策は、生成されたパーサに対する手作業の修正を、生成されたパーサ自体でなく、その見本ファイルのPI(プロセッシングインストラクション)に挿入することによってコード生成処理を変更してしまうことです。 | |
3554 | +パーサジェネレータはこのPIを取得し、その内容を、生成したコードにコピーしなければなりません。 | |
3376 | 3555 | @cindex Schema |
3377 | -@item XML データの意味上の制約はスキーマ言語でもっと簡単にコード化できます。 | |
3378 | -パーサジェネレーションの問題に対するもっと高度なアプローチは、既存の Schema 仕様をパーサの中に編入してしまうことかもしれません。 | |
3379 | -手元にある Schema 言語がそれ自身 XML で書かれている時、これは簡単な解決策のように見えるかもしれません。 | |
3380 | -しかし、じっと見てみると、このアプローチは多くの落とし穴がある本当のコンパイラ構築作業です。 | |
3556 | + | |
3557 | +@item XMLデータの意味上の制約は、スキーマ言語によってもっと簡単にコード化できます。 | |
3558 | +パーサ生成の問題に対するもっと高度なアプローチは、既存のSchema仕様をパーサの中に編入してしまうことかもしれません。 | |
3559 | +手元にあるSchema言語がそれ自身XMLで書かれている時、これは簡単な解決策のように見えるかもしれません。 | |
3560 | +しかし、じっと見てみると、このアプローチは、多くの落とし穴がある本当のコンパイラ構築作業となります。 | |
3381 | 3561 | @end itemize |
3382 | 3562 | |
3563 | + | |
3383 | 3564 | @node A parser for Microsoft Excel's XML file format |
3384 | -@section Microsoft Excel の XML ファイルに対するパーサ | |
3565 | +@section Microsoft ExcelのXMLファイルに対するパーサ | |
3385 | 3566 | @cindex Microsoft Excel |
3386 | 3567 | |
3387 | -見本の XML ファイルからテキストファイルを生成することについて書かれた前の二つの @value{SECTION} はかなり抽象的で、あなたを混乱させたかもしれませんでした。 | |
3388 | -この @value{SECTION} は違います。 | |
3389 | -ここでは、@file{parser_generator.awk} プログラムを動かして、それが何に役立つかを見ていきます。 | |
3390 | -Microsoft の Excel アプリケーションが作る XML の出力形式のためのパーサを生成します。 | |
3391 | -私たちの出発点はインターネットから取得した XML ファイルです。 | |
3568 | +見本のXMLファイルからテキストファイルを生成することについて書かれた前の二つの@value{SECTION}はかなり抽象的で、混乱したかもしれません。 | |
3569 | +この@value{SECTION}は違います。 | |
3570 | +ここでは、@file{parser_generator.awk}プログラムを動かして、それが何に役立つかを見ていきます。 | |
3571 | +MicrosoftのExcelアプリケーションが作るXMLの出力形式のためのパーサを生成します。 | |
3572 | +出発点は、インターネットから取得したXMLファイルです。 | |
3392 | 3573 | |
3393 | 3574 | このパーサジェネレータ動かす前に、もう一度繰り返しましょう。 |
3394 | -パーサジェネレータは @ref{fig:dtd_generator.awk} と @ref{fig:parser_generator1} と @ref{fig:parser_generator2} にあるソースコードで構成されています。 | |
3395 | -この三つの断片を @file{parser_generator.awk} という名前の一つのファイルに入れてください。 | |
3575 | +パーサジェネレータは、fig:dtd_generator.awk(@pxref{fig:dtd_generator.awk})とfig:parser_generator1(@pxref{fig:parser_generator1})とfig:parser_generator2(@pxref{fig:parser_generator2})にあるソースコードで構成されています。 | |
3576 | +この三つの断片を、@file{parser_generator.awk}という名前の一つのファイルに入れてください。 | |
3396 | 3577 | |
3397 | -ジェネレータで使用する、Microsoft Excel で作った XML ファイルを探す時間です。 | |
3578 | +ジェネレータで使用するMicrosoft Excelで作ったXMLファイルを探す時間です。 | |
3398 | 3579 | 見本ファイルは、問題となる構造的なエレメントとアトリビュートを全て含んでいなければなりません。 |
3399 | 3580 | これらのエレメントとアトリビュートは、生成されたパーサによって後で認識されるだけです。 |
3400 | 3581 | インターネット上で、可能な限り多くの妥当なエレメントとアトリビュートを含む見本ファイルを探しました。 |
3401 | 3582 | 自由に利用できて、テンプレートとして十分役立つかもしれないファイルをいくつか見つけましたが、全ての種類のエレメントとアトリビュートを含むものはありませんでした。 |
3402 | -ほぼ完全なもののうちの二つは以下のものです。 | |
3403 | -これらのコマンドを起動すれば、カレントディレクトリの中にこの二つのファイルを確認できるでしょう。 | |
3583 | +ほぼ完全なものの二つが以下のものです。 | |
3584 | +これらのコマンドを起動すれば、カレント作業ディレクトリの中に、この二つのファイルを確認できるでしょう。 | |
3404 | 3585 | |
3405 | 3586 | @smallexample |
3406 | 3587 | wget http://csislabs.palomar.edu/Student/csis120/Matthews/StudentDataFiles/Excel/PastaMidwest.xml |
3407 | 3588 | wget http://csislabs.palomar.edu/Student/csis120/Matthews/StudentDataFiles/Excel/Oklahoma2004.xml |
3408 | 3589 | @end smallexample |
3409 | 3590 | |
3410 | -もしあなた自身の見本ファイルをいくつかお持ちならば、このように他のものと一緒にそのファイルの名前を渡してください。 | |
3591 | +もし、独自の見本ファイルを持っていれば、次のように、他のものと一緒にそのファイルの名前を渡してください。 | |
3411 | 3592 | |
3412 | 3593 | @smallexample |
3413 | 3594 | gawk -f parser_generator.awk PastaMidwest.xml Oklahoma2004.xml > ms_excel_parser.awk |
3414 | 3595 | @end smallexample |
3415 | 3596 | |
3416 | -今、カレントワーキングディレクトリに @file{ms_excel_parser.awk} という新しいファイルが見つかるでしょう。 | |
3417 | -これは再帰下降パーサで、前述のテンプレートファイルに存在する全てのエレメントをパースして見分けるための用意がしてあります。 | |
3418 | -@cindex parser、再帰下降 | |
3419 | -この点を証明するために、新しいパーサをこのテンプレートファイルで動作させて、テンプレートファイルがルールに従っているかどうかを調べさせます。 | |
3597 | +これで、カレント作業ディレクトリに、@file{ms_excel_parser.awk}という新しいファイルができます。 | |
3598 | +これは、再帰下降パーサです。 | |
3599 | +前述のテンプレートファイルに存在する全てのエレメントをパースして見分けるための用意がしてあるものです。 | |
3600 | +@cindex parser, recursive descent | |
3601 | +この点を証明するために、新しいパーサを、このテンプレートファイルで動作させて、テンプレートファイルがルールに従っているかどうかを調べさせます。 | |
3602 | + | |
3420 | 3603 | @page |
3421 | 3604 | @example |
3422 | 3605 | gawk -f ms_excel_parser.awk PastaMidwest.xml |
@@ -3425,10 +3608,10 @@ gawk -f ms_excel_parser.awk xmltv.xml | ||
3425 | 3608 | could not find root element 'Workbook' |
3426 | 3609 | @end example |
3427 | 3610 | |
3428 | -当然、@ref{XMLTV ファイルからタブ付き ASCII への変換}から持ってきた @file{xmltv.xml} ファイルはこのルールに従わなかった唯一のファイルでした。 | |
3429 | -これは驚くことではありません。 | |
3430 | -Microsoft Excel からエクスポートされた XML ファイルはそれぞれそのルートノードとして @file{Workbook} タイプのノードを持っています。 | |
3431 | -これらの @file{Workbook} ノードは、@file{ms_excel_parser.awk} プログラムの以下に示す関数の冒頭で正しくパースされます。 | |
3611 | +当然、別の節(@pxref{Convert XMLTV file to tabbed ASCII})から持ってきた@file{xmltv.xml}ファイルはこのルールに従わなかった唯一のファイルでした。 | |
3612 | +これは、驚くことではありません。 | |
3613 | +Microsoft ExcelからエクスポートされたXMLファイルはそれぞれそのルートノードとして@file{Workbook}という種類のノードを持っています。 | |
3614 | +これらの@file{Workbook}ノードは、@file{ms_excel_parser.awk}プログラムの以下に示す関数の冒頭で正しくパースされます。 | |
3432 | 3615 | |
3433 | 3616 | @float Figure,fig:ch6_ms_excel_parser |
3434 | 3617 | @example |
@@ -3465,35 +3648,35 @@ function parse_Workbook() @{ | ||
3465 | 3648 | @} |
3466 | 3649 | @} |
3467 | 3650 | @end example |
3468 | -@caption{生成された @file{ms_excel_parser.awk} のコード片} | |
3651 | +@caption{生成された@file{ms_excel_parser.awk}のコード片} | |
3469 | 3652 | @end float |
3470 | 3653 | |
3471 | 3654 | |
3472 | -ルートノードが @file{Workbook} タイプのノードでは@emph{ない} (@file{xmltv.xml} ファイルを使った場合のような) 場合、その時はルートエレメントが無いことの報告が表示されます。 | |
3473 | -すぐにわかるように、@file{Workbook} にはいくつか必須のアトリビュートがあります。 | |
3474 | -生成されたパーサはこれらの存在についてチェックするようにも拡張できるでしょう。 | |
3475 | -その上、@file{Workbook} は、@file{Styles}、@file{Worksheet}、@file{ExcelWorkbook}、@file{OfficeDocumentSettings}、@file{DocumentProperties} というタイプのノードの並びです。 | |
3655 | +ルートノードが@file{Workbook}タイプのノードでは@emph{ない}(@file{xmltv.xml}ファイルを使った場合のような)場合、ルートエレメントが無いという報告が表示されます。 | |
3656 | +すぐに分かるように、@file{Workbook}にはいくつか必須のアトリビュートがあります。 | |
3657 | +生成されたパーサは、これらの存在についてチェックするようにも拡張できるでしょう。 | |
3658 | +さらに、@file{Workbook}は、@file{Styles}、@file{Worksheet}、@file{ExcelWorkbook}、@file{OfficeDocumentSettings}、@file{DocumentProperties}というタイプのノードが並んだものです。 | |
3476 | 3659 | |
3477 | 3660 | |
3478 | 3661 | @ignore |
3479 | 3662 | @cindex Schema |
3480 | 3663 | @section Converting Schema files |
3481 | -Schema ファイルは XML ファイルに対する制約の正式な表記です。 | |
3482 | -Schema ファイル自体も XML ファイルで保存されます。 | |
3664 | +Schemaファイルは、XMLファイルに対する制約の正式に記したものです。 | |
3665 | +Schemaファイル自体もXMLファイルとして保存されます。 | |
3483 | 3666 | @end ignore |
3484 | 3667 | |
3485 | 3668 | @ignore |
3486 | 3669 | @section Converting XSL programs |
3487 | -XSL スクリプトは XML ファイルの変換するためのプログラムを目的として作られています。 | |
3488 | -このスクリプト自体も xmlgawk で変換できる XML ファイルです。 | |
3670 | +XSLスクリプトは、XMLファイルの変換するためのプログラムを目的として作られています。 | |
3671 | +このスクリプト自体もxmlgawkで変換できるXMLファイルです。 | |
3489 | 3672 | |
3490 | -Sun は、入力されて Java XSL の入力を読み込んで Java の出力を生成するコンパイラをリリースしました。 | |
3491 | -このコンパイラ (@uref{http://xml.coverpages.org/saxon42Ann.html, xsltc}) は Saxon ツールの一部としてフリーなライセンスの下に置かれました。 | |
3673 | +Sunは、入力されてJava XSLの入力を読み込んでJavaの出力を生成するコンパイラをリリースしました。 | |
3674 | +このコンパイラ(@uref{http://xml.coverpages.org/saxon42Ann.html, xsltc})はSaxonツールの一部としてフリーなライセンスの下に置かれました。 | |
3492 | 3675 | |
3493 | 3676 | @section Compiling a GUI from a GLADE project file |
3494 | -Glade は GUI を作るためのツールです。 | |
3495 | -GUI を作成した結果は XML ファイルに収められます。 | |
3496 | -libglade はそのような GUI の記述を ADA や Java、Python のコードにコンパイルすることができます。 | |
3677 | +Gladeは、GUIを作るためのツールです。 | |
3678 | +GUIを作成した結果はXMLファイルに収められます。 | |
3679 | +libgladeは、そのようなGUIの記述をADAやJava、Pythonのコードにコンパイルすることができます。 | |
3497 | 3680 | |
3498 | 3681 | http://www-106.ibm.com/developerworks/library/l-gnome-glade/ |
3499 | 3682 |
@@ -3502,16 +3685,18 @@ http://www-106.ibm.com/developerworks/library/l-gnome-glade/phonebook.glade.txt | ||
3502 | 3685 | http://users.bigpond.net.au/mlm/libglade/ |
3503 | 3686 | @end ignore |
3504 | 3687 | |
3688 | + | |
3505 | 3689 | @ignore |
3506 | -@node XMark — An XML Benchmark Project | |
3690 | +@node XMark - An XML Benchmark Project | |
3507 | 3691 | @chapter XMark - An XML Benchmark Project |
3508 | -XMark プロジェクトの狙いは、ユーザや開発者に対して、彼らのリポジトリの特徴を見抜く能力を与えるベンチマークスイートを提供することです。 | |
3692 | + | |
3693 | +XMarkプロジェクトの狙いは、ユーザや開発者に対して、リポジトリの特徴を見抜く能力を与えるベンチマークスイートを提供することです。 | |
3509 | 3694 | |
3510 | 3695 | http://www.ins.cwi.nl/projects/xmark/Assets/xmlquery.txt |
3511 | 3696 | |
3512 | -このベンチマークの小さな問題は、xmlgawk の能力をそのテストへ向けるための好機です。 | |
3513 | -これで、xmlgawk が何が得意なのか、その欠陥はどこなのかを見つけだすことができます。 | |
3514 | -コアの xmlgawk と xmllib と xmltree を使ってよい時。 | |
3697 | +このベンチマークの小さな問題は、xmlgawkの能力をそのテストへ向けるための好機です。 | |
3698 | +これで、xmlgawkが何が得意なのか、その欠陥はどこなのかを見つけだすことができます。 | |
3699 | +コアのxmlgawkとxmllibとxmltreeを使ってよい時。 | |
3515 | 3700 | @end ignore |
3516 | 3701 | |
3517 | 3702 | @ignore |
@@ -3770,32 +3955,33 @@ SORTBY (.) | ||
3770 | 3955 | @end ignore |
3771 | 3956 | |
3772 | 3957 | |
3773 | - | |
3774 | 3958 | @node Reference of XML features |
3775 | -@chapter XML 機能のリファレンス | |
3959 | +@chapter XML機能のリファレンス | |
3776 | 3960 | |
3777 | 3961 | @menu |
3778 | -* gawk インタプリタに組込まれた XML 機能:: | |
3779 | -* XMLgawk コア言語インターフェイスの要約:: | |
3962 | +* XML features built into the gawk interpreter:: | |
3963 | +* XMLgawk Core Language Interface Summary:: | |
3780 | 3964 | * xmllib:: |
3781 | 3965 | * xmltree:: |
3782 | 3966 | @end menu |
3783 | 3967 | |
3784 | -この @value{CHAPTER} はリファレンスとして作られています。 | |
3785 | -それは、正確で包括的な方法で、その使用を動機付けすることなく、機能をリストしています。 | |
3786 | -まず最初は、XMLgawk の拡張で利用している組み込み変数と環境変数を全てリストしている @value{SECTION} です。 | |
3787 | -その次は、これらの変数を使う二つの違うやり方を説明する @value{SECTION} です。 | |
3788 | -そして最後は、XMLgawk 拡張の上に構築されたライブラリについて説明する二つの @value{SECTION} です。 | |
3968 | +この@value{CHAPTER}は、リファレンスとして作られています。 | |
3969 | +リファレンスは、機能の利用を動機付けすることなく、正確かつ包括的な方法で機能をリストしています。 | |
3970 | +まず、最初は、XMLgawkの拡張で利用している組み込み変数と環境変数を全てリストしている@value{SECTION}です。 | |
3971 | +その次は、これらの変数を使う二つの違うやり方を説明する@value{SECTION}です。 | |
3972 | +そして、最後は、XMLgawk拡張の上に構築されたライブラリについて説明する二つの@value{SECTION}です。 | |
3973 | + | |
3789 | 3974 | |
3790 | 3975 | @node XML features built into the gawk interpreter |
3791 | -@section gawk インタプリタに組込まれた XML 機能 | |
3792 | -この @value{SECTION} は GNU Awk の XML 拡張を構成する全ての変数と関数を紹介します。 | |
3793 | -各変数毎に、例となる XML の断片一つを使って、どういう XML コードが、セットされるパターンの原因となるのかを説明します。 | |
3794 | -このイベントが通過した後はその変数は空文字列を含んでいます。 | |
3795 | -ですので、同じ種類のイベントが別の値をセットしたとき、値を保持している変数を後になるまで信頼@emph{できません}。 | |
3796 | -私たちは行を読んでいるわけでは@emph{ありません} (XML イベントを見ている) ので、@code{$0} 変数は通常何かテキスト値がセットされているのではなく空文字列がセットされています。 | |
3797 | -@code{$0} に値をセットすると XML モードで副作用が見られます。 | |
3798 | -これはこのリファレンスでそのように説明します。 | |
3976 | +@section gawkインタプリタに組込まれたXML機能 | |
3977 | + | |
3978 | +この@value{SECTION}は、GNU AwkのXML拡張を構成する全ての変数と関数を紹介します。 | |
3979 | +各変数毎に、例となるXMLの断片一つを使い、パターンが設定されるXMLコードがどういうものなのかを説明します。 | |
3980 | +このイベントを通り過ぎた後は、その変数には空文字列が入っています。 | |
3981 | +ですから、同じ種類のイベントが別の値をセットした時、値を保持している変数を後になるまで信頼@emph{できません}。 | |
3982 | +行を読んでいるわけでは@emph{ありません}(XMLイベントを見ている)ので、@code{$0}変数は、通常、何かテキスト値がセットされているのではなく、空文字列がセットされています。 | |
3983 | +@code{$0}に値をセットするとXMLモードでは副作用が現われます。 | |
3984 | +これは、このリファレンスで説明します。 | |
3799 | 3985 | |
3800 | 3986 | @subsection @code{XMLDECLARATION}: ドキュメントの開始を示す整数 |
3801 | 3987 | @cindex @code{XMLDECLARATION} |
@@ -3804,10 +3990,10 @@ SORTBY (.) | ||
3804 | 3990 | <?xml @b{version="1.0" encoding="UTF-8"}?> |
3805 | 3991 | @end example |
3806 | 3992 | |
3807 | -XML 文書に (XML 宣言を含む) ヘッダがある場合、そのヘッダはあらゆる他の種類のデータよりも前方に常に置かれます。 | |
3993 | +XML文書に(XML宣言を含む)ヘッダがある場合、そのヘッダは、あらゆる他の種類のデータよりも前方に常に置かれます。 | |
3808 | 3994 | そのデータが、コメントやキャラクタデータ、プロセッシングインストラクションであってもです。 |
3809 | -それゆえ、@code{XMLDECLARATION} は (ともかく一つ存在すれば)、そのファイルから読まれる常に一番最初のイベントです。 | |
3810 | -そのイベントが起きた時、@code{XMLATTR} 配列が、インデックスアイテムの @code{VERSION}、@code{ENCODING}、@code{STANDALONE} で定義されます。 | |
3995 | +それゆえ、@code{XMLDECLARATION}がとにかく一つ存在すれば、そのファイルから読み込まれる常に一番最初のイベントとなります。 | |
3996 | +そのイベントが起きた時、@code{XMLATTR}配列は、インデックスアイテムの@code{VERSION}、@code{ENCODING}、@code{STANDALONE}で定義されます。 | |
3811 | 3997 | |
3812 | 3998 | @cindex @code{XMLATTR["VERSION"]} |
3813 | 3999 | @cindex @code{XMLATTR["ENCODING"]} |
@@ -3820,37 +4006,40 @@ XMLDECLARATION @{ | ||
3820 | 4006 | standalone = XMLATTR["STANDALONE"] |
3821 | 4007 | @} |
3822 | 4008 | @end example |
3823 | -@code{XMLATTR} 配列の各エントリは、それぞれの値が XML データに存在する場合にだけ存在します。 | |
3824 | 4009 | |
3825 | -@subsection @code{XMLMODE}: XML 処理の切り替えのための整数 | |
4010 | +@code{XMLATTR}配列の各エントリは、それぞれの値がXMLデータに存在する場合にだけ存在します。 | |
4011 | + | |
4012 | +@subsection @code{XMLMODE}: XML処理の切り替えのための整数 | |
3826 | 4013 | @cindex @code{XMLMODE} |
3827 | -この整数変数はインタプリタによって変更されません。 | |
3828 | -初期値は 0 です。 | |
3829 | -ユーザがこの変数を (0 以外の値に) セットすると、それ以後オープンされる各ファイルは XML ファイルとして読まれるということを示します。 | |
3830 | -この変数を再び 0 に設定すると、インタプリタが、次からのファイルをまた通常のテキストファイルとして読むようになります。 | |
4014 | + | |
4015 | +この整数変数は、インタプリタによって変更されません。 | |
4016 | +初期値は0です。 | |
4017 | +ユーザがこの変数を(0以外の値に)セットすると、それ以後オープンされる各ファイルはXMLファイルとして読まれるということを示します。 | |
4018 | +この変数を再び0に設定すると、インタプリタが、次からのファイルを、また、通常のテキストファイルとして読むようになります。 | |
3831 | 4019 | |
3832 | 4020 | @table @samp |
3833 | 4021 | @item XMLMODE |
3834 | - = 0: 次にオープンされるファイルの XML パーシングを無効にする。 | |
4022 | + = 0: 次にオープンされるファイルのXMLパーシングを無効にする。 | |
4023 | + | |
3835 | 4024 | @item XMLMODE |
3836 | - = 1: 次にオープンされるファイルの XML パーシングを有効にする。 | |
4025 | + = 1: 次にオープンされるファイルのXMLパーシングを有効にする。 | |
4026 | + | |
3837 | 4027 | @item XMLMODE |
3838 | - = -1: XML パーシングを有効にして、連結した XML ドキュメントを有効にする。 | |
4028 | + = -1: XMLパーシングを有効にして、連結したXMLドキュメントを有効にする。 | |
3839 | 4029 | @end table |
3840 | 4030 | |
4031 | +いくつかはXMLファイルで、その他はテキストファイルというように、複数のファイルを同時にオープンすることが許されています。 | |
4032 | +ファイルをあるモードでオープンした後、@code{XMLMODE}の値を変更して、別のモードで@emph{同じ}ファイルを読み続けるようなことはできません。 | |
4033 | +複数のルートエレメントを持つXMLファイルを読む必要があるユーザはたくさんいます。 | |
4034 | +そのようなXMLファイルは、(厳密に言うと)本当は整形式ではありません。 | |
4035 | +整形式のXMLドキュメントはルートエレメントを一つだけ持ちます。 | |
4036 | +@cindex Well-Formed | |
4037 | +@code{XMLMODE}を-1にセットすると、インタプリタは、一つ以上のルートエレメントを持つXMLドキュメントを受け付けるようになります。 | |
3841 | 4038 | |
3842 | -いくつかは XML ファイルでその他はテキストファイルというように、複数のファイルを同時にオープンすることは許されています。 | |
3843 | -ファイルをあるモード、あるいはもう一つのモードでオープンした後は、@code{XMLMODE} の値を変更したりして、他方のモードで@emph{同じ}ファイルを読み続けるようなことはできません。 | |
3844 | -複数のルートエレメントを持つ XML ファイルを読む必要があるユーザはたくさんいます。 | |
3845 | -そのような XML ファイルは、(厳密に言うと) 本当は整形式ではありません。 | |
3846 | -整形式の XML ドキュメントはルートエレメントを一つだけ持ちます。 | |
3847 | -@cindex 整形式 | |
3848 | -@code{XMLMODE} を -1 にセットすると、インタプリタは一つ以上のルートエレメントを持つ XML ドキュメントを受け付けるようになります。 | |
3849 | - | |
3850 | -''@@load xml'' という行を使うと副作用として、XMLMODE が -1 にセットされます。 | |
3851 | -コマンドラインオプションの ''-l xml'' も同様です。 | |
3852 | -それで、たいていのユーザは @code{XMLMODE} を直接設定するのではなく、後の二つの方法を好みます。 | |
3853 | -@code{xgawk} もしくは @code{xmlgawk} という名前で GNU Awk インタプリタを起動すると同じ副作用があります。 | |
4039 | +「@@load xml」という行を使うと、副作用として、XMLMODEが-1にセットされます。 | |
4040 | +コマンドラインオプションの「-l xml」も同様です。 | |
4041 | +そのため、たいていのユーザは@code{XMLMODE}を直接設定するのではなく、後者の方法を好みます。 | |
4042 | +@code{xgawk}、もしくは、@code{xmlgawk}という名前でGNU Awkインタプリタを起動すると同じ副作用があります。 | |
3854 | 4043 | |
3855 | 4044 | @subsection @code{XMLSTARTELEM}: エレメントに入った時にタグを保持する文字列 |
3856 | 4045 | @cindex @code{XMLSTARTELEM} |
@@ -3860,12 +4049,13 @@ XMLDECLARATION @{ | ||
3860 | 4049 | </book> |
3861 | 4050 | @end example |
3862 | 4051 | |
3863 | -マークアップグロックに入ると、XML パーサはタグ (例の中の @b{book}) を見つけて、その名前を @code{XMLSTARTELEM} 文字列変数へコピーします。 | |
3864 | -この変数がセットされている時はいつでもその値を取り出して、他の変数へその値を保存することができますが、取り囲んでいる (あるいは、含まれている) マークアップブロックのタグの名前にはアクセスすることは@emph{できません}。 | |
3865 | -副作用として、連想配列の @code{XMLATTR} と 変数 @code{$0} に値が入れられます。 | |
3866 | -変数 @code{$0} は XML データに現われた順番でアトリビュートの名前が入っています。 | |
3867 | -@code{$0} に入っているアトリビュートは空白で区切られています。 | |
3868 | -@code{$1} から @code{$NF} までの変数には、同じ順番でアトリビュートの名前が入っています。 | |
4052 | +マークアップブロックに入ると、XMLパーサはタグ(例の中の@b{book})を見つけて、その名前を、@code{XMLSTARTELEM}文字列変数へコピーします。 | |
4053 | +この変数がセットされている時は、いつでも、その値を取り出して、他の変数へその値を保存することができます。 | |
4054 | +しかし、取り囲んでいる(あるいは、含まれている)マークアップブロックのタグの名前にはアクセスすることが@emph{できません}。 | |
4055 | +副作用として、連想配列の@code{XMLATTR}と変数@code{$0}に値が入れられます。 | |
4056 | +変数@code{$0}は、XMLデータに現われた順番で、アトリビュートの名前が入っています。 | |
4057 | +@code{$0}に入っているアトリビュートは空白で区切られています。 | |
4058 | +@code{$1}から@code{$NF}までの変数には、同じ順番で、アトリビュートの名前が入っています。 | |
3869 | 4059 | |
3870 | 4060 | @subsection @code{XMLATTR}: アトリビュートの名前と値を保持する配列 |
3871 | 4061 | @cindex @code{XMLSTARTELEM} |
@@ -3878,22 +4068,27 @@ XMLDECLARATION @{ | ||
3878 | 4068 | @dots{} |
3879 | 4069 | </book> |
3880 | 4070 | @end example |
3881 | -この連想配列は常に空ですが、@code{XMLSTARTELEM}、@code{XMLDECLARATION}、@code{XMLSTARTDOCT} が true の時は例外です。 | |
3882 | -このケースの場合はすべて、@code{XMLATTR} は (広い意味で) 名前付きの複数のアトリビュートの値をユーザへ渡すために使われます。 | |
4071 | + | |
4072 | +この連想配列は常に空ですが、@code{XMLSTARTELEM}、@code{XMLDECLARATION}、@code{XMLSTARTDOCT}がtrueの時は例外です。 | |
4073 | +このケースの場合はすべて、@code{XMLATTR}は、(広い意味で)名前付きの複数のアトリビュートの値をユーザへ渡すために使われます。 | |
4074 | + | |
3883 | 4075 | @itemize |
3884 | 4076 | @item |
3885 | -@code{XMLSTARTELEM} が設定されると、@code{XMLATTR} 配列には、現在パースされているエレメントのアトリビュートの名前が入れられます。 | |
3886 | -各アトリビュートの名前はこの配列のインデックスとして入れられ、そのアトリビュートの値はインデックスに対応する値として入れられます。 | |
3887 | -この配列は、@code{XMLENDELEM} がセットされている時でも空であることに注意してください。 | |
4077 | +@code{XMLSTARTELEM}が設定されると、@code{XMLATTR}配列には、現在パースされているエレメントのアトリビュートの名前が入れられます。 | |
4078 | +各アトリビュートの名前はこの配列のインデックスとして入れられ、そのアトリビュートの値は、インデックスに対応する値として入れられます。 | |
4079 | +この配列は、@code{XMLENDELEM}がセットされている時でも空であることに注意してください。 | |
4080 | + | |
3888 | 4081 | @item |
3889 | -@code{XMLDECLARATION} がセットされると、この配列には XML ヘッダのパラメータを反映した、@code{VERSION}、@code{ENCODING}、@code{STANDALONE} という名前の変数が入れられます。 | |
4082 | +@code{XMLDECLARATION}がセットされると、この配列には、XMLヘッダのパラメータを反映した@code{VERSION}、@code{ENCODING}、@code{STANDALONE}という名前の変数が入れられます。 | |
3890 | 4083 | これらの各変数はオプショナルです。 |
4084 | + | |
3891 | 4085 | @item |
3892 | -@code{XMLSTARTDOCT} がセットされると、この配列には、@code{PUBLIC}、@code{SYSTEM}、@code{INTERNAL_SUBSET} と名付けられた、DTD の内部の同名のパラメータを反映した変数が入れられます。 | |
4086 | +@code{XMLSTARTDOCT}がセットされると、この配列には、@code{PUBLIC}、@code{SYSTEM}、@code{INTERNAL_SUBSET}と名付けられたDTDの内部の同名のパラメータを反映した変数が入れられます。 | |
3893 | 4087 | これらの各変数はオプショナルです。 |
3894 | 4088 | @end itemize |
3895 | 4089 | |
3896 | -例の場合だと、@code{XMLSTARTELEM} と @code{XMLATTR} はこのようにセットされます。 | |
4090 | +例の場合だと、@code{XMLSTARTELEM}と@code{XMLATTR}は次のようにセットされます。 | |
4091 | + | |
3897 | 4092 | @example |
3898 | 4093 | # Print all attribute names and values. |
3899 | 4094 | XMLSTARTELEM = "book" |
@@ -3905,10 +4100,11 @@ $2 = "lang" | ||
3905 | 4100 | NF = 2 |
3906 | 4101 | @end example |
3907 | 4102 | |
3908 | -@cindex 文字エンコーディング | |
4103 | +@cindex character encoding | |
3909 | 4104 | |
3910 | 4105 | @subsection @code{XMLENDELEM}: エレメントから離れる時にタグを保持する文字列 |
3911 | 4106 | @cindex @code{XMLENDELEM} |
4107 | + | |
3912 | 4108 | @example |
3913 | 4109 | <book id="hello-world" lang="en"> |
3914 | 4110 | <bookinfo> |
@@ -3917,15 +4113,18 @@ NF = 2 | ||
3917 | 4113 | @dots{} |
3918 | 4114 | <@b{/book}> |
3919 | 4115 | @end example |
3920 | -マークアップブロックを離れる時点で、XML パーサはタグを見つけ (例では @b{book})、その名前を @code{XMLENDELEM} 文字列変数にコピーします。 | |
4116 | + | |
4117 | +マークアップブロックを離れる時点で、XMLパーサはタグを見つけ(例では@b{book})、その名前を、@code{XMLENDELEM}文字列変数にコピーします。 | |
3921 | 4118 | この変数は、ぱっと見た感じのように役に立たないというわけではありません。 |
3922 | -@code{XMLENDELEM} パターンでトリガーされたアクションは、普通、XML エレメント (ここでは @code{title}) の内部に詰め込まれたキャラクタデータ (ここでは @code{Hello, world}) を処理するのに適切な場所です。 | |
3923 | -XML エレメントの @code{book} が、ネストした @code{bookinfo} のリストを含んでいれば、その時は、@code{XMLENDELEM == "book"} というパターンが、@code{bookinfo} データのリストを処理するアクションをトリガーするかもしれません。その @code{bookinfo} データのリストは @code{book} エレメントをパースする間に収集したものです。 | |
3924 | -@code{XMLATTR} はこの瞬間には空です。 | |
4119 | +@code{XMLENDELEM}パターンでトリガーされたアクションは、普通、XMLエレメント(ここでは@code{title})の内部に詰め込まれたキャラクタデータ(ここでは@code{Hello, world})を処理するのに適切な場所です。 | |
4120 | +XMLエレメントの@code{book}が、ネストした@code{bookinfo}のリストを含んでいれば、その時は、@code{XMLENDELEM == "book"}というパターンが、@code{bookinfo}データのリストを処理するアクションをトリガーするかもしれません。 | |
4121 | +その@code{bookinfo}データのリストは、@code{book}エレメントをパースする間に収集したものです。 | |
4122 | +@code{XMLATTR}はこの瞬間には空です。 | |
3925 | 4123 | |
3926 | 4124 | @subsection @code{XMLCHARDATA}: キャラクタデータを保持する文字列 |
3927 | 4125 | @cindex @code{XMLCHARDATA} |
3928 | 4126 | @cindex @code{XMLENDELEM} |
4127 | + | |
3929 | 4128 | @example |
3930 | 4129 | <title>@b{Warning}</title> |
3931 | 4130 |
@@ -3933,15 +4132,16 @@ XML エレメントの @code{book} が、ネストした @code{bookinfo} のリ | ||
3933 | 4132 | @end example |
3934 | 4133 | |
3935 | 4134 | マークアップタグの間に点在するテキストデータは@emph{キャラクタデータ}と呼ばれます。 |
3936 | -キャラクタデータが現われるたびに @code{XMLCHARDATA} がセットされて知らされます。 | |
3937 | -実際のデータは @code{$0} で渡され、現在使用されている文字エンコーディングでコード化されたテキストが入っているかもしれません。 | |
3938 | -データに入っているのが @file{0} バイトという可能性もあります。 | |
3939 | -データのバイト長は、@code{length($0)} で報告される文字の数とは異なるかもしれません。 | |
3940 | -たとえば日本語のテキストの場合です。 | |
3941 | -@code{$0} で報告されるキャラクタデータは、元の XML データとはバイト単位で同一であるとは限りません (もしかしたら異なるエンコーディングかもしれないからです)。 | |
4135 | +キャラクタデータが現われるたびに@code{XMLCHARDATA}がセットされて知らされます。 | |
4136 | +実際のデータは@code{$0}で渡され、現在使用されている文字エンコーディングでコード化されたテキストが入っているかもしれません。 | |
4137 | +データに入っているのが@file{0}バイトという可能性もあります。 | |
4138 | +データのバイト長は、@code{length($0)}で報告される文字の数とは異なるかもしれません。 | |
4139 | +例えば、日本語のテキストの場合です。 | |
4140 | +@code{$0}で報告されるキャラクタデータは、元のXMLデータとはバイト単位で同一であるとは限りません(もしかしたら異なるエンコーディングかもしれないからです)。 | |
3942 | 4141 | キャラクタデータには、上記の例の場合のように、改行がよく含まれています。 |
3943 | -XML ドキュメントにある連続するキャラクタデータは全て、1 度に @code{$0} で渡されます。 | |
3944 | -ですので、改行が @code{$0} に含まれることがあるかもしれません。 | |
4142 | +XMLドキュメントにある連続するキャラクタデータは全て、@code{$0}で一度に渡されます。 | |
4143 | +ですから、改行が@code{$0}に含まれることがあるかもしれません。 | |
4144 | + | |
3945 | 4145 | @example |
3946 | 4146 | # キャラクタデータを集めて、タグ付けされたデータブロックの終わりで報告する。 |
3947 | 4147 | XMLCHARDATA @{ data = $0 @} |
@@ -3952,15 +4152,18 @@ XMLENDELEM == "item" @{ print "title", title, "contains", item, "and", link @} | ||
3952 | 4152 | |
3953 | 4153 | @subsection @code{XMLPROCINST}: プロセッシングインストラクションターゲットを保持する文字列 |
3954 | 4154 | @cindex @code{XMLPROCINST} |
4155 | + | |
3955 | 4156 | @example |
3956 | 4157 | <?@b{ echo ("this is the simplest, an SGML processing instruction\n");} ?> |
3957 | 4158 | @end example |
3958 | -プロセッシングインストラクションは @code{<?} で始まり、@code{?>} で終わります。 | |
3959 | -@code{<?} の直後の名前は@emph{ターゲット}です。 | |
3960 | -@cindex ターゲット、プロセッシングインストラクションのもの | |
3961 | -@cindex プロセッシングインストラクチョン | |
4159 | + | |
4160 | +プロセッシングインストラクションは@code{<?}で始まり、@code{?>}で終わります。 | |
4161 | +@code{<?}の直後の名前は@emph{ターゲット}です。 | |
4162 | +@cindex target, of Processing Instruction | |
4163 | +@cindex Processing Instruction | |
3962 | 4164 | プロセッシングインストラクションの残りの部分はアプリケーション特有のものです。 |
3963 | -ターゲットは @code{XMLPROCINST} でユーザに渡され、プロセッシングインストラクションの内容は @code{$0} で渡されます。 | |
4165 | +@code{XMLPROCINST}でターゲットはユーザに渡され、プロセッシングインストラクションの内容は@code{$0}で渡されます。 | |
4166 | + | |
3964 | 4167 | @example |
3965 | 4168 | # これがどのようなプロセッシングインストラクションなのか調べる。 |
3966 | 4169 | switch (XMLPROCINST) @{ |
@@ -3969,21 +4172,26 @@ switch (XMLPROCINST) @{ | ||
3969 | 4172 | @} |
3970 | 4173 | @end example |
3971 | 4174 | |
4175 | + | |
3972 | 4176 | @subsection @code{XMLCOMMENT}: コメントを保持する文字列 |
3973 | 4177 | @cindex @code{XMLCOMMENT} |
4178 | + | |
3974 | 4179 | @example |
3975 | 4180 | <!-- @b{This is a comment} --> |
3976 | 4181 | @end example |
3977 | -XML ドキュメントにおけるコメントは HTML でのものと同じように見えます。 | |
3978 | -コメントが現われる時はいつも、XML パーサが @code{XMLCOMMENT} を @code{1} にセットし、コメントそのものを @code{$0} で渡します。 | |
4182 | + | |
4183 | +XMLドキュメントにおけるコメントは、HTMLでのものと同じように見えます。 | |
4184 | +コメントが現われる時は、XMLパーサが、@code{XMLCOMMENT}を@code{1}に必ずセットし、コメントそのものを@code{$0}で渡します。 | |
4185 | + | |
3979 | 4186 | @example |
3980 | 4187 | # コメントを報告する。 |
3981 | 4188 | XMLCOMMENT @{ print "comment:", $0 @} |
3982 | 4189 | @end example |
3983 | 4190 | |
3984 | 4191 | |
3985 | -@subsection @code{XMLSTARTCDATA}: CDATA の始まりを示す整数 | |
4192 | +@subsection @code{XMLSTARTCDATA}: CDATAの始まりを示す整数 | |
3986 | 4193 | @cindex @code{XMLSTARTCDATA} |
4194 | + | |
3987 | 4195 | @example |
3988 | 4196 | <script type="text/javascript"> |
3989 | 4197 | @b{<![CDATA[ |
@@ -3991,71 +4199,80 @@ XMLCOMMENT @{ print "comment:", $0 @} | ||
3991 | 4199 | ]]>} |
3992 | 4200 | </script> |
3993 | 4201 | @end example |
3994 | -@cindex @code{CDATA}, エスケープされていないキャラクタデータ | |
3995 | -キャラクタデータには @code{<} という文字を入れることが許されていません。 | |
3996 | -というのはこの文字がタグを示すという特殊な意味を持っているからです。 | |
4202 | + | |
4203 | +@cindex @code{CDATA}, unescaped Character Data | |
4204 | +キャラクタデータには@code{<}という文字を入れることが許されていません。 | |
4205 | +というのは、この文字がタグを示すという特殊な意味を持っているからです。 | |
3997 | 4206 | 他の四つの文字についても同じことが成り立ちます。 |
3998 | -全部で五つの文字が、XML ドキュメントの中で使われる時にエスケープされなければなりません (@code{<})。 | |
3999 | -XML ドキュメントの @code{CDATA} セクションはエスケープが必要になるのを避ける方法です。 | |
4000 | -@code{CDATA} セクションは @code{<![CDATA[} で始まり、@code{]]>} で終わります。 | |
4001 | -CDATA セクションの内部にあるものはすべて XML パーサに無視されますが、その中身はユーザに渡されます。 | |
4207 | +全部で五つの文字が、XMLドキュメントの中で使われる時にエスケープされなければなりません(@code{<})。 | |
4208 | +XMLドキュメントの@code{CDATA}セクションは、エスケープが必要になるのを避ける方法です。 | |
4209 | +@code{CDATA}セクションは@code{<![CDATA[}で始まり、@code{]]>}で終わります。 | |
4210 | +CDATAセクションの内部にあるものはXMLパーサに全て無視されますが、その中身はユーザに渡されます。 | |
4211 | + | |
4212 | +@code{CDATA}セクションが現われると、@code{XMLSTARTCDATA}が@code{1}にセットされ、@code{$0}が、その@code{CDATA}セクションの内容を保持します。 | |
4213 | +@code{CDATA}セクションには@code{]]>}という文字列を入れられません。 | |
4214 | +そのため、@code{CDATA}のネストはできないということに注意してください。 | |
4002 | 4215 | |
4003 | -@code{CDATA} セクションが現われると、@code{XMLSTARTCDATA} が @code{1} にセットされ、@code{$0} がその @code{CDATA} セクションの内容を保持します。 | |
4004 | -@code{CDATA} セクションには @code{]]>} という文字列を入れられませんので、そのため、@code{CDATA} のネストはできないということに注意してください。 | |
4005 | 4216 | |
4006 | -@subsection @code{XMLENDCDATA}: CDATA の終わりを示す整数 | |
4217 | +@subsection @code{XMLENDCDATA}: CDATAの終わりを示す整数 | |
4007 | 4218 | @cindex @code{XMLENDCDATA} |
4008 | 4219 | @cindex @code{XMLSTARTCDATA} |
4009 | -@code{XMLENDCDATA} がセットされる時はいつでも、@code{CDATA} セクションが終了して、XML パーサはデータを再び XML データとして解析しはじめます。 | |
4010 | -@code{CDATA} セクションを閉じる @code{]]>} というのはユーザには渡されません。 | |
4220 | + | |
4221 | +@code{XMLENDCDATA}がセットされる時は、いつでも、@code{CDATA}セクションが終了して、XMLパーサは、データを再びXMLデータとして解析しはじめます。 | |
4222 | +@code{CDATA}セクションを閉じる@code{]]>}はユーザには渡されません。 | |
4223 | + | |
4011 | 4224 | |
4012 | 4225 | @subsection @code{LANG}: デフォルトの文字エンコーディングを保持する環境変数 |
4013 | -@cindex @code{LANG}、環境変数 | |
4014 | -@cindex 文字エンコーディング | |
4226 | +@cindex @code{LANG}, environment variable | |
4227 | +@cindex character encoding | |
4015 | 4228 | @cindex @code{XMLCHARSET} |
4016 | 4229 | |
4017 | -GNU Awk インタプリタ実行時のオペレーティングシステムの環境は、@code{LANG} という環境変数を持っています。 | |
4018 | -これはオペレーティングシステムのローカル機構の一部です。 | |
4019 | -そしてその値は、インタプリタが使用する文字エンコーディングを決定します。 | |
4020 | -この値は、@code{XMLCHARSET} 変数の初期値としてユーザが見ることができます。 | |
4230 | +GNU Awkインタプリタ実行時のオペレーティングシステムの環境は、@code{LANG}という環境変数を持っています。 | |
4231 | +これは、オペレーティングシステムのローカル機構の一部です。 | |
4232 | +そして、その値は、インタプリタが使用する文字エンコーディングを決定します。 | |
4233 | +この値は、@code{XMLCHARSET}変数の初期値としてユーザが見ることができます。 | |
4021 | 4234 | |
4022 | 4235 | @example |
4023 | 4236 | # ユーザ環境の文字エンコーディングを表示する。 |
4024 | 4237 | BEGIN @{ print "LANG =", XMLCHARSET @} |
4025 | 4238 | @end example |
4026 | 4239 | |
4027 | -シェルレベルの @code{LANG} 変数の値が @code{XMLCHARSET} にそのままコピーされないことが時々あります。 | |
4240 | +シェルレベルの@code{LANG}変数の値が@code{XMLCHARSET}にそのままコピーされないことが時々あります。 | |
4028 | 4241 | つまり、オペレーティングシステムが別名を解決することを選ぶかもしれません。 |
4029 | 4242 | |
4030 | 4243 | @subsection @code{XMLCHARSET}: 現在の文字セットを保持する文字列 |
4031 | 4244 | @cindex @code{XMLCHARSET} |
4245 | + | |
4032 | 4246 | @example |
4033 | 4247 | <?xml version="1.0" encoding="x-sjis-cp932"?> |
4034 | 4248 | @end example |
4035 | 4249 | |
4036 | -この文字列は、インタプリタの環境 (@code{nl_langinfo(CODESET)}) の現在の文字セットに最初はセットされています。 | |
4037 | -最初はインタプリタがセットしますが、この文字列は、データを違う文字エンコーディングに変換する必要がある時にユーザがセットするためのものです。 | |
4038 | -たとえば、上記の XML ヘッダは日本語のエンコーディングであることを述べていて、他のアプリケーションが読むにはデータを UTF-8 へ変換する必要があるかもしれません。 | |
4250 | +この文字列は、インタプリタの環境(@code{nl_langinfo(CODESET)})の現在の文字セットに最初はセットされています。 | |
4251 | +最初はインタプリタがセットしますが、この文字列は、違う文字エンコーディングにデータを変換する必要がある時にユーザがセットするためのものです。 | |
4252 | +例えば、上記のXMLヘッダは、日本語のエンコーディングであることを述べています。 | |
4253 | +他のアプリケーションが読む場合には、データをUTF-8へ変換する必要があるかもしれません。 | |
4039 | 4254 | @cindex @code{UTF-8} |
4040 | 4255 | |
4041 | 4256 | @example |
4042 | -# XML データを変換するために文字エンコーディングをセットする。 | |
4257 | +# XMLデータを変換するために文字エンコーディングをセットする。 | |
4043 | 4258 | BEGIN @{ XMLCHARSET = "utf-8" @} |
4044 | 4259 | @end example |
4045 | 4260 | |
4046 | -その後、インタプリタが XML ファイルをオープンする時、XML データは全て、@code{XMLCHARSET} にユーザが設定した名前の文字セットへ変換されます。 | |
4047 | -@code{XMLCHARSET} に対する変更はすぐ効果が現われるわけではなく、引き続いていずれかのファイルをオープンしたときに効果が現われることに注意してください。 | |
4048 | -そういった変更は、変更された @code{XMLCHARSET} でオープンされたファイルにだけ作用します。 | |
4049 | -@code{XMLCHARSET} の変更に先立ってオープンされたファイルには影響しません。 | |
4261 | +その後、インタプリタがXMLファイルをオープンする時、XMLデータは全て、@code{XMLCHARSET}にユーザが設定した名前の文字セットへ変換されます。 | |
4262 | +@code{XMLCHARSET}に対する変更はすぐ効果が現われるわけではありません。 | |
4263 | +引き続いて、いずれかのファイルをオープンした時に効果が現われますので注意してください。 | |
4264 | +この変数を変更した場合、変更された@code{XMLCHARSET}を使ってオープンしたファイルにだけ作用します。 | |
4265 | +@code{XMLCHARSET}の変更に先立ってオープンされたファイルには影響しません。 | |
4050 | 4266 | |
4051 | 4267 | @ignore |
4052 | 4268 | http://www.gnu.org/software/libiconv/documentation/libiconv/iconv_open.3.html |
4053 | 4269 | The empty encoding name "" is equivalent to "char": it denotes the locale dependent character encoding. |
4054 | 4270 | @end ignore |
4055 | 4271 | |
4056 | -@subsection @code{XMLSTARTDOCT}: DTD の始まりを示すルートタグ名 | |
4272 | +@subsection @code{XMLSTARTDOCT}: DTDの始まりを示すルートタグ名 | |
4057 | 4273 | @cindex @code{XMLSTARTDOCT} |
4058 | 4274 | @cindex @code{XMLATTR} |
4275 | + | |
4059 | 4276 | @example |
4060 | 4277 | <?xml version="1.0" encoding="UTF-8" ?> |
4061 | 4278 | <!@b{DOCTYPE greeting} [ <!ELEMENT greeting (#PCDATA)> ]> |
@@ -4063,10 +4280,10 @@ The empty encoding name "" is equivalent to "char": it denotes the locale depend | ||
4063 | 4280 | @end example |
4064 | 4281 | |
4065 | 4282 | @cindex DTD, Document Type Definition |
4066 | -妥当な XML データは、妥当性の検証の対象となるべき DTD への参照を含んでいます。 | |
4067 | -@code{XMLSTARTDOCT} 変数は、DTD を参照するセクションの開始を示しています。 | |
4068 | -そういった DTD は (上記の例のように) XML データの中に埋め込まれているか、あるいは、(下の例のように) DTD ファイルへの実際の参照であるかのどちらかです。 | |
4069 | -両方の場合とも、XML データのルートタグの名前が @code{XMLSTARTDOCT} 変数へコピーされます。 | |
4283 | +妥当なXMLデータは、妥当性の検証の対象となるべきDTDへの参照を含んでいます。 | |
4284 | +@code{XMLSTARTDOCT}変数は、DTDを参照するセクションの開始を示しています。 | |
4285 | +そういったDTDは、上記の例のように、XMLデータの中に埋め込まれているか、あるいは、下の例のように、DTDファイルへの実際の参照であるかのどちらかです。 | |
4286 | +両方の場合とも、XMLデータのルートタグの名前が@code{XMLSTARTDOCT}変数へコピーされます。 | |
4070 | 4287 | |
4071 | 4288 | @example |
4072 | 4289 | <?xml version='1.0'?> |
@@ -4074,15 +4291,15 @@ The empty encoding name "" is equivalent to "char": it denotes the locale depend | ||
4074 | 4291 | <ListOfNames lang="English"> |
4075 | 4292 | @end example |
4076 | 4293 | |
4077 | -両ケースは、@code{XMLATTR} 配列を見ることで区別できます。 | |
4078 | -繰り返しですが、@code{XMLATTR} 配列は、(広い意味で) 名前の付いたアトリビュートいくつかの値をユーザへ渡すために使われます。 | |
4079 | -この配列が @code{INTERNAL_SUBSET} というインデックスを持っている場合、DTD は XML データに埋め込まれています。 | |
4080 | -そうでなければ、オプショナルなエントリである @code{PUBLIC} と @code{SYSTEM} が参照している DTD の SYSTEM 識別子か PUBLIC 識別子を報告します。 | |
4294 | +両ケースは、@code{XMLATTR}配列を見ることで区別できます。 | |
4295 | +繰り返しですが、@code{XMLATTR}配列は、(広い意味で)名前の付いたアトリビュートのいくつかの値をユーザへ渡すために使われます。 | |
4296 | +この配列が@code{INTERNAL_SUBSET}というインデックスを持っている場合、DTDはXMLデータに埋め込まれています。 | |
4297 | +そうでなければ、オプショナルなエントリである@code{PUBLIC}と@code{SYSTEM}が参照しているDTDのSYSTEM識別子かPUBLIC識別子を報告します。 | |
4081 | 4298 | |
4082 | 4299 | @cindex @code{XMLATTR["PUBLIC"]} |
4083 | 4300 | @cindex @code{XMLATTR["SYSTEM"]} |
4084 | 4301 | @example |
4085 | -# DTD 存在しているか、そしてそれが埋め込みか外部かを調べます。 | |
4302 | +# DTD存在しているか、そしてそれが埋め込みか外部かを調べます。 | |
4086 | 4303 | XMLSTARTDOCT @{ |
4087 | 4304 | root = XMLSTARTDOCT |
4088 | 4305 | if ("INTERNAL_SUBSET" in XMLATTR) @{ |
@@ -4093,82 +4310,104 @@ XMLSTARTDOCT @{ | ||
4093 | 4310 | @} |
4094 | 4311 | @} |
4095 | 4312 | @end example |
4096 | -どちらのケースでも、DTD 自体は XML パーサによってパースされることはありません。 | |
4097 | -しかし埋め込まれた DTD テキストは @code{XMLUNPARSED} 変数で、@cite{unparsed data} として渡されます。 | |
4313 | + | |
4314 | +どちらのケースでも、DTD自体は、XMLパーサによってパースされることはありません。 | |
4315 | +しかし、埋め込まれたDTDテキストは、@code{XMLUNPARSED}変数で@cite{unparsed data}として渡されます。 | |
4098 | 4316 | @cindex @code{XMLUNPARSED} |
4099 | 4317 | |
4100 | -@subsection @code{XMLENDDOCT}: DTD の終わりを示す整数 | |
4318 | + | |
4319 | +@subsection @code{XMLENDDOCT}: DTDの終わりを示す整数 | |
4101 | 4320 | @cindex @code{XMLENDDOCT} |
4102 | -@code{XMLENDDOCT} 変数が設定されるたびに、DTD セクションが終了し、XML パーサはタグ付けされた XML データとして、再びデータをパースし続けます。 | |
4103 | -DTD セクションの終了である @code{]>} はユーザに渡されません。 | |
4104 | 4321 | |
4105 | -@subsection @code{XMLUNPARSED}: unparsed characters を保持する文字列 | |
4322 | +@code{XMLENDDOCT}変数が設定されるたびに、DTDセクションが終了し、XMLパーサはタグ付けされたXMLデータとして、再びデータをパースし続けます。 | |
4323 | +DTDセクションの終了である@code{]>}はユーザに渡されません。 | |
4324 | + | |
4325 | + | |
4326 | +@subsection @code{XMLUNPARSED}: unparsed charactersを保持する文字列 | |
4106 | 4327 | @cindex @code{XMLUNPARSED} |
4107 | 4328 | @cindex @code{XMLSTARTDOCT} |
4108 | -XML データのうち、XML パーサにパースされないままなのはほんのわずかな部分しかありません。 | |
4109 | -XML ドキュメントの埋め込まれた DTD は (@code{XMLSTARTDOCT} に設定することによって) そのまま検出され伝えられますが、DTD の内容自体は @code{XMLUNPARSED} で、パースされないデータとして報告されます。 | |
4329 | + | |
4330 | +XMLデータのうち、XMLパーサにパースされないままなのは、ほんのわずかな部分しかありません。 | |
4331 | +XMLドキュメントに埋め込まれたDTDは、@code{XMLSTARTDOCT}に設定することによって、そのまま検出され伝えられますが、DTDの内容自体は、@code{XMLUNPARSED}でパースされないデータとして報告されます。 | |
4332 | + | |
4110 | 4333 | |
4111 | 4334 | @subsection @code{XMLERROR}: エラーの説明テキストを保持する文字列 |
4112 | 4335 | @cindex @code{XMLERROR} |
4113 | 4336 | @cindex @code{XMLROW} |
4114 | 4337 | @cindex @code{XMLCOL} |
4338 | + | |
4115 | 4339 | この文字列は常に空です。 |
4116 | -XML パーサが XML データの中でエラーを見つけた時だけ設定されます。 | |
4117 | -@code{XMLERROR} 文字列には、そのエラーのテキスト表現が入っています。 | |
4118 | -このテキストの内容は略式のもので、全てのプラットフォームで同じものだとは保証されません。 | |
4119 | -@code{XMLERROR} が空でない時はいつも、@code{XMLROW} 変数と @code{XMLCOL} 変数に XML データのそのエラーの場所が入っています。 | |
4340 | +XMLパーサがXMLデータの中でエラーを見つけた時だけ設定されます。 | |
4341 | +@code{XMLERROR}文字列には、そのエラーのテキスト表現が入っています。 | |
4342 | +このテキストの内容は略式のものです。 | |
4343 | +全てのプラットフォームで同じものだとは保証されません。 | |
4344 | +@code{XMLERROR}が空でない時は、必ず、@code{XMLROW}変数と@code{XMLCOL}変数に、XMLデータのそのエラーの場所が入っています。 | |
4345 | + | |
4120 | 4346 | |
4121 | 4347 | @subsection @code{XMLROW}: パースされているアイテムの現在行を保持する整数 |
4122 | 4348 | @cindex @code{XMLROW} |
4123 | -この整数には常に、現在パースされている行の番号が入っています。 | |
4124 | -最初は 0 に設定されています。 | |
4125 | -XML ファイルの最初の行が開かれると 1 にセットされ、XML データの各行でインクリメントされます。 | |
4126 | -インクリメンタルしながら行を読むことは XML パーサが行ないます。 | |
4127 | -ですので、ここでの行の概念は、AWK における@emph{レコード}の概念とは無関係です。 | |
4128 | -XMLROW の内容は @code{RS} の設定に依存していません。 | |
4349 | + | |
4350 | +この整数には、現在パースされている行番号が常に入っています。 | |
4351 | +最初は0に設定されています。 | |
4352 | +XMLファイルの最初の行が開かれると1にセットされ、XMLデータの各行でインクリメントされます。 | |
4353 | +インクリメンタルしながら行を読むことはXMLパーサが行います。 | |
4354 | +ですから、ここでの行の概念は、AWKにおける@emph{レコード}の概念とは無関係です。 | |
4355 | +XMLROWの内容は、@code{RS}の設定に依存していません。 | |
4356 | + | |
4129 | 4357 | |
4130 | 4358 | @subsection @code{XMLCOL}: パースされているアイテムの現在のカラムを保持する整数 |
4131 | 4359 | @cindex @code{XMLCOL} |
4132 | -この整数には常に現在パースされている現在行のカラムの番号が入っています。 | |
4133 | -最初は 0 に設定されています。 | |
4134 | -XML ファイルの最初の行がオープンされると、それは 1 にセットされ、XML データの各文字でインクリメントされます。 | |
4135 | -各行の行頭で 1 にセットされます。 | |
4136 | -インクリメントしながら行を読むことは XML パーサが行ないます。 | |
4137 | -ですので、ここでの行の概念は、 AWK での@emph{レコード}の概念とは無関係です。 | |
4138 | -XMLCOL の内容は @code{FS} の設定に依存していません。 | |
4360 | + | |
4361 | +この整数には、現在パースされている現在行のカラムの番号が常に入っています。 | |
4362 | +最初は0に設定されています。 | |
4363 | +XMLファイルの最初の行がオープンされると、それは1にセットされ、XMLデータの各文字でインクリメントされます。 | |
4364 | +各行の行頭で1にセットされます。 | |
4365 | +インクリメントしながら行を読むことはXMLパーサが行います。 | |
4366 | +ですから、ここでの行の概念は、AWKでの@emph{レコード}の概念とは無関係です。 | |
4367 | +XMLCOLの内容は、@code{FS}の設定に依存していません。 | |
4368 | + | |
4139 | 4369 | |
4140 | 4370 | @subsection @code{XMLLEN}: パースされているアイテムの長さを保持する整数 |
4141 | 4371 | @cindex @code{XMLLEN} |
4142 | 4372 | @cindex @code{XMLCHARSET} |
4143 | -この整数は常に、現在パースされているアイテムのバイト数が入っています。 | |
4144 | -最初は 0 に設定されています。 | |
4145 | -バイト数は、元のパースされた XML データのバイトを参照します。 | |
4373 | + | |
4374 | +この整数は、現在パースされているアイテムのバイト数が常に入っています。 | |
4375 | +最初は0に設定されています。 | |
4376 | +バイト数は、元のパースされたXMLデータのバイトを参照します。 | |
4146 | 4377 | 文字数と同じものではありません。 |
4147 | -@code{XMLCHARSET} で決定される文字エンコーディングへの変換 (オプショナル) の後、@code{XMLLEN} に入っている長さは、その XML データアイテムの変換後の長さとは異なっていることもあるかもしれません。 | |
4378 | +@code{XMLCHARSET}で決定される文字エンコーディングへの変換(オプショナル)の後、@code{XMLLEN}に入っている長さは、そのXMLデータアイテムの変換後の長さとは異なっていることもあるかもしれません。 | |
4379 | + | |
4148 | 4380 | |
4149 | 4381 | @subsection @code{XMLDEPTH}: エレメントのネスティングの深さを保持する整数 |
4150 | 4382 | @cindex @code{XMLDEPTH} |
4151 | -この整数は常に、現在パースされているエレメントのネスティングの深さが入っています。 | |
4152 | -最初は、XML ファイルがオープンされた時、0 に設定されています。 | |
4153 | -XML ファイルの最初のエレメントに入ると、1 にセットされ、(まだ完了していない) さらに先の各エレメントでインクリメントされます。 | |
4383 | + | |
4384 | +この整数は、現在パースされているエレメントのネスティングの深さが常に入っています。 | |
4385 | +XMLファイルがオープンされた時、最初は0に設定されています。 | |
4386 | +XMLファイルの最初のエレメントに入ると、1にセットされ、(まだ完了していない)さらに先の各エレメントでインクリメントされます。 | |
4154 | 4387 | エレメントのパースが完了すると、この変数はデクリメントされます。 |
4155 | 4388 | |
4389 | + | |
4156 | 4390 | @subsection @code{XMLPATH}: パースされているエレメントのネストされているタグを保持する文字列 |
4157 | 4391 | @cindex @code{XMLPATH} |
4158 | -インタプリタをスタートして、XML ファイルをオープン時は、この文字列は空です。 | |
4159 | -@code{XMLSTARTELEM} 毎に、新しいタグ名が、その前に @code{"/"} 文字を付けた状態で @code{XMLPATH} の後ろに追加されます。 | |
4160 | -(XML ファイルの文字エンコーディングに従ってエンコードされている) @code{"/"} 文字は、両者の間のセパレータとして働きます。 | |
4161 | -@code{XMLENDELEM} 毎に、古いタグ名 (と前置されている @code{"/"}) が @code{XMLPATH} から切り離されます。 | |
4162 | -ユーザが @code{XMLPATH} を変更するかもしれませんが、@code{XMLPATH} に対するどのような変更も、次の XML データの読み込みで上書きされます。 | |
4163 | 4392 | |
4164 | -@subsection @code{XMLENDDOCUMENT}: XML データの終わりを示す整数 | |
4393 | +インタプリタをスタートしてXMLファイルをオープンする時は、この文字列は空です。 | |
4394 | +@code{XMLSTARTELEM}ごとに、新しいタグ名が、その前に@code{"/"}文字を付けた状態で、@code{XMLPATH}の後ろに追加されます。 | |
4395 | +(XMLファイルの文字エンコーディングに従ってエンコードされている)@code{"/"}文字は、両者の間のセパレータとして働きます。 | |
4396 | +@code{XMLENDELEM}ごとに、古いタグ名(および、前置されている@code{"/"})が@code{XMLPATH}から切り離されます。 | |
4397 | +@code{XMLPATH}をユーザが変更するかもしれませんが、@code{XMLPATH}に対するどのような変更も、次のXMLデータの読み込みで上書きされます。 | |
4398 | + | |
4399 | + | |
4400 | +@subsection @code{XMLENDDOCUMENT}: XMLデータの終わりを示す整数 | |
4165 | 4401 | @cindex @code{XMLENDDOCUMENT} |
4166 | -この整数は常に 0 です。 | |
4167 | -XML パーサが、XML データの終端を見つけた時にだけセットされます。 | |
4402 | + | |
4403 | +この整数は常に0です。 | |
4404 | +XMLパーサが、XMLデータの終端を見つけた時にだけセットされます。 | |
4405 | + | |
4168 | 4406 | |
4169 | 4407 | @subsection @code{XMLEVENT}: イベント名を保持する文字列 |
4170 | 4408 | @cindex @code{XMLEVENT} |
4171 | -この文字列は常に、現在処理されているイベントの名前が入っています。 | |
4409 | + | |
4410 | +この文字列は、現在処理されているイベントの名前が常に入っています。 | |
4172 | 4411 | 有効な名前は |
4173 | 4412 | @code{DECLARATION} |
4174 | 4413 | @code{STARTDOCT} |
@@ -4183,25 +4422,29 @@ XML パーサが、XML データの終端を見つけた時にだけセットさ | ||
4183 | 4422 | @code{UNPARSED} |
4184 | 4423 | @code{ENDDOCUMENT} |
4185 | 4424 | です。 |
4186 | -この名前は同名の変数と密に関係があります。 | |
4187 | -同名の変数は @code{XML} というプリフィックスを持っています。 | |
4188 | -このイベントについてくるいかなる名前も @code{XMLNAME}、@code{$0}、@code{XMLATTR} で渡されます。 | |
4189 | -どの変数がどの情報を保持しているかの詳細は、@xref{fig:table_style_b}。 | |
4425 | +この名前は、同名の変数と密に関係があります。 | |
4426 | +同名の変数は、@code{XML}というプリフィックスが付いています。 | |
4427 | +このイベントと共に来る名前も、全て、@code{XMLNAME}、@code{$0}、@code{XMLATTR}で渡されます。 | |
4428 | +どの変数がどの情報を保持しているかについては別表を参照してください(@pxref{fig:table_style_b})。 | |
4429 | + | |
4190 | 4430 | |
4191 | -@subsection @code{XMLNAME}: XMLEVENT に割り当てられた名前を保持する文字列 | |
4431 | +@subsection @code{XMLNAME}: XMLEVENTに割り当てられた名前を保持する文字列 | |
4192 | 4432 | @cindex @code{XMLNAME} |
4193 | 4433 | @cindex @code{XMLEVENT} |
4194 | -@code{XMLNAME} 変数は、@code{XMLEVENT} 変数に特定のエベントが入っている時にデータを渡すために使われます。 | |
4195 | -どの変数がどの情報を保持しているかの詳細は、@xref{fig:table_style_b}。 | |
4434 | + | |
4435 | +@code{XMLNAME}変数は、@code{XMLEVENT}変数に特定のエベントが入っている時にデータを渡すために使われます。 | |
4436 | +どの変数がどの情報を保持しているかのについては別表を参照してください(@pxref{fig:table_style_b})。 | |
4437 | + | |
4196 | 4438 | |
4197 | 4439 | @node XMLgawk Core Language Interface Summary |
4198 | -@section XMLgawk コア言語インターフェイスの要約 | |
4199 | -前の @value{SECTION} の組み込み変数は、XML パーサ Expat の API に似た部分を引き受けるために選ばれました。 | |
4200 | -@pindex Expat、SAX ライクな API を持つ XML パーサ | |
4201 | -ほとんどの組み込み変数は Expat の API の ''ハンドラ'' 関数を反映しています。 | |
4202 | -Expat で作業したことがあるならば、XMLgawk を使えば家にいるような気分になるでしょう。 | |
4203 | -あなたが持つであろう疑問は、@emph{どのようにパラメータを渡すか}ということだけです。 | |
4204 | -この @value{SECTION} は、あなたの疑問に、変数名とパラメータ渡しの詳細による概要を表にして答えます。 | |
4440 | +@section XMLgawkコア言語インターフェイスの要約 | |
4441 | + | |
4442 | +前の@value{SECTION}の組み込み変数は、XMLパーサExpatのAPIに似た部分を引き受けるために選ばれました。 | |
4443 | +@pindex Expat, XML parser with SAX-like API | |
4444 | +ほとんどの組み込み変数は、ExpatのAPIの「ハンドラ」関数を反映しています。 | |
4445 | +Expatで作業したことがあるならば、XMLgawkを使えば家にいるような気分になるでしょう。 | |
4446 | +疑問は、@emph{どのようにパラメータを渡すか}ということだけです。 | |
4447 | +この@value{SECTION}では、この疑問に対して、変数名とパラメータ渡しの詳細による概要を表にして答えます。 | |
4205 | 4448 | |
4206 | 4449 | @ignore |
4207 | 4450 | Each row of the table |
@@ -4220,12 +4463,15 @@ the variable might be a future enhancement | ||
4220 | 4463 | @end table |
4221 | 4464 | @end ignore |
4222 | 4465 | |
4223 | -正確に言うと、この @value{CHAPTER} に実際には表が二つあります。 | |
4466 | +正確に言うと、この@value{CHAPTER}に実際には表が二つあります。 | |
4467 | + | |
4224 | 4468 | |
4225 | -@subsection Style A - 各イベントクラス XML@emph{eventname} ごとに一つの予め定義された専用の変数 | |
4226 | -最初の表では、プログラムの中でパターンとして単独で使える変数名を表わしていて、それぞれの種類のエベントを処理するアクションをトリガーします。 | |
4227 | -表の最初の欄には変数名が入っていて、2 番目の欄にはトリガーされた時の変数の値が入っています。 | |
4228 | -XML パーサから受け取ることのできるパラメータは全て、残りの欄に説明されています。 | |
4469 | +@subsection Style A - 各イベントクラスXML@emph{eventname}ごとに一つの予め定義された専用の変数 | |
4470 | + | |
4471 | +最初の表では、プログラムの中でパターンとして単独で使える変数名を表わしています。 | |
4472 | +これらの変数は、それぞれの種類のイベントを処理するアクションをトリガーします。 | |
4473 | +表の最初の欄には変数名が入っていて、2番目の欄にはトリガーされた時の変数の値が入っています。 | |
4474 | +XMLパーサから受け取ることのできるパラメータは残りの欄に全て説明されています。 | |
4229 | 4475 | |
4230 | 4476 | @float Figure,fig:table_style_a |
4231 | 4477 | @multitable { XMLNOTATIONDECL} {elemame} {list of attr nam} { INTERNAL_SUBSET} {encoding name} |
@@ -4235,14 +4481,14 @@ XML パーサから受け取ることのできるパラメータは全て、残 | ||
4235 | 4481 | @tab "1.0" encoding name "yes"/"no" |
4236 | 4482 | @item XMLSTARTDOCT @tab root element name @tab @tab PUBLIC@* SYSTEM @* INTERNAL_SUBSET @tab public Id@*system Id@*1 |
4237 | 4483 | @item XMLENDDOCT @tab 1 |
4238 | -@item XMLPROCINST @tab PI name @tab PI content | |
4484 | +@item XMLPROCINST @tab PI name @tab PI content | |
4239 | 4485 | @item XMLSTARTELEM @tab element name @tab Ordered list of attribute names @tab given name(s) @tab given value(s) |
4240 | 4486 | @item XMLENDELEM @tab element name |
4241 | -@item XMLCHARDATA @tab 1 @tab text data | |
4487 | +@item XMLCHARDATA @tab 1 @tab text data | |
4242 | 4488 | @item XMLSTARTCDATA @tab 1 |
4243 | 4489 | @item XMLENDCDATA @tab 1 |
4244 | -@item XMLCOMMENT @tab 1 @tab comment text | |
4245 | -@item XMLUNPARSED @tab 1 @tab text data | |
4490 | +@item XMLCOMMENT @tab 1 @tab comment text | |
4491 | +@item XMLUNPARSED @tab 1 @tab text data | |
4246 | 4492 | @item XMLENDDOCUMENT @tab 1 |
4247 | 4493 | @ignore |
4248 | 4494 | Manuel suggested inclusion of the following. |
@@ -4252,17 +4498,20 @@ Manuel suggested inclusion of the following. | ||
4252 | 4498 | @item * XMLNOTATIONDECL @tab ? @tab ? @tab ? @tab ? |
4253 | 4499 | @end ignore |
4254 | 4500 | @end multitable |
4255 | -@caption{style A で XML データを渡す変数} | |
4501 | +@caption{style AでXMLデータを渡す変数} | |
4256 | 4502 | @end float |
4257 | 4503 | |
4504 | + | |
4258 | 4505 | @subsection Style B - すべてのイベントで共有される、限定された変数の組 |
4506 | + | |
4259 | 4507 | さて、二つ目の変数の表です。 |
4260 | 4508 | 上記の表の中のいろいろな名前を全て覚えるのが好きではない人もいます。 |
4261 | -彼らは、変数名を最低二つ覚えるというほうを好みます。 | |
4262 | -1 番目の変数 (@code{XMLEVENT}) には発生したイベント (たとえば @code{STARTELEM}) の種類が入っていて、2 番目の変数 (@code{XMLNAME}) は、(エレメントの名前のように) それについての詳細を渡します。 | |
4263 | -全てのイベントとそのパラメータは、この方式で渡されます。 | |
4264 | -しかし時々、たった一つだけでなくて、それ以上のパラメータが渡されることがあります。 | |
4265 | -その時は、既に最初の表で説明したように、@code{$0} と @code{XMLATTR} に頼らなければなりません。 | |
4509 | +そういった人は、変数名を最低二つ覚えるという方を好むでしょう。 | |
4510 | +1番目の変数(@code{XMLEVENT})には、発生したイベント(例えば、@code{STARTELEM})の種類が入っています。 | |
4511 | +2番目の変数(@code{XMLNAME})には、エレメントの名前のように、それについての詳細を渡します。 | |
4512 | +全てのイベントとそのパラメータがこの方式で渡されます。 | |
4513 | +しかし、たった一つだけではなく、それ以上のパラメータが渡されることもあります。 | |
4514 | +その時は、最初の表で既に説明したような@code{$0}と@code{XMLATTR}に頼らなければなりません。 | |
4266 | 4515 | |
4267 | 4516 | @float Figure,fig:table_style_b |
4268 | 4517 | @multitable {XMLNOTATION} {elemname} {list of attr nam} { INTERNAL_SUBSET} {encoding name} |
@@ -4270,14 +4519,14 @@ Manuel suggested inclusion of the following. | ||
4270 | 4519 | @item DECLARATION @tab @tab @tab VERSION@* ENCODING@* STANDALONE @tab "1.0" @* encoding name @* "yes"/"no" |
4271 | 4520 | @item STARTDOCT @tab root element name @tab @tab PUBLIC@* SYSTEM@* INTERNAL_SUBSET @tab public Id@* system Id @* 1 |
4272 | 4521 | @item ENDDOCT |
4273 | -@item PROCINST @tab PI name @tab PI content | |
4522 | +@item PROCINST @tab PI name @tab PI content | |
4274 | 4523 | @item STARTELEM @tab element name @tab Ordered list of attribute names @tab given name(s) @tab given value(s) |
4275 | 4524 | @item ENDELEM @tab element name |
4276 | -@item CHARDATA @tab @tab text data | |
4525 | +@item CHARDATA @tab @tab text data | |
4277 | 4526 | @item STARTCDATA |
4278 | 4527 | @item ENDCDATA |
4279 | -@item COMMENT @tab @tab comment text | |
4280 | -@item UNPARSED @tab @tab text data | |
4528 | +@item COMMENT @tab @tab comment text | |
4529 | +@item UNPARSED @tab @tab text data | |
4281 | 4530 | @item ENDDOCUMENT |
4282 | 4531 | |
4283 | 4532 | @ignore |
@@ -4288,7 +4537,7 @@ Manuel suggested inclusion of the following. | ||
4288 | 4537 | @end ignore |
4289 | 4538 | |
4290 | 4539 | @end multitable |
4291 | -@caption{style B で XML データを渡す変数} | |
4540 | +@caption{style BでXMLデータを渡す変数} | |
4292 | 4541 | @end float |
4293 | 4542 | |
4294 | 4543 | @ignore |
@@ -4308,98 +4557,103 @@ Style A (one variable for each event) and style B (only two variables) interface | ||
4308 | 4557 | @end itemize |
4309 | 4558 | @end ignore |
4310 | 4559 | |
4560 | + | |
4311 | 4561 | @node xmllib |
4312 | 4562 | @section xmllib |
4563 | + | |
4313 | 4564 | @b{FIXME: This section has not been written yet}. |
4314 | 4565 | |
4566 | + | |
4315 | 4567 | @node xmltree |
4316 | 4568 | @section xmltree |
4569 | + | |
4317 | 4570 | @b{FIXME: This section has not been written yet}. |
4318 | 4571 | |
4572 | + | |
4319 | 4573 | @node Reference of Books and Links |
4320 | 4574 | @chapter 参考書籍とリンク |
4321 | 4575 | |
4322 | 4576 | @menu |
4323 | -* 良書:: | |
4324 | -* インターネットへのリンク:: | |
4577 | +* Good Books:: | |
4578 | +* Links to the Internet:: | |
4325 | 4579 | @end menu |
4326 | 4580 | |
4581 | + | |
4327 | 4582 | @node Good Books |
4328 | 4583 | @section 良書 |
4329 | -ここでは XML と AWK についてもっと学びたい人のための本についてコメントしながらリストしていきます。 | |
4584 | + | |
4585 | +ここでは、XMLとAWKについてもっと学びたい人のために、コメントしながら書籍を挙げていきたいと思います。 | |
4330 | 4586 | |
4331 | 4587 | @itemize |
4332 | 4588 | @item |
4333 | -AWK に関する一番最初の本は Aho, Kernighan, Weinberger による @cite{The AWK Programming Language} でした。 | |
4334 | -この本が最初に登場してから 20 年以上、いまだに、情報とインスピレーションのソースとして高く評価されています。 | |
4335 | -この本のことを @uref{http://cm.bell-labs.com/cm/cs/awkbook, @b{TAPL}} として参照する読者もいます。 | |
4589 | +AWKに関する一番最初の本はAho、Kernighan、Weinbergerによる@cite{The AWK Programming Language}でした。 | |
4590 | +この本が最初に登場してから20年以上経ちましたが、いまだに、情報とインスピレーションのソースとして高く評価されています。 | |
4591 | +この本のことを、@uref{http://cm.bell-labs.com/cm/cs/awkbook, @b{TAPL}}と呼ぶ読者もいます。 | |
4336 | 4592 | |
4337 | 4593 | @item |
4338 | -@cite{TAPL} は高価な本で、AT&T の Unix に付いて来たオリジナルの AWK 実装と結び付けられていました。 | |
4339 | -SunOS が一般的になったとき、AWK インタプリタ (@code{oawk} と @code{nawk}) | |
4594 | +@cite{TAPL}は高価な本で、AT&TのUnixに付いて来たオリジナルのAWK実装と結び付けられていました。 | |
4340 | 4595 | @cindex @code{nawk} |
4341 | -を実装した SunOS のやり方によって AWK の評判は傷付けられてしまいました。 | |
4342 | -それで、オープンソースコードでの実装と開発者によるサポート、適切なドキュメンテーションの必要がありました。 | |
4343 | -GNU Awk 実装は Arnold Robbins によって保守されています。 | |
4344 | -彼は @b{EAP3}、@uref{http://www.oreilly.com/catalog/awkprog3/index.html, GNU Awk manual} の第 3 版の著者としても役割を果たしています。 | |
4345 | -この高価でない本は O'Reilly によって出版されていますが、GNU Awk のソースディストリビューションと一緒に配布されてもいます。 | |
4596 | +SunOSが一般的になった時、AWKインタプリタ(@code{oawk}と@code{nawk})を実装したSunOSのやり方によってAWKの評判は傷付けられてしまいました。 | |
4597 | +そのため、オープンソースコードでの実装と開発者によるサポート、適切なドキュメントの必要がありました。 | |
4598 | +GNU Awk実装は、Arnold Robbinsによって保守されています。 | |
4599 | +彼は、@b{EAP3}、@uref{http://www.oreilly.com/catalog/awkprog3/index.html, GNU Awk manual}の第3版の著者としても役割を果たしています。 | |
4600 | +この高価でない本はO'Reillyによって出版されていますが、GNU Awkのソースディストリビューションと一緒に配布されてもいます。 | |
4346 | 4601 | この最新の情報ソースと一緒にリファレンスカードが来ています。 |
4347 | -残念ながら、このリファレンスカードは O'Reilly の本の一部ではありません。 | |
4348 | -POSIX スタンダードとオリジナルの AWK、そして GNU Awk の間の微妙な差異についてこれほど正確な発行物は他にありません。 | |
4602 | +残念ながら、このリファレンスカードはO'Reilly本の一部ではありません。 | |
4349 | 4603 | @cindex POSIX |
4604 | +POSIXスタンダードとオリジナルのAWK、そして、GNU Awkの間の微妙な差異について、これほど正確な発行物は他にありません。 | |
4350 | 4605 | |
4351 | 4606 | @item |
4352 | -AWK の成功を受けた中での他のスクリプト言語の成功と、初期の GNU/Linux の発展によって、AWK は他の言語に「置き換え」られつつあるという間違った認識が出てきました。 | |
4353 | -スタイリッシュな新しいスクリプト言語が 5 年毎に現われては消えをしている一方、AWK は消えたり、「置き換え」られたりしないでしょう。 | |
4354 | -@uref{http://en.wikipedia.org/wiki/Single_UNIX_Specification, Single UNIX Specification} | |
4607 | +AWKの成功を受けた中での他のスクリプト言語の成功と、初期のGNU/Linuxの発展によって、AWKは他の言語に「置き換え」られつつあるという間違った認識が出てきました。 | |
4608 | +スタイリッシュな新しいスクリプト言語が5年毎に現われては消えをしている一方、AWKは消えたり、「置き換え」られたりしないでしょう。 | |
4355 | 4609 | @cindex Unix |
4356 | 4610 | @cindex POSIX |
4357 | -の中で、AWK は、Unix オペレーティングシステムの必須ユーティリティの一つとして説明されています。 | |
4358 | -AWK を除けば、スクリプト言語 Bourne Shell ただ一つだけが、「権威あるスクリプト言語」としての地位を保っています。 | |
4359 | -実際に必要になる読者は少ないでしょうけれども、AWK の正確な仕様が知りたい場合は、@uref{http://www.opengroup.org/onlinepubs/009695399/utilities/awk.html, @b{POSIX AWK}} という仕様書を読んでください。 | |
4611 | +@uref{http://en.wikipedia.org/wiki/Single_UNIX_Specification, Single UNIX Specification}の中で、AWKは、Unixオペレーティングシステムの必須ユーティリティの一つとして説明されています。 | |
4612 | +AWKを除けば、スクリプト言語Bourne Shellただ一つだけが、「権威あるスクリプト言語」としての地位を保っています。 | |
4613 | +実際に必要になる読者は少ないでしょうけれども、AWKの正確な仕様が知りたい場合は、@uref{http://www.opengroup.org/onlinepubs/009695399/utilities/awk.html, @b{POSIX AWK}}という仕様書を読んでください。 | |
4360 | 4614 | |
4361 | 4615 | @item |
4362 | -ポータブルなスクリプト言語として AWK ユーティリティを認識しはじめたばかりでしたならば、入門や総覧、そしてさらなる情報源へのディスパッチャとして @uref{http://en.wikipedia.org/wiki/Awk, @b{Wikipedia's AWK entry}} を読むべきでしょう。 | |
4616 | +ポータブルなスクリプト言語としてAWKユーティリティを認識しはじめたばかりでしたならば、入門、総覧、そして、さらなる情報源へのディスパッチャとして@uref{http://en.wikipedia.org/wiki/Awk, @b{Wikipedia's AWK entry}}を読むべきでしょう。 | |
4363 | 4617 | |
4364 | 4618 | @item |
4365 | -XML は、ちょうど GNU Awk のように、1970 年代まで遡ることのできるスタンダードの成果です。 | |
4366 | -お勧めの読み物については前にいくつかすでに触れました (@pxref{XML ファイルを詳しく見る})。 | |
4367 | -単独の情報源としては、O'Reilly の本 @uref{http://www.oreilly.com/catalog/xmlnut3/, @b{XML in a Nutshell}} をよく勧めていました。 | |
4368 | -さらに、@uref{http://en.wikipedia.org/wiki/Xml, Wikipedia's XML entry} が、手軽な概要と入門、そしてリンクと情報源を集めたものを提供しています。 | |
4619 | +XMLは、ちょうどGNU Awkのように、1970年代まで遡ることのできるスタンダードの成果です。 | |
4620 | +お勧めの読み物については前にいくつかすでに触れました(@pxref{Looking closer at the XML file})。 | |
4621 | +単独の情報源としては、O'Reillyの@uref{http://www.oreilly.com/catalog/xmlnut3/, @b{XML in a Nutshell}}をよく勧めていました。 | |
4622 | +さらに、@uref{http://en.wikipedia.org/wiki/Xml, Wikipedia's XML entry}が、手軽な概要、入門、そして、リンクと情報源を集めたものを提供しています。 | |
4623 | +@end itemize | |
4369 | 4624 | |
4370 | 4625 | |
4371 | -@end itemize | |
4372 | 4626 | @page |
4373 | - | |
4374 | 4627 | @node Links to the Internet |
4375 | 4628 | @section インターネットへのリンク |
4376 | -このセクションは、この @value{DOCUMENT} を通してお話した様々な事柄に関する URL をリストしています。 | |
4629 | + | |
4630 | +このセクションは、この@value{DOCUMENT}を通してお話した様々な事柄に関するURLをリストしています。 | |
4377 | 4631 | |
4378 | 4632 | @itemize |
4379 | 4633 | @item |
4380 | -XMLgawk は Arnold Robbins の @uref{http://www.gnu.org/software/gawk/gawk.html, @b{GNU Awk}} を基にしています。 | |
4381 | -Arnold のディストリビューションは唯一の本物の GNU Awk です。 | |
4382 | -GNU Awk は、標準に対して忠実で、非常に多くの Unix オペレーティングシステムで使われる、安定したディストリビューションであることを目的としています。 | |
4634 | +XMLgawkは、Arnold Robbinsの@uref{http://www.gnu.org/software/gawk/gawk.html, @b{GNU Awk}}を基にしています。 | |
4635 | +Arnoldのディストリビューションは唯一の本物のGNU Awkです。 | |
4636 | +GNU Awkは標準に対して忠実です。 | |
4637 | +非常に多くのUnixオペレーティングシステムで使われる安定したディストリビューションであることを目的としています。 | |
4383 | 4638 | |
4384 | 4639 | @item |
4385 | -XMLgawk は GNU Awk の機能拡張です。 | |
4386 | -@uref{http://sourceforge.net/projects/xmlgawk/, @b{xgawk distribution}} の一部として配布されています。 | |
4640 | +XMLgawkは、GNU Awkの機能拡張です。 | |
4641 | +@uref{http://sourceforge.net/projects/xmlgawk/, @b{xgawk distribution}}の一部として配布されています。 | |
4387 | 4642 | @cite{xgawk} |
4388 | -SourceForge | |
4389 | 4643 | @cindex SourceForge |
4390 | -のプロジェクトは @emph{xmlgawk} (小文字、SourceForge のプロジェクト名は小文字で構成されなければなりません) と名付けられています。 | |
4391 | -これは、当初の計画が XML 拡張の実装だけを目指していたからです。 | |
4392 | -後に、XML パーサよりも e@b{x}tension に重点があることを反映するために、このディストリビューションの名前が選ばれました。 | |
4644 | +SourceForgeのプロジェクトは@emph{xmlgawk}(小文字、SourceForgeのプロジェクト名は小文字で構成されなければなりません)と名付けられています。 | |
4645 | +これは、当初の計画がXML拡張の実装だけを目指していたからです。 | |
4646 | +後に、XMLパーサよりもe@b{x}tensionに重点があることを反映するため、このディストリビューションの名前が選ばれました。 | |
4393 | 4647 | |
4394 | 4648 | @item |
4395 | -XMLgawk での XML データの処理の仕方が、SAX API を念頭にデザインされていることは @ref{XML ファイルのアウトラインの表示}の中で既に述べました。 | |
4396 | -@cindex SAX, XML のシンプルな API | |
4397 | -他の言語でもこの API を実装したライブラリを持っています。 | |
4398 | -ほとんどの開発者にとって Java の実装は SAX API の権威ある実装です。 | |
4649 | +@cindex SAX, Simple API for XML | |
4650 | +XMLgawkでのXMLデータの処理の仕方が、SAX APIを念頭にデザインされていることは、別の節(@pxref{Printing an outline of an XML file})の中で既に述べました。 | |
4651 | +他の言語でも、このAPIを実装したライブラリを持っています。 | |
4399 | 4652 | @cindex Java |
4400 | -@cite{Core Web Programming} という本の @uref{http://www.corewebprogramming.com/PDF/ch23.pdf, @b{XML Processing with Java}} というチャプターを見てください。 | |
4401 | -@ref{fig:ch2_outline.awk} で提供したスクリプト @file{outline.awk} の実装が見れます。 | |
4653 | +ほとんどの開発者にとってJavaの実装はSAX APIの権威ある実装です。 | |
4654 | +@cite{Core Web Programming}という本の@uref{http://www.corewebprogramming.com/PDF/ch23.pdf, @b{XML Processing with Java}}というチャプターを見てください。 | |
4402 | 4655 | @pindex @file{outline.awk} |
4656 | +fig:ch2_outline.awk(@pxref{fig:ch2_outline.awk})で提供したスクリプト@file{outline.awk}の実装が見れます。 | |
4403 | 4657 | 両方の実装を比較すれば、スクリプトによるソリューションとコンパイルによるソリューションの利点と欠点が明らかとなるでしょう。 |
4404 | 4658 | |
4405 | 4659 | @ignore |
@@ -4409,159 +4663,162 @@ XMLgawk での XML データの処理の仕方が、SAX API を念頭にデザ | ||
4409 | 4663 | @end ignore |
4410 | 4664 | |
4411 | 4665 | @item |
4412 | -The @uref{http://www.w3.org/TR/2004/REC-xml-20040204/, @b{XML standard's exact specification}} は誰にでも開放されています。 | |
4666 | +The @uref{http://www.w3.org/TR/2004/REC-xml-20040204/, @b{XML standard's exact specification}}は誰にでも開放されています。 | |
4413 | 4667 | しかし、ふと覗いてみたようなユーザには理解しにくいものです。 |
4414 | -消費して消化するのが少し簡単なものが、@uref{http://www.xml.com/axml/testaxml.htm, @cite{Introduction to the Annotated XML Specification}} です。 | |
4415 | -ビギナーはよく、XML ファイルのオプショナルな部分、あるいは必須の部分について全ての概要を得ようと奮闘しています。 | |
4416 | -そういう人たちは、@uref{http://www.mulberrytech.com/quickref/XMLquickref.pdf, @cite{XML Syntax Quick Reference}} をありがたく思うでしょう。 | |
4417 | -この 2 ページのリファレンスカードは、素晴しいグラフィカルな形式でレイアウトされ、XML データにおける DTD の適切な場所を無視@emph{しない}概要を提供している点で注目すべきです。 | |
4668 | +消費して消化するのがもう少し簡単なものが、@uref{http://www.xml.com/axml/testaxml.htm, @cite{Introduction to the Annotated XML Specification}}です。 | |
4669 | +ビギナーはよく、XMLファイルのオプショナルな部分、あるいは、必須の部分について全ての概要を得ようと奮闘しています。 | |
4670 | +そういう人たちは、@uref{http://www.mulberrytech.com/quickref/XMLquickref.pdf, @cite{XML Syntax Quick Reference}}をありがたく思うでしょう。 | |
4671 | +この2ページのリファレンスカードは、素晴しいグラフィカルな形式でレイアウトされ、XMLデータにおけるDTDの適切な場所を無視@emph{しない}概要を提供している点で注目すべきです。 | |
4418 | 4672 | @cindex DTD, Document Type Definition |
4419 | - | |
4420 | 4673 | @end itemize |
4421 | 4674 | |
4675 | + | |
4422 | 4676 | @node Extensible Gawk Language Extensions |
4423 | -@appendix Extensible Gawk 言語拡張 | |
4424 | -@command{xgawk} プログラムは、基本となる @command{gawk} の能力に、少しばかり機能を追加するものです。 | |
4425 | -これは、手短かにまとめたものです。 | |
4677 | +@appendix Extensible Gawk言語拡張 | |
4426 | 4678 | |
4427 | -@enumerate | |
4679 | +@command{xgawk}プログラムは、基本となる@command{gawk}の能力に、少しばかり機能を追加するものです。 | |
4680 | +以下は、手短かにまとめたものです。 | |
4428 | 4681 | |
4682 | +@enumerate | |
4429 | 4683 | @item |
4430 | -共有ライブラリをリンクするための、@option{-l} (@option{--load}) というコマンドラインオプションを新しく追加。 | |
4431 | -これにより、新しい @code{AWKLIBPATH} という環境変数を用いてライブラリを探します (環境に何もなければ、適切なデフォルト値が使われます)。 | |
4684 | +共有ライブラリをリンクするための、@option{-l}(@option{--load})というコマンドラインオプションを新しく追加。 | |
4685 | +これにより、@code{AWKLIBPATH}という新しい環境変数を用いてライブラリを探します(環境に何もなければ、適切なデフォルト値が使われます)。 | |
4432 | 4686 | また、ビルドされたプラットフォーム上の共有ライブラリに適したサフィックスを自動的に追加しようと試みます。 |
4433 | 4687 | |
4434 | 4688 | @item |
4435 | -@command{gawk} のソースコードをインクルードするためのコマンドラインオプション @option{-i} (@option{--include}) を新しく追加。 | |
4436 | -これにより、現在 @option{-f} の引数のために行なっているのと同様に、既存の AWKPATH 環境変数を用いて @command{gawk} コードを探します。 | |
4437 | -また、デフォルトの @file{.awk} サフィックスを付けたり外したりして自動的にこのファイルを見つけようと試みます。 | |
4689 | +@command{gawk}のソースコードをインクルードするためのコマンドラインオプション@option{-i}(@option{--include})を新しく追加。 | |
4690 | +これにより、現在@option{-f}の引数のために行っているのと同様に、既存のAWKPATH環境変数を用いて@command{gawk}コードを探します。 | |
4691 | +また、デフォルトの@file{.awk}サフィックスを付けたり外したりして、自動的にこのファイルを見つけようと試みます。 | |
4438 | 4692 | |
4439 | 4693 | @item |
4440 | -自動的な @file{.awk} サフィックスの付加も処理するように @option{-f} を強化。 | |
4441 | -(@code{AWKPATH} にあるディレクトリそれぞれについて、まずサフィックス無しのファイルをオープンしようと試みて、次に @file{.awk} を追加して試みます。) | |
4694 | +@file{.awk}サフィックスの自動的付加も処理するように@option{-f}を強化。 | |
4695 | +(@code{AWKPATH}にあるディレクトリそれぞれについて、まず、サフィックス無しのファイルをオープンしようと試みて、次に、@file{.awk}を追加して試みます。) | |
4442 | 4696 | |
4443 | 4697 | @item |
4444 | -ソースコード中の @code{@@include} ディレクティブのサポートを追加。 | |
4445 | -これは、現在の @command{igawk} スクリプトで提供されている機能と同じです。 | |
4446 | -これは @command{igawk} で行なわれているものと同じように動作します (新しいコマンドラインオプションの @option{-i} でも同様)。 | |
4447 | -ですので、@command{igawk} スクリプトを削除して、新しい @command{gawk} バイナリへのシンボリックリンクで置き換えることもできます。 | |
4448 | -これで、@file{.awk} サフィックスを自動付加できるので、@command{igawk} の @code{@@include} よりも少しだけパワフルになります。 | |
4698 | +ソースコード中の@code{@@include}ディレクティブのサポートを追加。 | |
4699 | +現在の@command{igawk}スクリプトで提供されている機能と同じです。 | |
4700 | +@command{igawk}で行われているものと同じように動作します(新しいコマンドラインオプションの@option{-i}でも同様)。 | |
4701 | +ですから、@command{igawk}スクリプトを削除して、新しい@command{gawk}バイナリへのシンボリックリンクで置き換えることもできます。 | |
4702 | +これで、@file{.awk}サフィックスを自動付加できるので、@command{igawk}の@code{@@include}よりも少しだけパワフルになります。 | |
4449 | 4703 | |
4450 | 4704 | @item |
4451 | -共有ライブラリをロードするために、ソースコード中の @code{@@load} ディレクティブのサポートを追加。 | |
4452 | -これは、新しいコマンドラインオプションの @option{-l} と同様のことをします。 | |
4705 | +共有ライブラリをロードするために、ソースコード中の@code{@@load}ディレクティブのサポートを追加。 | |
4706 | +新しいコマンドラインオプションの@option{-l}と同様のことをします。 | |
4453 | 4707 | |
4454 | 4708 | @item |
4455 | -共有ライブラリをロードするためのより良いサポートを提供するために内部を強化しています。 | |
4709 | +共有ライブラリをロードするより良いサポートを提供するために内部を強化しています。 | |
4456 | 4710 | |
4457 | 4711 | @item |
4458 | -本家 @command{gawk} にまだ取り込まれていないいくつかのバグ修正が含まれています。 | |
4712 | +本家@command{gawk}にまだ取り込まれていないいくつかのバグ修正が含まれています。 | |
4459 | 4713 | 特に、大きな整数の表示に関する問題が修正されました。 |
4460 | 4714 | |
4461 | 4715 | @item |
4462 | -プラットフォーム特有のパッケージングツールを入れるために package サブディレクトリが一つ追加されました。 | |
4463 | -現在 @acronym{RPM} の spec ファイル @file{xgawk.spec} だけが入っています。 | |
4464 | -これは、tarball から簡単に @acronym{RPM} をビルドするのに使われます (あなたの設定に応じて、@command{rpmbuild -tb xgawk.tar.gz} と同じくらい可能な限り簡単に)。 | |
4716 | +プラットフォーム特有のパッケージングツールを入れるため、packageサブディレクトリが一つ追加されました。 | |
4717 | +現在、@acronym{RPM}のspecファイル@file{xgawk.spec}だけが入っています。 | |
4718 | +これは、tarballから簡単に@acronym{RPM}をビルドするのに使われます(設定に応じて、@command{rpmbuild -tb xgawk.tar.gz}と同じくらい可能な限り簡単に)。 | |
4465 | 4719 | 他のプラットフォームに対するパッケージングツールの提案を歓迎します。 |
4466 | - | |
4467 | 4720 | @end enumerate |
4468 | -Extensible GNU Awk のインストールのプロセスもいくつか新しいオプションを追加しました。 | |
4469 | -@command{xgawk} のインストレーション処理は、決して @command{gawk} の前のインストレーションを損なったりしません。 | |
4470 | -インストールされるファイルは全て、本家 @command{gawk} によってインストールされるファイルとは明確に別の名前を持っています。 | |
4471 | -ですので、どちらのものもお互いの邪魔をすることなく共存できます。 | |
4721 | + | |
4722 | +Extensible GNU Awkのインストールのロセスも、いくつか新しいオプションを追加しました。 | |
4723 | +@command{xgawk}のインストール処理は、@command{gawk}の前のインストールを決して損なったりしません。 | |
4724 | +インストールされるファイルは全て、本家@command{gawk}によってインストールされるファイルとは明確に別の名前を持っています。 | |
4725 | +ですから、どちらのものもお互いの邪魔をすることなく共存できます。 | |
4472 | 4726 | |
4473 | 4727 | @enumerate |
4474 | 4728 | @item |
4475 | -本家 @command{gawk} の @option{--enable-switch} オプションはデフォルトで有効になっています。 | |
4729 | +本家@command{gawk}の@option{--enable-switch}オプションはデフォルトで有効になっています。 | |
4730 | + | |
4476 | 4731 | @item |
4477 | -@option{--enable-gawk} は新しいオプションで、そのデフォルトは @option{no} です。 | |
4478 | -このオプションを有効にすると、@command{xgawk} に加えて、@command{gawk} と @command{awk}、そして @command{igawk} の実行ファイルへのリンクをインストールします。 | |
4479 | -このオプションは、本家の @command{gawk} をインストールしたくない場合に役立ちます。 | |
4480 | -しかし、@command{xgawk} の前に、本家 @command{gawk} が既にインストールされている場合は、これらのリンクはインストールされません。 | |
4481 | -ですので、このオプションは効果を持ちません。 | |
4732 | +@option{--enable-gawk}は新しいオプションです。 | |
4733 | +デフォルトは@option{no}です。 | |
4734 | +このオプションを有効にすると、@command{xgawk}に加えて、@command{gawk}と@command{awk}、そして、@command{igawk}の実行ファイルへのリンクをインストールします。 | |
4735 | +本家の@command{gawk}をインストールしたくない場合に役立ちます。 | |
4736 | +しかし、@command{xgawk}の前に、本家@command{gawk}が既にインストールされている場合は、これらのリンクはインストールされません。 | |
4737 | +ですから、このオプションは効果を持ちません。 | |
4482 | 4738 | |
4483 | 4739 | @item |
4484 | 4740 | @cindex Cygwin |
4485 | -新しいオプション @option{--enable-static-extensions} (デフォルトで @option{no}) は、実行ファイルに静的にリンクされた拡張ライブラリを使うよう強制します。 | |
4486 | -Cygwin のようなプラットフォームでは、このオプションは拡張ライブラリと一緒に動作させるための唯一の方法です。 | |
4487 | -こういったプラットフォームは動的ライブラリの扱いに問題があります。 | |
4741 | +新しいオプション@option{--enable-static-extensions}(デフォルトで@option{no})は、実行ファイルに静的にリンクされた拡張ライブラリを使うよう強制します。 | |
4742 | +Cygwinのようなプラットフォームでは、このオプションは拡張ライブラリと一緒に動作させるための唯一の方法です。 | |
4743 | +こういったプラットフォームは、動的ライブラリの扱いに問題があります。 | |
4488 | 4744 | |
4489 | 4745 | @item |
4490 | 4746 | デフォルトでは、必要とされるライブラリがそのプラットフォーム上に存在するならば、全ての拡張ライブラリが構築されます。 |
4491 | -オプションの @option{--disable-xml}、@option{--disable-pgsql}、@option{--disable-mpfr}、@option{--disable-gd} が、特定の拡張を構築しないように切り替えるのに使うことができます。 | |
4747 | +オプションの@option{--disable-xml}、@option{--disable-pgsql}、@option{--disable-mpfr}、@option{--disable-gd}は、特定の拡張を構築しないように切り替えるのに使うことができます。 | |
4492 | 4748 | |
4493 | 4749 | @item |
4494 | -オプションの @option{--with-expat=@emph{PATH}}、@option{--with-libpq=@emph{PATH}}、@option{--with-mpfr=@emph{PATH}}、@option{--with-gd=@emph{PATH}} は、ライブラリの使用法が特定のパスへインストールされるのを許可します。 | |
4750 | +オプションの@option{--with-expat=@emph{PATH}}、@option{--with-libpq=@emph{PATH}}、@option{--with-mpfr=@emph{PATH}}、@option{--with-gd=@emph{PATH}}は、ライブラリの使用法が特定のパスへインストールされるのを許可します。 | |
4495 | 4751 | @end enumerate |
4496 | 4752 | |
4497 | -@node PostgreSQL API Reference | |
4498 | -@appendix PostgreSQL API リファレンス | |
4499 | 4753 | |
4754 | +@node PostgreSQL API Reference | |
4755 | +@appendix PostgreSQL APIリファレンス | |
4500 | 4756 | @pindex PostgreSQL |
4501 | 4757 | @cindex database |
4502 | 4758 | @cindex pgsql |
4503 | 4759 | |
4504 | -ここで説明する関数は、@uref{//http://www.postgresql.org/docs/8.0/interactive/libpq.html} で記されているように、libpq C API を明かにするためのものです。 | |
4505 | -このドキュメンテーションは libpq ドキュメンテーションと合わせることで初めて理解できます。 | |
4760 | +ここで説明する関数は、@uref{//http://www.postgresql.org/docs/8.0/interactive/libpq.html}で記されているように、libpq C APIを明らかにするためのものです。 | |
4761 | +このドキュメントは、libpqドキュメントと合わせることで初めて理解できます。 | |
4506 | 4762 | |
4507 | -この API は、@option{-l pgsql} というコマンライン引数で @command{xgawk} を起動するか、スクリプトの中に @code{@@load pgsql} を挿入することで使うことができます。 | |
4763 | +このAPIは、@option{-l pgsql}というコマンライン引数で@command{xgawk}を起動するか、スクリプトの中に@code{@@load pgsql}を挿入することで使うことができます。 | |
4508 | 4764 | |
4509 | -オプショナルなパラメータは角括弧@w{ ([ ])} で閉じています。 | |
4765 | +オプショナルなパラメータは角括弧@w{([ ])}で閉じています。 | |
4510 | 4766 | |
4511 | 4767 | @menu |
4512 | -* データベース接続制御関数:: | |
4513 | -* 接続ステータス関数:: | |
4514 | -* コマンド実行関数:: | |
4515 | -* 非同期コマンド処理:: | |
4516 | -* コピーデータ送受信関数:: | |
4517 | -* 問い合わせ結果情報の取得:: | |
4518 | -* 配列を使った問い合わせ結果の取得のための高レベル関数:: | |
4768 | +* Database Connection Control Functions:: | |
4769 | +* Connection Status Functions:: | |
4770 | +* Command Execution Functions:: | |
4771 | +* Asynchronous Command Processing:: | |
4772 | +* Functions for Sending and Receiving COPY Data:: | |
4773 | +* Retrieving Query Result Information:: | |
4774 | +* Higher-level Functions to Retrieve Query Results Using Arrays:: | |
4519 | 4775 | @end menu |
4520 | 4776 | |
4777 | + | |
4521 | 4778 | @node Database Connection Control Functions |
4522 | 4779 | @appendixsec データベース接続制御関数 |
4523 | 4780 | |
4524 | 4781 | @table @code |
4525 | - | |
4526 | 4782 | @cindex @code{pg_connect} pgsql extension function |
4527 | 4783 | @cindex @code{PQconnectdb} libpq function |
4528 | 4784 | @item pg_connect(@r{[}@var{conninfo}@r{]}) |
4529 | -データベースの接続を始める。 | |
4530 | -引数の文字列 @var{conninfo} は @code{PQconnectdb} 関数へ渡されます。 | |
4531 | -成功すれば、ユニークでオペークな接続ハンドルが返されます。 | |
4532 | -失敗すれば、ヌル文字列 (@code{""}) が返され、@code{ERRNO} がセットされます。 | |
4785 | +データベースの接続を始めます。 | |
4786 | +引数の文字列@var{conninfo}は@code{PQconnectdb}関数へ渡されます。 | |
4787 | +成功すれば、ユニークでopaqueな接続ハンドルが返されます。 | |
4788 | +失敗すれば、ヌル文字列(@code{""})が返され、@code{ERRNO}がセットされます。 | |
4533 | 4789 | |
4534 | 4790 | @cindex @code{pg_connectdb} pgsql extension function |
4535 | 4791 | @item pg_connectdb(@r{[}@var{conninfo}@r{]}) |
4536 | -この関数は単に @code{pg_connect} の別名です。 | |
4792 | +この関数は単に@code{pg_connect}の別名です。 | |
4537 | 4793 | |
4538 | 4794 | @cindex @code{pg_disconnect} pgsql extension function |
4539 | 4795 | @cindex @code{PQfinish} libpq function |
4540 | 4796 | @item pg_disconnect(@var{conn}) |
4541 | -@var{conn} で示されるハンドルで @code{PQfinish} 関数を呼び出します。 | |
4542 | -@var{conn} ハンドルは、その前に @code{pg_connect} を呼び出したことによって戻されたものでなければなりません。 | |
4543 | -このハンドルが見つからなければ、-1 が返され、@code{ERRNO} がセットされます。 | |
4544 | -成功すれば、0 が返され、@var{conn} と関連付けられた接続はもはや有効ではありません。 | |
4797 | +@var{conn}で示されるハンドルを使って@code{PQfinish}関数を呼び出します。 | |
4798 | +@var{conn}ハンドルは、その前に@code{pg_connect}を呼び出したことによって返されたものでなければなりません。 | |
4799 | +このハンドルが見つからなければ、-1が返され、@code{ERRNO}がセットされます。 | |
4800 | +成功すれば、0が返され、@var{conn}と関連付けられた接続はもはや有効ではありません。 | |
4545 | 4801 | |
4546 | 4802 | @cindex @code{pg_finish} pgsql extension function |
4547 | 4803 | @item pg_finish(@var{conn}) |
4548 | -この関数は単に @code{pg_disconnect} の別名です。 | |
4804 | +この関数は単に@code{pg_disconnect}の別名です。 | |
4549 | 4805 | |
4550 | 4806 | @cindex @code{pg_reset} pgsql extension function |
4551 | 4807 | @cindex @code{PQreset} libpq function |
4552 | 4808 | @item pg_reset(@var{conn}) |
4553 | -@var{conn} で示されるハンドルで @code{PQreset} 関数を呼び出します。 | |
4554 | -@var{conn} ハンドルは、その前に @code{pg_connect} を呼び出したことによって戻されたものでなければなりません。 | |
4555 | -このハンドルが見つからなければ、-1 が返され、@code{ERRNO} がセットされます。 | |
4556 | -そうでなければ、@code{PQreset} が呼び出されます。 | |
4557 | -もし @code{PQstatus} が返す次の値が @code{CONNECTION_OK} ならば、その時は 0 が返され、そうでなければ -1 返されて、@code{ERRNO} がセットされます。 | |
4809 | +@var{conn}で示されるハンドルを使って、@code{PQreset}関数を呼び出します。 | |
4810 | +@var{conn}ハンドルは、その前に@code{pg_connect}を呼び出したことによって戻されたものでなければなりません。 | |
4811 | +このハンドルが見つからなければ、-1が返され、@code{ERRNO}がセットされます。 | |
4812 | +そうでなければ、@code{PQreset}が呼び出されます。 | |
4813 | +もし、@code{PQstatus}が返す次の値が@code{CONNECTION_OK}ならば、0が返されます。 | |
4814 | +そうでなければ、-1返されて、@code{ERRNO}がセットされます。 | |
4558 | 4815 | |
4559 | 4816 | @cindex @code{pg_reconnect} pgsql extension function |
4560 | 4817 | @item pg_reconnect(@var{conn}) |
4561 | -この関数は単に @code{pg_reset} の別名です。 | |
4562 | - | |
4818 | +この関数は単に@code{pg_reset}の別名です。 | |
4563 | 4819 | @end table |
4564 | 4820 | |
4821 | + | |
4565 | 4822 | @node Connection Status Functions |
4566 | 4823 | @appendixsec 接続ステータス関数 |
4567 | 4824 |
@@ -4570,137 +4827,138 @@ Cygwin のようなプラットフォームでは、このオプションは拡 | ||
4570 | 4827 | @cindex @code{pg_errormessage} pgsql extension function |
4571 | 4828 | @cindex @code{PQerrorMessage} libpq function |
4572 | 4829 | @item pg_errormessage(@var{conn}) |
4573 | -この関数は指定された接続について @code{PQerrorMessage} を呼び出し、その結果を返します。 | |
4574 | -接続が見つからないときは、戻り値はヌル文字列 (@code{""}) で、@code{ERRNO} がセットされます。 | |
4830 | +この関数は指定された接続について@code{PQerrorMessage}を呼び出し、その結果を返します。 | |
4831 | +接続が見つからない時は、戻り値はヌル文字列(@code{""})で、@code{ERRNO}がセットされます。 | |
4575 | 4832 | |
4576 | 4833 | @end table |
4577 | 4834 | |
4835 | + | |
4578 | 4836 | @node Command Execution Functions |
4579 | 4837 | @appendixsec コマンド実行関数 |
4580 | 4838 | |
4581 | 4839 | @table @code |
4582 | - | |
4583 | 4840 | @cindex @code{pg_getresult} pgsql extension function |
4584 | 4841 | @cindex @code{PQgetResult} libpq function |
4585 | 4842 | @item pg_getresult(@var{conn}) |
4586 | -接続が見つからなければ、ヌル文字列 (@code{""}) が返され、@code{ERRNO} がセットされます。 | |
4587 | -そうでなければ、@code{PQgetResult} が指定された接続について呼び出されます。 | |
4588 | -それが NULL を返すならば、ヌル文字列 (@code{""}) を返します。 | |
4589 | -返された @code{PGresult} が非 NULL ならば、戻り値は、@code{PQresultStatus(PQgetResult(@var{conn}))} の値に依存します。 | |
4843 | +接続が見つからなければ、ヌル文字列(@code{""})が返され、@code{ERRNO}がセットされます。 | |
4844 | +そうでなければ、@code{PQgetResult}が、指定された接続に対して呼び出されます。 | |
4845 | +それがNULLを返すならば、ヌル文字列(@code{""})を返します。 | |
4846 | +返された@code{PGresult}が非NULLならば、戻り値は、@code{PQresultStatus(PQgetResult(@var{conn}))}の値に依存します。 | |
4590 | 4847 | 以下の通りです。 |
4591 | 4848 | |
4592 | 4849 | @table @code |
4593 | - | |
4594 | 4850 | @item PGRES_TUPLES_OK |
4595 | -この関数は、SQL クエリによって返される行へアクセスするために使われる文字列ハンドルを返します。 | |
4596 | -文字列ハンドルのフォーマットは @code{TUPLES <# of rows> <unique identifier>} です。 | |
4597 | -返されるハンドル 2 番目のワードを取り出すか、@code{pg_ntuples} 関数を呼び出すことで行数を知ることができます。 | |
4598 | -返された文字列ハンドルは、返されたデータをその後取り出すために使われる @code{PGresult} ポインタにマップされています。 | |
4851 | +この関数は、SQLクエリによって返される行へアクセスするために使われる文字列ハンドルを返します。 | |
4852 | +文字列ハンドルのフォーマットは、@code{TUPLES <# of rows> <unique identifier>}です。 | |
4853 | +返されるハンドルの2番目のワードを取り出すか、@code{pg_ntuples}関数を呼び出すことで行数を知ることができます。 | |
4854 | +返された文字列ハンドルは、返されたデータをその後取り出すために使われる@code{PGresult}ポインタにマップされています。 | |
4599 | 4855 | |
4600 | 4856 | @item PGRES_COMMAND_OK |
4601 | -まず、@code{PQcmdTulples} を呼び出し、次に @code{OK <result of PQcmdTuples>} という文字列を返します。 | |
4602 | -返されるデータが無くなれば、@code{PQclear} を自動的に呼び出します。 | |
4857 | +まず、@code{PQcmdTulples}を呼び出します。 | |
4858 | +次に、@code{OK <result of PQcmdTuples>}という文字列を返します。 | |
4859 | +返されるデータが無くなれば、@code{PQclear}を自動的に呼び出します。 | |
4603 | 4860 | |
4604 | 4861 | @item PGRES_EMPTY_QUERY |
4605 | -これは @code{PGRES_COMMAND_OK} と同じやり方で処理されます。 | |
4862 | +これは、@code{PGRES_COMMAND_OK}と同じやり方で処理されます。 | |
4606 | 4863 | |
4607 | 4864 | @item PGRES_COPY_IN |
4608 | -返される文字列は @code{COPY_IN <PQnfields(res)> @{BINARY|TEXT@}} というフォーマットです。 | |
4609 | -返されるデータが無くなれば、@code{PQclear} を自動的に呼び出します。 | |
4610 | -ユーザのコードが続けて @code{pg_putcopydata} を呼び出して、サーバに大量のデータを送信するかもしれません (そして @code{pg_putcopyend} を使って転送を終了します)。 | |
4865 | +返される文字列は、@code{COPY_IN <PQnfields(res)> @{BINARY|TEXT@}}というフォーマットです。 | |
4866 | +返されるデータが無くなれば、@code{PQclear}を自動的に呼び出します。 | |
4867 | +ユーザのコードが、続けて、@code{pg_putcopydata}を呼び出して、サーバに大量のデータを送信するかもしれません(そして、@code{pg_putcopyend}を使って転送を終了します)。 | |
4611 | 4868 | |
4612 | 4869 | @item PGRES_COPY_OUT |
4613 | -返される文字列は @code{COPY_OUT <PQnfields(res)> @{BINARY|TEXT@}} です。 | |
4614 | -返されるデータが無くなれば、@code{PQclear} を自動的に呼び出します。 | |
4615 | -ユーザのコードは、ヌル文字列 (@code{""}) を返すまで、@code{pg_getcopydata} を呼び出し続けるべきです。 | |
4870 | +返される文字列は、@code{COPY_OUT <PQnfields(res)> @{BINARY|TEXT@}}です。 | |
4871 | +返されるデータが無くなれば、@code{PQclear}を自動的に呼び出します。 | |
4872 | +ユーザのコードは、ヌル文字列(@code{""})を返すまで、@code{pg_getcopydata}を呼び出し続けるべきです。 | |
4616 | 4873 | |
4617 | 4874 | @item default (unhandled value) |
4618 | -これは処理されていない戻り値ですので、標準化されたエラー文字列を @code{ERROR @r{[}BADCONN @r{]}<status>} というフォーマットで返します。 | |
4619 | -ここで、@code{BADCONN} は、@code{PQstatus(conn)} が @code{CONNECTION_OK} と等しくない場合に含まれます。 | |
4620 | -また、その次の文字列は @code{PQresStatus(PQresultStatus(res))} の呼び出しの結果です。 | |
4621 | -そして、@code{ERRNO} を、 @code{PQresultErrorMessage(res)} によって返される文字列にセットします。 | |
4622 | -返されるデータが無くなれば、@code{PQclear} を自動的に呼び出します。 | |
4623 | - | |
4875 | +これは、処理されていない戻り値です。 | |
4876 | +標準化されたエラー文字列を、@code{ERROR @r{[}BADCONN @r{]}<status>}というフォーマットで返します。 | |
4877 | +ここで、@code{BADCONN}は、@code{PQstatus(conn)}が@code{CONNECTION_OK}と等しくない場合に含まれます。 | |
4878 | +また、その次の文字列は@code{PQresStatus(PQresultStatus(res))}の呼び出しの結果です。 | |
4879 | +そして、@code{PQresultErrorMessage(res)}によって返される文字列に@code{ERRNO}をセットします。 | |
4880 | +返されるデータが無くなれば、@code{PQclear}を自動的に呼び出します。 | |
4624 | 4881 | @end table |
4625 | 4882 | |
4626 | 4883 | @cindex @code{pg_clear} pgsql extension function |
4627 | 4884 | @cindex @code{PQclear} libpq function |
4628 | 4885 | @item pg_clear(@var{res}) |
4629 | -結果のハンドルが見付からなければ -1 が返され、@code{ERRNO} がセットされます。 | |
4630 | -そうでなければ、@code{PQclear(res)} が呼び出され、0 が返されます。 | |
4886 | +結果のハンドルが見付からなければ-1が返され、@code{ERRNO}がセットされます。 | |
4887 | +そうでなければ、@code{PQclear(res)}が呼び出され、0が返されます。 | |
4631 | 4888 | |
4632 | 4889 | @cindex @code{pg_exec} pgsql extension function |
4633 | 4890 | @cindex @code{PQexec} libpq function |
4634 | 4891 | @item pg_exec(@var{conn}, @var{command}) |
4635 | -接続が見つからなければ、ヌル文字列 (@code{""}) が返され、@code{ERRNO} がセットされます。 | |
4636 | -でなければ、@code{PQexec} が @var{command} 文字列で呼び出されます。 | |
4637 | -@code{PQexec} が NULL を返す場合、戻り値は @code{"ERROR "} で始まります。 | |
4638 | -@code{PQstatus} が @code{CONNECTION_OK} を返さない場合は、戻り値の次のワードが @code{"BADCONN"} となっています。 | |
4639 | -それから、@code{PQresStatus(PQresultStatus(NULL))} の呼び出し結果がその文字列に追加されます。 | |
4640 | -加えて、@code{ERRNO} が @code{PQerrorMessage} によって返される文字列にセットされます。 | |
4641 | -一方、@code{PQexec} が NULL を返さない場合は、結果は @code{pg_getresult} によって返される標準フォーマットになります。 | |
4892 | +接続が見つからなければ、ヌル文字列(@code{""})が返され、@code{ERRNO}がセットされます。 | |
4893 | +でなければ、@code{PQexec}が、@var{command}文字列で呼び出されます。 | |
4894 | +@code{PQexec}がNULLを返す場合、戻り値は@code{"ERROR "}で始まります。 | |
4895 | +@code{PQstatus}が@code{CONNECTION_OK}を返さない場合は、戻り値の次のワードが@code{"BADCONN"}となっています。 | |
4896 | +それから、@code{PQresStatus(PQresultStatus(NULL))}の呼び出し結果がその文字列に追加されます。 | |
4897 | +加えて、@code{ERRNO}は、@code{PQerrorMessage}によって返される文字列にセットされます。 | |
4898 | +一方、@code{PQexec}がNULLを返さない場合は、結果は、@code{pg_getresult}によって返される標準フォーマットになります。 | |
4642 | 4899 | |
4643 | 4900 | @cindex @code{pg_execparams} pgsql extension function |
4644 | 4901 | @cindex @code{PQexecParams} libpq function |
4645 | 4902 | @item pg_execparams(@var{conn}, @var{command}, @var{nParams} @r{[}, @var{paramValues}@r{]}) |
4646 | -接続が見つからない場合、あるいは @var{nParams} が負の場合は、ヌル文字列 (@code{""}) が返され、@code{ERRNO} がセットされます。 | |
4647 | -そうでなければ、@code{paramTypes}、@code{paramLengths}、そして@code{ParamFormats} の各引数が NULL にセットされ、それらの引数で @code{PQexecParams} が呼び出されます。 | |
4648 | -@code{paramValues} 配列は、@code{$n} と一致する値を @code{paramValues[n]} として探すのに使われます。 | |
4649 | -戻り値は @code{pg_exec} の場合と同じです。 | |
4903 | +接続が見つからない場合、あるいは、@var{nParams}が負の場合は、ヌル文字列(@code{""})が返され、@code{ERRNO}がセットされます。 | |
4904 | +そうでなければ、@code{paramTypes}、@code{paramLengths}、@code{ParamFormats}の各引数がNULLにセットされ、それらの引数で@code{PQexecParams}が呼び出されます。 | |
4905 | +@code{paramValues}配列は、@code{$n}と一致する値を、@code{paramValues[n]}として探すのに使われます。 | |
4906 | +戻り値は、@code{pg_exec}の場合と同じです。 | |
4650 | 4907 | |
4651 | 4908 | @cindex @code{pg_prepare} pgsql extension function |
4652 | 4909 | @cindex @code{PQprepare} libpq function |
4653 | 4910 | @item pg_prepare(@var{conn}, @var{command}) |
4654 | -接続が見つからない場合は、ヌル文字列 (@code{""}) が返され、@code{ERRNO} がセットされます。 | |
4655 | -そうでなければ、@code{PQprepare} が @var{command} 文字列で呼び出されます。 | |
4656 | -@code{PQprepare} が NULL を返す場合、あるいは @code{PQresultStatus(result) != PGRES_COMMAND_OK} の場合は、この関数はヌル文字列 @code{""} を返し、@code{ERRNO} をセットします。 | |
4657 | -そうでない場合、成功すれば、@code{pg_execprepared} や @code{pg_sendqueryprepared} で使えるオペークなステートメントハンドルが返されます。 | |
4911 | +接続が見つからない場合は、ヌル文字列(@code{""})が返され、@code{ERRNO}がセットされます。 | |
4912 | +そうでなければ、@code{PQprepare}が@var{command}文字列で呼び出されます。 | |
4913 | +@code{PQprepare}がNULLを返す場合、あるいは、@code{PQresultStatus(result) != PGRES_COMMAND_OK}の場合は、この関数はヌル文字列@code{""}を返し、@code{ERRNO}をセットします。 | |
4914 | +そうでない場合、成功すれば、@code{pg_execprepared}や@code{pg_sendqueryprepared}で使えるopaqueなステートメントハンドルが返されます。 | |
4658 | 4915 | |
4659 | 4916 | @cindex @code{pg_execprepared} pgsql extension function |
4660 | 4917 | @cindex @code{PQexecParams} libpq function |
4661 | 4918 | @item pg_execprepared(@var{conn}, @var{stmtName}, @var{nParams} @r{[}, @var{paramValues}@r{]}) |
4662 | -この関数は、SQL コマンドの代わりに 2 番目の引数として、前もっと用意されているステートメントハンドルを必要とするということを除いて、@code{pg_execparams} と同様に動作します。 | |
4663 | - | |
4919 | +この関数は、@code{pg_execparams}と同様に動作します。 | |
4920 | +ただし、SQLコマンドの代わりに、2番目の引数として、予め用意されているステートメントハンドルを必要とします。 | |
4664 | 4921 | @end table |
4665 | 4922 | |
4923 | + | |
4666 | 4924 | @node Asynchronous Command Processing |
4667 | 4925 | @appendixsec 非同期コマンド処理 |
4668 | 4926 | |
4669 | 4927 | @table @code |
4670 | - | |
4671 | 4928 | @cindex @code{pg_sendquery} pgsql extension function |
4672 | 4929 | @cindex @code{PQsendQuery} libpq function |
4673 | 4930 | @item pg_sendquery(@var{conn}, @var{command}) |
4674 | -接続が見つからなければ、0 が返され、@code{ERRNO} がセットされます。 | |
4675 | -そうでない場合、指定された @var{command} で @code{PQsendQuery} が呼び出され、その結果が返されます (失敗の時は 0、成功の時は 1 のはずです)。 | |
4676 | -戻り値が 0 の場合は、@code{ERRNO} がセットされます。 | |
4677 | -結果を取得するには @code{pg_getresult} を呼び出してください。 | |
4678 | -ヌル文字列 (@code{""}) を返すまで @code{pg_getresult} を呼び出し続けなければなりません。 | |
4931 | +接続が見つからなければ、0が返され、@code{ERRNO}がセットされます。 | |
4932 | +そうでない場合、指定された@var{command}で@code{PQsendQuery}が呼び出され、その結果が返されます(失敗の時は0、成功の時は1です)。 | |
4933 | +戻り値が0の場合は、@code{ERRNO}がセットされます。 | |
4934 | +結果を取得するには@code{pg_getresult}を呼び出してください。 | |
4935 | +ヌル文字列(@code{""})を返すまで@code{pg_getresult}を呼び出し続けなければなりません。 | |
4679 | 4936 | |
4680 | 4937 | @cindex @code{pg_sendqueryparams} pgsql extension function |
4681 | 4938 | @cindex @code{PQsendQueryParams} libpq function |
4682 | 4939 | @item pg_sendqueryparams(@var{conn}, @var{command}, @var{nParams} @r{[}, @var{paramValues}@r{]}) |
4683 | -接続が見つからなければ、あるいは @var{nParams} が負であれば、0 が返され、@code{ERRNO} がセットされます。 | |
4684 | -そうでない場合、NULL にセットされた @code{paramTypes}、@code{paramLengths}、@code{paramFormats} 引数を付けて @code{PQsendQueryParams} が呼び出され、その結果が返されます。 | |
4685 | -@code{pg_execparams} と同様に、@code{$n} に一致する値は @code{paramValues[n]} の中にあります。 | |
4686 | -もし戻り値が 0 ならば、@code{ERRNO} がセットされます。 | |
4940 | +接続が見つからなければ、あるいは、@var{nParams}が負であれば、0が返され、@code{ERRNO}がセットされます。 | |
4941 | +そうでない場合、NULLにセットされた@code{paramTypes}、@code{paramLengths}、@code{paramFormats}引数を付けて@code{PQsendQueryParams}が呼び出され、その結果が返されます。 | |
4942 | +@code{pg_execparams}と同様に、@code{$n}に一致する値は@code{paramValues[n]}の中にあります。 | |
4943 | +もし、戻り値が0ならば、@code{ERRNO}がセットされます。 | |
4687 | 4944 | |
4688 | 4945 | @cindex @code{pg_sendprepare} pgsql extension function |
4689 | 4946 | @cindex @code{PQsendPrepare} libpq function |
4690 | 4947 | @item pg_sendprepare(@var{conn}, @var{command}) |
4691 | -接続が見つからなければ、ヌル文字列 (@code{""}) が返され、@code{ERRNO} がセットされます。 | |
4692 | -そうでない場合、@var{command} 文字列で @code{PQsetPrepare} が呼び出されます。 | |
4693 | -@code{PQsendPrepare} が 0 を返すならば、この関数はヌル文字列 @code{""} を返し、@code{ERRNO} をセットします。 | |
4694 | -そうでなければ、@code{pg_sendqueryprepared} や @code{pg_execprepared} で利用できる opaque なステートメントハンドルが返されます。 | |
4695 | -コマンドが成功して完了したかどうかを確かめるには @code{pg_getresult} を呼び出してください。 | |
4948 | +接続が見つからなければ、ヌル文字列(@code{""})が返され、@code{ERRNO}がセットされます。 | |
4949 | +そうでない場合、@var{command}文字列で@code{PQsetPrepare}が呼び出されます。 | |
4950 | +@code{PQsendPrepare}が0を返すならば、この関数はヌル文字列@code{""}を返し、@code{ERRNO}をセットします。 | |
4951 | +そうでなければ、@code{pg_sendqueryprepared}や@code{pg_execprepared}で利用できるopaqueなステートメントハンドルが返されます。 | |
4952 | +コマンドが成功して完了したかどうかを確かめるには@code{pg_getresult}を呼び出してください。 | |
4696 | 4953 | |
4697 | 4954 | @cindex @code{pg_sendqueryprepared} pgsql extension function |
4698 | 4955 | @cindex @code{PQsendQueryPrepared} libpq function |
4699 | 4956 | @item pg_sendqueryprepared(@var{conn}, @var{stmtName}, @var{nParams} @r{[}, @var{paramValues}@r{]}) |
4700 | -この関数は、SQL コマンドの代わりに 2 番目の引数として予め用意しておいたステートメントハンドルを必要とすることを除いて、@code{pg_sendqueryparams} と同じように動作します。 | |
4701 | - | |
4957 | +この関数は、@code{pg_sendqueryparams}と同じように動作します。 | |
4958 | +ただし、SQLコマンドの代わりに、2番目の引数として、予め用意しておいたステートメントハンドルを必要とします。 | |
4702 | 4959 | @end table |
4703 | 4960 | |
4961 | + | |
4704 | 4962 | @node Functions for Sending and Receiving COPY Data |
4705 | 4963 | @appendixsec コピーデータ送受信関数 |
4706 | 4964 |
@@ -4709,28 +4967,29 @@ Cygwin のようなプラットフォームでは、このオプションは拡 | ||
4709 | 4967 | @cindex @code{pg_putcopydata} pgsql extension function |
4710 | 4968 | @cindex @code{PQputCopyData} libpq function |
4711 | 4969 | @item pg_putcopydata(@var{conn}, @var{buffer}) |
4712 | -接続が見つからなければ、-1 が返され、@code{ERRNO} がセットされます。 | |
4713 | -そうでない場合、@var{buffer} 引数で @code{PQputCopyData} が呼び出され、その値が返されます。 | |
4714 | -もし、@code{PQputCopyData} が -1 を返すならば、@code{ERRNO} がセットされます。 | |
4970 | +接続が見つからなければ、-1が返され、@code{ERRNO}がセットされます。 | |
4971 | +そうでない場合、@var{buffer}引数で@code{PQputCopyData}が呼び出され、その値が返されます。 | |
4972 | +もし、@code{PQputCopyData}が-1を返すならば、@code{ERRNO}がセットされます。 | |
4715 | 4973 | |
4716 | 4974 | @cindex @code{pg_putcopyend} pgsql extension function |
4717 | 4975 | @cindex @code{PQputCopyEnd} libpq function |
4718 | 4976 | @item pg_putcopyend(@var{conn} @r{[}, @var{errormsg}@r{]}) |
4719 | -接続が見つからなければ、-1 が返され、@code{ERRNO} がセットされます。 | |
4720 | -そうでない場合、もしあればオプショナルな @var{errormsg} 引数で @code{PQputCopyEnd} が呼び出され、その値が返されます。 | |
4721 | -もし @code{PQputCopyEnd} が -1 を返すならば、@code{ERRNO} がセットされます。 | |
4977 | +接続が見つからなければ、-1が返され、@code{ERRNO}がセットされます。 | |
4978 | +そうでない場合、もしあれば、オプショナルな@var{errormsg}引数で@code{PQputCopyEnd}が呼び出され、その値が返されます。 | |
4979 | +もし、@code{PQputCopyEnd}が-1を返すならば、@code{ERRNO}がセットされます。 | |
4722 | 4980 | |
4723 | 4981 | @cindex @code{pg_getcopydata} pgsql extension function |
4724 | 4982 | @cindex @code{PQgetCopyData} libpq function |
4725 | 4983 | @item pg_getcopydata(@var{conn}) |
4726 | -接続が見つからなければ、ヌル文字列 (@code{""}) が返され、@code{ERRNO} がセットされます。 | |
4727 | -そうでない場合、@code{FALSE} にセットされた @var{async} 引数で @code{PQgetCopyData} が呼び出されます。 | |
4728 | -もし @code{PQgetCopyData} が -1 を返すならば、そのコピーが行なわれ、ヌル文字列 (@code{""}) が返されます (@code{COPY} コマンドの最終的な結果のステータスを取得するために、ユーザは @code{pg_getresult} を呼び出さなければなりません)。 | |
4729 | -戻り値が、エラーを示す -2 であれば、ヌル文字列 (@code{""}) が返され、@code{ERRNO} がセットされます。 | |
4984 | +接続が見つからなければ、ヌル文字列(@code{""})が返され、@code{ERRNO}がセットされます。 | |
4985 | +そうでない場合、@code{FALSE}にセットされた@var{async}引数で@code{PQgetCopyData}が呼び出されます。 | |
4986 | +もし、@code{PQgetCopyData}が-1を返すならば、そのコピーが行われ、ヌル文字列(@code{""})が返されます(@code{COPY}コマンドの最終的な結果のステータスを取得するために、ユーザは、@code{pg_getresult}を呼び出さなければなりません)。 | |
4987 | +戻り値が、エラーを示す-2であれば、ヌル文字列(@code{""})が返され、@code{ERRNO}がセットされます。 | |
4730 | 4988 | そうでなければ、取得された行が返されます。 |
4731 | 4989 | |
4732 | 4990 | @end table |
4733 | 4991 | |
4992 | + | |
4734 | 4993 | @node Retrieving Query Result Information |
4735 | 4994 | @appendixsec 問い合わせ結果情報の取得 |
4736 | 4995 |
@@ -4739,35 +4998,36 @@ Cygwin のようなプラットフォームでは、このオプションは拡 | ||
4739 | 4998 | @cindex @code{pg_nfields} pgsql extension function |
4740 | 4999 | @cindex @code{PQnfields} libpq function |
4741 | 5000 | @item pg_nfields(@var{res}) |
4742 | -引数 @var{res} の結果ハンドルが見つからなければ、-1 が返され、@code{ERRNO} がセットされます。 | |
4743 | -そうでなければ、@code{PQnfields(res)} の値が返されます。 | |
5001 | +引数@var{res}の結果ハンドルが見つからなければ、-1が返され、@code{ERRNO}がセットされます。 | |
5002 | +そうでなければ、@code{PQnfields(res)}の値が返されます。 | |
4744 | 5003 | |
4745 | 5004 | @cindex @code{pg_ntuples} pgsql extension function |
4746 | 5005 | @cindex @code{PQntuples} libpq function |
4747 | 5006 | @item pg_ntuples(@var{res}) |
4748 | -引数 @var{res} の結果ハンドルが見つからなければ、-1 が返され、@code{ERRNO} がセットされます。 | |
4749 | -そうでなければ、@code{PQntuples(res)} の値が返されます。 | |
5007 | +引数@var{res}の結果ハンドルが見つからなければ、-1が返され、@code{ERRNO}がセットされます。 | |
5008 | +そうでなければ、@code{PQntuples(res)}の値が返されます。 | |
4750 | 5009 | |
4751 | 5010 | @cindex @code{pg_fname} pgsql extension function |
4752 | 5011 | @cindex @code{PQfname} libpq function |
4753 | 5012 | @item pg_fname(@var{res}, @var{column_number}) |
4754 | -引数 @var{res} の結果ハンドルが見つからない場合、あるいは、@var{column_number} が範囲外であった場合はヌル文字列 (@code{""}) が返され、@code{ERRNO} がセットされます。 | |
4755 | -そうでなければ、@code{PQfname(res, column_number)} の値が返されます。 | |
5013 | +引数@var{res}の結果ハンドルが見つからない場合、あるいは、@var{column_number}が範囲外であった場合、ヌル文字列(@code{""})が返され、@code{ERRNO}がセットされます。 | |
5014 | +そうでなければ、@code{PQfname(res, column_number)}の値が返されます。 | |
4756 | 5015 | |
4757 | 5016 | @cindex @code{pg_getvalue} pgsql extension function |
4758 | 5017 | @cindex @code{PQgetvalue} libpq function |
4759 | 5018 | @item pg_getvalue(@var{res}, @var{row_number}, @var{column_number}) |
4760 | -引数 @var{res} の結果ハンドルが見つからない場合、あるいは、@var{row_number} か @var{column_number} が範囲外であった場合、ヌル文字列 (@code{""}) が返され、@code{ERRNO} がセットされます。 | |
4761 | -そうでなければ、@code{PQgetvalue(res, row_number, column_number)} の値が返されます。 | |
5019 | +引数@var{res}の結果ハンドルが見つからない場合、あるいは、@var{row_number}か@var{column_number}が範囲外であった場合、ヌル文字列(@code{""})が返され、@code{ERRNO}がセットされます。 | |
5020 | +そうでなければ、@code{PQgetvalue(res, row_number, column_number)}の値が返されます。 | |
4762 | 5021 | |
4763 | 5022 | @cindex @code{pg_getisnull} pgsql extension function |
4764 | 5023 | @cindex @code{PQgetisnull} libpq function |
4765 | 5024 | @item pg_getisnull(@var{res}, @var{row_number}, @var{column_number}) |
4766 | -引数 @var{res} の結果ハンドルが見つからなければ、あるいは、@var{row_number} か @var{column_number} が範囲外であったならば、-1 が返され、@code{ERRNO} がセットされます。 | |
4767 | -そうでなければ、@code{PQgetisnull(res, row_number, column_number)} の値が返されます (データが NULL ならば 1、非 NULL ならば 0 です)。 | |
5025 | +引数@var{res}の結果ハンドルが見つからない場合、あるいは、@var{row_number}か@var{column_number}が範囲外の場合、-1が返され、@code{ERRNO}がセットされます。 | |
5026 | +そうでなければ、@code{PQgetisnull(res, row_number, column_number)}の値が返されます(データがNULLならば1、非NULLならば0です)。 | |
4768 | 5027 | |
4769 | 5028 | @end table |
4770 | 5029 | |
5030 | + | |
4771 | 5031 | @node Higher-level Functions to Retrieve Query Results Using Arrays |
4772 | 5032 | @appendixsec 配列を使った問い合わせ結果の取得のための高レベル関数 |
4773 | 5033 |
@@ -4775,142 +5035,149 @@ Cygwin のようなプラットフォームでは、このオプションは拡 | ||
4775 | 5035 | |
4776 | 5036 | @cindex @code{pg_fields} pgsql extension function |
4777 | 5037 | @item pg_fields(@var{res}, @var{field_names}) |
4778 | -引数 @var{res} の結果ハンドルが見つからなければ、-1 が返され、@code{ERRNO} がセットされます。 | |
4779 | -そうでなければ、結果のフィールド数 (すなわち @code{pg_nfields(res)}) が返され、配列 @code{field_names} がクリアされて、@code{PQfname(res, col)} によって返された値が @code{field_names[col]} に入るようにカラム名がそこに入れられます。 | |
5038 | +引数@var{res}の結果ハンドルが見つからなければ、-1が返され、@code{ERRNO}がセットされます。 | |
5039 | +そうでなければ、結果のフィールド数(すなわち@code{pg_nfields(res)})が返されます。 | |
5040 | +配列@code{field_names}はクリアされ、@code{PQfname(res, col)}によって返された値が@code{field_names[col]}に入るようにカラム名がそこに入れられます。 | |
4780 | 5041 | |
4781 | 5042 | @cindex @code{pg_fieldsbyname} pgsql extension function |
4782 | 5043 | @item pg_fieldsbyname(@var{res}, @var{field_names}) |
4783 | -引数 @var{res} の結果ハンドルが見つからなければ、-1 が返され、@code{ERRNO} がセットされます。 | |
4784 | -そうでなければ、結果のフィールド数 (すなわち、@code{pg_nfields(res)}) が返され、配列 @var{field_names} がクリアされて、@code{fields_names[PQfname(res, col)]} が @code{col} を含むようになるようカラム名がそこに入れられます。 | |
5044 | +引数@var{res}の結果ハンドルが見つからなければ、-1が返され、@code{ERRNO}がセットされます。 | |
5045 | +そうでなければ、結果のフィールド数(すなわち、@code{pg_nfields(res)})が返されます。 | |
5046 | +配列@var{field_names}はクリアされ、@code{fields_names[PQfname(res, col)]}が@code{col}を含むようになるようカラム名がそこに入れられます。 | |
4785 | 5047 | |
4786 | 5048 | @cindex @code{pg_getrow} pgsql extension function |
4787 | 5049 | @item pg_getrow(@var{res}, @var{row_number}, @var{field}) |
4788 | -引数 @var{res} の結果ハンドルが見つからければ、あるいは @var{row_number} が範囲外であったならば、-1 が返され、@code{ERRNO} がセットされます。 | |
4789 | -そうでなければ、行の中の NULL でないフィールドの数が返され、配列 @var{field} がクリアされ、@code{field[col_number]} に、NULL でない全てのカラムについて @code{PQgetvalue(res, row_number, col_number)} 入るようにデータが入れられます。 | |
5050 | +引数@var{res}の結果ハンドルが見つからなければ、あるいは、@var{row_number}が範囲外であったならば、-1が返され、@code{ERRNO}がセットされます。 | |
5051 | +そうでなければ、行の中のNULLでないフィールドの数が返されます。 | |
5052 | +配列@var{field}はクリアされ、NULLでない全てのカラムについて、@code{field[col_number]}が、@code{PQgetvalue(res, row_number, col_number)}となるようにデータが入れられます。 | |
4790 | 5053 | |
4791 | 5054 | @cindex @code{pg_getrowbyname} pgsql extension function |
4792 | 5055 | @item pg_getrowbyname(@var{res}, @var{row_number}, @var{field}) |
4793 | -引数 @var{res} の結果ハンドルが見つからない場合、あるいは、@var{row_number} が範囲外である場合、-1 が返され、@code{ERRNO} がセットされます。 | |
4794 | -そうでなければ、その行の NULL でないフィールドの数が返されます。 | |
4795 | -そして、配列 @var{field} がクリアされ、NULL でない全てのカラムについて @code{field[PQfname(res, col_number)]} に @code{PQgetvalue(res, row_number, col_number)} が入るようにデータが入れられます。 | |
4796 | - | |
5056 | +引数@var{res}の結果ハンドルが見つからない場合、あるいは、@var{row_number}が範囲外である場合、-1が返され、@code{ERRNO}がセットされます。 | |
5057 | +そうでなければ、その行のNULLでないフィールドの数が返されます。 | |
5058 | +配列@var{field}がクリアされ、NULLでない全てのカラムについて、@code{field[PQfname(res, col_number)]}が、@code{PQgetvalue(res, row_number, col_number)}となるようにデータが入れられます。 | |
4797 | 5059 | @end table |
4798 | 5060 | |
4799 | -@node Time Extension Reference | |
4800 | -@appendix Time Extension リファレンス | |
4801 | 5061 | |
5062 | +@node Time Extension Reference | |
5063 | +@appendix Time Extensionリファレンス | |
4802 | 5064 | @cindex time |
4803 | 5065 | @cindex sleep |
4804 | 5066 | |
4805 | -これらの関数は、@option{-l time} というコマンドライン引数を付けて @command{xgawk} を起動するか、スクリプトに @code{@@load time} を挿入するか、どちらかで使うことができます。 | |
5067 | +これらの関数は、@option{-l time}というコマンドライン引数を付けて@command{xgawk}を起動するか、スクリプトに@code{@@load time}を挿入するか、どちらかで使うことができます。 | |
4806 | 5068 | |
4807 | 5069 | @table @code |
4808 | 5070 | |
4809 | 5071 | @cindex @code{gettimeofday} time extension function |
4810 | 5072 | @item gettimeofday() |
4811 | -この関数は、1970-01-01 UTC から経過した時間を浮動小数点で返します。 | |
4812 | -これは 1 秒以下の精度を持つべきですが、実際の精度はプラットフォームによって変わります。 | |
4813 | -もし、このプラットフォームで時刻が利用できないのならば、-1 を返して、@code{ERRNO} をセットします。 | |
4814 | -標準の @code{gettimeofday} 関数が利用可能ならば、単にその値を返します。 | |
4815 | -そうでない場合、もし Windows 上であれば、@code{GetSystemTimeAsFileTime} を使うことを試みます。 | |
5073 | +この関数は、1970-01-01 UTCから経過した時間を浮動小数点で返します。 | |
5074 | +1秒以下の精度を持つはずですが、プラットフォームによって実際の精度は変わります。 | |
5075 | +もし、プラットフォームで時刻が利用できないのならば、-1を返して、@code{ERRNO}をセットします。 | |
5076 | +標準の@code{gettimeofday}関数が利用可能ならば、単にその値を返します。 | |
5077 | +利用できない場合、Windows上であれば、@code{GetSystemTimeAsFileTime}を使うことを試みます。 | |
4816 | 5078 | |
4817 | 5079 | @cindex @code{sleep} time extension function |
4818 | 5080 | @item sleep(@var{seconds}) |
4819 | -この関数は、@var{seconds} 秒間のスリープを試みます。 | |
4820 | -@var{senconds} は浮動小数点の (不可欠須ではない) 値かもしれないことに注意してください。 | |
4821 | -@var{seconds} が負であるか、あるいは、スリープする試みが失敗した場合、-1 が返され、@code{ERRNO} がセットされます。 | |
4822 | -そうでなければ、この関数は、指示されただけの時間スリープした後 0 を返すはずです。 | |
4823 | -実装の詳細としては、プラットフォームの利用可能性に応じて、@code{nanosleep} を使ったり、@code{select} を使ったりして遅延を実装しようと試みています。 | |
4824 | - | |
5081 | +この関数は、@var{seconds}秒間のスリープを試みます。 | |
5082 | +@var{senconds}は、浮動小数点数(不可欠ではない)かもしれないことに注意してください。 | |
5083 | +@var{seconds}が負であるか、あるいは、スリープする試みが失敗した場合、-1が返され、@code{ERRNO}がセットされます。 | |
5084 | +そうでなければ、この関数は、指示されただけの時間スリープした後、0を返します。 | |
5085 | +実装の詳細としては、プラットフォームの利用可能性に応じて、@code{nanosleep}を使ったり、@code{select}を使ったりして遅延を実装しようと試みています。 | |
4825 | 5086 | @end table |
4826 | 5087 | |
4827 | -@node GD Graphics Extension Reference | |
4828 | -@appendix GD グラフィックス拡張リファレンス | |
4829 | 5088 | |
5089 | +@node GD Graphics Extension Reference | |
5090 | +@appendix GDグラフィックス拡張リファレンス | |
4830 | 5091 | @cindex GD |
4831 | 5092 | |
4832 | -@uref{http://www.boutell.com/gd/manual2.0.33.html} でドキュメントされているのと同じように、ここで説明されている関数は GD graphics API を明らかにするものです。 | |
4833 | -このドキュメンテーションは GD ドキュメンテーションと合わせることで初めて理解することができます。 | |
5093 | +@uref{http://www.boutell.com/gd/manual2.0.33.html}でドキュメントされているのと同じように、ここで説明されている関数はGD graphics APIを明らかにするものです。 | |
5094 | +このドキュメントは、GDドキュメントと合わせることで初めて理解することができます。 | |
4834 | 5095 | |
4835 | -これらの関数は、@option{-l gd} というコマンドライン引数を付けて @command{xgawk} を起動するか、スクリプトに @code{@@load gd} を挿入することで使えるようになります。 | |
5096 | +これらの関数は、@option{-l gd}というコマンドライン引数を付けて@command{xgawk}を起動するか、スクリプトに@code{@@load gd}を挿入することで使えるようになります。 | |
4836 | 5097 | |
4837 | 5098 | @table @code |
4838 | - | |
4839 | 5099 | @cindex @code{gdImageCreateFromFile} GD graphics extension function |
4840 | 5100 | @item gdImageCreateFromFile(@var{img_dst}, @var{file_name}) |
4841 | -この関数を使って、オリジナルの @code{gdImageCreateFromJpeg()} や @code{gdImageCreateFromPng()}、@code{gdImageCreateFromGif()} の代わりに、PNG、JPG、GIF ファイルから画像をロードします。 | |
5101 | +この関数を使って、オリジナルの@code{gdImageCreateFromJpeg()}、@code{gdImageCreateFromPng()}、@code{gdImageCreateFromGif()}の代わりに、PNG、JPG、GIFファイルから画像をロードします。 | |
4842 | 5102 | 画像ハンドルを返します。 |
4843 | -失敗した場合は空文字列を返します。 | |
5103 | +失敗した場合、空文字列を返します。 | |
4844 | 5104 | |
4845 | 5105 | @cindex @code{gdImageCopyResampled} GD graphics extension function |
4846 | 5106 | @item gdImageCopyResampled(@var{img_dst}, @var{img_src}, @var{dstX}, @var{dstY}, @var{srcX}, @var{srcY}, @var{destW}, @var{destH}, @var{srcW}, @var{srcH}) |
4847 | -成功した場合は 0 を、失敗した場合は -1 を返します。 | |
5107 | +成功した場合は、0を返します。 | |
5108 | +失敗した場合は、-1を返します。 | |
4848 | 5109 | |
4849 | 5110 | @cindex @code{gdImageCreateTrueColor} GD graphics extension function |
4850 | 5111 | @item gdImageCreateTrueColor(@var{width}, @var{height}) |
4851 | 5112 | 画像ハンドルを返します。 |
4852 | -失敗したら空文字列を返します。 | |
5113 | +失敗した場合、空文字列を返します。 | |
4853 | 5114 | |
4854 | 5115 | @cindex @code{gdImageDestroy} GD graphics extension function |
4855 | 5116 | @item gdImageDestroy(@var{img}) |
4856 | -成功した場合は 0 を、失敗した場合は -1 を返します。 | |
5117 | +成功した場合は、0を返します。 | |
5118 | +失敗した場合は、-1を返します。 | |
4857 | 5119 | |
4858 | 5120 | @cindex @code{gdImagePngName} GD graphics extension function |
4859 | 5121 | @item gdImagePngName(@var{img}, @var{file_name}) |
4860 | -この関数を使って、オリジナルの @code{gdImagePng()} の代わりに、画像を PNG ファイルとして保存します。 | |
4861 | -成功した場合は 0 を、失敗した場合は -1 を返します。 | |
5122 | +この関数を使って、オリジナルの@code{gdImagePng()}の代わりに、画像をPNGファイルとして保存します。 | |
5123 | +成功した場合は、0を返します。 | |
5124 | +失敗した場合は、-1を返します。 | |
4862 | 5125 | |
4863 | 5126 | @cindex @code{gdImageStringFT} GD graphics extension function |
4864 | 5127 | @item gdImageStringFT(@var{img}, @var{brect}, @var{fg}, @var{fontname}, @var{ptsize}, @var{angle}, @var{x}, @var{y}, @var{string}) |
4865 | 5128 | テキストを描くのに使います。 |
4866 | -brect に 8 個の整数の配列を返すことに注意してください。 | |
4867 | -img が空の AWK 文字列であることは、元の C 関数で img ポインタが NULL であるのと同じ意味です。 | |
4868 | -GDFONTPATH 環境変数にフォントパスを設定し忘れないようにしてください。 | |
4869 | -成功した場合は空文字列を返し、失敗した場合はエラーメッセージの文字列が返されます。 | |
5129 | +brectに8個の整数の配列を返すことに注意してください。 | |
5130 | +imgが空のAWK文字列であることは、元のC関数でimgポインタがNULLであるのと同じ意味です。 | |
5131 | +GDFONTPATH環境変数にフォントパスを設定し忘れないようにしてください。 | |
5132 | +成功した場合は、空文字列を返します。 | |
5133 | +失敗した場合は、エラーメッセージの文字列が返されます。 | |
4870 | 5134 | |
4871 | 5135 | @cindex @code{gdImageColorAllocate} GD graphics extension function |
4872 | 5136 | @item gdImageColorAllocate(@var{img}, @var{r}, @var{g}, @var{b}) |
4873 | -指定された r、g、b の値と一致する RGB カラーを返します。 | |
4874 | -失敗した場合は -1 を返します。 | |
5137 | +指定されたr、g、bの値と一致するRGBカラーを返します。 | |
5138 | +失敗した場合は、-1を返します。 | |
4875 | 5139 | |
4876 | 5140 | @cindex @code{gdImageFilledRectangle} GD graphics extension function |
4877 | 5141 | @item gdImageFilledRectangle(@var{img}, @var{x1}, @var{y1}, @var{x2}, @var{y2}, @var{color}) |
4878 | 5142 | 指定された色で長方形を塗りつぶします。 |
4879 | -成功すれば 0 を、失敗すれば -1 を返します。 | |
5143 | +成功すれば、0を返します。 | |
5144 | +失敗すれば、-1を返します。 | |
4880 | 5145 | |
4881 | 5146 | @cindex @code{gdImageSetAntiAliasedDontBlend} GD graphics extension function |
4882 | 5147 | @item gdImageSetAntiAliasedDontBlend(@var{img}, @var{color}, @var{dont_blend}) |
4883 | 5148 | アンチエイリアシングの際、この色をブレンドしません。 |
4884 | -成功すれば 0 を、失敗すれば -1 を返します。 | |
5149 | +成功すれば、0を返します。 | |
5150 | +失敗すれば、-1を返します。 | |
4885 | 5151 | |
4886 | 5152 | @cindex @code{gdImageSetThickness} GD graphics extension function |
4887 | 5153 | @item gdImageSetThickness(@var{img}, @var{thickness}) |
4888 | 5154 | 線を描く時の太さをセットします。 |
4889 | -成功すれば 0 を、失敗すれば -1 を返します。 | |
5155 | +成功すれば、0を返します。 | |
5156 | +失敗すれば、-1を返します。 | |
4890 | 5157 | |
4891 | 5158 | @cindex @code{gdImageSX} GD graphics extension function |
4892 | 5159 | @item gdImageSX(@var{img}) |
4893 | 5160 | 画像の幅を返します。 |
4894 | -失敗すれば -1 を返します。 | |
5161 | +失敗すれば、-1を返します。 | |
4895 | 5162 | |
4896 | 5163 | @cindex @code{gdImageSY} GD graphics extension function |
4897 | 5164 | @item gdImageSY(@var{img}) |
4898 | 5165 | 画像の高さを返します。 |
4899 | -失敗すれば -1 を返します。 | |
5166 | +失敗すれば、-1を返します。 | |
4900 | 5167 | |
4901 | 5168 | @cindex @code{gdImageCompare} GD graphics extension function |
4902 | 5169 | @item gdImageCompare(@var{img1}, @var{img2}) |
4903 | -画像が等しければ 0 を返します。 | |
4904 | -違っていれば、GD のドキュメントに説明されている値を返します。 | |
4905 | -また、img1 が無効の場合は 1<<14 を、img2 が無効の場合は 1<<15 を返します。 | |
4906 | - | |
5170 | +画像が等しければ、0を返します。 | |
5171 | +違っていれば、GDのドキュメントに説明されている値を返します。 | |
5172 | +また、img1が無効の場合は1<<14を、img2が無効の場合は1<<15を返します。 | |
4907 | 5173 | @end table |
4908 | 5174 | |
5175 | + | |
4909 | 5176 | @node MPFR Extension Reference |
4910 | -@appendix MPFR 拡張リファレンス | |
5177 | +@appendix MPFR拡張リファレンス | |
4911 | 5178 | |
4912 | 5179 | @cindex MPFR |
4913 | -@cindex 任意精度の計算 | |
5180 | +@cindex Arbitrary Precision Arithmetic | |
4914 | 5181 | |
4915 | 5182 | @ignore |
4916 | 5183 |
@@ -5030,27 +5297,28 @@ Arnold | ||
5030 | 5297 | @end ignore |
5031 | 5298 | |
5032 | 5299 | |
5033 | -@uref{http://www.mpfr.org, MPFR} は、@uref{http://en.wikipedia.org/wiki/Floating-point, floating-point numbers} における @uref{http://en.wikipedia.org/wiki/Arbitrary_precision_arithmetic, arbitrary precision arithmetic} のためのポータブルなライブラリです。 | |
5034 | -これはつまり、MPFR 拡張を使って、@uref{http://en.wikipedia.org/wiki/IEEE_754, IEEE 754-1985 standard} で定義されているような通常の浮動小数点数よりも、高い精度で (望めば低い精度でも) 数値計算を行なうことができるということです。 | |
5300 | +@uref{http://www.mpfr.org, MPFR}は、@uref{http://en.wikipedia.org/wiki/Floating-point, floating-point numbers}における@uref{http://en.wikipedia.org/wiki/Arbitrary_precision_arithmetic, arbitrary precision arithmetic}のためのポータブルなライブラリです。 | |
5301 | +これはつまり、MPFR拡張を使って、@uref{http://en.wikipedia.org/wiki/IEEE_754, IEEE 754-1985 standard}で定義されているような通常の浮動小数点数よりも、高い精度で(望めば低い精度でも)数値計算を行うことができるということです。 | |
5035 | 5302 | |
5036 | 5303 | @menu |
5037 | -* 誰が任意精度の計算を必要とするか?:: | |
5038 | -* Nullary 関数:: | |
5039 | -* Unary 関数:: | |
5040 | -* Binary 関数:: | |
5041 | -* Nullary 述語:: | |
5042 | -* Unary 述語:: | |
5043 | -* Binary 述語:: | |
5044 | -* 数値の入出力:: | |
5304 | +* Who Needs Arbitrary Precision Arithmetic ?:: | |
5305 | +* Nullary Functions:: | |
5306 | +* Unary Functions:: | |
5307 | +* Binary Functions:: | |
5308 | +* Nullary Predicates:: | |
5309 | +* Unary Predicates:: | |
5310 | +* Binary Predicates:: | |
5311 | +* Input and Output of Numbers:: | |
5045 | 5312 | @end menu |
5046 | 5313 | |
5314 | + | |
5047 | 5315 | @node Who Needs Arbitrary Precision Arithmetic ? |
5048 | -@appendixsec 誰が任意精度の計算を必要とするか? | |
5049 | -多くのユーザにとって、そういった人たちが、この特殊な@emph{任意の精度}の数値を実際に必要としているのはなぜなのかということは明確ではありません。 | |
5050 | -2 かける 2 は 4 となる。 | |
5051 | -これ以上を必要としている人は誰でしょうか。 | |
5052 | -実生活における計算の大半 (値段や距離の合計を計算するとか、VAT (付加価値税) 込みのガソリンの計算) においては、あなたのポケット計算機やコンピュータの精度は、実に十分良いものです。 | |
5053 | -しかし、さらに少し先へ進めて、以下の多項式を計算する場合、あなたのソフトウェアの能力にいくらかの疑念が生じてきます (@uref{http://www.math.uni-wuppertal.de/org/WRST/literatur/PXSCENGL.ps.gz, PASCAL-XSC Language Reference with Examples}, page 188 から取った例)。 | |
5316 | +@appendixsec 誰が任意精度の計算を必要とするか | |
5317 | + | |
5318 | +多くのユーザにとって、この特殊な@emph{任意の精度}の数値が実際に必要とされるのはなぜなのかということは明確ではありません。 | |
5319 | +「2かける2は4」、これ以上を必要としている人は誰でしょうか。 | |
5320 | +実生活における計算の大半(値段や距離の合計を計算するとか、VAT(付加価値税)込みのガソリンの計算)においては、ポケット計算機やコンピュータの精度は、実に十分良いものです。 | |
5321 | +しかし、さらに少し先へ進めて、以下の多項式を計算するような場合、ソフトウェアの能力にいくらかの疑念が生じてきます(@uref{http://www.math.uni-wuppertal.de/org/WRST/literatur/PXSCENGL.ps.gz, PASCAL-XSC Language Reference with Examples}, page 188から取った例)。 | |
5054 | 5322 | @cindex PASCAL-XSC |
5055 | 5323 | |
5056 | 5324 | @example |
@@ -5059,16 +5327,17 @@ awk 'BEGIN @{x=665857; y=470832; print x^4 - 4 * y^4 - 4 * y^2 @}' | ||
5059 | 5327 | @end example |
5060 | 5328 | |
5061 | 5329 | この結果の驚くところは、それが@emph{間違っている}というところです。 |
5062 | -ほんのちょっとだけというわけでなく、@code{1.0} という正確な結果と比べると、@emph{完全に}間違っています。 | |
5063 | -さらに悪いことに、このソフトウェアはあなたに何の手掛かりも示しません。 | |
5064 | -これは AWK が原因ではないので安心してください。 | |
5065 | -AWK は、下にあるオペレーティングシステムの数値計算の実装を当てにしています (計算に使用しているプログラミング言語を問わず同じ結果になります) | |
5330 | +ほんのちょっとだけというわけでなく、@code{1.0}という正確な結果と比べると、@emph{完全に}間違っています。 | |
5331 | +さらに悪いことに、このソフトウェアはユーザに何の手掛かりも示しません。 | |
5332 | +これは、AWKが原因ではないので安心してください。 | |
5333 | +AWKは、下にあるオペレーティングシステムの数値計算の実装を当てにしています(計算に使用しているプログラミング言語を問わず同じ結果になります) | |
5066 | 5334 | |
5067 | -では、MPFR はこれについて何をより良く実行できるのでしょうか。 | |
5335 | +では、MPFRは、これについて何をより良く実行できるのでしょうか。 | |
5068 | 5336 | まず、別の構文で問題を書き直さなければなりません。 |
5069 | -AWK の通常の計算オペレータを、等価な MPFR のオペレータへ置き換えなければなりません。 | |
5070 | -これでプログラムが少し読み難くなります。 | |
5071 | -以下の例は、同じ多項式を計算するためにMPFR 拡張を使ったものです。 | |
5337 | +AWKの通常の計算オペレータを、等価なMPFRのオペレータへ置き換えなければなりません。 | |
5338 | +これによって、プログラムが少し読み難くなります。 | |
5339 | +以下の例は、同じ多項式を計算するためにMPFR拡張を使ったものです。 | |
5340 | + | |
5072 | 5341 | @example |
5073 | 5342 | gawk @b{-l mpfr} 'BEGIN @{x=665857; y=470832; \ |
5074 | 5343 | print @b{mpfr_sub(mpfr_sub(mpfr_pow(x, 4), mpfr_mul(4, mpfr_pow(y, 4)))}, 4 * y^2)@}' |
@@ -5076,12 +5345,12 @@ gawk @b{-l mpfr} 'BEGIN @{x=665857; y=470832; \ | ||
5076 | 5345 | @end example |
5077 | 5346 | |
5078 | 5347 | @cindex IEEE 754-1985 |
5079 | -デフォルトでは、MPFR 拡張は、オペレーティングシステムで実装されている通常の IEEE 754 互換のオペレータと同じ精度 (仮数部で 53 ビット) で計算をします。 | |
5348 | +デフォルトでは、MPFR拡張は、オペレーティングシステムで実装されている通常のIEEE 754互換のオペレータと同じ精度(仮数部で53ビット)で計算をします。 | |
5080 | 5349 | ゆえに、その結果は上のものと同じになります。 |
5081 | -ここまでのところ有利な点はありません。 | |
5082 | -では、どのようにすれば MPFR の@emph{任意の精度}の能力を最終的に活用することができるでしょうか。 | |
5083 | -私たちは、その数値の仮数部にあともういくらかのビットを使うように MPFR に指示しなければなりません。 | |
5084 | -この場合だと 80 ビットで十分です。 | |
5350 | +ここまでのところ、有利な点はありません。 | |
5351 | +では、どのようにすればMPFRの@emph{任意の精度}の能力を最終的に活用することができるでしょうか。 | |
5352 | +その数値の仮数部に、さらにいくらかのビットを使うようにMPFRに指示しなければなりません。 | |
5353 | +この場合だと80ビットで十分です。 | |
5085 | 5354 | |
5086 | 5355 | @example |
5087 | 5356 | gawk -l mpfr 'BEGIN @{@b{MPFR_PRECISION = 80}; x=665857; y=470832; \ |
@@ -5089,62 +5358,67 @@ gawk -l mpfr 'BEGIN @{@b{MPFR_PRECISION = 80}; x=665857; y=470832; \ | ||
5089 | 5358 | 1.0000000000000000000000000 |
5090 | 5359 | @end example |
5091 | 5360 | |
5092 | -仮数部を 80 ビットにして計算すると、計算全体の結果が正しい (@code{1.0}) ことがわかります。 | |
5361 | +仮数部を80ビットにして計算すると、計算全体の結果が正しい(@code{1.0})ことが分かります。 | |
5093 | 5362 | さて、プログラムをもう一度見てください。 |
5094 | 5363 | 多項式の最後に注意してください。 |
5095 | -多項式の最後の項が MPFR のオペレータの項として書き直されていません。 | |
5096 | -まだ通常のオペレータを使っています。 | |
5097 | -この例は、通常の数値と、MPFR が返す長い数値を混ぜることができるということを示しています。 | |
5098 | -通常の数値と長い数値を混ぜるとかなり便利で、プログラムの読み易さを改善します。 | |
5099 | -しかし、(分析的な視点から) これは悪い例です。 | |
5100 | -通常の数値は、もしかすると精度が低く、多項式にそのような項が一つあると、完全な計算を台無しにしてしまうかもしれません。 | |
5101 | -上記のような多項式の計算の場合では、それは問題ではありません (その項が単に @code{y} の 2 次式であって、@code{x} と @code{y} の 2 次の項ほどの長さの仮数を必要としていないからです)。 | |
5102 | -しかし、もっと一般的なケース (変数が実際に@emph{変化して}、定数ではないような場合) では、MPFR の関数の項で完全な計算をするべきでしょう。 | |
5103 | - | |
5104 | -まとめますと、MPFR は、浮動小数点数における任意精度の計算をするためのポータブルなライブラリです。 | |
5105 | -精度は、ビット単位で、各変数に対して有効ならばどのような値も厳密にセットできます。 | |
5106 | -MPFR における計算の意味は以下のように規定されます。 | |
5107 | -要求された計算操作を正確に (無限の正確さで) 計算し、その結果を、行き先の変数の精度に、指定された丸めモードで丸めます。 | |
5108 | -MPFR の浮動小数点関数は、IEEE 754-1985 の計算をスムーズに拡張することを目的としています。 | |
5109 | - | |
5110 | -数値の内部表現は MPFR 拡張のユーザには見えません。 | |
5364 | +多項式の最後の項が、MPFRのオペレータの項として書き直されていません。 | |
5365 | +通常のオペレータをまだ使っています。 | |
5366 | +この例は、通常の数値とMPFRが返す長い数値を混在させることができるということを示しています。 | |
5367 | +通常の数値と長い数値を混用するとかなり便利で、プログラムの読み易さを改善します。 | |
5368 | +しかし、分析的な視点からは、これは悪い例です。 | |
5369 | +通常の数値はもしかすると精度が低く、そのような項が多項式に一つあると、完全な計算を台無しにしてしまうかもしれません。 | |
5370 | +上記のような多項式の計算の場合では、それは問題ではありません(その項が単に@code{y}の2次式であって、@code{x}と@code{y}の2次の項ほどの長さの仮数を必要としていないからです)。 | |
5371 | +しかし、もっと一般的なケース(変数が実際に@emph{変化して}、定数ではないような場合)では、MPFRの関数の項で完全な計算をするべきでしょう。 | |
5372 | + | |
5373 | +まとめますと、MPFRは、浮動小数点数における任意精度の計算をするためのポータブルなライブラリです。 | |
5374 | +精度は、各変数に対して有効ならば、どのような値でもビット単位で厳密にセットできます。 | |
5375 | +MPFRにおける計算の意味は以下のように規定されます。 | |
5376 | +要求された計算操作を正確に(無限の正確さで)計算し、その結果を、行き先の変数の精度に指定された丸めモードで丸めます。 | |
5377 | +MPFRの浮動小数点関数は、IEEE 754-1985の計算をスムーズに拡張することを目的としています。 | |
5378 | + | |
5379 | +数値の内部表現は、MPFR拡張のユーザには見えません。 | |
5111 | 5380 | ユーザには、数値は、可変長の文字列として見えます。 |
5112 | -一般的なルールとして、MPFR 関数はすべて、数値を収めた文字列として数値計算をした結果を返します。 | |
5113 | -それぞれの変数の初期化や計算は以下の大域変数で制御されています。 | |
5381 | +一般的なルールとして、MPFR関数は、数値を収めた文字列として数値計算をした結果を全て返します。 | |
5382 | +それぞれの変数の初期化や計算は、以下の大域変数で制御されています。 | |
5114 | 5383 | |
5115 | 5384 | @itemize |
5116 | 5385 | @cindex MPFR_ROUND |
5117 | -@item MPFR_ROUND (デフォルト GMP_RNDN) は、次の値を取ります。 | |
5118 | -GMP_RNDN (最近接値へ丸める)、GMP_RNDZ (ゼロ方向へ丸める)、GMP_RNDU (正の無限大方向へ丸める)、GMP_RNDD (負の無限大方向へ丸める)。 | |
5119 | -これらのシンボルの値は、IEEE 754-1985 標準の四つの丸めモードと一致します。 | |
5386 | +@item MPFR_ROUND(デフォルトGMP_RNDN)は、GMP_RNDN(最近接値へ丸める)、GMP_RNDZ(ゼロ方向へ丸める)、GMP_RNDU(正の無限大方向へ丸める)、GMP_RNDD(負の無限大方向へ丸める)という値を取ります。 | |
5387 | +これらのシンボルの値は、IEEE 754-1985標準の四つの丸めモードと一致します。 | |
5388 | + | |
5120 | 5389 | @cindex MPFR_PRECISION |
5121 | -@item MPFR_PRECISION (デフォルト 53) は、各変数に対してどのような有効な値にでもセットすることのできる、ビット単位の精度です (非常に小さな精度も含みます)。 | |
5122 | -特に、53 ビットの精度では、MPFR は、倍精度マシンの浮動小数点数 (C でいう double 型) での全ての計算を正確に再現できるはずです。 | |
5390 | +@item MPFR_PRECISION(デフォルト53)は、各変数に対してどのような有効な値にでもセットすることのできるビット単位の精度です(非常に小さな精度も含みます)。 | |
5391 | +特に、53ビットの精度では、MPFRは、倍精度マシンの浮動小数点数(Cでいうdouble型)での全ての計算を正確に再現できるはずです。 | |
5123 | 5392 | デフォルトの指数範囲を除きます。 |
5124 | 5393 | この指数範囲は、より範囲が広く標準以下の数値で、実装されていませんが、エミュレートはできます。 |
5394 | + | |
5125 | 5395 | @cindex MPFR_EXACT |
5126 | -@item MPFR_EXACT (デフォルト 0)。 | |
5127 | -いくつかの特別な関数は、正確な戻り値の時はゼロ、正確な結果よりも大きい戻り値の時は正の値、それら以外の時は負の値を返します。 | |
5128 | -この変数は、最近起動された特別な関数からの戻り値を保持しています。 | |
5396 | +@item MPFR_EXACT(デフォルト0)。 | |
5397 | +いくつかの特別な関数は、正確な戻り値の時は、ゼロを返し、正確な結果よりも大きい戻り値の時は、正の値を返し、それら以外の時は、負の値を返します。 | |
5398 | +この変数は、最後に呼び出された特別な関数からの戻り値を保持しています。 | |
5399 | + | |
5129 | 5400 | @cindex MPFR_BASE |
5130 | -@item MPFR_BASE (デフォルトは 10 進数の 10) には、数字を表記するのに使われる基数が入っています。 | |
5401 | +@item MPFR_BASE(デフォルトは10進数の10)には、数字を表記するのに使われる基数が入っています。 | |
5131 | 5402 | @end itemize |
5132 | 5403 | |
5133 | -この補遺の残りの部分は、MPFR 拡張で提供される全関数のリストです。 | |
5134 | -ここにリストされている関数は実際に使うことができるものだけですので注意してください。 | |
5135 | -古い MPFR バージョンの obsolete でレガシーな関数はサポートされていません。 | |
5136 | -サポートしている関数は、@option{-l mpfr} というコマンドライン引数を付けて @command{xgawk} を起動するか、スクリプトに @code{@@load mpfr} を挿入して起動するかした後に使えるようになります。 | |
5137 | -オプショナルなパラメータは角括弧@w{ ([ ]) }で閉じてあります。 | |
5404 | +この補遺の残りの部分は、MPFR拡張で提供される全関数のリストです。 | |
5405 | +ここにリストされている関数は、実際に使うことができるものだけですので注意してください。 | |
5406 | +古いMPFRバージョンのobsoleteでレガシーな関数はサポートされていません。 | |
5407 | +サポートしている関数は、@option{-l mpfr}というコマンドライン引数を付けて@command{xgawk}を起動するか、スクリプトに@code{@@load mpfr}を挿入して起動するかした後に使えるようになります。 | |
5408 | +オプショナルなパラメータは角括弧@w{([ ])}で閉じてあります。 | |
5138 | 5409 | 以下のセクションでは、関数をグループ毎に紹介しています。 |
5139 | -グループの分け方は、@uref{http://en.wikipedia.org/wiki/Arity, arity} に基づいています (arity は、関数のパラメータと戻り値のシグネチャ)。 | |
5410 | +グループの分け方は、@uref{http://en.wikipedia.org/wiki/Arity, arity}に基づいています(arityは、関数のパラメータと戻り値のシグネチャ)。 | |
5411 | + | |
5140 | 5412 | |
5141 | 5413 | @node Nullary Functions |
5142 | -@appendixsec Nullary 関数 | |
5143 | -nullary 関数は、引数を取りません (@emph{null}) が、役立つ数値を返します。 | |
5144 | -これらの関数は、ある数値に対する、与えられた環境 (選択された精度、基数、丸め) の下で可能な限りの最良の近似値を提供するものです。 | |
5414 | +@appendixsec Nullary関数 | |
5145 | 5415 | |
5146 | -次の関数は、それぞれ、e を底とする 2 の対数、Pi の値、オイラー定数 0.577... を返します。 | |
5147 | -値は、その時セットされている方向 MPFR_ROUND で丸められます。 | |
5416 | +nullary関数は引数を取りません(@emph{null}引数を取ります)。 | |
5417 | +しかし、有用な数値を返します。 | |
5418 | +これらの関数は、ある数値に対する、与えられた環境(選択された精度、基数、丸め)の下で可能な限り最良の近似値を提供するものです。 | |
5419 | + | |
5420 | +次の関数は、それぞれ、eを底とする2の対数、Piの値、オイラー定数0.577...を返します。 | |
5421 | +値は、その時セットされている方向MPFR_ROUNDで丸められます。 | |
5148 | 5422 | |
5149 | 5423 | @itemize |
5150 | 5424 | @cindex @code{mpfr_const_pi} mpfr extension function |
@@ -5155,36 +5429,39 @@ nullary 関数は、引数を取りません (@emph{null}) が、役立つ数値 | ||
5155 | 5429 | @item mpfr_const_log2() |
5156 | 5430 | @end itemize |
5157 | 5431 | |
5158 | -次の例は、nullary 関数の使い方を示すだけでなく、算術オペレータのどのような実装にも付いて回る制限についてもはっきり示します。 | |
5159 | -有名な定数の Pi を 2 進数で 1000 桁になるまで表示するのが簡単なことに、あなたは驚かないでしょう。 | |
5432 | +次の例は、nullary関数の使い方を示すだけでなく、算術オペレータのどのような実装にも付いて回る制限についてもはっきり示します。 | |
5433 | +よく知られる定数Piを、2進数で1000桁になるまで表示するのが簡単なことは驚くことではありません。 | |
5434 | + | |
5160 | 5435 | @example |
5161 | 5436 | gawk -l mpfr 'BEGIN @{MPFR_PRECISION=1000; print "pi = " mpfr_const_pi() @}' |
5162 | 5437 | pi = 3.14159265358979323846264338327950288419716939937510582097494459230781640628620899862803482534211706798214808651328230664709384460955058223172535940812848111745028410270193852110555964462294895493038196442881097566593344612847564823378678316527120190914564856692346034861045432664821339360726024914127360 |
5163 | 5438 | @end example |
5164 | 5439 | |
5165 | -この例を、2 進数で 100 万桁になるまで Pi を表示するように簡単に変更できるでしょう (この計算に数秒余計にかかるだけでしょう)。 | |
5166 | -しかし、たった 4 ビットの精度での動作についてはどうでしょう。 | |
5440 | +この例を、2進数で100万桁になるまでPiを表示するように変更するのは簡単です(この計算に数秒余計にかかるだけです)。 | |
5441 | +しかし、たった4ビットの精度での動作についてはどうでしょう。 | |
5442 | + | |
5167 | 5443 | @example |
5168 | 5444 | gawk -l mpfr 'BEGIN @{MPFR_PRECISION=4; print "pi = " mpfr_const_pi() @}' |
5169 | 5445 | pi = 3.25 |
5170 | 5446 | @end example |
5171 | 5447 | |
5172 | -結果の @code{3.25} というのが間違いなのはわかっていますが、その間違いは本当なのでしょうか。 | |
5173 | -Pi の@emph{正しい}値というのは実際何@emph{である}のでしょうか。 | |
5448 | +結果の@code{3.25}というのが間違いなのは分かっていますが、その間違いは本当なのでしょうか。 | |
5449 | +Piの@emph{正しい}値というのは実際何@emph{である}のでしょうか。 | |
5174 | 5450 | 前の例にある値でしょうか。 |
5175 | 5451 | いいえ、それらの中に本当に@emph{正確な}ものはありません。 |
5176 | -他の多くの数値のように、Pi は無限に多い桁数を持っています。 | |
5177 | -そのような数値の浮動小数点の数値はすべて近似値としてだけ表現できます (仮数部が 4 ビットだけで、最近接値に丸めた場合 3.25)。 | |
5178 | -浮動小数点数でのいずれかの計算が、@emph{正確な}結果を返すならば、あなたは単に運が良かったのです。 | |
5179 | -@emph{正確な}結果というのは例外で、一般的ではありません。 | |
5452 | +他の多くの数値のように、Piは無限の桁数を持っています。 | |
5453 | +そのような数値の浮動小数点の数値は、近似値としてだけ全て表現できます(仮数部が4ビットだけで最近接値に丸めた場合、3.25)。 | |
5454 | +浮動小数点数でのいずれかの計算が@emph{正確な}結果を返すならば、単に運が良かったのです。 | |
5455 | +@emph{正確な}結果というのは例外であって、普通のことではありません。 | |
5456 | + | |
5180 | 5457 | |
5181 | 5458 | @node Unary Functions |
5182 | -@appendixsec Unary 関数 | |
5459 | +@appendixsec Unary関数 | |
5183 | 5460 | |
5184 | -unary 関数は、引数を一つ取って、便利な数値をいくつか返します。 | |
5185 | -これらの関数は、特定の関数の、与えられた環境 (選択された精度、基数、丸め) の下で可能な限り最良の近似値を提供するものです。 | |
5186 | -以下のリストの関数名が、何を意味しているのかを説明しているはずです。 | |
5187 | -疑問がある場合は、@uref{http://www.mpfr.org/mpfr-current/mpfr.html, MPFR library} のドキュメンテーションを参照してください。 | |
5461 | +unary関数は、引数を一つ取って、便利な数値をいくつか返します。 | |
5462 | +これらの関数は、特定の関数の、与えられた環境(選択された精度、基数、丸め)の下で可能な限り最良の近似値を提供するものです。 | |
5463 | +以下のリストの関数名が、何をするものなのかを説明しています。 | |
5464 | +疑問がある場合は、@uref{http://www.mpfr.org/mpfr-current/mpfr.html, MPFR library}のドキュメントを参照してください。 | |
5188 | 5465 | |
5189 | 5466 | @itemize |
5190 | 5467 | @cindex @code{mpfr_sqr} mpfr extension function |
@@ -5246,14 +5523,16 @@ Only available since version 2.2 of MPFR. | ||
5246 | 5523 | @item mpfr_frac(op) |
5247 | 5524 | @end itemize |
5248 | 5525 | |
5526 | + | |
5249 | 5527 | @node Binary Functions |
5250 | -@appendixsec Binary 関数 | |
5251 | -bina |
差分はサイズ制限により省略されました。全ての差分を見るためにはローカルクライアントを利用してください。