# Extra Wrappers
Extra wrappers or mixins contributed by the community. These wrappers canbe mixed in into request objects to add extra functionality.
Example:
~~~
from werkzeug.wrappers import Request as RequestBase
from werkzeug.contrib.wrappers import JSONRequestMixin
class Request(RequestBase, JSONRequestMixin):
pass
~~~
Afterwards this request object provides the extra functionality of the[JSONRequestMixin](# "werkzeug.contrib.wrappers.JSONRequestMixin").
*class *werkzeug.contrib.wrappers.JSONRequestMixin
Add json method to a request object. This will parse the input datathrough simplejson if possible.
[BadRequest](# "werkzeug.exceptions.BadRequest") will be raised if the content-typeis not json or if the data itself cannot be parsed as json.
json
Get the result of simplejson.loads if possible.
*class *werkzeug.contrib.wrappers.ProtobufRequestMixin
Add protobuf parsing method to a request object. This will parse theinput data through [protobuf](http://code.google.com/p/protobuf/) [http://code.google.com/p/protobuf/] if possible.
[BadRequest](# "werkzeug.exceptions.BadRequest") will be raised if the content-typeis not protobuf or if the data itself cannot be parsed property.
parse_protobuf(*proto_type*)
Parse the data into an instance of proto_type.
protobuf_check_initialization* = True*
by default the [ProtobufRequestMixin](# "werkzeug.contrib.wrappers.ProtobufRequestMixin") will raise a[BadRequest](# "werkzeug.exceptions.BadRequest") if the object is notinitialized. You can bypass that check by setting thisattribute to False.
*class *werkzeug.contrib.wrappers.RoutingArgsRequestMixin
This request mixin adds support for the wsgiorg routing args[specification](http://www.wsgi.org/wsgi/Specifications/routing_args) [http://www.wsgi.org/wsgi/Specifications/routing_args].
routing_args
The positional URL arguments as tuple.
routing_vars
The keyword URL arguments as dict.
*class *werkzeug.contrib.wrappers.ReverseSlashBehaviorRequestMixin
This mixin reverses the trailing slash behavior of [script_root](# "werkzeug.contrib.wrappers.ReverseSlashBehaviorRequestMixin.script_root")and [path](# "werkzeug.contrib.wrappers.ReverseSlashBehaviorRequestMixin.path"). This makes it possible to use urljoin()directly on the paths.
Because it changes the behavior or Request this class has to bemixed in *before* the actual request class:
~~~
class MyRequest(ReverseSlashBehaviorRequestMixin, Request):
pass
~~~
This example shows the differences (for an application mounted on/application and the request going to /application/foo/bar):
>
| | normal behavior | reverse behavior |
|-----|-----|-----|
| script_root | /application | /application/ |
| path | /foo/bar | foo/bar |
path
Requested path as unicode. This works a bit like the regular pathinfo in the WSGI environment but will not include a leading slash.
script_root
The root path of the script includling a trailing slash.
*class *werkzeug.contrib.wrappers.DynamicCharsetRequestMixin
“If this mixin is mixed into a request class it will providea dynamic charset attribute. This means that if the charset istransmitted in the content type headers it's used from there.
Because it changes the behavior or Request this class hasto be mixed in *before* the actual request class:
~~~
class MyRequest(DynamicCharsetRequestMixin, Request):
pass
~~~
By default the request object assumes that the URL charset is thesame as the data charset. If the charset varies on each requestbased on the transmitted data it's not a good idea to let the URLschange based on that. Most browsers assume either utf-8 or latin1for the URLs if they have troubles figuring out. It's stronglyrecommended to set the URL charset to utf-8:
~~~
class MyRequest(DynamicCharsetRequestMixin, Request):
url_charset = 'utf-8'
~~~
0.6 新版功能.
charset
The charset from the content type.
default_charset* = 'latin1'*
the default charset that is assumed if the content type headeris missing or does not contain a charset parameter. The defaultis latin1 which is what HTTP specifies as default charset.You may however want to set this to utf-8 to better supportbrowsers that do not transmit a charset for incoming data.
unknown_charset(*charset*)
Called if a charset was provided but is not supported bythe Python codecs module. By default latin1 is assumed thento not lose any information, you may override this method tochange the behavior.
| 参数: | **charset** – the charset that was not found. |
|-----|-----|
| 返回: | the replacement charset. |
*class *werkzeug.contrib.wrappers.DynamicCharsetResponseMixin
If this mixin is mixed into a response class it will providea dynamic charset attribute. This means that if the charset islooked up and stored in the Content-Type header and updatesitself automatically. This also means a small performance hit butcan be useful if you're working with different charsets onresponses.
Because the charset attribute is no a property at class-level, thedefault value is stored in default_charset.
Because it changes the behavior or Response this class hasto be mixed in *before* the actual response class:
~~~
class MyResponse(DynamicCharsetResponseMixin, Response):
pass
~~~
0.6 新版功能.
charset
The charset for the response. It's stored inside theContent-Type header as a parameter.
default_charset* = 'utf-8'*
the default charset.
- 开始
- Werkzeug 文档概览
- 安装
- 过渡到 Werkzeug 1.0
- Werkzeug 教程
- API 标准
- 快速开始
- Python 3 Notes
- 服务和测试
- Debugging Applications
- 在服务器运行 WSGI 应用
- 单元测试
- 参考
- Request / Response Objects
- URL Routing
- WSGI Helpers
- HTTP Utilities
- Data Structures
- Utilities
- Context Locals
- Middlewares
- HTTP Exceptions
- 部署
- CGI
- mod_wsgi (Apache)
- FastCGI
- HTTP Proxying
- 贡献模块
- Atom Syndication
- Sessions
- Secure Cookie
- Cache
- Extra Wrappers
- Iter IO
- Fixers
- WSGI Application Profiler
- Lint Validation Middleware
- 额外说明
- Werkzeug Changelog
- Important Terms
- Unicode
- Dealing with Request Data