質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.35%
HTML5

HTML5 (Hyper Text Markup Language、バージョン 5)は、マークアップ言語であるHTMLの第5版です。

JavaScript

JavaScriptは、プログラミング言語のひとつです。ネットスケープコミュニケーションズで開発されました。 開発当初はLiveScriptと呼ばれていましたが、業務提携していたサン・マイクロシステムズが開発したJavaが脚光を浴びていたことから、JavaScriptと改名されました。 動きのあるWebページを作ることを目的に開発されたもので、主要なWebブラウザのほとんどに搭載されています。

HTML

HTMLとは、ウェブ上の文書を記述・作成するためのマークアップ言語のことです。文章の中に記述することで、文書の論理構造などを設定することができます。ハイパーリンクを設定できるハイパーテキストであり、画像・リスト・表などのデータファイルをリンクする情報に結びつけて情報を整理します。現在あるネットワーク上のほとんどのウェブページはHTMLで作成されています。

Q&A

解決済

5回答

5091閲覧

iframeの必要性

moomoom

総合スコア19

HTML5

HTML5 (Hyper Text Markup Language、バージョン 5)は、マークアップ言語であるHTMLの第5版です。

JavaScript

JavaScriptは、プログラミング言語のひとつです。ネットスケープコミュニケーションズで開発されました。 開発当初はLiveScriptと呼ばれていましたが、業務提携していたサン・マイクロシステムズが開発したJavaが脚光を浴びていたことから、JavaScriptと改名されました。 動きのあるWebページを作ることを目的に開発されたもので、主要なWebブラウザのほとんどに搭載されています。

HTML

HTMLとは、ウェブ上の文書を記述・作成するためのマークアップ言語のことです。文章の中に記述することで、文書の論理構造などを設定することができます。ハイパーリンクを設定できるハイパーテキストであり、画像・リスト・表などのデータファイルをリンクする情報に結びつけて情報を整理します。現在あるネットワーク上のほとんどのウェブページはHTMLで作成されています。

2グッド

7クリップ

投稿2020/02/03 06:37

編集2020/02/03 07:29

ブログなど運営していると外部サイトの埋め込みがよくありますが、このときURLをiframeで表示するメリットはなんでしょうか?

自前でスクレイピングしてURLからサムネイルとタイトルを取得してDBに入れてそれを表示するという方が読み込みも早いと思うのですが。

これらの手間をはぶくためのiframe、という程度のメリットでしょうか?

YouTubeなどJSでの動きがあるコンテンツを埋め込む場合を除けば、iframeで表示するよりも、スクレイピングしてDBに入れておいたものを表示する方がいいですよね?

※※※補足※※※

私は"スクレイピング"を以下のことだと認識しておりました。

”PHPで「https://github.com/scottmac/opengraph」を使い、URLからタイトルとサムネイルを取得すること”

間違いあるかと思いますが、このことについてお伺いできましたら幸いです。

makosankibu, ikatako👍を押しています

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Lhankor_Mhy

2020/02/03 06:41

著作権法の観点からは「複製」に当たるかと思いますが、そういうコンプラに関する回答は不要ですか?
moomoom

2020/02/03 06:51

ありがとうございます。ブログでよくある「ページを紹介する」という程度なので「引用」の範疇というつもりでおりました。しかし「DBに入れたものを表示する」とそれが「複製」にあたるとは、勉強不足でした。そしてiframeならその心配が無用なのですか。なるほど。大変参考になりました。
moomoom

2020/02/03 07:04

うーん、この判例が根拠ならば、特にタイトルとサムネイルをDBに入れても問題とは思えません。WEBサイトの記事の数十字程度のタイトルが著作権で保護されるとは考えにくいですし(それだけを集めたサイトなら問題ですが明らかに引用と判断されるでしょうし)、そしてサムネイルはURLで保存するのでその出力はこの判例と同じ意味ですから。もしくは他に「複製」とされうる根拠はございますか?
Lhankor_Mhy

2020/02/03 07:27 編集

どうやら、「スクレイピング」という言葉の認識に差異があるようですね。 個人的には、「タイトルとサムネイル」を保存するのに、スクレイピングという言葉を使わないです。 とはいえ、サムネイル、つまりブラウザ表示のスクリーンショットは「複製」にあたるでしょうね。違法になるかどうかはともかくとして。 https://ec-houmu.com/right/chosakuken_thumbnail.html#i-4
moomoom

