Kage - Công cụ loại bỏ JavaScript khỏi website và lưu trữ ngoại tuyến

 (github.com/tamnd)
2 điểm bởi GN⁺ 3 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Dùng Chrome không giao diện để render trang, chụp lại DOM cuối cùng mà người dùng thực sự nhìn thấy, sau đó xóa toàn bộ JavaScript và tải CSS·hình ảnh·phông chữ về đường dẫn cục bộ để tạo một bản sao tĩnh hoạt động không cần mã
  • Giải quyết vấn đề các trang lưu bằng "Save As" sau một thời gian sẽ hỏng với màn hình trắng·spinner bị treo·các nỗ lực kết nối đến máy chủ analytics đã biến mất
    • Cung cấp tệp .html có thể mở trực tiếp từ ổ đĩa mà không có theo dõi·gọi mạng·hành vi ngoài ý muốn
  • Dùng crawl theo chiều rộng để đọc robots.txt, lấy điểm bắt đầu từ sitemap.xml và chỉ ở lại trong host seed
    • Nhờ tính chất idempotent, cùng một trang chỉ được lấy một lần bất kể là http·https hay có/không có dấu gạch chéo cuối
    • Khi nhấn Ctrl-C sẽ lưu vị trí và tiếp tục khi chạy lại; dùng --refresh để render lại, --force để bắt đầu mới
  • Cung cấp các flag điều khiển phạm vi·hành vi crawl như --max-pages, --max-depth, --scope-prefix, --subdomains, --scroll, --workers
  • Với kage pack, có thể đóng gói bản sao thành một tệp duy nhất, chọn giữa kho lưu trữ ZIM hoặc tệp thực thi độc lập có thể tự hoạt động như một website
    • ZIM tương thích với hệ sinh thái Kiwix nên có thể xem bằng kiwix-serve hoặc ứng dụng Kiwix trên desktop·di động
    • Binary độc lập giúp người nhận không cần cài gì thêm, và có thể dùng --base để tạo viewer cho hệ điều hành khác (khoảng 13 MiB + dung lượng website)
  • Nhờ đóng gói có tính xác định, cùng một bản sao sẽ luôn tạo ra tệp giống hệt nhau ở mức byte; UUID của archive được suy ra từ nội dung nên an toàn cho checksum·cache
  • Khi build với tag webview, sẽ dùng WebView của hệ điều hành (WKWebView·WebView2·WebKitGTK) để mở trong cửa sổ riêng thay vì tab trình duyệt
  • Pipeline xử lý: seed URL → render bằng Chrome không giao diện → chụp final DOM → loại bỏ JS → nội địa hóa tài nguyên → lưu xuống đĩa
  • Giấy phép MIT

Bài viết liên quan

