wget VS curl 中英文对照

This document started off as a blog entry, but I decided that I should better make a permanent home for this as I'm sure I'll get reasons to update and fix this as time goes by.

The main differences as I see them. Please consider my bias towards curl since after all, curl is my baby - but I have contributed code to Wget as well.Please let me know if you have other thoughts or comments on this document. Email them to me or reply on the blog entry.

curl 
•Features and is powered by libcurl - a cross-platform library with a stable API that can be used by each and everyone. This difference is major since it creates a completely different attitude on how to do things internally. It is also slightly harder to make a library than a "mere" command line tool.
•Pipes. curl is more in the traditional unix-style, it sends more stuff to stdout, and reads more from stdin in a "everything is a pipe" manner.•Return codes. curl returns a range of defined and documented return codes for various (error) situations.
•Single shot. curl is basically made to do single-shot transfers of data. It transfers just the URLs that the user specifies, and does not contain any recursive downloading logic nor any sort of HTML parser.
•More protocols. curl supports FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, LDAP, LDAPS and FILE at the time of this writing. Wget supports HTTP, HTTPS and FTP.
•More portable. Ironically curl builds and runs on lots of more platforms than wget, in spite of their attempts to keep things conservative. For example: OS/400, TPF and other more "exotic" platforms that aren't straight-forward unix clones.
•More SSL libraries and SSL support. curl can be built with one out of four different SSL/TLS libraries, and it offers more control and wider support for protocol details.
•curl (or rather libcurl) supports more HTTP authentication methods, and especially when you try over HTTP proxies.
•Bidirectional. curl offers upload and sending capabilities. Wget only offers plain HTTP POST support. 
•HTTP multipart/form-data sending, which allows users to do HTTP "upload" and in general emulate browsers and do HTTP automation to a wider extent 
Wget 
•Wget is command line only. There's no lib or anything.
•Recursive! Wget's major strong side compared to curl is its ability to download recursively, or even just download everything that is referred to from a remote resource, be it a HTML page or a FTP directory listing.•Older. Wget has traces back to 1995, while curl can be tracked back no longer than 1997.
•Less developer activity. While this can be debated, I consider three metrics here: mailing list activity, source code commit frequency and release frequency. Anyone following these two projects can see that the curl project has a lot higher pace in all these areas, and it has indeed been so for several years.
•HTTP 1.0. Wget still does its HTTP operations using HTTP 1.0, and while that is still working remarkably fine and hardly ever is troublesome to the end-users, it is still a fact. curl has done HTTP 1.1 since March 2001 (while still offering optional 1.0 requests).
•GPL. Wget is 100% GPL v3. curl is MIT licensed. 
•GNU. Wget is part of the GNU project and all copyrights are assigned to FSF. The curl project is entirely stand-alone and independent with no organization parenting at all - with almost all copyrights owned by Daniel.
•Wget requires no extra options to simply download a remote URL to a local file, while curl requires -o or -O. However trivial, this fact is often mentioned to me when people explain why they prefer downloading with wget. 
Additional Stuff 
You may argue that I should compare uploading capabilities with wput, but that's a separate tool and I don't include that in this comparison.

For a stricter feature by feature comparison (that also compares other similar tools), see the curl comparison table

Updated: February 16, 2009 18:19 (Central European, Stockholm Sweden)

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

CURL

• 基于libcurl库，libcurl是一个稳定的跨平台的类库，任何人可以免费使用其API进行开发。CURL继承了libcurl库的优良设计，这是它能成为优秀的命令行工具的重要原因。
   

• 管道（Pipes）. CURL不仅仅遵循 传统UNIXstyle, 它在对输入和输出做更多的处理，贯彻了 "everything is a pipe" 的设计思想。
   
• 返回值（Return codes）. curl为一系列应用返回多种结果（错误），适用于很多情况。
   
• 单点传送 curl仅仅单点传送数据。它只会传送用户指定的URLS，并不包含任何递归下载的逻辑，也不对html进行任何解析。
   
• 多协议支持. curl 支持的协议有： FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, LDAP, LDAPS, FILE, POP3, IMAP, SMTP 和 RTSP 在写这篇文章时，Wget仅仅支持 HTTP, HTTPS 和 FTP.
   
• 适应更多的平台： curl比wget运行在更多的平台上面，虽然curl设计当初并没有打算这样。比如: OS/400, TPF 和其他很多非UNIX的平台。
   
• 更强大的SSL库. curl能应用于多个不同的 SSL/TLS 库, 并提供了更多的可控性和对协议的广泛支持。
   
• curl支持更多的 HTTP 认证方式
   
• 双向通信. curl 提供了上传能力，Wget仅仅支持HTTP post 方式
   
• HTTP multipart/form-data 的发送能力, 这使得用户可以进行HTTP上传，模拟浏览器的行为和HTTP认证等，提供了更多操作的可能。
   
• 压缩. curl 支持GZIP和 inflate Content-Encoding 并且自动进行解压缩操作。

Wget

 

• Wget 仅仅支持命令行方式运行. 没有类库，不提供API等。
   
• 递归! Wget 与CURL的最大区别也是Wget的最大的优势是可以进行递归的下载，可以一次下载一个HTML页面 或者ftp列表中的所有内容。
   
• 更久的历史. Wget 可以追溯到 1995年，curl则要在 1997年之后出现.
   
• 参与开发的人员相对较. 我打赌，任何参与这两个项目的人都能感觉到这一点。
   
• HTTP 1.0. Wget 仍然仅仅使用 HTTP 1.0，但是它一直工作很好，并且对于最终用户没有任何影响。curl在2001年三月的时候就开始支持 HTTP 1.1 了(仍然保留对 1.0 请求的支持).
   
• GPL. Wget 100% 遵循 GPL v3 协议，. curl 则是  MIT licensed.
   
• GNU. Wget 是 GNU 项目的一部分 并且所有的版权归于 FSF. curl项目则是独立的，独立于任何组织，所有的版权属于Daniel。（哇！）
   
• Wget 不需要任何额外参数 就能从URL下载文件到本地, 而curl需要至少 -o 或者 -O这两个参数.

补充：你可能会有疑问为什么不比较curl和 wput,的上传能力？因为这是两个单独的工具，并没有在这篇文章讨论的范围内。