我是否需要 utf8mb4 字符集来存储地理编码 address.components long_names？答案

【问题标题】：Do I need utf8mb4 charset for storing geocoding address.components long_names?我是否需要 utf8mb4 字符集来存储地理编码 address.components long_names？
【发布时间】：2016-11-03 00:33:42
【问题描述】：

我正在开发一个应用程序，让世界各地的人们在搜索框中输入地址、城市或其他内容。然后他们可以选择与他们的目标相匹配的结果。所选结果包含来自 address.components long_name 的文本。

地理编码器 API 返回的一些示例：

"long_name" : "King's Street",
"short_name" : "King's St",
"types" : [ "route" ]

"long_name" : "Newport",
"short_name" : "Newport",
"types" : [ "postal_town" ]

"long_name" : "Staffordshire",
"short_name" : "Staffordshire",
"types" : [ "administrative_area_level_2", "political" ]

在这种情况下，我会例如商店：

“国王街”

“纽波特”

“斯塔福德郡”

进入我的数据库。

然后...此应用程序可以存储来自所有国家/地区的位置，并且可能以这些国家/地区使用的所有官方母语存储 - 由谷歌在“long_name”字符串中。请注意，我在地理编码器中设置了国家和语言，以便以用户的母语显示地图，并以正确的语言为用户返回结果（address.components 字符串）。

有谁知道在 MySql 中使用 UTF-8（即 3 字节 UNICODE）时 address.components long_names 是否可以精确存储（字符集），或者我是否需要使用 utf8mb4 字符集（4-字节UNICODE）？

如果我需要使用 utf8mb4 字符集，那是什么原因？ Google Geocoder 存储的哪些语言需要 utf8mb4（4 字节）UNICODE，以便在存储到数据库时不丢失任何字符/语言信息？

【问题讨论】：

任何说它是 UTF-8 的都是标准的 4 字节 UTF-8。 MySQL 是一个例外，他们最初使用 3 个字节。强烈建议您在 3byte 版本上尽可能使用utf8mb4。 This StackOverflow Post 应该对你也很有帮助。
我检查了你链接到的帖子。那个人想一路支持UNICODE。我的做法有些不同。我需要支持我必须支持的东西。如果谷歌地理编码器不返回任何需要 4 字节 UTF-8 的字符集（参考地址.components long_name 中地理编码器使用的），那么我认为没有理由使用 utf8mb4 字符集，因为它会导致的唯一结果是： a) 数据库中有更多数据 b) 更大的索引再次导致查询速度变慢，并在服务器上使用更多资源。是否有任何文档显示地理编码器使用哪些字符集？
如果我运行这个选项，我总是会选择utf8mb4，因为使用任何其他UTF8_ MySQL 字符集只是在等待同样的问题在另一天再次出现并咬你。我不知道地理编码器使用什么，但 UTF8 现在是事实上的网络标准字符集。数据集的大小（除非它们真的很大）不会影响索引或数据检索速度。 MySQL 可以处理并超过数十亿行数据。
此外，如果地理编码器返回的任何数据是特定于语言环境的，例如世界偏远地区的地名，那么这些字符将在 3 字节 UTF8 存储中丢失和损坏。说真的，省去你自己的努力，在问题变成问题之前阻止它。 :-) 。使用UTF8mb4

标签： mysql google-maps-api-3 unicode character-encoding google-geocoding-api

【解决方案1】：

如果您的应用程序是新的工作（新应用程序）并且您使用的是最新版本的 MySQL 或 MariaDb，则应使用 utf8mb4。它将处理 Unicode 中的所有内容，包括一些晦涩的字符集，您不必再考虑这个问题。

【讨论】：

感谢您的快速响应。但是为了进一步缩小我的问题：从地理编码器返回的任何使用的 address.components long_name 字符串是否使用需要超过 3 字节 UTF8 的字符？如果是这种情况，特别是哪些语言（由谷歌地理编码器返回）导致我使用 4 字节 UTF8？我问的原因很简单。有很多数据进入数据库，我想使用尽可能少的数据库空间。如果我能摆脱 3 字节的 UTF8，那么我的索引也会更小，而且查询也可能会更快。
只有 Google 地图人员知道您的确切问题的答案。如果您要收集足够的信息以产生影响，您可能已经为商业访问付费。因此，请让您的 Google 客户经理为您找出答案。如果您还没有为访问付费，他们会限制您的抓取，并且磁盘驱动器的价格会在您看到甚至最轻微的影响之前下降。

【解决方案2】：

cmets 暗示真正的问题是关于 3 字节 utf8 和 4 字节 utf8mb4 的大小。（我假设您使用的是VARCHAR 或TEXT？

对于英语，没有区别——在 utf8 或 utf8mb4 中，每个字符占用 1 个字节。 大小和编码都没有区别。
对于欧洲，没有区别——每个字符占用 1 或 2 个字节。
对于大多数亚洲语言来说，没有区别——每个字符正好占 3 个字节。
对于中文，有一个问题 -- 一些中文字符需要 4 个字节，将这些数据存储在 utf8 列中会导致截断或其他错误。

所以，你不妨使用 utf8mb4 来处理一切。

对于除 MySQL 之外的所有应用程序，“UTF-8”指的是可变长度编码；它甚至可以超过 4 个字节（尽管尚未为字符分配超过 4 个字节的代码）。

【讨论】：