ウェブ魚拓をご利用いただきありがとうございます。
Xの改行の再現性などで修正のご要望をいただいておりましたが、このたぶ表題の通り、改行の修正を行いました。再現性が向上しております。
以上どうぞよろしくお願いいたします。
取得とその他を修正・変更しました
ウェブ魚拓をご利用いただきありがとうございます。表題に関しまして、以下の通りです。
- 非ストリーミング動画の直接URLを指定して取得する際における取得の修正
URLを直接指定したときの動画の取得において非ストリーミングの動画を取得できるようにしました。ただし、サイズ制限は通常のHTML取得よりかなり小さいものとなります。
今までは取得が終了せずにタイムアウトになる現象が発生しておりましたことお詫び申し上げます。 - PNG,JPGの直接URLを指定して取得する際における圧縮条件の変更
あまり大きくないファイルの場合は圧縮せずにそのままのファイルを取得するようにしました。メタデータの保存などが可能です。大きいものは今まで通りAVIFに保存され、取得が可能です。
通常は今まで通りAVIFに圧縮されます。たとえばPNGやJPGで30MBのファイルであってもAVIFで150KB程度に圧縮されます。
“あまり大きくないファイル”のサイズの判定は調整中です。 - 取得制限を変更
1日(直近24時間以内)で30から60とし、取得時のボタンの下に表示されます。
通常のHTML等の取得は1です。
上記の動画やPNGにおけるいずれかに引っ掛かった場合、取得制限を複数回使います。この”複数回”はまだ調整中で変更される可能性があります。
なお、”その他のエラー”が起きたときに関しては今まで通り回数は0となりますが、今後失敗を利用した攻撃が見られた場合、変更する可能性はございます。
“その他のエラー”に関しましては、直近10000回で10回程度に減っており、さらに同一のURL取得でもほぼ再現性が無いため、再挑戦すると取得できる可能性が上がっています。
もしも同一のURLで”その他のエラー”が何度か発生したという場合はご報告ください。
以上どうぞよろしくお願いいたします。
取得等を修正しました
平素よりウェブ魚拓をご利用いただきありがとうございます。修正は以下の通りです。
- ウェブフォントのサイズが大きく、取得に影響がありえると考えられる場合、ウェブフォントを無視することとしました。サイズはコースによる取得許容量別になります。通常、有料版取得ではよほどのことが無い限り影響がありません。
一見あまり大きいページなのかわからないが容量オーバーでスクリーンショットになった、というようなことが大きく減ると思います。 - 画像対応を強化しました。
今後画像がリンク切れのようになる取得が減るかと思います。
もし確認が出来ましたら修正を試みることができますのでご報告くださいますと幸いです。(ファイルサイズ上限越えに防止よる打ち切りを除く) - お問い合わせフォームはbotと考えられる空欄送信が多いため、メールからの投稿に修正しました。
PNG等の可逆圧縮フォーマットにおける扱いは現在も検討中です。
以上どうぞよろしくお願いいたします。
【終了】緊急メンテナンス中です
弊社サービスをご利用いただき、ありがとうございます。
CVE-2024-6387脆弱性に関する対策を行います。
メンテナンス前後でご利用に関する機能などの変更はございません。
サービス再開まで今しばらくお待ちください。
※本メンテナンスは終了しました。
取得を修正しました(6/26追記2)
ウェブ魚拓をご利用いただき、ありがとうございます。
- 6/26
10:30 取得を調整しました。
08:50 取得を調整しました。 - 6/24 追記 広告と考えづらいiframeについては、スクリーンショットし保存するようにしました。(webpとなります)
- 6/20 追記 特定の条件下での取得を調整しました
- レンダリングにおけるCSSの処理を修正しました
引き続きどうぞよろしくお願いいたします。
取得を修正しました(追記2)
ウェブ魚拓をご利用いただきありがとうございます。
【追記】6/10 12:30、HTMLヘッダが実際のコンテンツと異なる場合の判定を調整しました
【追記】6/9 21:30、一部のutlに発生するバグを修正しました。
以下は変更ありません。
- レンダリングにおけるCSSの順番の維持を強化しました。
- クローラー判定をパスする処理を強化しました。
クローラー判定は特定のURLに思わぬ影響があるかもしれません。
この変更により問題が起きたと考えられる場合はその旨をURLとご一緒にご報告いただけますと幸いです。
以上どうぞよろしくお願いいたします。
取得周りおよびその他修正いたしました
ウェブ魚拓をご利用いただきありがとうございます。
リソースの増強を試みましたため、以下のバージョンアップをいたしました。
様子見をしながら調整していく予定です。
- HTMLの取得
- 処理を速くしました。タイムアウトエラーの割合も減るかと考えられます。
- 精度を向上させました。
- ファイルサイズを超えた場合※の中断処理からCSSを除きました
(ファイルサイズを超えた場合の中断処理に引っ掛かったかどうか具体的に確認したい場合は<img src=”https://…”>が<img src=””>となるようなHTMLになっていた場合です) - スクリーンショットのみになった場合の理由をタイトルに記述されるケースを追加しました
- HTML以外の取得
- 時間を大幅に伸ばしました。
- 一部png,jpeg等のファイルをavifへの変換に戻しました。
(つまり現状、webpとavif混在となります) - 上記変換前のファイルサイズを超えた場合※の余裕を大きくしました。
- その他
- QAにSHA256の出し方を追記しました。
- QAにSHA256の出し方を追記しました。
※ファイルサイズを超えるかどうか判定するケースは複雑です。
結果的にダウンロード前に80MB、圧縮が終われば80KBのファイルがあるとしても、ダウンロードが完了し圧縮するまではどのくらいになるかわからず、さらに通信を占有されることは避けられません。
圧縮後を考え数段階に分けて、それぞれ余裕を持たせています。HTMLですと、数段階変換を行って完成しますが、第2段階までだと約3倍の余裕が持たされています。
ご意見ご報告、結果からの判断が不明瞭な問題が再現するURLをお持ちでしたら引き続きご連絡ください。
以上どうぞよろしくお願いいたします。
【重要】Xはtwitter.comではなくx.comでご取得下さい【追記】
ウェブ魚拓をご利用いただき、ありがとうございます。
追記です。
弊社で調査したところ、取得がx.comの場合は
It’s what’s happening / X
が滅多に発生しておりませんでした。
ここ数日は取得に対し0といっていいほどの差があります。
現在、約1割ほどtwitter.comで取得を行われております。かなり移行は進んでいるかと思いますが、
xの公式アプリでもURLを共有するとtwitter.comとなるバージョンもあるかと思います。
twitter.comで取得しようとしたときに簡単な警告が出るようにいたしました。
本件においては実施してもよいかと思いますが、
現状のウェブ魚拓の性質から、強制リダイレクトまでは行っておりません。
以上、追記となります
・Xの取得が増えたときに発生する問題を修正しました。
・一部の条件にかかるURLの表示時に発生する問題の修正をいたしました。
Xの取得の修正はネットワークの修正となりますので、しばらく安定性の問題やウェブページによっては想定していない問題が発生する可能性があるため、お心当たりがありましたらご連絡いただけると幸いです。
なお同時に取得のリソースの改善も進めております。
以上どうぞよろしくお願いいたします。
Xの取得について
Xの取得がうまくいかないというご報告を受けています。
調査中ですが、原因と考えられるのは
- Xの取得が増えた(もしくはXのアクセス上限の変更があった)ためアクセス制限を超えた
というものです。
ウェブ魚拓で確保しているサーバー群による制限を上記の理由で使い切っているということになります。
また、実地チェックに使っています
「政府機関や多国間機関、またはその関係者のアカウント」
は上記制限と考えられる状況下でも取得可能であったため、確認が遅れましたことお詫び申し上げます。
近日中に別途IPアドレスの確保を行い暫定対応させていただこうと思います。
以上どうぞよろしくお願いいたします。
5/19 17:10 取得・表示周りを修正いたしました
ウェブ魚拓をご利用いただき、ありがとうございます。
・テキストのみのコンテンツの取得を修正しました
・画像等のファイルタイプの直接取得の際、ファイルサイズの判定に存在したバグを修正しました
以上どうぞよろしくお願いいたします。
5/18の修正は以下となります。
・X (旧twitter) に対応しなおしました。
以上どうぞよろしくお願いいたします。
5/17の修正は以下となります。
様々なURLの修正をご要望いただき、ありがとうございます。
前回より修正にお時間かけてしまいましたことお詫び申し上げます。
・一部の動画SNS等のサムネイル取得を改善しました。
・取得時のクローラー等のアクセスブロックに引っ掛かる確率を下げました。
・フラグメント付きのURLの表示を修正しました。
・非HTMLファイル保存の成否時に時間がかかることがあるのを修正しました。
・取得に問題があった時のエラー表示を細かくしました。
その他、現状確認できた問題点は以下です。
・取得時に割り当てられたメモリ等リソースを超過したときに約500-600秒たってようやくエラーになる
一見ただの小さい画像に見えるものが10MBのpngで、それを複数載せているようなページがあり、そういったものをそのままのサイズで圧縮するのにメモリを使います。
こちらは現状、プログラム上では補足が容易ではないため、取得用のサーバーの強化し、そのサーバーがダウンしているときに自動的に切り替えるバックアップを用意する計画を立てています。
引き続きお気づきの点ございましたら
ご面倒かと思いますがご連絡どうぞよろしくお願いいたします。