happyou.infoのブログ

ニュース収集サイトhappyou.infoのブログです。 国内外のあらゆる企業と組織、団体のウェブサイトの更新を収集します。 岡本将吾が運営しています。twitterは @happyou_info_ja です。

AWS Textractについて調べた

AWS Textractは、PDFデータや画像データに含まれるフォーム形式のデータ、または、表形式のデータを読み取り、機械判読可能なデータに変換するサービスです。

aws.amazon.com

2019年8月現在まだ日本語はサポートしていませんが、どのようなデータをパースできるのか実際に使ってみました。

条件

Excelで作成したデータをPDF形式で出力しAWS Textractにアップロードして認識させる。現実バージョンは、tabula-javaのテストに用いられているPDFデータをそのまま利用する。

  1. シンプルな表(罫線あり)
  2. シンプルな表(罫線一部のみ)
  3. シンプルな表(罫線なし)
  4. 複雑な表(罫線あり)
  5. 複雑な表(罫線一部のみ)
  6. 複雑な表(罫線なし→これはありえないのでパス)
  7. テキストの列挙
  8. 同じ構造の繰り返し
  9. 現実バージョン1
  10. 現実バージョン2
  11. 現実バージョン3
  12. 現実バージョン4

結果

(1) シンプルな表(罫線あり)

入力

f:id:happyou_info:20190716210654p:plain

f:id:happyou_info:20190717002958p:plain

出力

なし

評価: 表形式を認識できない。アラインメント(右寄せ)を調整してみたが認識できない。

(1-2) シンプルな表(罫線あり、大きなフォント)

入力:

f:id:happyou_info:20190801215725p:plain

出力:

f:id:happyou_info:20190801215836p:plain

評価:

大きなフォントに変換するとテーブルとテキストを認識する。

(2) シンプルな表(罫線一部のみ)

入力