1 bình luận

 
GN⁺ 3 giờ trước
Ý kiến trên Hacker News

  • Tôi thấy tò mò về cách tạo ra ảnh GIF demo trong README nên đã xem: https://github.com/tamnd/kage/blob/01e75b87ecc893bbba7943c63...
    Hóa ra nó dùng một dự án khác của cùng tác giả là https://github.com/tamnd/ascii-gif
    Script dùng cho demo nằm ở https://github.com/tamnd/kage/blob/01e75b87ecc893bbba7943c63..., và cách chạy cũng có trong chú thích: ascii-gif render docs/demo/kage.tape -o docs/static/demo.gif
    Có vẻ như là một wrapper mang đậm gu cá nhân bọc quanh https://github.com/charmbracelet/vhs

    • Bạn đã nghe tin mừng của vị cứu tinh terminal asciinema chưa: https://asciinema.org/
    • Trong $HOME/bin/ của tôi cũng có khá nhiều binary cá nhân kiểu này. Những thứ như delete-all-npm, clean-rust-cache, download-youtube-playlist, get-markdown; điểm hay là không cần phải nhớ lệnh
      Đôi khi coding agent còn tự tìm ra cách gọi các công cụ này
    • Cũng có thể làm bằng animated SVG thay cho GIF, và vì chỉ là các keyframe văn bản nên nhẹ hơn GIF rất nhiều: https://github.com/vytskalt/pseudoc/blob/main/assets/factori...
    • Nhân tiện, trên các nền tảng khác là Windows/macOS thì LiceCAP là một công cụ tuyệt vời để ghi màn hình thành GIF nhỏ. Nó do tác giả của Winamp và Reaper DAW tạo ra: https://www.cockos.com/licecap/
    • VHS rất tuyệt khi bạn muốn script hóa việc tạo video dòng lệnh

  • Có thể dùng cái này khi bạn muốn giúp việc truy cập wiki công ty trở nên dễ dàng ngay cả khi offline. Ví dụ, có thể có tài liệu hữu ích trên wiki để dùng tại hiện trường nơi điện thoại không bắt được sóng
    Việc có thể gói cả website thành một binary duy nhất rất ngầu, nhưng sẽ càng hay hơn nếu có phiên bản không cần serving process riêng
    Có vẻ cũng có thể làm kiểu một shim với một điểm vào HTML duy nhất chứa một ít JavaScript để duyệt kho lưu trữ nội dung của site, nếu có thể thì ở dạng nhúng sẵn

    • Đăng lên Hacker News đúng là đúng chỗ rồi. Tôi sẽ cân nhắc triển khai ý tưởng này
      Trong đầu tôi đã có sẵn một script/chương trình chuyển HTML sang Markdown, nên trên thực tế cũng có thể lưu mọi thứ thành một thư mục các file Markdown trên đĩa rồi commit vào Git repository

  • Cái này rất hay. Tôi đã muốn lấy một bản sao offline của prototype ai đó làm trên Lovable hay mấy nơi tương tự, để quản lý phiên bản và chia sẻ theo định dạng dễ hơn
    Cách chúng tôi tiếp cận việc này được viết ở đây: https://productnow.ai/blogs/extracting-html-from-ai-prototyp...
    Giờ tôi sẽ xem thử cái này và xem có thể thay đổi một vài phần không. Tôi thích ý tưởng mirror offline, và các use case liên quan đến cộng tác cũng trở nên đơn giản hơn nhiều

  • Có ghi kage serve $HOME/data/kage/paulgraham.com, nhưng nếu đầu ra là tĩnh thì tôi không hiểu vì sao lại cần server. Không thể làm cho nó mở trực tiếp trong trình duyệt sao?
    Ví dụ nếu có thể như $ firefox $HOME/data/kage/paulgraham.com thì đầu ra có thể dùng được cả trên máy không cài kage

    • Thay vào đó có vẻ có thể dùng python -m http.server. Tôi chưa thử nhưng có lẽ sẽ chạy
      Thực ra Kage gồm hai phần. Một phần là crawler dùng để crawl trang, chụp DOM sau khi Chrome/Chromium render và biến nó thành HTML sạch, còn phần kia là thành phần pack/serve để đóng gói kết quả thành file ZIM cho Kiwix hoặc thành executable
    • Thường thì khi tải trang theo kiểu đó, JavaScript sẽ bị chặn
    • Làm vậy thì có lẽ sẽ gặp cả đống vấn đề CORS

  • Tôi nghĩ SingleFile [0] là một phiên bản vững chắc hơn nhiều so với cái này
    Nó cũng loại bỏ toàn bộ JavaScript, nhưng gói mọi thứ vào một tệp HTML duy nhất rất dễ chia sẻ. Các tài sản nhị phân như web font hay hình ảnh được nhúng dưới dạng chuỗi base64
    Nó cũng cung cấp CLI dựa trên Puppeteer [1]
    [0]: https://github.com/gildas-lormeau/singlefile
    [1]: https://github.com/gildas-lormeau/single-file-cli

    • Kho này có vẻ chỉ lưu một trang web duy nhất
      Còn thứ đang được triển khai ở đây là mirror cả website, bao gồm cả các trang con, nên vẫn có thể duyệt toàn bộ khi ngoại tuyến. Ví dụ như toàn bộ các bài luận trên paulgraham.com
    • Tôi rất thích SingleFile. Tiện ích mở rộng Firefox hoạt động khá tốt trong việc lưu gọn gàng
      Tuy vậy, nếu Kage có thể kết hợp chất lượng tái hiện ở mức SingleFile với cách tiếp cận spidering kiểu HTTPTrack thì trông rất hứa hẹn. Ứng dụng trang đơn hơi khó để lưu trữ, nên tôi tò mò không biết Kage sẽ xử lý tốt đến mức nào
    • Cảm ơn vì liên kết. Tôi sẽ thử triển khai tính năng HTML đơn này. Có vẻ sẽ rất hữu ích
    • Nó khác gì so với việc vào bất kỳ trình duyệt nào trên máy tính rồi chọn File -> Save as?
    • Tôi cũng nghĩ ngay đến điều này lúc đầu, và thấy đây là một giải pháp rất thanh lịch. Nó cũng không phức tạp một cách không cần thiết

  • Tôi đã thử sao chép một trang dùng HTTP, tức không phải HTTPS, nhưng gặp navigation failed: net::ERR_NAME_NOT_RESOLVED. Ngay cả khi chỉ rõ giao thức bằng http:// thì vẫn vậy

  • Tôi đã dùng httrack(https://www.httrack.com) để tải wiki về đọc trên máy bay. Nó không hoàn hảo, nhưng tốt hơn những thứ tôi từng tìm thấy trước đây
    Tôi cũng sẽ thử cái này, và sẽ rất vui nếu kết quả tốt

    • Gợi nhiều kỷ niệm quá. Khoảng 20 năm trước, Internet vẫn là quay số đắt đỏ, nên tôi thường ra tiệm net, dùng HTTrack để tải website và truyện tranh, rồi chép hết vào chiếc USB 128MB khi đó cảm giác rất lớn, sau đó mang về nhà đọc ngoại tuyến
    • Chỉ riêng với wiki thì có lý do gì để không dùng Kiwix không? Với những bản không phải phát hành “chính thức” thì phức tạp hơn, nhưng có các dịch vụ tạo tệp ZIM. Theo trải nghiệm của tôi, ứng dụng đọc trên desktop khá tốt
      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 hoặc browsertrix có thể dễ dùng hơn với một số người. Đây là các công cụ từng được dùng khi lưu hàng loạt dữ liệu data.gov trước khi chúng bị gỡ xuống

  • Tôi đã sưu tầm khá nhiều kho lưu trữ các website cũ trong nhiều năm. Điều thú vị là các bản dump HTML xấu xí lại hữu ích hơn những bản lưu trữ “hoàn hảo”
    Đó cũng là một trong những lý do khiến theo thời gian tôi càng thích RSS hơn. Nhiều feed từ khoảng 10 năm trước ngày nay còn dễ dùng hơn những website kiểu ứng dụng được bảo tồn công phu

    • Tôi đang làm một dự án tạo feed RSS và lưu trữ chúng. Nó bảo tồn toàn bộ lịch sử kể từ thời điểm crawler bắt đầu chạy
      Tôi sẽ dọn dẹp thêm một chút rồi sớm mã nguồn mở nó

  • Cái này có vẻ có khả năng tạo tải khá lớn cho website. Có thiết lập nào để điều tiết tốc độ sao chép hoặc tránh hình ảnh/video không?
    Tôi cũng muốn biết liệu có cách chỉ lấy một phần của website hay không

    • Bạn có thể tạo việc này thành một issue mới không? Tôi sẽ xử lý sau. Bây giờ là 1 giờ sáng theo giờ của tôi, nhưng tôi rất vui vì có người quan tâm
    • Cứ giả vờ là trình thu thập AI thì vấn đề sẽ được giải quyết

  • Dự án gọn gàng và tôi thích ý tưởng này
    Đọc lướt nhanh thì tôi thấy nó chạy Chrome với --no-sandbox, có lý do cụ thể nào cho việc đó không? Xét về bảo mật thì đây có thể không phải ý hay. Nếu không có lý do đặc biệt, tôi khuyên nên bật sandbox
    Dù sao thì đây vẫn là một công việc rất ấn tượng

    • --no-sandbox là cần thiết trong Docker. Có lẽ là vì họ giả định nó chủ yếu sẽ chạy trong Docker?