TEIガイドラインP5

非ユニコード文字とXMLプロセッサー非ユニコード文字とXMLプロセッサー¶

しかしながら、準拠XMLプロセッサが文字集合がユニコードではない文書を扱う仕方には厳しい制限がある。これらの制限が理解されていないならば、まだ全面的にユニコードに関与する準備のできていないプロジェクトは、レガシーな文字エンコーディングを操作しようとするときに予期しない困った問題に陥ってしまうであろう。第一に、XML標準におけるいかなるものも準拠プロセッサに非ユニコード文書を処理することを要求することはない、ということは繰り返されなければならない。しかし、たとえそれを根拠に非ユニコード文書を処理することを拒むような実際のプロセッサがあったとしても、一見そう見えるほどひどくはその利便性を制限することはないであろう。その理由は、内部的にユニコードコードポイントを表示する方法があるからである。(詳細は以下のUTF-8に関連したエンコーディングエラーで説明される) その場合、実際に7ビットのみを用いるASCIIで符号化された文書と、ユニコードで符号化されてはいるが単に7ビットASCII標準に取り囲まれた抽象文字をたまたま含んでいる文書との間には、見つられるような違いは何もない。そして、XML標準は、ユニコードを表示するこの方法が、プロセッサがあるエンコーディングを明確に宣言していない文書にとってのデフォルトとして仮定しなければならないものである、ということを明記している。一挙にこの規定は、純然たる7ビットASCIIで符号化された文書をすべてあらゆるXMLプロセッサがさらなる苦労なく処理することができる、ということを保証しているのである。これに加えて、XML標準の中でもそうであるが、どんなユニコードコードポイントでも数値文字参照 (NCR) を通して7ビットASCII文字のみを使用して間接的に明記することを可能にしている規定とその結果は、7ビットASCII領域外のいかなる文字でもNCR記法でユニコードコードポイントとして書き換えるよう前処理することのできる (そのためのソフトウェアが容易に利用可能な単純なバッチ処理) 非ユニコードエンコーディングのすべての文書を、ユニコード以外のエンコーディングへの組み込みのサポートを全くもたないプロセッサによってさえ扱うことができるということである。

実際、これまで公開されたどのXMLプロセッサも、必須ではないけれども標準の中に明記された、少なくともいくつかの非ユニコード文字集合での文書の処理を許可する方法を実装してきた。そのようなプロセッサはそのドキュメンテーションの中にサポートする非ユニコードエンコーディングの宣言を含んでおり、そのようなエンコーディングを使用することがプロセッサに対して正しい方法で宣言されなければならない。

そのようなエンコーディングサポートを利用する時の混乱を避けるためには、あるXML文書の中のエンコーディング宣言が実際単純に宣言であって、それが後続の文書を当該のエンコーディングへと魔法のように変換する呪文ではない、ということを理解することがまず最初に必要である。単純にある文書のエンコーディングを例えばISO-8859-1 (あるいはそれならUTF-8やUTF-16でも、そのサポートが必須であるようなユニコード表示) であると宣言することが‘そうする’ために充分であると考えることは、共通の誤りである。そのような宣言は実際に後続する文書が宣言に準拠して厳格に符号化されなければ役に立たないものである。実際にはそのようなことにならないような状況のいくつかは、以下のユニコード内部表示から生じる問題において概説される。第二に、あるエンコーディング宣言はあるXMLプロセッサをその宣言が及ぶ限りそのエンコーディングで完全に動作するモードにどうにかして切り替えるわけではない。それどころか、その宣言されたエンコーディングのコードポイントをすべてユニコードの対応するものに直ちに変換するフィルタに入力を通すようプロセッサに指示するだけである。その時点以降、すべての後続する処理段階で見られるような文書は、たとえそのことが使用者にとって一見わからなくても、実際にはユニコードのものなのである。第三に、この不変の内部変換には決定的な帰結がある。あるプロセッサがある非ユニコードエンコーディングの文書をうまく受け取ることができるということが、その出力を元の宣言された入力エンコーディングに必ず変換するということを意味しない、ということである。内部的に、その文書がユニコードに変換され処理されたが、逆変換を出力段階で実行することを要求するものはXML標準には何もない。ほとんどのプロセッサは標準を越えて多様なエンコーディングで出力する手段を提供しているが、それが利用できるかどうか、どのように使用するのかということはそのプロセッサのドキュメンテーションから確認しなければならない。それが利用できないあるいは信頼できないとすれば、文字コンバータを通して元のエンコーディングを復元するよう後処理する必要があるかもしれないが、そのようなソフトウェアは自由に利用でき、使用するのも容易である。

