在SQL表中，例如，我应该使用“é”还是“ e´”？

Question

我徒劳地寻找相关问题。他们超出了我的工资范围。我不是专业人士。为了进一步说明这一点：在我编写的HTML中，破折号是“＆＃151;”。 （插入了该空格，因此它不会显示为实际的破折号）。它最终出现在表中（其他人正在执行该工作）为“ —”。使用PHP完成搜索时，这些显示不正确。我只得到带有问号的图像。我的SQL帐户确实设置为Unicode。

Answer 1

采取哲学立场：数据库（数据库表）应包含 data ，而不是数据的某些特殊编码。

“数据”为é

以HTML格式显示时，可能需要将其转换为e´。但是，如果 é被编码为UTF-8，则所有现代浏览器都不会出现问题。

如果您选择使用“ html实体”，则让您的应用在从表中提取é后进行 转换。 PHP具有专门用于该任务的功能htmlentities()。

但是，我仍然没有解决表中代表é的字节。如今，您应该“使用” UTF-8（又名MySQL的utf8mb4）。那将是两个十六进制字节C3A9，可以使用SELECT HEX(col) ...发现。如果您使用旧的默认值latin1，则十六进制将显示C9。

一个相关的问题是，您应该在获取数据后存储html“标签”还是动态构建html。所以，让我给你三个理念。您选择要应用的内容：

• 该表包含纯数据；格式等操作是在获取之后并交付给用户的浏览器之前完成的。
• 该表包含需要发送到浏览器的内容的“不透明”图像-带有标签，实体等。使用这种方法，您最好将其称为BLOB，而不是{{ 1}}。
• 两者之间有些妥协。注意：CSS的使用可以避免在存储到数据库之前对格式进行过多的硬编码。

此外，第一选择是更干净的搜索。这可能会导致您选择它。但是，另一种方法是有两列-一列旨在提供大多数格式的输出；另一个用于搜索（已删除标签，没有实体等）；它主要是文本，但是您可能无法从中生成网页（包含链接，段落等）。

é-为不同的人提供不同的笔触

• TEXT in latin1（不建议使用）十六进制E9，1字节
• é in utf8 C3A9 2字节
• é-Unicode代码点-6个字节
• \u00E9-html实体（请参阅PHP的é）-8字节
• htmlentities()-PHP的%C3%A9（用于URL）-6个字节

回复评论

如果urlencode()，entries_lists和entries_languages有许多映射表，请考虑提到的here的几种优化。

请勿使用authors_entries。相反，找出导致它们编码不正确和/或显示不正确的原因。从

开始

utf8_encode

某些带有重音字母的作者。