From: TAHRI Ahmed R Date: Tue, 31 Aug 2021 12:44:12 +0000 (-0700) Subject: :pencil: Docs patch following PR #1791 section compatibility.encoding (#1812) X-Git-Tag: 1.0.0.beta0~12 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=ecbece178fae4919994ac20ae8318b46972b7493;p=thirdparty%2Fhttpx.git :pencil: Docs patch following PR #1791 section compatibility.encoding (#1812) * :pencil: Docs patch following PR #1791 section compatibility.encoding Reintroducing charset detection * 📝 Amend sentence in 3080a9d66ead9b1ffcdc2ec9f4f9364734f8a0c4 Co-authored-by: Tom Christie --- 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