WhyCan Forum(哇酷开发者社区)

试试把字符转换成\x31 \x32这类或者\u这类，试试，这样再也不用担心编码问题了
http://www.msxindl.com/tools/unicode16.asp
http://www.ab126.com/goju/10861.html
https://the-x.cn/encodings/Hex.aspx

最近编辑记录 小智 (2021-05-27 10:54:33)

这样是可以的 我试过  这种方式显示汉字是正确的  但是直接"我们"这种方式就不行了

将编码格式改为utf-8后，把字符删掉，重新再打出来呢。这个我也有一个问题，就是如果汉字个数为奇数个就会报错，这个是怎么回事呢

你说的奇偶这种我么有与遇到过

不清楚阿里字体库跟LVGL是怎么联系的。

普通的单片机开发：
1 文件默认都是ANSI编码，内嵌的汉字用GBK编译后得到的内容是GBK。
2 程序中，也是根据GBK定位算法对字库进行寻址。
3 包含的点阵文件也是按照GBK排布。

意思是要用汉字，三方面的规格要匹配：
输入的内容，取字体算法，字体本身。

你现在用的源码文件时UTF8，编译后得到的应该是unicode，那么找字算法和字体库都要是unicode。
或者进行编码转换后再对GBK字库寻址。

http://www.wujique.com/2021/05/15/elementor-811/
http://www.wujique.com/2020/05/10/%e5%8d%95%e7%89%87%e6%9c%ba%e6%ba%90%e7%a0%81%e4%b8%ad%e6%96%87%e5%a4%9a%e5%b9%b3%e5%8f%b0%e4%b9%b1%e7%a0%81%e9%97%ae%e9%a2%98/

你好博主，LVGL无法显示中文的问题最后你是怎么解决了，可以方便讲讲吗，微信：18312727390

源代码使用UTF-8带BOM的格式保存。
实在不行就转换成"\xxxx"的格式

不能同意你这种说法，BOM非常重要，说BOM不重要的人只是没有遇到那种场景而已。

BOM是干哈用？是用来指示是小端法还是大端法的。什么情况下需要区分大小端？就是数值长度超过一个字节。UTF-8的数值都是以字节进行编排，顺序是固定的，无需再额外指示。
UTF-16这种才会出现长度超过一个字节的数值，这种数值在不同平台上的存储顺序有大小端之分，所以才需要指明。

最近编辑记录 海石生风 (2022-11-17 09:35:06)

BOM不仅用来指示大小端还用来指示文本编码。开发过文本编辑器的都有体会，如果文本文件的开头没有BOM那么就只能靠猜，当然UTF8编码总是能够猜对的，因为它有自编码规则，但是ANSI CODEPAGE和UTF16就不是那么好猜了。编辑器每次都靠从头猜到尾来判断文本编码对效率来说也不好，假如编译器每打开一个源文件就要猜一次，那编译一个大工程也是够累的，当然有些编译器不愿意去猜，只承认ANSI编码。
顺便提一下，KEIL这个IDE以前是支持BOM的，到了5.x后好像取消了对BOM的支持，这样一来用户就变得不方便了。其实检测文件头的BOM只不过是几行代码的事情，我实在想不明白为什么他们不愿意支持这个功能。Win平台上的文本编辑工具绝大多数会支持BOM，连最简单的记事本都能够支持BOM，这才是以用户为中心的做法。

在UNICODE文本流前面加BOM是符合UNICODE标准的，为什么符合标准仍然会被一些人指责呢？指责方无非是为了己方利益而已，说白了就是争夺话语权（加BOM还是不加BOM的事实话语权）。

从技术上看加BOM能够指示读取程序快速解码，有利于提高用户体验，用户更喜欢。不加BOM也无大碍，无非是解码时需要逐个尝试UTF8/UTF16-LE/UTF16-BE/ANSI CODEPAGE等编码方式，耗费的时间多一点而已，从这一点看加BOM是比较聪明的做法（懒的人一般更聪明😝）。

我们知道XML文件有“encoding”，HTML文件有“charset”指示符，说明了客观上是有指示读取程序如何解码的需求，在UNICODE文本流前面加入BOM是能够给与一般文本文件读取程序一定的帮助又符合UNICODE标准的做法。
不管哪个系统的文本文件读取软件都应该能够识别开头的BOM，可以不加BOM但不应该不能识别BOM，这是为了提高用户体验而不是为了程序员自身的固执偏见

这个话题根本无需争论，各执己见比较好。