: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 <tom@tomchristie.com>

diff --git a/docs/compatibility.md b/docs/compatibility.md
index 7aed9dc1ed3ec683d577479579991f6d3cbccdaa..7a8dc7eee855d734d6203ee4bb2fd169b2f958bb 100644 (file)
--- 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=<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