站在哲学的立场上：数据存储（数据库表）应该包含数据，而不是数据的一些特殊编码。
“数据”是 é 在html中显示时，可能需要将其转换为 e´ . 然而，所有现代浏览器都不会有问题，如果 é 编码为utf-8。
如果您选择使用“html实体”，那么让您的应用程序在获取之后进行转换 é 从table上。php具有以下功能 htmlentities() 特别是为了那个任务。
但是，我仍然没有说明表中的字节代表什么 é . 现在，您应该使用utf-8（又称mysql的utf8mb4）。那就是两个十六进制字节 C3A9 ，可以使用 SELECT HEX(col) ... . 如果使用旧的默认值拉丁1，十六进制将显示 C9 .
一个相关的问题是，在获取数据之后，是应该存储html“标记”还是动态构造html。所以，让我给你们三种哲学；您可以选择应用：
该表包含纯数据；格式化等都是在获取之后，在传递到用户浏览器之前完成的。
该表包含需要发送到浏览器的内容的“不透明”图像，包括标记、实体等。使用这种方法，您不妨称之为 BLOB ，不是 TEXT .
他们之间有些妥协。注意：使用css可以避免在存储到数据库之前对格式进行太多的硬编码。
而且，第一选择是更干净的搜索。这可能会导致你选择它。然而，另一种方法是有两个列——一个用于传递大部分格式化的输出；另一个用于搜索（删除标签、无实体等）；它主要是文本，但你可能无法从中生成网页（带有链接、段落等）。
é -- 不同的人有不同的笔触 é 拉丁文1（不建议）十六进制e9，1字节 é utf8 c3a9 2字节 \u00E9 --unicode码位--6字节 é --html实体（参见php的 htmlentities() )--8字节 %C3%A9 --php的 urlencode() （对于URL）--6字节
回应评论
如果 entries_lists , entries_languages ，和 authors_entries 是many:many mapping 表，请考虑这里提到的几个优化。
不要使用 utf8_encode . 相反，找出是什么导致它们编码不正确和/或显示不正确。开始时间

echo bin2hex($record['author']);

SELECT name, HEX(name) FROM authors WHERE ...

对于一个有重音字母的作者。