encode/httpx
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

📝 Docs patch following PR #1791 section compatibility.encoding (#1812)

Browse Source 
* 📝 Docs patch following PR #1791 section compatibility.encoding

Reintroducing charset detection

* 📝 Amend sentence in 3080a9d66e

Co-authored-by: Tom Christie <tom@tomchristie.com>
This commit is contained in:
TAHRI Ahmed R 2021-08-31 05:44:12 -07:00 committed by GitHub
parent 0ccc3fa9be
commit ecbece178f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/compatibility.md
View File

@ -35,7 +35,7 @@ and is expected to be fully removed with the HTTPX 1.0 release.
HTTPX uses `utf-8` for encoding `str` request bodies. For example, when using `content=<str>` the request body will be encoded to `utf-8` before being sent over the wire. This differs from Requests which uses `latin1`. If you need an explicit encoding, pass encoded bytes explictly, e.g. `content=<str>.encode("latin1")`.
For response bodies, assuming the server didn't send an explicit encoding then HTTPX will do its best to figure out an appropriate encoding. Unlike Requests which uses the `chardet` library, HTTPX relies on a plainer fallback strategy (basically attempting UTF-8, or using Windows-1252 as a fallback). This strategy should be robust enough to handle the vast majority of use cases.
For response bodies, assuming the server didn't send an explicit encoding then HTTPX will do its best to figure out an appropriate encoding. HTTPX makes a guess at the encoding to use for decoding the response using `charset_normalizer`. Fallback to that or any content with less than 32 octets will be decoded using `utf-8` with the `error="replace"` decoder strategy.
## Cookies