Definitivamente querrás comenzar con un buen marco de web scraping. Más adelante, puede decidir que son demasiado limitantes y puede armar su propia pila de bibliotecas, pero sin mucha experiencia en scraping, su diseño será mucho peor que pjscrape o scrapy.
Nota: Utilizo los términos rastreo y raspado 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, según su navegador preferido. Esto será absolutamente necesario mientras navega por el sitio del que está extrayendo datos y mapea qué URL contienen los datos que está buscando y qué formatos de datos componen las respuestas.
Necesitará un buen conocimiento práctico de HTTP y HTML y probablemente querrá encontrar una pieza decente en el software de proxy intermedio. Deberá poder inspeccionar las solicitudes y respuestas HTTP y comprender cómo se transmiten las cookies y la información de la 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 mucho mitmproxy ( http://mitmproxy.org/ ) porque soy más un tipo de teclado que de ratón.
Algún tipo de entorno de tipo consola / shell / REPL donde pueda 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 descatalogado, no es adecuado para esta tarea y el soporte de la biblioteca / marco es deficiente en esta área. Python (Scrapy es un excelente punto de partida) y Clojure / Clojurescript (increíblemente poderoso y productivo pero con una gran curva de aprendizaje) son excelentes lenguajes para este problema. Dado que prefiere no aprender un nuevo idioma y ya conoce Javascript, definitivamente sugeriría que se quede con JS. No he usado pjscrape pero se ve bastante bien después 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 las expresiones regulares: NO USE EXPRESIONES REGULARES PARA PARAR 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 html y solo use expresiones regulares para extraer datos del texto real dentro de un nodo html. Es posible que esto ya sea obvio para usted, se vuelve obvio rápidamente si lo intenta, 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 las expresiones regulares y fueron diseñados para resolver este problema exacto.
Sitios con mucho Javascript
En los viejos tiempos, solo tenía que hacer una solicitud http y analizar la respuesta HTML. Ahora es casi seguro que tendrá que lidiar con sitios que son una combinación de solicitudes / respuestas HTTP HTML estándar y llamadas HTTP asíncronas realizadas por la parte javascript del sitio de destino. Aquí es donde su software proxy y la pestaña de red de firebug / devtools resultan muy útiles. Las respuestas a estos pueden ser html o json, en casos raros serán xml u otra cosa.
Hay dos enfoques para este problema:
El enfoque de bajo nivel:
Puede averiguar qué URL ajax está llamando el sitio javascript y cómo se ven esas respuestas y hacer esas mismas solicitudes usted mismo. Por lo tanto, puede extraer el html de http://example.com/foobar y extraer una pieza de datos y luego tener que extraer la respuesta json de http://example.com/api/baz?foo=b ... para obtener el otro dato. Deberá saber pasar 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 cálculo loco realizado en el javascript del sitio, la ingeniería inversa puede ser molesta.
El enfoque del navegador integrado:
¿Por qué necesita averiguar qué datos están en html y qué datos provienen de una llamada ajax? ¿Gestionar toda esa sesión y datos de cookies? No tiene que hacerlo cuando navega por un sitio, el navegador y el sitio javascript lo hacen. Ese es todo el punto.
Si simplemente carga la página en un motor de navegador sin cabeza como phantomjs, cargará la página, ejecutará el javascript y le dirá 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 javascript del sitio para cargar los datos apropiados.
Ahora tiene dos opciones, hacer que escupe el html terminado y analizarlo o inyectar algo de javascript en la página que realiza el análisis y el formato de datos y escupe los datos (probablemente en formato json). También puede mezclar libremente estas dos opciones.
¿Qué enfoque es el mejor?
Eso depende, seguramente tendrá que estar familiarizado y cómodo con el enfoque de bajo nivel. El enfoque del navegador integrado funciona para cualquier cosa, será mucho más fácil de implementar y hará que desaparezcan algunos de los problemas más complicados de scraping. También es una pieza de maquinaria bastante compleja que deberá comprender. No son solo solicitudes y respuestas HTTP, son solicitudes, renderizado del navegador integrado, javascript del sitio, javascript inyectado, su propio código e interacción bidireccional con el proceso del navegador integrado.
El navegador incrustado también es mucho más lento a escala debido a la sobrecarga de procesamiento, pero eso casi seguramente no importará a menos que esté raspando muchos dominios diferentes. Su necesidad de limitar la tasa de sus solicitudes hará que el tiempo de procesamiento sea completamente insignificante en el caso de un solo dominio.
Limitación de velocidad / comportamiento del bot
Debes estar muy consciente de esto. Debe realizar solicitudes a sus dominios de destino a un ritmo razonable. Necesita escribir un bot que se comporte bien al rastrear sitios web, y eso significa respetar el archivo robots.txt y no golpear el servidor con 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 pregunte, 1req / s es el máximo al que se ejecuta el rastreador de Google, pero usted no es Google y probablemente no sea tan bienvenido como Google. Mantenlo tan lento como sea razonable. Sugeriría 2-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 su bot que explique su propósito. Esta URL va en la cadena del agente.
Será fácil bloquearlo si el sitio quiere bloquearlo. Un ingeniero inteligente por su parte puede identificar fácilmente los bots y unos minutos de trabajo por su parte pueden causar semanas de trabajo cambiando su código de raspado por su parte o simplemente hacerlo imposible. Si la relación es antagónica, un ingeniero inteligente en el sitio de destino puede obstaculizar por completo a un ingeniero genio que escribe un rastreador. El raspado de código es intrínsecamente 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 escriba un bot que se porta bien y no se preocupe por esto.
Pruebas
¿No eres un examinador de unidad / integración? Demasiado. Ahora tendrás que convertirte en uno. Los sitios cambian con frecuencia y cambiará su código con frecuencia. Ésta es una gran parte del desafío.
Hay muchas partes móviles involucradas en el raspado de un sitio web moderno, las 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 devuelve datos corruptos de forma silenciosa. Sin buenas pruebas para verificar las regresiones, descubrirá que ha estado guardando datos corruptos inútiles en su base de datos durante un tiempo sin darse cuenta. Este proyecto lo familiarizará mucho con la validación de datos (encontrará algunas buenas bibliotecas para usar) y las pruebas. No hay muchos otros problemas que combinen requiriendo pruebas exhaustivas y 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 desea martillar el servidor para la misma página una y otra vez sin ningún motivo. Mientras ejecuta sus pruebas unitarias, desea saber si sus pruebas fallan porque 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 es complicado de configurar y usar correctamente.
También desea saber si el sitio ha cambiado. Si rediseñaron el sitio y su rastreador no funciona, sus pruebas unitarias aún se aprobarán porque se ejecutan en una copia en caché. Necesitará otro conjunto más pequeño de pruebas de integración que se ejecutan con poca frecuencia en el sitio en vivo 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 detiene el rastreo. Ahora puede actualizar su caché, ejecutar sus pruebas unitarias y ver qué 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 normalmente 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 un software de navegador para solicitar una URL y ver 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 son amados por ello. Identificar el nombre de su bots en el agente de usuario y ser abierto sobre los objetivos e intenciones de su rastreador web ayudará aquí, ya que la ley entiende qué 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 "bloqueado" por robots.txt o debido a algún tipo de explotación de autorización), entonces tenga en cuenta que está haciendo algo poco ético. y la ignorancia tecnológica de la ley será extraordinariamente peligrosa aquí. Es una situación ridícula, pero es real.
Es literalmente posible intentar construir un nuevo motor de búsqueda como un ciudadano honrado, cometer un error o tener un error en su software y ser visto como un hacker. No es algo que quieras considerando 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 software relacionado con la web durante más de una década como consultor, empleado y fundador de una startup. Los primeros días estaban escribiendo rastreadores / raspadores de perl y sitios web php. Cuando estábamos incrustando iframes ocultos cargando datos csv en páginas web para hacer ajax antes de que Jesse James Garrett lo llamara ajax, antes de que XMLHTTPRequest fuera una idea. Antes de jQuery, antes de json. Tengo alrededor de 30 años, eso aparentemente se considera antiguo para este negocio.
He escrito dos veces sistemas de rastreo / rastreo a gran escala, una vez para un equipo grande en una empresa de medios (en Perl) y recientemente para un equipo pequeño como CTO de una startup de motores 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 rastreadores / raspadores sean una delicia)
También he escrito exitosos sistemas de software anti-rastreo. Es muy fácil escribir sitios casi imposibles de rastrear si lo desea o 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 puede usarse para crear cosas asombrosas.