[f:id:happyou_info:20190716210714p:plain

出力

f:id:happyou_info:20190801220528p:plain

f:id:happyou_info:20190716214928p:plain

評価: 表形式は認識できたが、正しく文字を認識できない。”col" の半角小文字の"L"を罫線と認識してしまっている。

(3) シンプルな表(罫線なし)

入力

f:id:happyou_info:20190716210728p:plain

出力

f:id:happyou_info:20190716215028p:plain

評価: 罫線がなくなると正しく認識できた!罫線が苦手のよう。

(4) 複雑な表(罫線あり)

入力

f:id:happyou_info:20190716210744p:plain

出力

f:id:happyou_info:20190716215043p:plain

評価:罫線があっても、parent, 2018, 2019を除くとほぼ正しく抽出できている

(5) 複雑な表(罫線一部のみ)

入力

f:id:happyou_info:20190716210757p:plain

出力

f:id:happyou_info:20190716215054p:plain

評価:

4に比べて精度が落ちている。

(6) 複雑な表(罫線なし→これは現実的にありえないのでパス)

(7) テキストの列挙

入力

f:id:happyou_info:20190716210807p:plain

出力

f:id:happyou_info:20190717010625p:plain

評価:パーフェクト

case7_2

入力

f:id:happyou_info:20190717001419p:plain

出力

f:id:happyou_info:20190717010543p:plain

評価:パーフェクト

case7_3

入力

f:id:happyou_info:20190717001449p:plain

出力

f:id:happyou_info:20190717001518p:plain

評価: 文字が認識できなくなる。

(8) 同じ構造の繰り返し

入力

f:id:happyou_info:20190716210837p:plain

出力

f:id:happyou_info:20190716215114p:plain

f:id:happyou_info:20190717011601p:plain

評価:

そもそもこの同じ構造を繰り返す形式はサポートしていないよう

(9) 現実バージョン1

入力

f:id:happyou_info:20190716210851p:plain

出力

f:id:happyou_info:20190716215124p:plain

評価: 親子関係が死んでいる以外はパーフェクト。フォントによるのかな?

(10) 現実バージョン2

入力

f:id:happyou_info:20190716210901p:plain
f:id:happyou_info:20190716210923p:plain

出力

f:id:happyou_info:20190717011850p:plain

評価:

パーフェクト。2ページ目は表と認識しないのも正解。

(11) 現実バージョン3

入力

f:id:happyou_info:20190716210937p:plain
case11

出力

f:id:happyou_info:20190716215147p:plain

評価

行が正しく認識できていない(odd行even行の色違いを認識しない)

  1. 現実バージョン4

入力

f:id:happyou_info:20190717005115p:plain

出力

f:id:happyou_info:20190717005131p:plain

評価:

4つのテーブルは認識しているが、行を認識できていない。

まとめ

  • テーブルにはキー(ヘッダ)とバリューが存在するが、現時点でのバージョンでは何がキーで何がバリューかを認識できない。
  • 一般的にPDFデータには文字情報が含まれているが、その文字情報は利用していないよう(もったいない)。飽くまで画像のOCR
  • 抽出できるかどうかはフォントに依存するよう。
  • CSVを生成するところでミスが多い。
  • 罫線が苦手のよう。

インボイスや申請書の認識(フォーム)の成績は結構よいとのことですので、表(テーブル)の認識はまだまだこれからのようですね。日本語版を作るのはおそらく大変でしょう。

happyou.infoの新元号対応完了

元号令和に対応しました。

令和1/5/1      Wed May 01 00:00:00 JST 2019 [令和1/5/1]
令和01/5/1        Wed May 01 00:00:00 JST 2019 [令和01/5/1]
R1.5.1          Wed May 01 00:00:00 JST 2019 [R1.5.1]
R01.5.01        Wed May 01 00:00:00 JST 2019 [R01.5.01]
令和01年5月01日        Wed May 01 00:00:00 JST 2019 [令和01年5月01日]
令和1年5月01日     Wed May 01 00:00:00 JST 2019 [令和1年5月01日]
令和元年5月01日       Wed May 01 00:00:00 JST 2019 [令和01年5月01日]
H31.4.30        Tue Apr 30 00:00:00 JST 2019 [H31.4.30]
H31.5.01        Wed May 01 00:00:00 JST 2019 [H31.5.01]
平成31年4月30日        Tue Apr 30 00:00:00 JST 2019 [平成31年4月30日]
平成31年5月1日     Wed May 01 00:00:00 JST 2019 [平成31年5月1日]
平成32年1月1日     Wed Jan 01 00:00:00 JST 2020 [平成32年1月1日]
令和2年1月01日     Wed Jan 01 00:00:00 JST 2020 [令和2年1月01日]
令和2年5月01日     Fri May 01 00:00:00 JST 2020 [令和2年5月01日]

マシンリーダブルな形式に変換するツール/サービス各種

HTML

import.io magicという、一部自動的にデータを抽出する機能があったのだが、見えなくなってしまった。 www.import.io

dexi,io dexi.io マニュアル

Diffbot www.diffbot.com URLと、ページの構造の種類(記事リスト、商品リスト、ビデオ)を指定すると構造を分析してJSONを出力

Apify www.apify.com

DATAFINITI Datafiniti | Intelligent Web Data for Data-Driven Businesses 企業/人物/製品/不動産のリスト

PhantomBuster https://phantombuster.com/ 各種ウェブサービスのデータ変換

PromptCloud www.promptcloud.com major ecommerce, travel and job portals

ウェブ系は他にもいくつもあるが、ツール系はの場合は、だいたいマニュアルで人間がスクレイピングする箇所を指定 しなければならず、近年進歩がないように思う。

PDF tabula PDF中にの表データを抽出しCSV形式に変換するOSS(Java) github.com

Camelot PDF中にの表データを抽出しCSV形式に変換するOSS(Python) tabulaとの違いは、マニュアルで抽出条件を指定することが指定可能な点 camelot-py.readthedocs.io

画像 Amazon Textract 文書となる画像に含まれている表形式の文書からデータを抽出するサービス いつ頃使えるんだろう? aws.amazon.com

ELIS インボイスのような書類をデータ化するサービス。サンプルの書類と、抽出されたデータの項目名 が異なっているところに注目した(自動的にマッピングが行われているよう)。 rossum.ai

スマートOCR www.smartocr.jp

サーバを更新しました。

これまでクローラはCentOS6.5で動作させていたのですが、CentOS7.4での動作に更新しました。 クロールに用いるウェブブラウザはPhantomJSとSWTの利用を止めてGoogleChrome headlessモードとFirefoxに 統一しました。 AdobeFlashの対応があるため、Firefoxは必要です。

APIサーバはCentOS6.5のままなので、いずれ更新を行わなければなりません。

現在FinalScraper2を開発しています。うまくゆくかどうかはわかりません。

やはり普及してはならないアンチスクレイピングサービス

この記事は、クローラー/Webスクレイピング Advent Calendar 2016 に参加させていただいています。昨日はL_e_k_oさんによるSelenium IDEで作ったテストをCLIで動かす方法でした。

 

さて、去年のspaceprobeさんのこの記事を読んで考えました。

qiita.com

地図帳や百科事典には、他社にコピーされたことを判別できるように、実用上は問題のない偽データ(たどり着くことの出来ない道路や存在しない言葉など)が埋め込まれているというのは有名な話です。
 

少し角度は違いますが、Tim Berners-Lee先生も「オープンデータも悪い人に加工されて不正確になったらマズいよね」とおっしゃっています。

https://www.theguardian.com/technology/2016/nov/01/tim-berners-lee-warns-danger-of-chaos-unprotected-public-open-data?CMP=share_btn_tw

 

以下に単純化したHTMLページを書きます。
 
sample.html

<div class="cls1">製品1、価格1、電話番号1</div>

<div class="cls2">製品2、価格2、電話番号2</div>

<div class="cls3">製品3、価格3、電話番号3</div>

 

sample.css

.cls3 {

     display:none;
}

cls3のページにアクセスした人は人間じゃないbot(*1). この製品3にアクセスした人には、次のページからところどころ価格を2割あげたデータを提示したり、電話番号を1ずらして表示すればいいんですね? それにそもそも製品3なんて世の中に実在しないんだけど、あなたそのデータどこから持ってきました?

(*1)今回はかなり話を単純化しています。実際にこれをやったら危険。
 
スクレイピングの需要が高まっているようです。気がつくと関連の書籍も色々出版されています。データの収集がカジュアル化するにつれ、「ウチのデータは顧客と潜在的顧客に提供しているのであって、同業他社さんにごっそりコピーされたくない」という需要が高まってくるはずです。
 
自社のウェブサイトをヒューマンリーダブルだけどマシンリーダブルにはしない。一般のユーザさんには影響がない程度の毒を自社サイトに混ぜることでコピーされるのを防ぐ、機械お断りというオープンデータとは真逆の流れが生まれてくるはずです。

この流れは強くなってほしくないですねー。メジャーなCMS向けにアンチスクレイピングプラグインとか、そういうのはリリースされないで欲しいです。予想外れてほしいです!
 
私は、私が2年前に書いたHTMLの構造を常に変化させる方法のほうがまだ良心的のように思えてきました。
このサービスは、私がアンチスクレイピングと認識しているものをhtml obfuscationと呼んでいるようです。価格表示だけ別サーバは大胆。色々あわせ技凄い。なるほど。
 

中華人民共和国大使館のスクレイピング

この記事は、クローラー/Webスクレイピング Advent Calendar 2016 に参加させていただいています。 昨日の記事は、anoChick さんによる AWS上にサーバレスな汎用クローラを展開するぞ。 - あのにのに  でした。

--

happyou.infoでは、中国政府のサイトをスクレイピングしています。

今回はその中でも中国政府の大使館や領事館のウェブサイトの更新情報を検出しRSS化しましたので公開したいと思います。

 

Q: なぜ中国大使館のスクレイピングを行うのか?

1.意味があるため

中国政府が対外的に発信する情報を網羅的に収集することには社会的に意味があると考えらるため。

 

2.ウェブサイトがマシンリーダブルでないため

中国政府のウェブサイトはマシンリーダブルでないため。RSSはなく、TwitterFacebookの利用も体系的には行われていないため。

 

3.happyou.infoが得意な分野であるため

たとえば、日本の東京にある中国大使館のサイトは、アメリカのワシントンにある中国大使館のサイトとはデザインが異なります。イタリアの大使館サイトはまた別のデザインです。

中華人民共和国駐日本国大使館

Embassy of the People's Republic of China in the United States of America

中华人民共和国驻意大利共和国大使馆

このようなサイトが 言語別にわけると約500近くあります。 これらのサイトを手作業でスクレイピングするのは大変ですが、happyou.infoは全て自動で収集することが出来るためです。*1

---

 これが入力元のサイト一覧です。

Missions Overseas

そして、これが現時点でのスクレイピングの結果です。

All Chinese embassies and consulates

  • 諸事情により中国語、英語、日本語以外の言語については生成していません。
  • 更新の半分くらいは 中国の外交部(日本の外務省に相当する)のプレスリリースがそのまま書き写されています。中国本国のリリースを中国語と現地の公用語で発信しているコピペです。
  • 残りは2国間関係のニュース、大使の講演や発言、中国関連のイベントの告知など。
  • 継続して収集しているのでわかるのですが、2016年の7月あたりを最後に、南シナ海に関する情報発信を発信を止めちゃったようです。
  • 在北朝鮮大使館の英語版のサイトの更新が止まっていて物悲しい。私は読めないけれど韓国語版も止まってる。仕事しろ同盟国じゃろ…

一つ一つのニュースはあまり面白くなく、とても意味があるとは思えません。しかしこれらを蓄積して分類しアーカイブ化すると価値が生まれることを知っています。

 

中国政府のスクレイピングで、クローラの多言語化にかなり対応できたのではないかと考えています。今回の成果をもとに去年失敗したNASDAQ全銘柄スクレイピングにもう一度挑戦してみるつもりです。

以上です。

*1:少なくとも民間レベルでは他に存在しないと考えています。