חילוץ נקודות קצה של פרוקסי שורה אחת בטבלה בכל פעם
שמרו על כתובות IP מותאמות לפורטים שלהן ואמתו את השדות בעת ניתוח טבלת HTML שמורה של רשימת פרוקסי.
נתחו כל שורת פרוקסי כיחידה אחת. אם משטחים כל td תואם בעמוד ומקבצים את התוצאות לפי מספר קבוע, כתובת משורה אחת עלולה להיות מותאמת לפורט מהשורה הבאה כאשר תא חסר או טבלה אחרת מופיעה.
עבור HTML שהאפליקציה כבר השיגה, טבלה ששתי העמודות הראשונות שלה הן כתובת IP ופורט ניתנת לניתוח כך:
import ipaddress
from bs4 import BeautifulSoup
soup = BeautifulSoup(html, "html.parser")
table = soup.select_one(table_selector)
if table is None:
raise ValueError("Expected proxy table was not found")
endpoints = set()
for row in table.select("tbody tr"):
cells = row.find_all("td", recursive=False)
if len(cells) < 2:
continue
try:
address = ipaddress.ip_address(cells[0].get_text(strip=True))
port = int(cells[1].get_text(strip=True))
except ValueError:
continue
if 1 <= port <= 65535:
endpoints.add((str(address), port))html ו-table_selector הם קלטים של האפליקציה. בחרו את הבורר ואת מיפוי העמודות לפי הסימון בפועל של המקור. רשימת הפרוקסי החינמית היא מקור אחד לרשומות נקודות קצה, אך יש לבדוק את שורותיה לפני בחירת המיפוי הזה. לא מזהה טבלה היסטורי ולא הטענה שעמוד מכיל בדיוק 300 רשומות הם סכימה מתמשכת.
הקבוצה מסירה זוגות כתובת-ופורט כפולים תוך שמירה על השיוך של כל זוג. בכל זאת יש לחקור ייבוא בלתי צפוי עם אפס תוצאות: ייתכן שהטבלה השתנתה או שהמסמך שהושג הוא עמוד אתגר ולא הרשימה.
שמרו פרוטוקול מוצהר ושדות של זמן בדיקה לצד נקודת הקצה כשהם חשובים. חילוץ IP ופורט סבירים מבסס את התבנית, לא את העובדה שנקודת הקצה מספקת כעת שירות HTTP או SOCKS פעיל.
שורות כותרת או סינון אינן נקודות קצה. שורה שמכילה רק תאי th מדולגת, ואילו שדות ריקים או כאלה שאינם כתובות נכשלים באימות. אל תשליכו את השורה הראשונה והאחרונה לפי מיקום: כל אחת מהן יכולה להיות נקודת קצה אמיתית לאחר שהפריסה של העמוד משתנה.