2020/02/03 07:26

たしかに私はその言葉をよく理解せず使っていたふしが大いにあります。申し訳ございません。 ここで私の認識を述べさせていただきます。 ”PHPで「https://github.com/scottmac/opengraph」を使い、URLからタイトルとサムネイルを取得すること” わたしはこれを指して呼んでいたので、よろしければこれが「複製」やその他の法律的ないし倫理的問題にあたるとお考えでしたら、恐れ入りますが改めてお伺いしたいのですが。
Lhankor_Mhy

2020/02/03 07:28

ああ、ごめんなさい、五月雨式にコメントを追加してました。 そちらをご覧いただければ。
moomoom

2020/02/03 07:32

ありがとうございます。拝見しました。タイトルはともかくサムネイルの問題ということですね。 しかし「>サムネイル画像をサイトにアップロードする行為」ではなく「サムネイル画像のURLをサイトに保存する行為」なので、これはご提示のサイトによれば「複製」には当たらないと理解できそうですね。
moomoom

2020/02/03 07:36

ところで、先に述べました私のいう”スクレイピング”ですが、これは実行時に相手サイトに不正なJavaScriptがあっても危険はないのでしょうか? これだけ広まっているgithubのプラグインなので平気っぽい(←安易w)ですが、なぜ平気なのかと疑問です。"スクレイピング"したら、相手サイトのJavaScriptは実行されてしまいますよね?
Lhankor_Mhy

2020/02/03 07:45

> これはご提示のサイトによれば「複製」には当たらないと理解できそうですね。 それは読みが違うと思いますが、まあ、私も専門家ではないので間違っているかもしれません。 > 不正なJavaScriptがあっても危険はないのでしょうか? 大丈夫でしょう。問題になるのはコードを送信した場合なので。
moomoom

2020/02/03 07:51

>それは読みが違うと思います 違うと思いましたか?「サムネイル画像のURLをサイトに保存する行為」が「複製」にあたるとは、どのようにお考えになられましたでしょうか。ご面倒とは思いますが、個人的ご意見でかまいませんので、よろしければ後学のためにお聞かせいただけますと幸いです。 >大丈夫でしょう。 なるほど。つまりgithubのプラグインは、相手サイトのコードは私のブログに送信せず、タグだけを送信する、という感じでしょうか。 そしてあなたはスクレイピングを前者の意味で正しく捉えていて、私は後者もスクレイピングだと誤解していた、という感じでしょうか。 いろいろありがとうございます。
Lhankor_Mhy

2020/02/03 08:03

先のサイトを引用しますね。 > 1.2 ②サムネイル画像自体を作成する行為 > 1.2.1 「複製」にあたるのか。 > 他人の著作物を「複製」したといえるためには、元の著作物の特徴的部分を直接感得しうることが必要であると法律上は考えられています。(……)ほとんどの場合、「複製」にあたると考えられます とあるように、サムネイルを作成する行為自体が「複製」である、と書かれています。 また、 > 1.3 ③サムネイル画像をサーバにアップして、アクセスした利用者に送信する行為 > サムネイル画像をサイトにアップロードする行為は、「送信可能化」(著作権法2条1項9号の5)にあたります とあり、moomoomさんがおっしゃる「スクレイピング」はサーバに保存するのですから、これに当たるはずですし、 > アクセスしてきた利用者に画像を見せる行為は、「自動公衆送信」(著作権法2条1項9号の4)にあたります とあり、moomoomさんがおっしゃる「スクレイピング」はアクセスがあった利用者に画像を見せるのですから、これに当たるはずです。
Lhankor_Mhy

2020/02/03 08:04

> そしてあなたはスクレイピングを前者の意味で正しく捉えていて、私は後者もスクレイピングだと誤解していた、という感じでしょうか。 定義があいまいな言葉なので、どちらが正しいというよりも行き違いがあった、ということではないかと思いますが。
moomoom

2020/02/03 08:18

