From ecbece178fae4919994ac20ae8318b46972b7493 Mon Sep 17 00:00:00 2001 From: TAHRI Ahmed R Date: Tue, 31 Aug 2021 05:44:12 -0700 Subject: [PATCH] :pencil: Docs patch following PR #1791 section compatibility.encoding (#1812) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * :pencil: Docs patch following PR #1791 section compatibility.encoding Reintroducing charset detection * 📝 Amend sentence in 3080a9d66ead9b1ffcdc2ec9f4f9364734f8a0c4 Co-authored-by: Tom Christie --- docs/compatibility.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/compatibility.md b/docs/compatibility.md index 7aed9dc1..7a8dc7ee 100644 --- a/docs/compatibility.md +++ b/docs/compatibility.md @@ -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=` 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=.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