阅读了两者的内容后,我仍然不能理解其中的差异,可能是语言差异,请帮忙作出澄清。
返回一个中间件,该中间件只解析urlencoded请求体,并且只查看Content-Type标头与type选项匹配的请求。该解析器仅接受UTF-8编码的请求体并支持gzip和deflate编码的自动膨胀。
而
在处理程序之前的中间件中解析传入的请求体,可在req.body属性下使用。
我理解
但最终两者都提供了一个包含请求体对象中发送的参数的req.body。那么为什么我应该使用需要单独安装的body-parser而不总是使用express.urlencoded()呢?
我知道这不是一个代码问题,但提前感谢任何可以列出主要区别的人。
express.urlencoded()
:返回一个中间件,该中间件只解析urlencoded请求体,并且只查看Content-Type标头与type选项匹配的请求。该解析器仅接受UTF-8编码的请求体并支持gzip和deflate编码的自动膨胀。
而
body-parser
中间件:在处理程序之前的中间件中解析传入的请求体,可在req.body属性下使用。
我理解
express.urlencoded
是基于 Node.js body-parser
实现的。同时,这两个页面:https://expressjs.com/en/api.html#express.urlencoded 和 https://expressjs.com/en/resources/middleware/body-parser.html 都提到了相同的警告:由于req.body的形状基于用户控制的输入,因此该对象中的所有属性和值都是不可信的,在信任之前应进行验证。例如,req.body.foo.toString()可能会有多种失败方式,例如foo可能不存在或不是字符串,toString可能不是函数而是字符串或其他用户输入。但最终两者都提供了一个包含请求体对象中发送的参数的req.body。那么为什么我应该使用需要单独安装的body-parser而不总是使用express.urlencoded()呢?
我知道这不是一个代码问题,但提前感谢任何可以列出主要区别的人。
body-parser
的理由,但仍然有可能出现依赖项失败(就像我在PassportJS中遇到的问题一样,在调查后发现它似乎缺少了body parser,尽管我已经使用了urlencoded
中间件。这可能是为什么?) - fedescpassport-strategy
和pause
,但它可能来自于其他依赖于body-parser
的软件包。 - 1565986223urlencoded()
可靠性的问题,并让我想知道是否最好总是包括body-parser
而不是urlencoded
以确保安全。毕竟,它是一个Node模块。它本身就非常可靠。@naga - elixir - jar非常感谢您的回答。 - fedescexpress
有body-parser
作为依赖项,所以当你运行npm install express
时,它应该自动下载body-parser
。不确定为什么需要重新下载。 - 1565986223body parser
并不是我的代码中真正的问题,它只是引导我去研究它,但我无法分辨差异 :) 我会继续寻找。 - fedesc