>とあるように、サムネイルを作成する行為自体が「複製」である、と書かれています。 なるほど。「サムネイルの作成」が「サムネイルのURL取得と保存」を含むというお考えですね。私は画像ファイルなら複製でしょうけど、URLだけなら平気だろうという思いに囚われてしまっています。 >moomoomさんがおっしゃる「スクレイピング」はサーバに保存するのですから、これに当たるはずですし、 なるほど。「サーバに保存する・サムネイル画像をサーバにアップ」が「サムネイルのURL取得と保存」を含むというお考えですね。私はやはりアップロードとは画像ファイルそのもののアップロードであり、URLの保存はアップロードには含まれないという認識でした。 >「自動公衆送信」 これは明らかにあたりますね。「複製」にばかり目がいっていましたが、「自動公衆送信」は確かに。(まぁこのくらいは勘弁してください、変なことはしないので。笑) 丁寧にありがとうございます。大変勉強になりました。
Lhankor_Mhy

2020/02/03 08:21 編集

> URLだけなら平気 うーん?  もしかして、ここでいうサムネイルというのは「WordPressなどで使われるアイキャッチ画像」のことですか? こちら側で作成するスクリーンショットではなくて? そして、「サムネイルとタイトルを取得してDBに入れて」というのは、画像自体を保存するのではなくて、URLを保存する、という意味ですか?
moomoom

2020/02/03 08:20

>定義があいまいな言葉なので、どちらが正しいというよりも行き違いがあった、ということではないかと思いますが。 いえ理解のない言葉を安易に未定義のまま用いた点から生じた行き違いですから大いに反省すべきでした。どうもありがとうございます。
Lhankor_Mhy

2020/02/03 08:24

つまり、metaタグの thumbnail 属性と titleタグを読んで、サーバに保存しておくってことでしょうか? それならば、私も「スクレイピング」という言葉を使いますし、「複製」には当たらないと思います。 なるほどなるほど、ようやく合点がいきました。
moomoom

2020/02/03 08:25

>もしかして、ここでいうサムネイルというのは「WordPressなどで使われるアイキャッチ画像」のことですか? こちら側で作成するスクリーンショットではなくて? はい、そうです。もしかして、サムネイルという言葉も私、間違っていましたか…?先程「どうしてスクリーンショットの話なんてしてるんだろう」と思っていましたが、サムネイルとはスクリーンショットを指すこともあるのですか。これはたびたび申し訳ございませんでした。 >そして、「サムネイルとタイトルを取得してDBに入れて」というのは、画像自体を保存するのではなくて、URLを保存する、という意味ですか? こちらも仰る通りです。
Lhankor_Mhy

2020/02/03 08:27

やはりそうでしたか。 いや、すっかり誤読してお手間をお掛けしました。 大変失礼しました。
moomoom

2020/02/03 08:32

いえいえ、とんでもないです。良い機会をありがとうございました。明らかに初心者は私なので、言葉には特に留意すべきでした。またお気づきの点ございましたらいつでも仰ってください。
guest

回答5

0

iframeで表示するよりも、スクレイピングしてDBに入れておいたものを表示する方がいいですよね?

実装が手間な以外にも、セキュリティ面での問題があります。

iframeであれば、ブラウザのクロスオリジン制約が有効に働きますので、埋め込む側に不正なJavaScriptがあっても、外側には影響しません。

一方で、スクレイピングでHTMLを展開してしまうと、同一ドメインとなりますので、悪意のあるJavaScriptは自分のページでそのまま実行されてしまいます。

あと、相手先が画像の直リンク禁止を行っているような場合も、iframe経由でないと正常に表示されないことになります。

投稿2020/02/03 06:46

maisumakun

総合スコア146018

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

maisumakun

2020/02/03 06:54

CSSの適用などを考えると、「他のページを混ぜた上で、正しくレイアウトを効かせて出力する」ほうが困難かと思ってしまいます。
moomoom

2020/02/03 06:59

なるほど。セキュリティ面の問題は仰る通りでした。 すると疑問に思うのが、下記のようなiframe作成サービスです。 ・https://iframely.com/embedhttps://embed.ly/code など。 これらのサービスは、その問題をどう回避しているのだと思いますか? スクレイピングでサムネとタイトルを取得する、とはまた別に安全な方法があったりするのでしょうか?
moomoom

2020/02/03 07:00

>他のページを混ぜた上で、正しくレイアウトを効かせて出力する」 あ、スクレイピングでサムネイルとタイトルだけ取得してそれをDBに入れてしまうので、DBのものを表示するときは取得先サイトのCSSはないです。
AkitoshiManabe

2020/02/03 07:36

