api - tecnicas - ¿Cuál es la mejor manera de recopilar datos de un sitio web?
tecnicas de recoleccion de datos pdf (2)
Necesito extraer contenidos de un sitio web, pero la aplicación no proporciona ninguna interfaz de programación de aplicaciones u otro mecanismo para acceder a esos datos mediante programación.
Encontré una herramienta de terceros útil llamada Import.io que proporciona funcionalidad de clic y avance para raspar páginas web y crear conjuntos de datos, lo único es que quiero conservar mis datos localmente y no quiero suscribirme a ningún plan de suscripción. .
¿Qué tipo de técnica utiliza esta empresa para raspar las páginas web y crear sus conjuntos de datos? Encontré algunos frameworks de web scraping pjscrape & Scrapy Podrían proporcionar tales características?
Definitivamente querrás comenzar con un buen marco de web scraping. Más tarde, puede decidir que son demasiado limitantes y puede armar su propia pila de bibliotecas, pero sin mucha experiencia de raspado, su diseño será mucho peor que pjscrape o scrapy.
Nota: uso los términos crawling y scraping básicamente intercambiables aquí. Esta es una copia de mi respuesta a tu pregunta de Quora, es bastante larga.
Herramientas
Familiarícese con las herramientas de desarrollo de Firebug o Chrome dependiendo de su navegador preferido. Esto será absolutamente necesario a medida que navega por el sitio del que está extrayendo datos y establece qué URL contienen los datos que está buscando y qué formatos de datos constituyen las respuestas.
Necesitarás un buen conocimiento práctico de HTTP y de HTML, y probablemente quieras encontrar un hombre decente en el software proxy intermedio. Tendrá que poder inspeccionar las solicitudes y respuestas HTTP y comprender cómo se están pasando las cookies y la información de sesión y los parámetros de consulta. Fiddler ( http://www.telerik.com/fiddler ) y Charles Proxy ( http://www.charlesproxy.com/ ) son herramientas populares. Uso mitmproxy ( http://mitmproxy.org/ ) mucho ya que soy más un tipo de teclados que un tipo de mouse.
Algún tipo de entorno consola / shell / REPL en el que puedes probar varios fragmentos de código con comentarios instantáneos será invaluable. Las tareas de ingeniería inversa como esta son muchas pruebas y errores, por lo que querrá un flujo de trabajo que lo haga fácil.
Idioma
PHP está básicamente fuera, no es muy adecuado para esta tarea y el soporte de biblioteca / framework es pobre en esta área. Python (Scrapy es un gran punto de partida) y Clojure / Clojurescript (increíblemente poderoso y productivo pero una gran curva de aprendizaje) son excelentes idiomas para este problema. Como preferiría no aprender un nuevo idioma y ya sabe Javascript, definitivamente le recomendaría seguir con JS. No he usado pjscrape, pero se ve bastante bien a partir de una lectura rápida de sus documentos. Es muy adecuado e implementa una excelente solución al problema que describo a continuación.
Una nota sobre expresiones regulares: NO USE EXPRESIONES REGULARES PARA PARSE HTML. Muchos principiantes hacen esto porque ya están familiarizados con las expresiones regulares. Es un gran error, use los selectores xpath o css para navegar por html y solo use expresiones regulares para extraer datos del texto real dentro de un nodo html. Puede que esto ya sea obvio para ti, se vuelve obvio rápidamente si lo intentas, pero mucha gente pierde mucho tiempo yendo por este camino por alguna razón. No tenga miedo de los selectores xpath o css, son MUCHO MÁS fáciles de aprender que los regex y fueron diseñados para resolver este problema exacto.
Sitios con mucho Javascript
En los viejos tiempos solo tenías que hacer una solicitud http y analizar la respuesta HTML. Ahora seguramente tendrá que tratar con sitios que son una combinación de solicitudes / respuestas HTTP HTML estándar y llamadas HTTP asincrónicas realizadas por la parte de javascript del sitio de destino. Aquí es donde su software proxy y la pestaña de red de firebug / devtools son muy útiles. Las respuestas a estos pueden ser html o pueden ser json, en casos raros serán xml o algo más.
Hay dos enfoques para este problema:
El enfoque de bajo nivel:
Puede averiguar a qué URL de AJA está llamando el sitio que javascript y cómo se verán esas respuestas y hacer las mismas solicitudes usted mismo. Por lo tanto, puede extraer el html de http://example.com/foobar y extraer un dato y luego extraer la respuesta json de http://example.com/api/baz?foo=b ... para obtener la otra pieza de datos. Deberá conocer las cookies o los parámetros de sesión correctos. Es muy raro, pero ocasionalmente algunos parámetros requeridos para una llamada ajax serán el resultado de algún loco cálculo hecho en el sitio javascript, la ingeniería inversa esto puede ser molesto.
El enfoque del navegador integrado:
¿Por qué necesita averiguar qué datos están en html y qué datos provienen de una llamada ajax? ¿Administrando toda esa sesión y datos de cookies? No es necesario cuando navegas por un sitio, el navegador y el sitio javascript hacen eso. Ese es todo el punto.
Si solo carga la página en un motor de navegación sin cabeza como phantomjs, cargará la página, ejecutará el javascript y le informará cuando se hayan completado todas las llamadas ajax. Puede inyectar su propio javascript si es necesario para activar los clics apropiados o lo que sea necesario para activar el sitio JavaScript para cargar los datos apropiados.
Ahora tiene dos opciones, obtener escupir el html terminado y analizarlo o inyectar algún javascript en la página que hace su análisis y formato de datos y escupe los datos (probablemente en formato json). También puedes mezclar libremente estas dos opciones.
¿Qué enfoque es el mejor?
Eso depende, necesitarás estar familiarizado y cómodo con el enfoque de bajo nivel para estar seguro. El enfoque de navegador integrado funciona para cualquier cosa, será mucho más fácil de implementar y hará desaparecer algunos de los problemas más complicados en el raspado. También es una pieza de maquinaria bastante compleja que deberá comprender. No se trata solo de solicitudes y respuestas de HTTP, sus solicitudes, representación de navegador incorporado, javascript de sitio, javascript inyectado, su propio código e interacción bidireccional con el proceso de navegador integrado.
El navegador integrado también es mucho más lento a escala debido a la sobrecarga de procesamiento, pero eso seguramente no importará a menos que esté raspando muchos dominios diferentes. Su necesidad de calificar limite sus solicitudes hará que el tiempo de representación sea completamente insignificante en el caso de un solo dominio.
Límite de velocidad / comportamiento de Bot
Debes ser muy consciente de esto. Debe realizar solicitudes a sus dominios de destino a un precio razonable. Debes escribir un bot de buen comportamiento al rastrear sitios web, y eso significa respetar robots.txt y no presionar al servidor con las solicitudes. Los errores o la negligencia aquí son muy poco éticos, ya que esto puede considerarse un ataque de denegación de servicio. La tasa aceptable varía según a quién le preguntes, 1req / s es el máximo que corre el rastreador de Google, pero no eres de Google y probablemente no seas tan bienvenido como Google. Mantenlo tan lento como sea razonable. Sugeriría de 2 a 5 segundos entre cada solicitud de página.
Identifique sus solicitudes con una cadena de agente de usuario que identifique su bot y tenga una página web para que su bot lo explique. Esta url va en la cadena del agente.
Será fácil de bloquear si el sitio quiere bloquearlo. Un ingeniero inteligente en su extremo puede identificar bots fácilmente y unos minutos de trabajo en su extremo pueden causar semanas de trabajo cambiando su código de raspado en su extremo o simplemente hacerlo imposible. Si la relación es antagónica, un ingeniero inteligente en el sitio de destino puede bloquear por completo a un ingeniero genial escribiendo un rastreador. El código de raspado es inherentemente frágil y esto se explota fácilmente. Algo que provocaría esta respuesta es casi seguro que no es ético de todos modos, así que escribe un robot de buen comportamiento y no te preocupes por esto.
Pruebas
¿No es una persona de prueba de unidad / integración? Demasiado. Ahora tendrás que convertirte en uno. Los sitios cambian con frecuencia y usted cambiará su código con frecuencia. Esta es una gran parte del desafío.
Hay muchas partes móviles involucradas en el robo de un sitio web moderno, buenas prácticas de prueba ayudarán mucho. Muchos de los errores que encontrará al escribir este tipo de código serán del tipo que simplemente devuelve datos dañados de forma silenciosa. Sin buenas pruebas para verificar regresiones, descubrirá que ha estado guardando datos corruptos inútiles en su base de datos por un tiempo sin darse cuenta. Este proyecto lo familiarizará con la validación de datos (encuentre algunas buenas bibliotecas para usar) y las pruebas. No hay muchos otros problemas que combinen que requieran pruebas exhaustivas y que sean muy difíciles de probar.
La segunda parte de sus pruebas implica el almacenamiento en caché y la detección de cambios. Mientras escribe su código, no quiere estar martillando el servidor por la misma página una y otra vez sin ningún motivo. Al ejecutar las pruebas de su unidad, quiere saber si sus pruebas están fallando porque usted rompió su código o porque el sitio web ha sido rediseñado. Ejecute sus pruebas unitarias contra una copia en caché de las URL involucradas. Un proxy de almacenamiento en caché es muy útil aquí pero difícil de configurar y usar correctamente.
También desea saber si el sitio ha cambiado. Si rediseñaron el sitio y tu rastreador se rompió, las pruebas de tu unidad seguirán pasando porque se están ejecutando contra una copia en caché. Necesitará otro conjunto más pequeño de pruebas de integración que se ejecutan con poca frecuencia contra el sitio activo o un buen registro y detección de errores en su código de rastreo que registra los problemas exactos, lo alerta sobre el problema y deja de rastrear. Ahora puede actualizar su caché, ejecutar sus pruebas de unidad y ver lo que necesita cambiar.
Asuntos legales
La ley aquí puede ser un poco peligrosa si haces cosas estúpidas. Si la ley se involucra, se trata de personas que regularmente se refieren a wget y curl como "herramientas de piratería". No quieres esto
La realidad ética de la situación es que no hay diferencia entre usar el software del navegador para solicitar una URL y mirar algunos datos y usar su propio software para solicitar una URL y ver algunos datos. Google es la empresa de raspado más grande del mundo y les encanta. Identificar su nombre de bots en el agente de usuario y ser abierto acerca de los objetivos e intenciones de su rastreador web ayudará aquí ya que la ley comprende lo que es Google. Si está haciendo algo sospechoso, como crear cuentas de usuario falsas o acceder a áreas del sitio que no debería (ya sea "bloqueadas" por robots.txt o debido a algún tipo de aprovechamiento de autorización), tenga en cuenta que está haciendo algo poco ético. y la ignorancia de la ley sobre la tecnología será extraordinariamente peligrosa aquí. Es una situación ridícula, pero es real.
Literalmente es posible intentar construir un nuevo motor de búsqueda como un ciudadano respetable, cometer un error o tener un error en su software y ser visto como un hacker. No es algo que desee teniendo en cuenta la realidad política actual.
¿Quién soy yo para escribir esta pared gigante de texto de todos modos?
He escrito mucho código relacionado con el rastreo web en mi vida. He estado desarrollando aplicaciones de software relacionadas con la web durante más de una década como asesor, empleado y fundador de startups. Los primeros días estaban escribiendo perl crawlers / scrapers y sitios web php. Cuando estábamos incorporando iframes ocultos cargando datos csv en páginas web para hacer ajax antes de que Jesse James Garrett lo llamara ajax, antes de XMLHTTPRequest era una idea. Antes de jQuery, antes de json. Estoy en mis mediados de los 30, que aparentemente se considera antiguo para este negocio.
He escrito sistemas de rastreo / raspado a gran escala dos veces, una para un equipo grande en una empresa de medios (en Perl) y recientemente para un equipo pequeño como CTO de un inicio de motor de búsqueda (en Python / Javascript). Actualmente trabajo como consultor, principalmente codificando en Clojure / Clojurescript (un maravilloso lenguaje experto en general y tiene bibliotecas que hacen que los problemas de los rastreadores / raspadores sean una delicia)
También escribí exitosos sistemas de software anti-rastreo. Es notablemente fácil escribir sitios poco aptos para decodificar si lo desea o para identificar y sabotear los bots que no le gustan.
Me gusta escribir rastreadores, raspadores y analizadores más que cualquier otro tipo de software. Es desafiante, divertido y se puede usar para crear cosas increíbles.
Sí, puedes hacerlo tú mismo. Solo se trata de agarrar las fuentes de la página y analizarlas de la manera que desee.
Hay varias posibilidades. Un buen combo es usar python-requests (construido sobre urllib2, es urllib.request en Python3) y BeautifulSoup4 , que tiene sus métodos para seleccionar elementos y también permite selectores de CSS :
import requests
from BeautifulSoup4 import BeautifulSoup as bs
request = requests.get("http://foo.bar")
soup = bs(request.text)
some_elements = soup.find_all("div", class_="myCssClass")
Algunos preferirán el análisis xpath o pyquery tipo jquery, lxml u otra cosa .
Cuando los datos que desea son producidos por JavaScript , lo anterior no funcionará. O necesitas python-ghost o Selenium. Prefiero este último combinado con PhantomJS , mucho más ligero y simple de instalar, y fácil de usar:
from selenium import webdriver
client = webdriver.PhantomJS()
client.get("http://foo")
soup = bs(client.page_source)
Te aconsejaría comenzar tu propia solución. Comprenderá los beneficios de Scrapy al hacerlo.
ps: echa un vistazo a scrapely: https://github.com/scrapy/scrapely
pps: echa un vistazo a Portia, para comenzar a extraer información visualmente, sin conocimientos de programación: https://github.com/scrapinghub/portia