MicroPython Forum (Archive)

Hello there, I'm new to this forum

I'm trying to make my LCD driver(st7735s) to support Chinese letters.

My solution is to encode a Chinese letter and get its utf-8 format code, then use this code and a key to search in a dict that contains all the letters used in my project. While I am a bit confused because the char '冯' in my Micropython environment (esp32) is b'\xb7\xeb'. But in my python environment (PC) I got it with b'\xe5\x86\xaf'. I am now stuck in here, as I planned to generate all the letters in my PC (python environment), then download to my esp32 (micropython environment).

The utf-8 code should be the same in both of the environment, only with that can I extract letters in json stream (utf-8 code) then show them on my LCD.

Another thing is that when I use REPL through COM9 (my COM to my board), I cannot type Chinese letters in cmd...

My implement details are as follows:

board : ESP32 DEVKIT V1 GPIO with 30 pins
firmware : esp32-20220117-v1.18.bin lateset firmware, downloaded from https://micropython.org/download/esp32/
IDE : VS Code with RT-Thread, python 3.8.0 with esptool 4.0

Can anyone help my get out of it? Or is there another way to match json char from web API to my local letters?

Best regards!

Lab~

Are you sure? I get the correct UTF-8 running on a ESP32:

I suspect your source file (the first code block – you don’t show any >>> prompts so I guess this is a source file, not REPL input) isn’t actually encoded in UTF-8. Can you open it in a hex editor and see what bytes are there in the '冯' string literal?

With the amount of encoding-unaware tools around, in my opinion it’s generally safer to use escapes like '\u51af' instead of non-ASCII characters like '冯' in string literals in source files. (But as someone who writes in mostly-ASCII languages, it may be easier for me to say that than for you.)

But, taking a step back, do you even need to encode the character in UTF-8 and then assemble the bytes into a number? Why not just use ord('冯') as the dictionary key?

Lobo-T wrote: ↑

Sat May 28, 2022 4:54 pm

Are you sure? I get the correct UTF-8 running on a ESP32:

Code: Select all

>>> data_code = '冯'.encode('utf-8')
>>> print (data_code)
b'\xe5\x86\xaf'
>>> 

Thank you for your reply, I tried another IDE (Thonny), and this problem disappeared, the mismatch problem only occurred when I use VS Code XD, now I just use VS Code to code(prefer to its python plugins) and debug on Thonny.

I think its RT-Thread plugin's problem but I'm not sure...

Christian Walther wrote: ↑

Sat May 28, 2022 6:54 pm

I suspect your source file (the first code block – you don’t show any >>> prompts so I guess this is a source file, not REPL input) isn’t actually encoded in UTF-8. Can you open it in a hex editor and see what bytes are there in the '冯' string literal?

With the amount of encoding-unaware tools around, in my opinion it’s generally safer to use escapes like '\u51af' instead of non-ASCII characters like '冯' in string literals in source files. (But as someone who writes in mostly-ASCII languages, it may be easier for me to say that than for you.)

But, taking a step back, do you even need to encode the character in UTF-8 and then assemble the bytes into a number? Why not just use ord('冯') as the dictionary key?

I double checked my src file, the file was auto-saved with UTF-8 encoding, the first code block is a pseudo code as I'm not sure if I have made myself clear, this did occurred in REPL XD.

Christian Walther wrote: to use escapes like '\u51af' instead of non-ASCII characters like '冯' in string literals

I'm trying to get a json string from a web api, so I actually don't know what exactly the letter is, '冯' is just a test to check if I make it correct.

Christian Walther wrote: just use ord('冯') as the dictionary key

My original idea is to use ord(char) function (the easiest way I think), but it generates the ascii format code which doesn't match the utf-8 format json string, so in the end I have to switch to utf-8 code as the dict key.

Now the code run correctly on my board and the result is just what I needed, maybe it still can be optimized and , I decided to leave it still out of time concern.

Anyway, thank you for your reply~