Sơ đồ Venn curl-wget
(daniel.haxx.se)- wget không phải là đối thủ cạnh tranh trực tiếp của curl; nên xem nó là một công cụ có một phần chức năng chồng lấn và có thể dùng cùng tùy theo tác vụ
- Tiêu chí lựa chọn không phải là sở thích công cụ, mà là công cụ nào phù hợp hơn để hoàn thành công việc; nếu wget phù hợp hơn thì cứ dùng wget
- Các khác biệt kỹ thuật và vùng chồng lấn giữa curl và wget đã được tóm tắt bằng sơ đồ Venn để dễ nhìn, đồng thời cũng có ảnh độ phân giải đầy đủ
- Hai dự án không ở thế đối đầu; phía curl từng đóng góp mã cho wget, và nhiều maintainer của wget cũng từng đóng góp cho curl
- Các lỗi hoặc thiếu sót trong sơ đồ có thể được cập nhật; có thể xem chi tiết hơn trong tài liệu so sánh riêng và bảng so sánh các công cụ tải xuống
Tiêu chí nhìn nhận curl và wget
- wget gần với một công cụ đồng hành hơn là đối thủ của curl
- Hai công cụ có một phần chức năng chồng lấn, nhưng điều cốt lõi không phải là khăng khăng dùng một công cụ cụ thể, mà là chọn công cụ phù hợp với tác vụ cần giải quyết
- Trong tình huống wget phù hợp hơn để hoàn thành công việc, nên dùng wget
Tóm tắt khác biệt bằng sơ đồ Venn
- Một sơ đồ Venn đã được tạo để trực quan hóa các khác biệt kỹ thuật và một số điểm tương đồng giữa curl và wget
- Có thể nhấp vào ảnh sơ đồ để xem phiên bản độ phân giải đầy đủ
- Tác giả đề nghị thông báo nếu phát hiện vấn đề hoặc mục bị thiếu, và có thể cập nhật sơ đồ khi cần
Hợp tác giữa các dự án
- Phía curl từng đóng góp mã cho wget
- Nhiều maintainer của wget cũng từng đóng góp cho curl
- Mối quan hệ giữa hai dự án gần với hợp tác hơn là cạnh tranh hay đối đầu
Các tài liệu so sánh đáng xem thêm
- curl vs wget: tài liệu so sánh curl và wget
- Compare curl with other download tools: bảng so sánh curl với các công cụ tải xuống khác
- OpenHub’s curl vs wget table: bảng so sánh curl-vs-wget của OpenHub
1 bình luận
Ý kiến trên Hacker News
Tôi nghĩ phía Wget ít nhất cũng nên có các giá trị mặc định hợp lý, tiếp tục tải, và thử lại khi gặp lỗi
Gần đây tôi phải viết một script để tải một tệp rất lớn qua kết nối không ổn định, và nhận thức chung giữa các kỹ sư là với việc như vậy thì nên dùng Wget
Tôi cũng đã thử curl, nhưng mặc định nó không tiếp tục tải hay thử lại; tôi phải đọc hướng dẫn và chỉ định nhiều tùy chọn, tham số. Tôi cảm thấy những hành vi này nên là mặc định
Với Wget, chỉ cần một tùy chọn
--continuelà bật được việc tiếp tục tải trong mọi tình huống, kể cả sau khi bị crash; phần giới thiệu trong hướng dẫn cũng nói rằng nó được thiết kế để hoạt động vững vàng trên mạng chậm hoặc không ổn định, và nếu tải thất bại thì sẽ tiếp tục thử lại cho đến khi nhận được toàn bộ tệpVới curl, có lẽ cũng có thể chỉnh đủ mọi tùy chọn để nó hoạt động đáng tin cậy trên kết nối kém, nhưng Wget dường như đã bật sẵn kiểu hành vi mặc định đó, khiến tôi tin rằng nó sẽ làm đúng như kỳ vọng ngay cả trong các tình huống lỗi mà tôi chưa tự kiểm thử. Dù giao thức HTTP được cập nhật, Wget mới có khả năng sẽ hỗ trợ mặc định, còn curl có thể cần một switch mới để bật hành vi cải tiến, mà sau khi sản phẩm đã phát hành thì tôi không thể thêm vào được
Với tôi, curl là một công cụ cấp thấp tuyệt vời và cực kỳ đa năng, CLI của nó cũng phản ánh điều đó, nhưng trong công việc hằng ngày tôi thích Wget hơn vì mặc định nó hoạt động tốt hơn nhiều. Hướng dẫn của nó cũng có thể lướt nhanh hơn, có lẽ vì nó không hỗ trợ tất cả các giao thức khó hiểu được nhắc đến ở đây
Chỉ riêng việc
wget urltải URL xuống và lưu lại cũng đủ để tôi thấy Wget thắng trong cách dùng dòng lệnhcurlcũng có đúng chức năng đó. Tiếp tục tải là flag-C, còn thử lại là--retryCá nhân tôi thấy mặc định của curl cũng khá hợp lý, và với một công cụ như curl thì tôi không muốn bất kỳ tính năng nào trong hai thứ đó được bật mặc định
-i, cho phép Wget đọc URL từ một tệpĐặc biệt
wget -i -đọc từ đầu vào chuẩn nên rất hữu ích trong pipelineTheo tôi biết thì curl không làm được việc này. Người ta thường bảo dùng
xargs, nhưng như vậy phải đợi đến khi tất cả URL đến rồi mới chạy curl, tức là đánh mất tính song song giữa lệnh sinh URL và lệnh tải xuống, nên không hẳn là một phương án thay thế tốtDù trước đây đã đọc hướng dẫn, việc nhớ chính xác flag mình muốn cũng không dễ; thường thì kiểm chứng một dòng lệnh được sinh ra sẽ đỡ tốn công hơn là đọc hướng dẫn rồi tự ghép từ đầu
Trên web hiện đại, đôi khi dùng các công cụ như Puppeteer trong script tự viết còn dễ hơn. Đặc biệt là khi trang bạn tương tác dùng nhiều JavaScript
Ví dụ
$ curl -sSLOJ 'example.com/file name.txt'báo lỗicurl: (3) URL using bad/illegal format or missing URL, còn$ curl -sSLOJ 'example.com/file%20name.txt'tạo ra tệp tênfile%20name.txtNgược lại, wget tạo tệp
"file name.txt"từ cả hai URL mà không cần flag bổ sung. Tuy nhiên URL ví dụ này trả 404, nên nói cho chặt chẽ thì với wget cũng phải thêm--content-on-errorVới nhiều người, khác biệt cốt lõi có lẽ là giữa công cụ mặc định ghi ra đầu ra chuẩn và công cụ mặc định tạo tệp
sh;-)Với tôi, tính năng quyết định của Wget là mặc định nó tải tệp xuống với tên tệp suy ra từ URL
Chạy
wget url://to/file.htmthì trong thư mục làm việc hiện tại sẽ có một tệp tên"file.htm"Với curl thì phải viết kiểu
curl url://to/file.htm > file.htm, hoặc dùng một câu lệnh khác kém tiện hơncurl -Ohttps://curl.se/docs/manpage.html#-O
wget "url://to/file.htm?uid=foo&q=bar&rnd=4"curl -Otiện hơnNếu ví “tính năng quyết định” đó với
cat, thìcat file.htmlsẽ biến thànhcat file.html > file.html. Khi đó nếu thật sự muốn in ra chứ không phải sao chép, bạn sẽ phải dùng kiểucat file.html -o -, nên tôi mừng là curl không có tính năng như vậyDaniel Stenberg thuộc nhóm hiếm các lập trình viên dốc tâm huyết và linh hồn vào tác phẩm của mình
Trong Big Tech hiện đại, các lập trình viên như những cái bóng trông như bánh răng thay thế được trong cỗ máy kiếm tiền, và đặc tính như vậy dường như ngày càng biến mất
Có vẻ ông ấy xem curl như dấu ấn của mình để lại trong thế giới IT
Tất nhiên ngày nay nhiều khi nó thật sự tốt hơn về mặt kỹ thuật, nên lựa chọn càng dễ hơn
So sánh này có vẻ hơi cũ. Ví dụ trong biểu đồ, phía Wget thiếu hai thứ dưới đây
HTTP PUTcó thể làm bằngwget --method=PUT --body-data=, còn proxy và HTTPS cũng có thể làm kiểuwget --use-proxy=on --https_proxy=[https://example.com](<https://example.com>)curl nhất quán có nhiều tùy chọn và linh hoạt hơn, nhưng trong số nhiều mục ở phía bên phải của biểu đồ Venn, cũng có những thứ Wget làm được ở một mức nào đó
Chà, tôi không biết curl hỗ trợ nhiều giao thức đến vậy. Dù vậy, vùng giao nhau nhỏ kia có lẽ là phần mà hơn 90% người dùng curl/Wget thật sự sử dụng
Từ góc nhìn nhà phát triển thì phần chồng lấp không lớn lắm, nhưng từ góc nhìn người dùng thì nó có thể trông lớn hơn nhiều
Phần tôi thích nhất trong bài là câu này
“Tôi từng đóng góp mã cho wget. Nhiều maintainer của wget cũng đã đóng góp cho curl. Tất cả chúng tôi đều là bạn.”
Bản so sánh do Daniel Stenberg tạo cũng là thứ nhất định phải xem
https://daniel.haxx.se/docs/curl-vs-wget.html
Ngày xưa khi muốn mirror một website, tôi dùng Wget. Wget là một công cụ chuyên biệt
curl là một thư viện request đa dụng có CLI frontend, và cũng được nhúng vào các chương trình khác hoặc dùng như API thư viện chuẩn trong PHP, v.v.
Cách dùng phổ biến nhất có lẽ là phần chồng lấp của hai công cụ. Vì vậy tôi muốn thấy một biểu đồ Venn cho biết mỗi công cụ được cài sẵn trên hệ điều hành và Docker image nào