utf-8 与 latin1

问题描述 投票:0回答:4

使用

utf8
作为字符集与使用
latin1
相比有何优点/缺点?

如果 UTF 可以支持更多字符并且一致使用,它不是总是更好的选择吗?有什么理由选择

latin1

mysql database character-set charset
4个回答
23
投票

UTF8 优点:

  1. 支持大多数语言,包括希伯来语等 RTL 语言。

  2. 将数据导入/导出到支持 UTF8 的组件(JavaScript、Java 等)时无需翻译。

UTF8 缺点:

  1. 非 ASCII 字符由于其更复杂的编码方案而需要更多时间进行编码和解码。

  2. 非 ASCII 字符将占用更多空间,因为它们可能使用超过 1 个字节进行存储(不在 ASCII 字符集的前 127 个字符中的字符)。

    CHAR(10)
    VARCHAR(10)
    字段可能需要最多 30 个字节来存储一些 UTF8 字符。

  3. utf8_bin
    以外的排序规则会比较慢,因为排序顺序不会直接映射到字符编码顺序),并且需要在某些存储过程中进行转换(因为变量默认为
    utf8_general_ci
    排序规则)。

  4. 如果您需要

    JOIN
    UTF8 和非 UTF8 字段,MySQL 将造成 严重 性能损失。如果连接的字段是不同的字符集/排序规则,亚秒级查询可能需要分钟

底线:

如果您不需要支持非 Latin1 语言、想要实现最佳性能或已有使用

latin1
的表,请选择
latin1

否则,请选择

UTF8


20
投票

latin1
的优点是它是单字节编码,因此可以在相同的存储空间中存储更多的字符,因为MySql中字符串数据类型的长度取决于编码。手册声明

要计算用于存储特定 CHAR 的字节数, VARCHAR 或 TEXT 列值,您必须考虑 该列使用的字符集以及该值是否包含 多字节字符。特别是,当使用 utf8 Unicode 时 字符集,您必须记住,并非所有字符都使用 相同的字节数。 utf8mb3 和 utf8mb4 字符集可以要求 每个字符分别最多三个和四个字节。为一个 用于不同类别 utf8mb3 或的存储的细分 utf8mb4 字符,请参阅第 10.9 节“Unicode 支持”。

此外,使用单字节编码,许多字符串操作(例如获取子字符串和依赖于排序规则的比较)速度更快。

无论如何,如果你关心国际化,latin1 并不是一个强有力的竞争者。当您要存储已知的安全值(例如百分比编码的 URL)时,它可能是一个合适的选择。


7
投票

@Ross Smith II,第 4 点非常有价值,这意味着列之间的不一致可能会很危险。

为了给已经很好的答案增加价值,这里有一个关于字符集之间差异的小型性能测试:

现代 2013 年服务器,实际使用表有 20000 行,相关列上没有索引。

subscribers
中选择 4 个,其中 1 按
time_utc_str
排序; (4 是缓存破坏者)

  • varchar(20) 字符集 latin1 排序 latin1_bin:15ms
  • varbinary(20):17ms
  • utf8_bin:20毫秒
  • utf8_general_ci:23毫秒

对于像数字日期这样的简单字符串,当考虑到性能时,我的决定是使用 utf8_bin (CHARACTER SET utf8 COLLATE utf8_bin)。这将防止对其他期望数据库字符集为 utf8 但仍然是二进制的代码产生任何不利影响。


1
投票

固定长度编码(例如 latin-1)在 CPU 消耗方面总是更高效。

如果已知某些固定长度字符集中的标记集足以满足您当前的目的,并且您的目的涉及繁重且密集的字符串处理,其中包含大量 LENGTH() 和 SUBSTR() 内容,那么这可能是这是不使用 UTF-8 等编码的充分理由。

哦,顺便说一句。 不要像您似乎所做的那样混淆字符集及其“编码”。 字符集是一些已定义的可写字形集。 同一字符集可以有多种不同的编码。 unicode标准的各个版本各自构成一个字符集。 它们中的每一个都可以接受 UTF-8、UTF-16 和“UTF-32”(不是官方名称,但它指的是对任何字符使用完整四个字节的想法)编码,并且后两者可以分别有 HOB-first 或 HOB-last 两种口味。

© www.soinside.com 2019 - 2024. All rights reserved.