> 下記のようなiframe作成サービス(中略)その問題をどう回避しているのだと思いますか? 問題などありません。Web-Widget(BLOGパーツなど)用に公開されるiframeタグ生成機能を、集めて1つのサイトで出来るようにしたサービスに過ぎません。マークアップ言語を知らなくても、WISIWIGベースで操作できるという人には便利なはずです。ブックマーク1つで済むのですから。
moomoom

2020/02/03 07:37

質問に補足しましたが、"スクレイピング"について私の認識が間違っていました。
moomoom

2020/02/03 07:42 編集

AkitoshiManabeさん ありがとうございます。よくわからないので、改めて詳細申し上げさせてください。 「私のブログ」で、「iframe作成サービス」で発行されたiframeを使うことを意味しての問題の危惧ではないです。 「iframe作成サービス」が「入力URLのサイト」の情報を取得するときに、「iframe作成サービス」対して、「入力URLのサイト」のJavaScriptが実行されないのか?という危惧を意味したつもりでした。 この意味においても、問題はないのでしょうか?
AkitoshiManabe

2020/02/03 08:10

moomoom さん、質問の内容(スクレイピング)とは異なる iframe のみの意見でしたので、コメント欄をお借りして返信しました(maisumakun さんの回答で必要十分とも思っています)。 > 入力URLのサイトのJavaScriptが実行されないのか? マークアップ内に script 要素が含まれていても公式のものしか動きません。 技術的には、URLパラメータや option要素やsource要素の値が異なるだけのマークアップ生成に過ぎません。また、公開サービスで「非公式なマークアップ内容の生成」はできないはずです。
guest

0

iframeは基本的には別ウィンドウを開いているようなものですから
本来であれば一意にしか設定できないタグや属性も
iframe内では自由に使うことができます。
ある意味名前空間を変えているようなものだと思えばいいでしょう

投稿2020/02/03 07:51

yambejp

総合スコア116724

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

moomoom

2020/02/03 07:55

なるほど。考えてもないメリットでした。どうもありがとうございます。 とはいえやはりiframeは遅いので、質問の補足にある方法の方が早いですよね。もちろんこれでは手間はかかりますし仰るメリットはありませんが、普通にブログで「詳しくはこの記事にあります」のようなリンクを埋め込む場合を考えれば。
yambejp

2020/02/03 08:15

たとえばqiitaにcodepenを埋め込んだりするときとか iframeじゃないとやってられないでしょ? (実際には埋め込み用のタグをいれるとiframeとして埋め込まれる)
moomoom

2020/02/03 08:21

なるほど。そんなときに画像とタイトルだけ貼られてもこまりますねwどうもありがとうございます。
guest

0

自前でスクレイピングしてURLからサムネイルとタイトルを取得してDBに入れてそれを表示するという方が読み込みも早いと思うのですが。

質問の経緯など追っていくと、どうやらスクレイピングに関して認識が違っていたようですが、
ウェブスクレイピング - Wikipedia
基本的に、自前でアクセスして、URLなどを自前でDBに保存するといったことは、スクレイピングとは言いません。
botやバッチ処理によって、プログロムによって人を介在させずhttpアクセスし、情報の取得や操作を行う行為またはソフトウェアのことを言います。
そう考えると、この質問がいかに、一見、かなり危険(というか違法まがい)なことをしようと見えてしまうか、お分かりでしょう。
ちなみにおそらく、本来のスクレイピングでやるとなると(自動取得)をさせると、毎回外部アクセスを行いDBに値を保存とするので、iframeより遥かに遅くなるし、自前のサイトのサーバー負荷とんでもないことになると思いますよ。

これらの手間をはぶくためのiframe、という程度のメリットでしょうか?

YouTubeなどJSでの動きがあるコンテンツを埋め込む場合を除けば、iframeで表示するよりも、スクレイピングしてDBに入れておいたものを表示する方がいいですよね?

違います。
メリットうんぬんの話ではありません。
役割と用途の違いです。
似たような技術(今回は似てるとも言い難いが)、であっても、本来の役割や用途は違ったものとなります。

iframe

iframeはあくまで、外部サイトないし、同Webページ外のWebページを、インラインブロックで表示するためのマークアップ要素です。
以前は、iframeであっても、読み込み先の情報の取得が簡単にでき、読み込み先のWebページの改竄まで可能でした。
ですが現在は、セキュリティによって、そのような行為は原則できないようになっています。
つまりは、iframeは、セキュリティ対象になっているので、合法的に使用できるものとされているので、
表示だけであれば、クロスドメインだろうとなんだろうと基本的には制限がありません。
つまりは、安全に(完全にではない)外部の更新に伴って、表示を常に新しくすることができるってわけです。