XML文書における非ユニコード文字XML文書における非ユニコード文字¶

前節において考えられたケースにおいては、入力文書の非ユニコード文字集合に含まれている各々の抽象文字に対応するふさわしいユニコードコードポイントがあった。そのような事例においては、プロセッサによって実行された必要な内部的なユニコードへの変換が、非ユニコード文字集合で作業を続けようと望む使用者にとって多かれ少なかれ明白でありうる。非ユニコード文字集合がユニコード標準におけるコードポイントをもっていないような抽象文字を含む時、あるいは、終始ユニコードでの作業を試みているあるプロジェクトが、ユニコード標準において現在のところ提供されていない抽象文字を表示する必要があるとわかった時には、事態はかなり異なってくる。ここではSGMLとXMLの間の重要な違いがかなり困難な仕方で浮かび上がってくるのである。

実装するのに相当より容易であるSGMLのサブセットを考案するための彼らの指針にしたがって、XML規格の著者たちは内部SDATA実体として知られているSGMLで利用可能なある特定の型の実体をXMLにもち越すべきではないと決定した。ここでその決定に異議を唱えることは無益であろうが、しかしユニコード定義のない抽象文字の扱いに対するその結果は重要であった。

我々がローカルに定義された抽象文字と呼ぶものを符号化し、処理し、交換するためにこのガイドラインの以前の版で推奨された手順は、SDATA型のものとして宣言された実体を利用できることに頼っていたが、その型はXMLにおいてサポートされていない。したがって、XMLベースのプロジェクトにとって以前に提供された推奨された処置に対応するものは全く用意されていない。³¹ XMLの実体は実際には二つの基本的な型があるだけである。パースされたものとパースされていないものである。パースされていない実体はここでは何の関連もない。あるXML文書におけるパースされた実体への参照は、ある種の挙動のみに帰結する。それらがパーサの入力ストリームに現れる時、パーサは、その実体名をその代替テキストに対応づける文書の内部あるいは外部のサブセットの中の宣言を見つけることによってそれらを解決できることを期待する。パーサはそれから、代替テキストを実体参照の代わりにその文書に挿入し、その実体参照は跡形もなく捨て去られる。置換処置は、その実体が宣言されていなかったり、その宣言がある面で不完全であったりする (その場合パーサは致命的エラーの信号を発し停止する) ために失敗する場合以外は、アプリケーションに通知されることはない。

説明上の便のために、いっそうXMLに関連するドキュメンテーションは、このガイドラインも含めて、文字実体と文字実体参照には明確に言及するが、XMLにおける文字実体は、‘型’がコンピュータ科学用語法で理解されているという意味でのはっきりした‘型’ではない。例えばある属性の型に言及する場合である。したがって、挿入されることになる代替物が実際、マークアップを含むこともありうるテキストの任意の塊というよりもむしろ、単一の文字あるいはそれに相当するものであることを、編集ソフトウェアあるいはその他のソフトウェアが検査できるような方法は全くない。文字実体とは単純に、その代替テキストがある文字価あるいはその値を表示するあるNCRとしてたまたま宣言されている一般的な実体である。このことは、そのような実体参照をユニコード対応をもたないある文字を表すために使用するつもりであるとすると、二つの重要な帰結をもつ。第一に、実体名参照はパースの初期段階で消えてしまい、宣言された実体の値に置換されることになる。その結果、パースされた文書の中で元々入力された通りに実体参照にアクセスすることを必要とする処理は全く不可能である。第二に、もしある文字実体が普通の文字に真に等しいものとして使用され、結果としてある単一の文字が正当に起こりうる文書のあらゆる場所で (ただし要素名と属性名の中は別である。そこではいかなる参照も認められない。) 用いられることになるとするならば、その時には、その代替値が実際純粋な文字データであるということは不可欠である。もしその実体の代替値が何らかのマークアップやあるいは処理の指示を含んでいるとしたならば、ある文書の中に、単一の文字データは正当であるが、マークアップや他の代替が文書を無効あるいは整形式でないものにしてしまいうるような箇所が多くあることになるであろう。まとめると、これらの考察は、XML文書の中で非ユニコード文字を表すためのCERの明白な使用が単純に可能でないことを意味している。

