法语和西班牙语的特殊字符可以保存在 varchar 中吗？答案

【问题标题】：Can the French and Spanish special chars be held in a varchar?法语和西班牙语的特殊字符可以保存在 varchar 中吗？
【发布时间】：2011-11-03 04:20:10
【问题描述】：

法语和西班牙语中有特殊字符，在普通英语中不使用（重音元音等）。

varchar 是否支持这些字符？或者我需要他们的 nvarchar 吗？

（注意：我确实不想要讨论我应该使用 nvarchar 还是 varchar。）

【问题讨论】：

标签： sql unicode character-encoding varchar

【解决方案1】：

您在谈论什么 SQL 实现？

我可以谈谈 Microsoft Sql Server；其他 SQL 实现，不多。

对于 Microsoft SQL Server，默认排序规则为 SQL_Latin1_General_CP1_CI_AS（Latin 1 通用、保留大小写、不区分大小写、区分重音）。它允许以单字节形式 (varchar) 而不是双字节形式 (nvarchar) 来表示大多数西欧语言。

它基于“Windows 1252”代码页构建。该代码页实际上是 ISO-8859-1，代码点范围 0x80–0x9F 由一组备用字形表示，包括 0x80 处的欧元符号。 ISO-8859-1 将该代码点范围指定为没有图形表示的控制字符。

ISO-8859-1 由 Unicode 的前 256 个字符组成基本多语言平面，涵盖了 8 位字符 (0x00–0xFF) 的整个域。有关详细信息和比较，请参阅

难以使用这种整理顺序的西欧语言包括（但不一定限于）拉脱维亚语、立陶宛语、波利奇语、捷克语和斯洛伐克语。如果您需要支持这些，您要么需要使用不同的排序规则（SQL Server 提供了大量的排序规则），要么转而使用 nvarchar。

应该注意，在数据库中混合排序规则往往会导致问题。仅在必要时才应偏离默认排序规则，并了解如何使用它来击中自己的脚。

我怀疑 Oracle 和 DB2 提供了类似的支持。我不知道 MySQL 或其他实现。

【讨论】：

这句话是错误的：““Windows 1252”代码页，即 ISO-8859-1”。不，这不对！ Windows-1252 不是 ISO-8859-1。 Windows-1252 不是 ISO-8859-1。 Windows-1252 不是 ISO-8859-1。 我告诉你三遍是真的。
那么也许您实际上应该阅读所写的句子：它建立在“Windows 1252”代码页上，即 ISO-8859-1 , 代码点范围 0x80-0x9F...替换为备用字形。这是一个正确的陈述。这是 ISO-8859-1 和 Windows 1252 之间的差异。
这就是“吃笋和树叶”问题：一个放错位置的逗号会完全改变句子的意思。通过将逗号放在 with 前面，您将其更改为不是的。这就像“我会问我的朋友，谁[恰好]吃西兰花”和“我会问我的朋友[那个]吃西兰花”之间的区别。看？如果它阅读“它基于 Windows-1252 构建，除了代码点范围之外，它与 ISO-8859-1 类似……”会清楚得多添加信息，因此应省略。
假装 Latin1 表示 Windows-1252 也是非常邪恶的。它不是！ Latin1 是 ISO-8859-1 的 IANA 注册别名，not 是 Windows-1252。这只是微软通过破坏既定的正式标准并通过误导性的不适当和不正确的名称来称呼事物来欺骗用户的另一个恶劣例子。
我认为你今天早上需要停止喝咖啡了。请把你的社论带到别处。

【解决方案2】：

你必须使用 nvarchar。

http://theniceweb.com/archives/156

大多数字符都适合 varchar，但有些不适合，为什么要冒险。

【讨论】：

【解决方案3】：

可以存储在 varchar 字段中的字符完全取决于为该特定字段定义的代码页。如果您要存储特定字符，那么您可以选择一个代码页来存储这些字符，它应该可以工作。很糟糕。

我的建议是始终使用 nvarchar 在 SQL 数据库中存储字符串。事实上，我认为非 Unicode 字符编码是一个错误，无论是在数据库中还是在其他任何地方。

您的操作系统在内部使用 Unicode（无论是 Windows、Mac、Linux 还是其他）。 JVM 和 .NET Framework 在内部使用 Unicode。每次查询数据库时都进行代码页转换是没有意义的。每次写入数据库时都进行代码页转换是没有意义的。只需使用 nvarchar 列，您的字符串就会直接从您的应用程序传输到数据库，而不会受到影响——没有字符转换查找、没有回退编码错误处理程序、没有奇怪的字符或意外的问号。

通过将 nvarchar 用于数据库中的所有字符串数据（以及普遍适用于任何地方的 Unicode），您可以不再关心编码，而是现在和永远专注于应用程序的核心功能。

今天是放弃传统字符编码的日子。

为追随你的维护者做这件事。为你的孩子做这件事。自己做吧。

【讨论】：

唉，这个数据库的主要原因之一是与过滤掉所有 Unicode 的医疗系统对话。因此，我与该系统的任何通信都需要使用非 unicode。因此，我需要对我收集的任何数据强制使用非 unicode。这只是情况使 unicode 不再需要的情况之一。
@Vaccano - 考虑一下：您可以正确地将数据存储在系统中，并在与其他（旧版）系统通信时应用过滤器。然后当其他系统最终升级时，您的系统和所有数据都将准备就绪。毕竟，您的应用程序（如果使用任何现代平台构建，则在内部使用 Unicode）与您的数据的通信点将比外部系统多得多。而且，只是为了事情的原则，人名应该拼写正确！
哦，还有一点很重要！ varchar 列可以设置为各种代码页。如果您不同意我的建议决定坚持使用 varchar，那么请确保您选择的代码页与您正在与之通信的其他系统正在使用的任何代码页相匹配。然后至少错误将是一致的，并且您不会创建任何其他错误。如果你听从我的建议，在所有地方都使用 Unicode，那么在与其他系统的通信点，你将不得不进行编码转换，同样重要的是代码页与其他系统匹配。

【解决方案4】：

我不确定，但其中一种排序规则可能同时适合西班牙语和法语，不过这必须进行研究。

http://dev.mysql.com/doc/refman/5.5/en/charset-charsets.html

【讨论】：

【解决方案5】：

一些很好的信息，特别是来自 Nicholas Carey，但没有人直接回答你的问题是/否...

是的，您可以使用 varchar 来处理法语和西班牙语的混合，提供您的字符集是 Windows-1252（或带有一些额外字符的 ISO-8859-1 的类似现代超集像欧元符号）。在 SQL Server 中，通过设置排序规则（服务器范围、每个数据库或每列）来选择字符集： *Latin1* 排序规则使用 Windows-1252。在 MySQL 中，Windows-1252 被称为 Latin1。

请注意，如果您尝试将字符存储在所选字符集的曲目之外，系统可能会抛出错误，或者默默地将角色从其曲目中转换为相似的角色。例如。 SQL Server 会将波兰语 Ł 转换为简单的 L，但对于日语字符会抛出错误。

【讨论】：