#スクレイピング
一方スクレイピングは、Webサイトに対して大量のバッチ処理が必要な時や、どうしても人間が介すると不可能な処理が必要になったりする時などに用いる技術なので、そもそも、iframeとは根本的に役割が異なります。
検索エンジンのロボットに関しても、各サイトにhttpアクセスを行っているため、スクレイピングの一種と言えます。
(星の数ほどあるWebサイトの登録を人がやったりは不可能ですよね?)
今回がたまたま、どっちでもやれるよね、ってなっただけの話です。
そして、スクレイピングの場合は、ブラウザからのhttpアクセスとしてサーバー側で認識されるため、
けっこう情報取得や、不正操作(ロボットでのフォーム送信など)を、容易に可能にしてしまいます。
(つまりセキュリティガバガバなサイトだったら、かなりいろいろやらかせてしまう)
なので、行為によっては、違法行為になりかねません。

結論

本質問でやろうとしてることを、スクレイピングでやるなら、
法に抵触する可能性が非常に高いと思われます。
というか、スクレイピング使わないで自前でやるにしても、勝手に情報控えてDBに保存とか、やらないほうがいいですよ。
それだけで、違法になる可能性大です。
なので、やるにしても、読み込み先のサイトの規約やプライバシーポリシーなど、よーく読んで、
また、規約などに記載がないなら特に、読み込み先のサイトからしっかり許可をもらってからやるようにしましょう。
APIの提供があるなら、APIを使うに止めましょう。
(APIは、外部に、情報使っていいよ、ということを前提で作られているので。)

投稿2020/02/03 09:10

編集2020/02/03 09:35
miyabi_takatsuk

総合スコア9555

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

moomoom

2020/02/03 09:47

>勝手に情報控えてDBに保存とか、やらないほうがいいですよ。 それだけで、違法になる可能性大です。 すみません、いろいろなご意見大変勉強になったのですが、「相手サイトのサムネイルURLとタイトルを、勝手に控えて、自分のDBに保存すること」と「それを自分のサイトの訪問者に表示すること」は、どんな点で違法になりそうだとお考えでしょうか? 見た目としてiframeとなんら変わらないので、やられる相手サイト側もよほど潔癖な方でない限り不満には感じないでしょうから倫理的には問題ないと考えていますしこれはあなたにもご同意いただけるかと思いますが、でも、法的な面での問題とは?もう少しご意見いただけましたら幸いです。 >表示を常に新しくすることができるってわけです。 たしかに仰る通り、DB保存では速度が速くとも更新に対応できないデメリットがありますね。ご指摘ありがとうございます。
moomoom

2020/02/03 09:51

あと「本来のスクレイピング」は私の誤解のせいで無関係ということでしたので、質問にあるような"スクレイピング"のお話だけで進めさせて頂ければと思います。初心者なので同時進行では混乱してしまいそうです。
miyabi_takatsuk

2020/02/03 09:58 編集

”DBに保存"、の部分です。 Webサイトは確かに、基本的には外部に向けて発信するものなので、 閲覧することに関しては、なんぼでもいいかと思います。 しかし、情報のDB保存は、あらゆる使用用途が可能になってしまうため、(使うことができてしまう以上、そう思われる懸念をされるということ)情報の奪取に該当する可能性があります。 そのサイトさんに不利益を被ると思われても仕方のない行為と言えるでしょう。 例えば自身の情報を、住所とかを、公開している情報とはいえ、 誰かに勝手に書類として保存されてたら、なんでやねん?気持ち悪い!って思いません? (なので世の中の契約には、情報の開示と譲渡に関しての条文が盛り込まれるのが常なんです)
miyabi_takatsuk

2020/02/03 09:59

つまり、スクレイピングだろうが自前だろうが、そのサイトさんに黙って勝手に情報保存するのはやめときましょうって話です。
moomoom

2020/02/03 10:10

すみません今2つのご返信を拝見致しました。アドバイスどうもありがとうございました。
miyabi_takatsuk

2020/02/03 16:20

twitterに関しては、実際にその参考にされたページを見ていないのでなんとも言えませんが、 多くの場合は、APIからの情報取得ないし、Webガジェットを使用しての情報表示です。 つまり、twitterが認めている公式の手段にて情報取得、表示をしているので、合法ってわけです。
miyabi_takatsuk

