Kage - เครื่องมือสำหรับลบ JavaScript ออกจากเว็บไซต์และเก็บถาวรแบบออฟไลน์

 (github.com/tamnd)
2 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เรนเดอร์หน้าเว็บด้วย Headless Chrome เพื่อสแนปช็อต DOM สุดท้ายตามที่ผู้ใช้เห็น จากนั้นลบ JavaScript ทั้งหมด และดาวน์โหลด CSS, รูปภาพ, ฟอนต์ มาไว้ในพาธภายในเครื่อง เพื่อสร้างสำเนาแบบสแตติกที่ทำงานได้โดยไม่ต้องมีโค้ด
  • แก้ปัญหาหน้าเว็บที่บันทึกด้วย "Save As" แล้วเมื่อเวลาผ่านไปกลับพังเป็นหน้าจอว่าง, สปินเนอร์ค้าง, หรือพยายามเชื่อมต่อกับเซิร์ฟเวอร์ analytics ที่หายไป
    • ให้ไฟล์ .html ที่เปิดได้จากดิสก์โดยตรง โดยไม่มีการติดตาม, การเรียกเครือข่าย, หรือพฤติกรรมไม่คาดคิด
  • ใช้การครอว์ลแบบ breadth-first โดยอ่าน robots.txt, ใช้ sitemap.xml เป็นจุดเริ่มต้น และอยู่ภายในโฮสต์ตั้งต้นเท่านั้น
    • ด้วยคุณสมบัติ idempotent จึงดึงหน้าเดียวกันเพียงครั้งเดียว ไม่ว่าจะเป็น http/https หรือมี/ไม่มี trailing slash
    • เมื่อกด Ctrl-C จะบันทึกตำแหน่งไว้ และเมื่อรันใหม่จะทำต่อจากเดิม โดยใช้ --refresh เพื่อเรนเดอร์ใหม่ และ --force เพื่อเริ่มต้นใหม่
  • มี แฟล็กสำหรับควบคุมขอบเขตและพฤติกรรมการครอว์ล เช่น --max-pages, --max-depth, --scope-prefix, --subdomains, --scroll, --workers
  • ใช้ kage pack เพื่อบีบอัดสำเนาเป็นไฟล์เดียว โดยเลือกได้ระหว่าง ZIM archive หรือ ไฟล์ปฏิบัติการเดี่ยว ที่ทำงานเป็นเว็บไซต์ได้เอง
    • ZIM เข้ากันได้กับระบบนิเวศของ Kiwix จึงเปิดดูได้ผ่าน kiwix-serve หรือแอป Kiwix บนเดสก์ท็อปและมือถือ
    • ไบนารีแบบสแตนด์อโลนทำให้ผู้รับไม่ต้องติดตั้งอะไรเพิ่มเติม และสามารถใช้ --base เพื่อสร้าง viewer สำหรับ OS อื่นได้ (ประมาณ 13 MiB + ขนาดเว็บไซต์)
  • ด้วย deterministic packing สำเนาเดียวกันจะสร้างไฟล์ที่ byte-identical เสมอ และ UUID ของ archive ถูกสร้างจากเนื้อหา จึงปลอดภัยต่อ checksum และ cache
  • เมื่อบิลด์ด้วยแท็ก webview จะใช้ OS WebView (WKWebView, WebView2, WebKitGTK) เพื่อเปิดใน หน้าต่างแอปของตัวเองแทนแท็บเบราว์เซอร์
  • ไปป์ไลน์การประมวลผล: seed URL → เรนเดอร์ด้วย headless Chrome → สแนปช็อต final DOM → strip JS → ทำให้แอสเซ็ตเป็นไฟล์ภายในเครื่อง → บันทึกลงดิสก์
  • สัญญาอนุญาต MIT

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 시간 전
ความคิดเห็นจาก Hacker News

  • สนใจเลยไปดูว่าเดโม GIF ใน README สร้างอย่างไร: https://github.com/tamnd/kage/blob/01e75b87ecc893bbba7943c63...
    ปรากฏว่าใช้โปรเจ็กต์อีกตัวของผู้เขียนคนเดียวกันคือ https://github.com/tamnd/ascii-gif
    สคริปต์ที่ใช้ในเดโมอยู่ที่ https://github.com/tamnd/kage/blob/01e75b87ecc893bbba7943c63... และมีคอมเมนต์บอกวิธีรันไว้ด้วย: ascii-gif render docs/demo/kage.tape -o docs/static/demo.gif
    ดูเหมือนเป็นแรปเปอร์ที่ครอบ https://github.com/charmbracelet/vhs แบบมีสไตล์เฉพาะตัวมาก

    • เคยได้ยินกิตติศัพท์ของผู้กอบกู้เทอร์มินัล asciinema ไหม: https://asciinema.org/
    • ใน $HOME/bin/ ของผมก็มีไบนารีส่วนตัวแนวนี้อยู่พอสมควร เช่น delete-all-npm, clean-rust-cache, download-youtube-playlist, get-markdown ซึ่งดีตรงไม่ต้องจำคำสั่ง
      บางครั้งเอเจนต์เขียนโค้ดก็หาวิธีเรียกใช้เครื่องมือพวกนี้ได้เองด้วย
    • ทำเป็น animated SVG แทน GIF ก็ได้ และเพราะมันเป็นแค่คีย์เฟรมข้อความ จึงเล็กกว่า GIF มาก: https://github.com/vytskalt/pseudoc/blob/main/assets/factori...
    • อีกอย่าง ถ้าเป็นแพลตฟอร์มอื่นอย่าง Windows/macOS, LiceCAP ก็เป็นเครื่องมือที่ยอดเยี่ยมสำหรับอัดหน้าจอเป็น GIF ขนาดเล็ก ผู้สร้างเดียวกับ Winamp และ Reaper DAW: https://www.cockos.com/licecap/
    • VHS เหมาะมากสำหรับทำการสร้างวิดีโอจากบรรทัดคำสั่งแบบสคริปต์

  • ถ้าอยากให้เข้าถึงวิกิของบริษัทได้ง่ายแม้ตอนออฟไลน์ ก็อาจใช้สิ่งนี้ได้ เช่น อาจมีเอกสารที่มีประโยชน์อยู่ในวิกิสำหรับใช้หน้างานที่สัญญาณมือถือเข้าไม่ถึง
    การรวมทั้งเว็บไซต์เป็นไบนารีเดียวได้ถือว่าเจ๋งมาก แต่จะดียิ่งขึ้นถ้ามีเวอร์ชันที่ไม่ต้องใช้ serving process แยกต่างหาก
    ดูเหมือนว่าน่าจะทำเป็น shim ที่มีจุดเข้าใช้งานเป็น HTML ไฟล์เดียว พร้อม JavaScript เล็กน้อยสำหรับค้นดูคลังเนื้อหาของเว็บไซต์ในรูปแบบที่ฝังมาในตัวได้ด้วย

    • โพสต์ลง Hacker News ได้เหมาะที่พอดีเลย เดี๋ยวจะลองพิจารณาทำไอเดียนี้ดู
      ในหัวผมมีสคริปต์/โปรแกรมสำหรับแปลง HTML เป็น Markdown อยู่แล้ว ดังนั้นจริง ๆ อาจเก็บทุกอย่างลงดิสก์เป็น โฟลเดอร์ไฟล์ Markdown แล้ว commit เข้า Git repository ไปเลยก็ได้

  • อันนี้ยอดเยี่ยมมาก ผมอยากได้วิธีรับต้นแบบของใครสักคนที่ทำจาก Lovable หรืออะไรทำนองนั้นมาเป็นสำเนาออฟไลน์ แล้ว จัดการเวอร์ชันและแชร์ ได้ในรูปแบบที่ง่ายกว่า
    วิธีที่เราเข้าถึงปัญหานี้เขียนไว้ที่นี่: https://productnow.ai/blogs/extracting-html-from-ai-prototyp...
    ตอนนี้จะลองดูอันนี้และดูว่าสามารถดัดแปลงบางส่วนได้ไหม ชอบไอเดียเรื่องออฟไลน์มิเรอร์ และทำให้กรณีใช้งานด้านการทำงานร่วมกันง่ายขึ้นมาก

  • มีตัวอย่าง kage serve $HOME/data/kage/paulgraham.com แต่ถ้าผลลัพธ์เป็นไฟล์สแตติก ก็ไม่เข้าใจว่าทำไมยังต้องมีเซิร์ฟเวอร์ จำเป็นต้องทำให้เปิดในเบราว์เซอร์ได้ตรง ๆ ไม่ได้หรือ?
    เช่นถ้าทำให้ใช้แบบ $ firefox $HOME/data/kage/paulgraham.com ได้ ก็จะใช้ผลลัพธ์นี้ได้แม้บน เครื่องที่ไม่ได้ติดตั้ง kage

    • หรือไม่ก็อาจใช้ python -m http.server แทนได้ ยังไม่ได้ลองแต่คิดว่าน่าจะใช้ได้
      จริง ๆ แล้ว Kage มีอยู่สองส่วน ส่วนหนึ่งคือ crawler ที่ crawl หน้าเว็บหลังจาก Chrome/Chromium เรนเดอร์เสร็จ แล้วจับ DOM มาแปลงเป็น HTML ที่สะอาด อีกส่วนคือองค์ประกอบ pack/serve ที่แพ็กผลลัพธ์เป็นไฟล์ ZIM สำหรับ Kiwix หรือเป็นไฟล์ปฏิบัติการ
    • ปกติถ้าโหลดหน้าเว็บแบบนั้น JavaScript จะถูกบล็อก
    • ถ้าทำแบบนั้นก็น่าจะเจอ ปัญหา CORS เยอะมาก

  • มองว่า SingleFile [0] เป็นเวอร์ชันที่แข็งแกร่งกว่านี้มาก
    มันลบ JavaScript ออกทั้งหมดด้วย แต่จะรวมทุกอย่างเป็น ไฟล์ HTML เดียว ที่ส่งต่อได้ง่าย
    แอสเซ็ตไบนารีอย่างเว็บฟอนต์หรือรูปภาพจะถูกใส่เป็นสตริง base64
    และยังมี CLI ที่ทำงานบน Puppeteer ให้ด้วย [1]
    [0]: https://github.com/gildas-lormeau/singlefile
    [1]: https://github.com/gildas-lormeau/single-file-cli

    • ดูเหมือนว่ารีโพซิทอรีนี้จะเก็บได้แค่หน้าเว็บเดียว
      แต่สิ่งที่กำลังทำตรงนี้คือ การมิเรอร์ทั้งเว็บไซต์ รวมถึงหน้าย่อยด้วย เลยท่องดูได้ทั้งหมดแม้ออฟไลน์ เช่น เรียงความทั้งหมดบน paulgraham.com
    • ชอบ SingleFile มาก ส่วนขยาย Firefox ทำงานได้ดีพอสมควรในการบันทึกแบบสะอาด
      แต่ถ้า Kage สามารถรวมคุณภาพการเก็บหน้าแบบ SingleFile เข้ากับแนวทางการไต่เว็บแบบ HTTPTrack ได้ ก็ดูมีอนาคตมาก แอปหน้าเดียว นั้นเก็บถาวรค่อนข้างยาก เลยสงสัยว่า Kage จะจัดการได้ดีแค่ไหน
    • ขอบคุณสำหรับลิงก์ จะลองทำ ฟีเจอร์ HTML เดียว นี้ดู ถ้ามีก็น่าจะดี
    • ต่างจากการสั่ง File -> Save as ในเว็บเบราว์เซอร์ทั่วไปบนคอมพิวเตอร์อย่างไร?
    • ตอนแรกผมก็นึกถึงแบบนี้เหมือนกัน และมองว่าเป็นวิธีแก้ที่สวยมาก ไม่ได้ซับซ้อนเกินจำเป็นด้วย

  • ลองคัดลอกเว็บไซต์ที่เป็น HTTP คือไม่ใช่ HTTPS แล้ว แต่ขึ้น navigation failed: net::ERR_NAME_NOT_RESOLVED แม้จะระบุโปรโตคอลเป็น http:// แล้วก็ยังเหมือนเดิม

  • ตอนดาวน์โหลดวิกิไว้อ่านบนเครื่องบิน ผมใช้ httrack(https://www.httrack.com) มาตลอด ไม่ได้สมบูรณ์แบบ แต่ก็ดีกว่าตัวอื่นที่เคยหาเจอมาก่อน
    จะลองอันนี้เหมือนกัน และถ้าผลออกมาดีก็คงดีใจมาก

    • ชวนให้นึกความหลังเลย ราว 20 ปีก่อนอินเทอร์เน็ตยังเป็นแบบต่อสายโทรศัพท์ที่แพงอยู่ ผมจะไปร้านเน็ต ใช้ HTTrack โหลดเว็บไซต์กับการ์ตูน แล้วคัดลอกทั้งหมดลงแฟลชไดรฟ์ USB 128MB ที่ตอนนั้นรู้สึกว่าใหญ่มาก ก่อนเอากลับบ้านมาอ่านแบบออฟไลน์
    • ถ้าเอาเฉพาะวิกิ มีเหตุผลอะไรที่ไม่ใช้ Kiwix ไหม? ถ้าไม่ใช่รีลีสแบบ “ทางการ” มันจะซับซ้อนขึ้นหน่อย แต่ก็มีบริการที่สร้างไฟล์ ZIM ให้ แอปรีดเดอร์บนเดสก์ท็อปจากที่ผมใช้มาก็ค่อนข้างดี
      https://wiki.openzim.org/wiki/Build_your_ZIM_file
      EDIT: https://get.kiwix.org/en/solutions/applications/kiwix-reader...
    • https://github.com/archiveteam/grab-site หรือ browsertrix อาจใช้ง่ายกว่าสำหรับบางคน เป็นเครื่องมือที่เคยใช้ตอนต้องเก็บข้อมูลจาก data.gov จำนวนมากก่อนที่มันจะหายไป

  • หลายปีมานี้ผมสะสมคลังเว็บไซต์เก่าไว้พอสมควร เรื่องน่าสนใจก็คือ HTML dump ที่หน้าตาไม่สวยกลับมีประโยชน์มากกว่าอาร์ไคฟ์ที่ “สมบูรณ์แบบ”
    นี่ก็เป็นหนึ่งในเหตุผลที่ยิ่งนานไปผมยิ่งชอบ RSS เพราะฟีดที่อายุสัก 10 ปีมักใช้งานได้ง่ายกว่าเว็บไซต์แบบแอปพลิเคชันที่ถูกเก็บรักษาอย่างประณีตในปัจจุบัน

    • ผมกำลังทำโปรเจ็กต์ที่สร้างและเก็บถาวร RSS feed โดยเก็บ ประวัติทั้งหมด ตั้งแต่ตอนที่ครอว์เลอร์เริ่มทำงาน
      จัดระเบียบอีกนิดแล้วจะปล่อยเป็นโอเพนซอร์สเร็ว ๆ นี้

  • ดูเหมือนว่านี่อาจสร้างภาระให้เว็บไซต์ค่อนข้างมาก มีการตั้งค่าให้หน่วงความเร็วในการคัดลอก หรือหลีกเลี่ยงรูปภาพ/วิดีโอไหม?
    แล้วก็สงสัยว่ามี วิธีดึงมาแค่บางส่วนของเว็บไซต์ หรือเปล่า

    • ช่วยทำเป็น issue ใหม่ให้ได้ไหม? เดี๋ยวผมมาจัดการทีหลัง ตอนนี้เป็นตี 1 ตามเวลาผมแล้ว แต่ก็ดีใจที่มีคนสนใจ
    • ก็แค่แกล้งเป็น AI crawler ปัญหาก็หมด

  • เป็นโปรเจ็กต์ที่เรียบร้อยดีและผมชอบไอเดียนี้
    อ่านผ่าน ๆ เห็นว่าเปิด Chrome ด้วย --no-sandbox มีเหตุผลอะไรเป็นพิเศษไหม? ในแง่ความปลอดภัยนี่อาจไม่ใช่ความคิดที่ดีนัก ถ้าไม่มีเหตุผลก็แนะนำให้เปิด sandbox ไว้
    ยังไงก็เป็นงานที่เจ๋งมาก

    • --no-sandbox จำเป็นใน Docker อาจจะตั้งต้นจากสมมติฐานว่าส่วนใหญ่จะ รันใน Docker ก็ได้?