You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Originally posted by alleml May 17, 2024
httpx.Request blindly dumps provided json to ascii characters by invoking json.dumps without any parameters. Currently there is no way to provide ensure_ascii=False argument to the Request instance (or even better to the client).
This bug have a huge impact on the openai package (1.52.0).
Openai package uses httpx to make it requests, and it turns out that when we make call in French, the GPT models receives text in the wrong encoding. The encoding should be UTF-8 !
For example :
input text in French : "salut ça va ? très bien ou pas bien ?"
GPT receives in payload : "salut \u00e7a va ? tr\u00e8s bien ou pas bien ?"
This could have huge impact on text understanding by LLMs, and also could generate more costs for intesive llm users.
Here's a comparison in the official openai tokenizer to prove the point :
UTF-8 correct encoding ==> 11 tokens for GPT-4o
Openai package uses httpx to make it requests, and it turns out that when we make call in French, the GPT models receives text in the wrong encoding.
We're compliant with the JSON spec here, and parsers will be decoding text escape sequences into the correct unicode text. Tho you are correct that a more compact format would be sensible here. Would you like to submit a pull request resolving this?
The following related issues could all be resolved together...
We should use ensure_ascii=False for more compact text representations.
We should use separators = (',', ':') for more compact list and object representations.
We should use allow_nan=False to disallow invalid Infinity and NaN representations.
Useful review points are the UNICODE_JSON, COMPACT_JSON and STRICT_JSON settings in REST framework where we previously worked through these design issues.
Openai package uses httpx to make it requests, and it turns out that when we make call in French, the GPT models receives text in the wrong encoding.
We're compliant with the JSON spec here, and parsers will be decoding text escape sequences into the correct unicode text. Tho you are correct that a more compact format would be sensible here. Would you like to submit a pull request resolving this?
The following related issues could all be resolved together...
We should use ensure_ascii=False for more compact text representations.
We should use separators = (',', ':') for more compact list and object representations.
We should use allow_nan=False to disallow invalid Infinity and NaN representations.
Useful review points are the UNICODE_JSON, COMPACT_JSON and STRICT_JSON settings in REST framework where we previously worked through these design issues.
Thank you for your reply.
I will submit a pull request to resolve the issue.
Regards
I plan to add configurable JSON serialization options that allow users to control Unicode encoding (e.g. ensure_ascii), while maintaining full backward compatibility with the existing behavior.
Activity
BERRADA-Omar commentedon Oct 24, 2024
This bug have a huge impact on the openai package (1.52.0).
Openai package uses httpx to make it requests, and it turns out that when we make call in French, the GPT models receives text in the wrong encoding. The encoding should be UTF-8 !
For example :
This could have huge impact on text understanding by LLMs, and also could generate more costs for intesive llm users.
Here's a comparison in the official openai tokenizer to prove the point :

UTF-8 correct encoding ==> 11 tokens for GPT-4o
ASCII encoding ==> 21 tokens !!!

Please have this issue fixed.
BERRADA-Omar commentedon Oct 24, 2024
For those who are looking for a workaround, you can override the method that causes the issue in the entry point of your app (main.py for example).
The patch would be :
lovelydinosaur commentedon Oct 25, 2024
We're compliant with the JSON spec here, and parsers will be decoding text escape sequences into the correct unicode text. Tho you are correct that a more compact format would be sensible here. Would you like to submit a pull request resolving this?
The following related issues could all be resolved together...
ensure_ascii=Falsefor more compact text representations.separators = (',', ':')for more compact list and object representations.allow_nan=Falseto disallow invalidInfinityandNaNrepresentations.Useful review points are the
UNICODE_JSON,COMPACT_JSONandSTRICT_JSONsettings in REST framework where we previously worked through these design issues.BERRADA-Omar commentedon Oct 25, 2024
Thank you for your reply.
I will submit a pull request to resolve the issue.
Regards
[-]httpx forces converting json content to ascii[/-][+]Ensure JSON representation is compact.[/+]Ensure JSON representation is compact. encode#3363
Ensure JSON representation is compact. #3363 (#3367)
lovelydinosaur commentedon Oct 28, 2024
Thanks @BERRADA-Omar
[tests] use compact json representation; because httpx is doing so
Ensure JSON representation is compact. encode#3363 (encode#3367)
Yevtech commentedon Dec 28, 2025
Hi, I’d like to work on this issue.
I plan to add configurable JSON serialization options that allow users to control Unicode encoding (e.g. ensure_ascii), while maintaining full backward compatibility with the existing behavior.
I’ll submit a PR once ready. Thanks!