2020/02/04 01:07 編集

法的な部分では、こういったWebの情報などは、 "知的財産"になります。 この知的財産権法に抵触する可能性があるわけです。 詳しくはご自分でお調べください。 記事のタイトル、そのサイトの全ての情報(外部と提携している際のその表示、広告バナーなどは覗く)は、そのサイト様が知的財産として保有しているものであり、 法的にも保有の権利があります。 これらの情報を、そのサイトの利用規約などに反する利用の仕方や、行為をすると、 財産権の侵害として、法律違反になる、ってわけです。
moomoom

2020/02/04 04:54

なるほど、どうもありがとうございました。
guest

0

補足 として追記されているので:

PHPで「https://github.com/scottmac/opengraph」を使い、URLからタイトルとサムネイルを取得すること

XMLベースのRSSのように、異なるサイト間で情報共有したい情報を手軽に扱いたいよね。マークアップ言語だからできるよね。ということで、「opengraph protocol和訳)」が誕生しました。

HTML文書のHEAD内に記述される meta 要素(property 属性値/ content属性値)を使い、Webページにアクセスすることで情報共有を簡単にするものです。

Open Graph Protocol helper for PHPhttps://github.com/scottmac/opengraph)は、
そのタイトルどおり、meta要素で公開され、共有されるべき「メタ情報」を抜き取るコードです。

スクレイピングを乱暴に言えば、次の処理になります。

  1. 「マークアップ文書の字句解析」
  2. 「必要な情報の取得」

スクレイピングを応用するテーマとして複製があります。

  • img[src] から取得したURL情報にある 画像ファイル
  • script[src] から取得したURL情報にある javascript ファイル
  • etc

JavaScript実行の危険性については

取得した JavaScript ファイルの複製物は
自分の運営するサイト内のHTMLに埋め込んで実行するかどうか、自分で決めることができます。

  • ライセンスがMITなど、OSS基準を満たしている

(Public Domain に等しいコードスニペットの寄せ集めに過ぎず、ソースを読んで挙動も納得した)

というのであれば、リスクは少ないでしょう。
しかし、複製したスクリプトを処理内容を把握もせずに使うのは危険極まりないです。

世界を見渡せば javascript 製キーロガーを作って公開してる人もいます。
悪意あるサーバーと組み合わせる方法でページ内で叩かれたキーの情報を抜き取る手法です。

MIT は Prototype.js の登場時に初めて目にしたライセンスですが、
最初の Help は「Read Source (ソース読め)」でした。

(追記)

iframeの必要性

上記で述べた「複製」による、法的な制限を簡単に回避したい場合もあります
(サービス提供者が、ユーザ自身が運営するブログなどのサイトに引用してほしい場合)。
これが iframe の必要性です。

スクレイピングも「サーバー要求し、応答された結果の文字列処理」のため、
許容される範囲は「マークアップ文書に現れる、文字列まで」という認識が正しいでしょう。
(サービス不能攻撃と見做されないような要求頻度の考慮は必要です)

スクレイピングも便利ですが 使い分ける 必要はあります。
(法整備が進んでいる現在は、両技術共に法的な制限下にあると考えたほうが良いです)

投稿2020/02/03 10:55

編集2020/02/04 12:29
AkitoshiManabe

総合スコア5434

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

moomoom

2020/02/04 04:57

全体的な文脈として少し理解できなかった部分もございますが、スクレイピングの歴史的な経緯などとても勉強になるご回答でした。どうもありがとうございます。
guest

0

ベストアンサー

html だけで ほかのページを埋め込みたいなら
iframe しかありませんよね。

ただそれだけのことです。

また、ほかの方がスクレイピングには許可が、と申されていますが、

iframe でも img でもスクレイピングほかの方のコンテンツを引用するときは、掲載した部分が引用するのが引用、抜粋わかるようにするのがマナーです。

ちなみに他の人のサイトをiframeで表示するのは一般的には非常識です

むかしはホームページ作成ソフトが流行っていたので、それを使って段組をつくると

iframeでナビゲーションを作るページが多かったです。

つまりホームページ作成ソフトがCSSではなくiframeを含むコードを吐いていたのです。

つまり、cssやphpなどができるweb系のひとには
考える必要もない仕様が iframe です

投稿2020/02/11 02:20

yukijiro1990

総合スコア37

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.35%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問