互換文字TEI: 互換文字¶

ユニコードの原則は実用主義によって思慮分別をもって和らげられている。このことは、中でも、標準が符号化する実際の文字レパートリー、特にその初期の時期から始まるそれらの部分が、ユニコードコンソーシアムの理論的アプローチの厳格な解釈の上に本来抽象文字としてみなされてこなかったたくさんのものを含んでいる、ということを意味している。これらの文字のいくつかは互換文字に割り当てられたコードポイント領域に一緒に分類されている。合字は好例である。合字 (例えばラテン文字の近接する小文字‘s’と‘t’あるいは‘f’と‘i’がある。一筆一筆の間でペンをあげない筆記慣習によって生み出されたのか、タイプデザインの美学によって要求されたのか) は結合している二つの文字以上に付加された意味論的価値のない表象的素性である。(ただし古文書学者や活版印刷術の歴史家にとって、与えられたマニュスクリプトや版にそれらが存在することやその形は学術的重要性をもつこともある。) しかしながら、ユニコード標準が最初に議論されるまで、より一般的な合字を表示する単一のグリフを組版装置や高級プリンターのレパートリーに含めることは一般的な慣習となっていた。そしてたとえそれらが二つの異なる抽象文字を表示するものであっても、それらの装置に組み込まれた符号化文字集合がそのようなグリフのために単一のコードポイントを使用することもそうであった。そのような装置の製造者と使用者の間でユニコードをますます受け入れさせるために、そのような擬似文字をユニコードに編入するべきであるということが同意された。それにもかかわらず、あるプロジェクトがそのような合字形の存在を符号化する必要をもつならば、通常マークアップを通してなされるべきであって、互換文字を使用してなされるべきではない。そうして、合字の存在は、依然として適切な場所で識別されうる (そして望むならば視覚的に表現されうる) のであるが、索引生成や検索のソフトウェアはその文書の中のコードポイントを当該の二つの構成要素となる文字が単に連続して現れたものとして扱い、またそうして正しくそれらの意味を非合字の対応する物と連携させるであろう。そのような合字は、フランス語の“cœur”においてそうであるように、(普通) 二重母音を指示する際の、二重音字と混同すべきではない。二重音字は本来抽象文字を表示する極小の正書法の単位であって単純にグリフの合成であるわけではなく、索引生成や検索のソフトウェアはそれをそのようなものとして扱わなければならないのである。ある二重音字がある元テキストにある場合、適切なCERであれNCRであれ当該文字を直接的に入力することによって、それが実際表示する単一の抽象文字に対する適切なコードポイントを使用して通常符号化されるべきである。

前もって組み合わされた文字・組み合わせ文字と正規化TEI: 前もって組み合わされた文字・組み合わせ文字と正規化¶

