测试SELECT：
['abcd' ,'fghi', 'srqp', 'uxyz']
您可以看到正确显示的阿拉伯字符。
然后我检查编码：
MySQL [chuangwai]> select ar_detail from items limit 1\G;
*************************** 1. row ***************************
ar_detail: {"طراز": "فساتين قفطان", "المواد": "الشيفون"}
如果你想存储非拉丁字符，如中文，日文， 希伯来语，西里尔语等使用Latin1编码，然后它们最终会成为 变为乱码。
如你所见，这不是我的情况。有谁能请我解释为什么我可以用MySQL [chuangwai]> select * from information_schema.SCHEMATA\G;
*************************** 2. row ***************************
CATALOG_NAME: def
SCHEMA_NAME: chuangwai
DEFAULT_CHARACTER_SET_NAME: latin1
DEFAULT_COLLATION_NAME: latin1_swedish_ci
SQL_PATH: NULL
编码存储阿拉伯字符？我们是否有必要将数据库的编码从latin1切换为latin1？
编辑：好的，我刚发现uft8的编码是items ...
uft8答案 0 :(得分：1)
最有可能的解释是，即使您的架构是ASCII，您的表也是UTF8。尝试
SelectedItem.ProductValue = FormerItem.ProductValue + 1就我而言，SELECT TABLE_COLLATION
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME = 'items';
表格给了我：UTF8。您可能会看到utf8_general_ci（由于各种原因，它实际上优于utf8mb4_general_ci）
现在，关于你的问题“是否有必要改变编码？”答案是“技术上，不，但这可能是一个好主意。”只要在表定义中包含编码，就不必担心模式编码。尽管如此，最好还是切换编码，这样您就不必担心以后会意外地重置数据。
答案 1 :(得分：1)
请提供SHOW CREATE TABLE。 可能表格的默认是一回事，但列是另一回事。
您需要向MySQL宣布您在客户端中的字节数为utf8。 （他们不能是latin1，更不用说ascii，因为那些字符集没有相关的字符。）
您需要将列声明为CHARACTER SET utf8（或utf8mb4）。 那么一切都会好的。
但你设法用latin1到达某个地方？嗯，这是一个意外。
案例1：您对客户端中的内容以及表列中存储的内容撒谎。但拉丁1是宽容的;它本质上存储字节而不考虑它们的含义。
案例2：你得到“双重编码”，字符最终存储为4个字节。但他们神奇地回来看起来很好。
案例3：Mojibake是另一种做错事的方法。但由于文本被完整检索，我认为你没有这种情况。
案例......（还有其他案例;请参阅下面的链接。）
无论如何，ORDER BY和WHERE可能会对内容进行错误排序或过滤。
请参阅this
中的“最佳做法”