karthink / gptel

A simple LLM client for Emacs
GNU General Public License v3.0
1.14k stars 119 forks source link

Resolved #4: Handles multi-byte characters with url-retrieve (i.e., without the external curl command) #29

Closed algal closed 1 year ago

algal commented 1 year ago

These two commits fix handling of multi-byte characters in the prompt send to OpenAI and in the response received from it.

As a result, you can now use non-Latin alphabets like Greek, or emojis.

To make requests work, it was necessary to encode the loaded API key as utf-8, for reasons that remain obscure, but may have to do with some subtlety concerning how the concat function combines multibyte and non-multibyte strings. To make replies work, it was necessary to decode the response body as utf-8 before, not after, parsing it as json.

I have tested this lightly on Emacs 28.1 running on Linux.

algal commented 1 year ago

This is intended to resolve #4

karthink commented 1 year ago

Appears to work for me too. This is great! I'm also on Emacs 28.2 on Linux, I'm going to make the assumption here that explicitly encoding all parts of the request as utf-8 is the conservative approach and thus unlikely to cause issues in other versions or platforms.

To make requests work, it was necessary to encode the loaded API key as utf-8, for reasons that remain obscure, but may have to do with some subtlety concerning...

Ah, I can see why this could be a problem.

Pushed.

narendraj9 commented 2 months ago

Wouldn't it be better to always encode all headers (including Authorization) at a lower level to utf-8 instead of just modifying the auth source helper function: gptel-api-key-from-auth-source? @algal Or am I missing something about the issue here?