> ## Documentation Index
> Fetch the complete documentation index at: https://docs.abbyy.com/llms.txt
> Use this file to discover all available pages before exploring further.
# OCR品質がさまざまな文書で、既知または未知の形式の単一行fieldを検索する
> 正規表現とアルファベットを使用する Character String 要素を組み合わせることで、OCR品質がさまざまな場合でも請求書番号のような単一行fieldを検出します。
単一行fieldを検出するために、FlexiLayout Studio には専用の **Character String** 要素があります。fieldの形式が既知であれば、要素のプロパティで、**Character String** タブの **Regular expression** field にその形式を記述できます。
ただし、正規表現を使用するには、印字文書であり、かつ画質が良好であることが必要です。というのも、正規表現による記述ではfield内の誤りを許容できないため、少しでも誤りがあると要素は検出されないからです。
また、文書のlayoutを記述できる場合でも、手書きで記入された文書に正規表現を使用してはいけません。それでも、そのようなfieldを検出することは可能です。
## StructuredStrings.fsp サンプルプロジェクト
サンプルプロジェクト `StructuredStrings.fsp` では、すべてのページで類似した形式を持つ単一行field「請求書番号」を検索する方法を示しています (フォルダー `%public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\Structured strings`)。
このプロジェクトには4つのページがあります。
* **1ページ目と2ページ目** – field「請求書番号」は高品質で印字されています。
* **3ページ目** – field「請求書番号」は印字されていますが、画像にノイズがあります。
* **4ページ目** – 画質は良好ですが、field「請求書番号」は手書きで記入されています。
| 
| 
|
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 
| 
|
## 正規表現で請求書番号を記述する
field名を手がかりに **請求書番号** fieldを探します。まず、field名の検索条件を記述する要素が必要です。プロジェクトでは、これは **Static Text** 要素で、名前は **InvoiceNumberHeader**、値は `InvoiceN:` です。
**請求書番号** fieldは単一行fieldです。これを検出するために、プロジェクトでは **Character String** 要素 **NumAsRegularExpression** を使用します。プロジェクトのページを見ると、**請求書番号** fieldの形式は次の正規表現で記述できます。
```text theme={null}
NNNN"-"NN"-"[A-Z]"/"NN
```
または (同じ意味ですが)
```text theme={null}
[0-9]{4}"-"[0-9]{2}"-"[A-Z]"/" [0-9]{2}
```
これは、その番号が「4桁の数字 - 2桁の数字 - 1つのラテン大文字/2桁の数字」という並びであることを意味します。
プロジェクトを見ると、**Match** コマンドを選択して FlexiLayout のマッチング手順を実行した後、3ページ目と4ページ目では要素 **NumAsRegularExpression** に対して null 仮説が生成され、つまり要素は検出されませんでした。
3ページ目では、ノイズによってfieldと正規表現の間に不一致が生じました。3ページ目を開いてツールバーの **L** (**Show Recognized Lines**) をクリックすると、そのページ上の請求書番号の事前認識結果は `10&0-20-A/04` のように表示されます。
4ページ目では、請求書番号は手書きで記入されています。事前認識結果 (`Z.OOO-41-C/03`) も、記述された形式に一致していません。
## アルファベットを使用したフォールバック用の Character String 要素 を追加する
推奨される解決策は次のとおりです。**Character String** 要素 をもう 1 つ作成し、**NumAsAlphabet** という名前を付けます。この 要素 には、**NumAsRegularExpression** 要素 と同じ 検索条件 を指定します。次に、この 2 つの 要素 を 1 つの Group 要素 **InvoiceNumber** にまとめます。
ただし、**NumAsAlphabet** 要素 は 正規表現 としてではなく、有効な文字をすべて列挙したリストとして記述します。
次のコードを **Advanced pre-search relations** field に記述します。
```text theme={null}
if (NumAsRegularExpression.IsNull == FALSE) then Dontfind();
```
これは、**NumAsAlphabet** 要素で記述された形式不明の文字列の検索は、固定形式の文字列を記述する **NumAsRegularExpression** 要素で FlexiLayout Studio が検出できなかった場合にのみ実行されることを意味します。
**NumAsAlphabet** 要素の検索条件を指定する際は、ドラッグアンドドロップを使用して、**NumAsRegularExpression** 要素の **Relations** セクションの設定を現在の要素の同じセクションにコピーできます。あるいは、**Advanced pre-search relations** field に次のコードを記述することもできます。
```text theme={null}
if (NumAsRegularExpression.IsNull == FALSE) then Dontfind();
else RestrictSearchArea (NumAsRegularExpression.Rect);
```
このコードは、請求書番号の構造が指定した形式に一致せず、つまり FlexiLayout Studio が **NumAsRegularExpression** 要素を検出できなかった場合にのみ、**NumAsAlphabet** 要素の検索が実行されることを意味します。続いて、**NumAsRegularExpression** 要素が見つからなかったのと同じ領域で **NumAsAlphabet** 要素が検索されます。
次に、すべてのページで FlexiLayout マッチングを再度実行します。プロジェクトに示されているとおり、**請求書番号** field は各ページで正常に見つかるようになりました。
プロジェクトツリーには、**InvoiceNum** という名前のテキストブロックがあります。その **ソース要素** として、グループ `SearchElements.InvoiceNumber` が指定されています。この段階で、**請求書番号** fields を検出するための FlexiLayout は完成です。
何らかの理由で、前述のメソッドだけではデータfield (形式が既知か未知かを問わず) の検出に不十分な場合は、グループ内にもう 1 つ要素 (型は **Object Collection**) を作成できます。このプロジェクトでは、これは **NumAsObjectCollection** という名前の **Object Collection** 要素です。
このプロジェクトでは画像の品質が良いため、これは実際には不要で、単なる例として示しているだけです (これには **Disable** コマンドが指定されています) 。
追加の **Object Collection** 要素が必要になるのは、ページごとの事前認識結果の予測は難しくても、検索領域は正確に記述でき、不要な情報が仮説に入り込むのを防げる場合です。
## 正規表現が信頼性を向上させる理由
ここで、次のような疑問が生じるかもしれません。field が場合によってはそれなしでも検出できるのに、なぜ正規表現が必要なのでしょうか。答えは、正規表現を使うことで検索の信頼性が高まるからです。
この要素が見つかれば、必要なその行を見つけたと確信できます。この情報は、その後の要素やそれらのリレーションを検出するために安心して使用できます。検索条件が緩い場合は、必要なものを正確に見つけたと完全に確信することはできません。
これは、画像にノイズが非常に多い場合に起こることがあります。そのような場合、指定されたアルファベットを持つ **Character String** 要素を使用すると、エラー率 (**Percentage of non-alphabet characters** parameter) が高くなりすぎることがあります。
その結果、要素はまったく検出されないか、一部しか検出されません。そのような状況の例を次の図に示します。