ユニコードの中のダイアクリティカルマークを伴う文字の扱いは、厳格さと実用主義の同様の組み合わせを示している。ラテン文字やその他の字体でダイアクリティカルマークを伴う多くの文字をコードポイント列によって表示することがもっともらしいのは充分明白である。その場合、一方のコードポイントが基本となる文字を指示し、残りが当該の抽象文字のにふさわしいグリフ表現を生み出すために基本となる文字と組み合わされる一つあるいはそれ以上のダイアクリティカルマークを表示するのである。その初期段階から、ユニコードコンソーシアムは理論上この見解を支持したが、実用面では、既に一般的に現存のエンコーディングスキーマにおいて単一の他と区別されるコードポイントを割り当てられてきた前もって組み合わされた文字に単一のコードポイントを割り当てることによって妥協するよう準備がされていた。しかしながら、このことは、かなり多くの一般に現れる抽象文字にとって、ユニコードが二つの異なってはいるが論理的・意味論的には等しいエンコーディングをもっているということを意味している。前もって組み合わされた単一のコードポイントと、基本となる文字に加えて一つ以上の組み合わせのダイアクリティックというコードポイント列である。最近ユニコードに追加された字体は、もはやこのコードポイントの重複を示すことはない (現在の慣習では、組み合わせ文字の使用が可能である場合、前もって組み合わされた新たな文字は何も定義されることはない) が、そうであるからといって、その文字集合の古層において永久的に具体化された重複によって引き起こされる問題が取り除かれるわけではない。ある東アジア文字のエンコーディングから生じる本質的に類似した問題とともに、この重複はユニコード文書の正規化を実行する必要性を提起している。正規化とは、ある与えられた抽象文字が、ある与えられたユニコード文書あるいは文書コレクションの中でのみ、単一の方法で表示されているということを保証する処理である。ユニコードコンソーシアムは四つの標準正規化形式を提供しており、そのうち、正規化形式C (NFC) がテキストエンコーディングプロジェクトにとっては最も適切であるように思われる。ワールド・ワイド・ウェブコンソーシアムは、Character Model for the World Wide Web 1.0(http://www.w3.org/TR/charmod) という文書を作ったが、それは、中でも、正規化の問題を議論しており、いくつかの関連する原則を概説している。権威ある参考文献はUnicode Standard Annex #15 Unicode Normalization Forms (http://www.unicode.org/reports/tr15/) である。個別のプロジェクトは正規化の必要性に関する自分たちの決定が、当面ハードウェアやソフトウェアが組み合わせ記号を使用して符号化された抽象文字を正しく表現することは (あるいは整合性をもって識別することさえ) 決してできないという事実によってどれほど影響されるか、ということを決定しなければならないであろう。しかしながら、上記文書で議論されたような正規化は、ハングルの組み合わせ文字に関連した問題に対する以外では、東アジア文字に関して上述した問題を扱うわけではないということは注意すべきである。

どのユニコードベースのプロジェクトも、包括的かつ首尾一貫した正規化の慣習に関して同意し、整合的に実装し、充分に記述すべきである、ということは重要である。あるプロジェクトの中でのデータの完全性を保証するのと同様に、整合的に実装され、適切に記述された正規化の方針は、うまく文書を交換するには不可欠なのである。

文字の意味TEI: 文字の意味¶

ユニバーサル文字集合自体に加えて、ユニコードコンソーシアムは付加的な文字の意味に関するデータベースを維持している。(http://www.unicode.org/ucd/) これは各々の文字コードポイントとそれに対する基準素性の名前を含んでいる。文字素性は、このデータベースで得られるように、意味と、したがってあるコードポイントあるいは文字の所期の使用法を決定する。それはまた、この文字を異なった目的で正しく処理するのに必要とされうる情報を含んである。このデータベースはどのユニコードポイントをある文字を符号化するのに使用するのかということを決定する際に重要な参考文献である。

ユニコードコンソーシアムによって入手可能となっている印刷されたドキュメンテーションとリストに加えて、それが含む情報は、ウェブ上のたくさんの検索システムによって入手することもできる。(例えばhttp://www.eki.ee/letter/) データベースに含まれている文字素性の例は、格・数値・指向性・どこで‘互換文字’として利用できる状態があるかを含んでいる。(詳細はFreytag (2006)を参照) あるプロジェクトがPUAのコードポイントでローカルな文字定義を行う場合、当該の文字に関するどんな関連する付加情報も、5 標準化されていない文字と字形の表現で詳しく議論されているのと類似の方法で記録することが望ましい。

UTF-8に関連したエンコーディングエラーTEI: UTF-8に関連したエンコーディングエラー¶

ユニコード3.0以降によって割り当てられたコードポイントは概念上32ビット整数であり、コンピュータストレージ上で各々そのような整数を表示する最も率直な方法は4つの8ビットバイトを使用することであろう。ラテン文字で最も一般的に使用される文字のコードポイントの多くは、1バイトだけで表示され、一般的に使用される大多数 (最も頻繁に使用されるPUA領域から割り当てられたものも含む) は2バイトのみで表現されうる。これがUTF-8とUTF-16との使用とXML標準におけるその特別な地位の理由となる。UTF-8とUTF-16は32ビットコードポイントを経済的に表示する方法なのである。

UTF-8は可変長エンコーディングである。基礎となるコードポイントの中で重要なビットが多いほど (あるいは日常的用語法では文字を表示するために使用される数が大きいほど)、UTF-8は多くのバイトをそれを符号化するために使用する。UTF-8をXML文書のデフォルトエンコーディングとしてラテン文字を表示し、その状態を説明するために特に魅力的にしているものは、7ビット以下で表現できるすべてのコードポイント (元のASCII文字集合にある127の値) もUTF-8では同じ7ビット以下のビットとして (したがって単一バイトで) 表現されることである。そういうわけで、実際には純粋な7ビットASCIIで符合化されている文書を改変なく、またそのエンコーディングを明示的に宣言することなく、XMLプロセッサに送ることができるのである。プロセッサはそれをユニコードのUTF-8表示のものであるとみなし、かつそれを根拠に正しくそれを扱うことができるのである。

しかしながら、ラテンベースの字体の範囲の中でも、ASCIIに対する8ビット拡張からの文字を使用する文書をもつプロジェクトもある。例えば、ISO-8859-nエンコーディングシリーズである。ISO-8859-nのもとで8ビットすべてを使用する文字がUTF-8で符号化される仕方は著しく異なっており、困惑させるようなエラーを提起する。最上位ビットがセットされる単一バイトコードポイントをもつ抽象文字 (つまり、129～255の十進法表示をもつ) はISO-8859-nではコードポイントと同じ値で単一バイトとして符号化される。しかしUTF-8では、その範囲内のコードポイントの値は2バイトの列として表現される。つまり、当該の抽象文字は、ファイルあるいはメモリーの中で、もはやそのコードポイントの値と同じ数で表示されることはないのである。それは二つの異なった数の列へと変換され (transformed)る。 (したがってUTFのTである。) 今や、そのようなUTF-8列が基礎となるコードポイントの値に由来する仕方の副作用として、ISO-8859-nエンコーディングで用いられる単一バイトの8ビットの値の多くがUTF-8では不正なものなのである。

この複雑な状況は単純な帰結として大きな当惑をもたらしうる。XMLプロセッサはパーサに対して宣言することが必要なそのエンコーディングがないと、7ビットASCIIとして文字データを易々と扱い、同様に、ISO文字集合の厳密なASCIIサブセット外の文字をたまたま使用していないならば、宣言されていないISO-8859-nエンコーディングで符号化された文書を受け入れてしまうであろう。しかし、文書のエンコーディングが明示的にかつ正しく宣言されていない限り、入力ストリームにおいてISO-8859-n集合からの8ビット文字に出会った時、パースは直ちに失敗してしまうであろう。明示的にエンコーディングを宣言することが問題を解決するはずであるが、そのファイルが一貫して正しく符号化されていれば、そうするであろう。しかし、テキストエディタとワードプロセッサは現在もっているユニコードサポートの程度も割合も異なっているから、プロジェクトがUTF-8で符号化されたファイルを例えばISO-8859-1の他のものと一緒に扱わなければならないということに気づきそうである。そのようなエンコーディングの違いは、特に内部エンコーディングが区別できる文字の割合が比較的小さいならば (例えば長い英語のテキストで少量のフランス語の単語をともなう場合) 気づかれないままになるかもしれない。もし文書を準備する過程でそのような二つのファイルが組み込まれたり、‘切り貼り’手法を介して混合されたりしたならば、結果としてのファイルの内部エンコーディングが同様に混ざったものとなっている可能性があまりに高い。場違いの‘使い勝手’の概念のおかげで、現在の編集ソフトウェアの中にはテキストを表示する時に黙ってそのような誤った符号化を訂正してしまうものもあり、その結果、XMLパーサが致命的な‘無効な文字’のエラーを出して終了するまでその誤った符合化が隠れたままになってしまうのである。

誤って混合されたエンコーディングがそのようなエラーの元となる場合、エンコーディング宣言を変えても、そうすることがその問題をわかりにくくするかもしれないけれども、問題を解決することはない。UTF-8として宣言されたあるファイルの中の8ビットの文字コードが常にパーサを止めてしまうであろう。さらに油断のならないことに、ISO-8859-1として宣言されたあるファイルの中のUTF-8列はパースを止めてしまうことはなく、データの損傷を引き起こしてしまう。パーサはすべてのUTF-8列の各々のバイトを黙って、しかし誤って、偽りの別々の文字に変換してしまう。そのことが意味論的なエラーを引き起こしても、一連の処理の中のずっと後になるまで一見して明らかなものとはならないこともある。

非ラテン文字の文書を日常的に扱うプロジェクトにおいては、すべての人が正確で整合性をもったエンコーディングを確実にする必要があることに充分気づいている。混合エンコーディングの問題がめったに起こらないような場所や、容易にその問題を識別し、対処するような場合には、そうである。しかしながら、本当の混乱は、その問題への意識が低いプロジェクトにおいて起こりがちである。なぜならば、そうしたプロジェクトは主としてアクセントのないラテン文字を用い、アクセント付きの文字あるいはその他の‘特殊な文字’、つまりISO-8859-nとUTF-8での内部的な表示が異なっているもの (たとえばコピーライト記号や、最終的なHTML出力が思い描かれる際にしばしばトラブルメーカーとなる‘ノーブレークスペース (non-breaking space)’)、はまばらにあるだけである。そのようなプロジェクトが自らを英語文書のみに関わるものと見なしていても、あるいは特にそう見なしている場合には、XMLとユニコードの近接した関係は、そのプロジェクトがこれらのエンコーディングの問題を理解し、コード変換と検証のために適切なソフトウェアを使用することを含む、エンコーディングとその正しい宣言との整合性と完全性を保証する手続きを開発することが必要であるということを意味している。

UTF-16に関連したエンコーディングエラーUTF-16に関連したエンコーディングエラー¶

以上で概説したユニコードコードポイントの内部表示としてのUTF-8の利点は、文書がラテン文字・キリル文字・ヘブライ文字以外の字体である場合には通用しない。16ビットの領域 (2バイト) のコードポイントをもつ文字が主な場合、UTF-8は適切ではない。各々の抽象文字を表示するには三つ以上のバイトが必要であるからである。この場合、より好ましいユニコード表示 (ただしすべてのXML準拠パーサがサポートしていなければならない) はUTF-16である。その場合、抽象文字に対応する各々のコードポイントは二つの8ビットバイト³²で表示される。このエンコーディングは別の危険をもたらす。編集ソフトウェアのユニコードサポートが比較的均質ではなく未成熟である場合は特にである。そのコードポイントは (ほとんどの大衆的なコンピュータで) 二つの別々のバイトに保存された16ビット整数として表示されるから、それらのバイトが保存される順序が重要となる。これは基礎となるハードウェアに依存する。卓上のコンピュータ利用の範囲では、例えば非インテルのマッキントッシュの機械は (メモリ上でと同様ディスク上でも) 16ビット整数を高位バイトを最初にして表示するバイトの組を保存するが、PCともっと最近のマッキントッシュのインテルプロセッサを使用するシステムは逆順でバイトを保存する。(このことはしばしばスウィフトの命名によるビッグエンディアン対リトルエンディアンバイト順として言及される。) このことは、UTF-16で符号化された意味上同一のプレーンテキストファイルがマッキントッシュとPCで準備され、その二つのファイルがディスクに保存される場合、一方のファイルの各々のバイトの組がもう一方のファイルの対応するバイトの組と逆の順序になっているであろう、ということを意味している。その明らかな非互換問題を避けるために、XML標準は、宣言されたエンコーディングがUTF-16であるすべての文書に、それ自体は文書の一部ではなく、単に後続する文書のバイト順をプロセッサが決定するためのバイト順マーカー (BOM) である特別な擬似文字を伴うことを要求している。正しいBOMが挿入され、そのファイルを通して一貫してバイト順が維持されることは、ソフトウェアが透過的に注意するべきであるが、経験上、ビッグエンディアンとリトルエンディアンのハードウェアをまたいで作業が配布される環境では特に、現在のソフトウェア開発の状態では必ずしも当然のものと考えることはできない。UTF-8を含む混合エンコーディングの問題と同様、UTF-16のファイルの一貫性をもたないバイト順は、バイト順の完全性を正しく強制しないソフトウェアを使用してファイル間で組み込んだり切り貼りしたりした結果であるように思われる。そのこともバイト順の一貫性を使用者から隠してしまう見当違いの‘使い勝手’によるものである。今一度繰り返せば、その結果が、あるエディタでは正しく見えるが、XMLパーサがすぐさま拒絶したり、あるいは黙ってひどく歪曲された形で通してしまうファイルである。さらに、それに続くエラーを避けるためには、関連するエンコーディングの問題に関する見識のある自覚を啓発し、最初にそれらを避け、早期の段階で検知する方策を考案する必要があるのである。