标签: unicode

我继承了一些 SQL Server 数据库。有一个表（我称之为“G”），大约有 8670 万行，41 列宽，来自 SQL Server 2014 Standard 上的源数据库（我称之为“Q”），它得到了 ETL在 SQL Server 2008 R2 Standard 上具有相同表名的目标数据库（我将称之为“P”）。

即 [Q].[G] ---> [P].[G]

编辑：2017 年 3 月 20 日：有人问过源表是否是目标表的唯一源。是的，它是唯一的来源。就 ETL 而言，并没有发生任何真正的转变；它实际上旨在成为源数据的 1:1 副本。因此，没有计划向此目标表添加其他源。

[Q].[G] 中略多于一半的列是 VARCHAR（源表）：

• 13 列是 VARCHAR(80)
• 9 列是 VARCHAR(30)
• 其中 2 列是 VARCHAR(8)。

同样，[P].[G] 中的相同列是 NVARCHAR（目标表），具有相同宽度的相同列数。（换句话说，长度相同，但 NVARCHAR）。

• 13 列是 NVARCHAR(80)
• 9 列是 NVARCHAR(30)
• 其中 2 列是 NVARCHAR(8)。

这不是我的设计。

我想将 [P].[G]（目标）列数据类型从 NVARCHAR 更改为 VARCHAR。我想安全地做到这一点（没有转换造成的数据丢失）。

如何查看目标表中每个 NVARCHAR 列中的数据值以确认该列是否实际包含任何 Unicode 数据？

可以检查每个 NVARCHAR 列的每个值（在循环中？）并告诉我是否有任何值是真正的 Unicode 的查询（DMV？）是理想的解决方案，但欢迎使用其他方法。

越南语校对中的“tR”似乎有一些特别之处。知道的人能不能用简单的语言解释一下，不胜感激。此问题是在“越南语”整理的 SQL Server 上安装我们的产品期间发现的。模式中的一个表的名称中包含“tR”，但存储过程正在以所有小写的“tr”引用该表。而这个参考失败了。

我想这种情况类似于“？” 匹配其他排序规则中的“ss”。

这是一个复制品：

select  case when 'tr' = 'tR' COLLATE SQL_Latin1_General_CP1_CI_AS   then 'match' else 'no match' end 
select  case when 'tr' = 'tR' COLLATE Vietnamese_CI_AI   then 'match' else 'no match' end 
select  case when 'tr' = 'TR' COLLATE Vietnamese_CI_AI   then 'match' else 'no match' end 

结果：

-----
match


--------
no match


-----
match

第二个 T-SQL 产生不匹配。't' 和 'R' 的其他组合则不然。

在 SQL Server 2019 中，Microsoft 引入了对和数据类型的UTF-8 支持，并表示：CHARVARCHAR

此功能可显着节省存储空间，具体取决于使用的字符集。例如，使用支持 UTF-8 的归类将带有 ASCII 字符串的现有列数据类型从 NCHAR(10) 更改为 CHAR(10)，意味着存储需求减少了近 50%。这种减少是因为 NCHAR(10) 需要 22 个字节的存储空间，而 CHAR(10) 需要 12 个字节来存储相同的 Unicode 字符串。

UTF-8似乎支持每个脚本，所以基本上我们就可以开始在存储Unicode数据varchar和char列。正如文档中所说，这可以减少表和索引的大小，从那里我们可以获得更好的性能，因为读取的数据量更少。

我想知道这是不是意味着我们可以停止使用nvarchar和nchar列，它实现UTF-16？

任何人都可以指出一个场景和原因，不要使用带有UTF编码的 char 数据类型并继续使用 n-chars数据类型吗？

我正在使用 Postgresql v12。我创建了一个像这样的排序规则：

CREATE COLLATION ci (provider = icu, locale = 'tr_TR', deterministic = false);

我在表中使用了该排序规则：

create table testtable1 (
    id serial  primary key,
    name text  COLLATE "ci"
);

我插入了示例数据：

insert into testtable1 values(3,'abc');

当我使用 查询该表时LIKE，它返回以下错误：

select name from testtable1 WHERE name LIKE '%a%'  

错误：LIKE SQL 状态不支持非确定性排序规则：0A000

但我需要使用LIKE. 有什么办法允许这样做吗？

我是一个数据库新手，正在查看似乎将文本存储在整数列中的 SQLite 数据库。这是 sqlite3 命令行中的示例会话：

sqlite> .schema mytable
CREATE TABLE mytable (
    id              integer primary key,   /* 0 */
    mycol           integer not null,      /* 1 */
);

sqlite> SELECT mycol FROM mytable;
here is some text
here is more text
[...]
it's text all the way down

我糊涂了。是什么赋予了？

我有 java 代码将 UTF-8 字符串修剪为我的 Oracle (11.2.0.4.0) 列的大小，最终抛出错误，因为 java 和 Oracle 将字符串视为不同的字节长度。我已经验证我NLS_CHARACTERSET在 Oracle 中的参数是“UTF8”。

我写了一个测试，使用unicode 花栗鼠表情符号(?)

public void test() throws UnsupportedEncodingException, SQLException {
    String squirrel = "\uD83D\uDC3F\uFE0F";
    int squirrelByteLength = squirrel.getBytes("UTF-8").length; //this is 7
    Connection connection = dataSource.getConnection();

    connection.prepareStatement("drop table temp").execute();

    connection.prepareStatement("create table temp (foo varchar2(" + String.valueOf(squirrelByteLength) + "))").execute();

    PreparedStatement statement = connection.prepareStatement("insert into temp (foo) values (?)");
    statement.setString(1, squirrel);
    statement.executeUpdate();
}

这在测试的最后一行失败，并显示以下消息：

ORA-12899: 列
"MYSCHEMA"."TEMP"."FOO" 的值太大（实际：9，最大值：7）

的设置NLS_LENGTH_SEMANTICS是BYTE。不幸的是，我无法改变它，因为它是一个遗留系统。我对增加列大小不感兴趣，只是能够可靠地预测字符串的 Oracle 大小。

Unicode代码点9619是一个叫“深色”字符：?（http://unicode-table.com/en/search/?q=9619）。

使用SQL_Latin1_General_CP1_CI_AS排序规则和 1252 代码页，我希望将该 Unicode 字符转换/转换为非 Unicode 数据类型会导致问号 ( ?)，因为代码页 1252 似乎不包含此字符，这似乎是 SQL Server 的无法进行转换时的行为。

所以我的问题是：为什么 SQL Server 将此字符转换为 ASCII 代码 166，即“管道，垂直竖线”：¦？

SELECT NCHAR(9619), CAST(NCHAR(9619) AS CHAR(1)), ASCII(CAST(NCHAR(9619) AS CHAR(1)))

我们有一些基于数据库的 Web 应用程序，它们utf8mb4用作字符集和utf8mb4_Standard排序规则。

我们看到我们可以在这个设置中使用我们想要的任何字符。

在 SQL Server Express 中，情况对我来说不是很清楚。

当我切换到Standard它时选择Latin1_General_CI_AS排序规则。

但我不知道这是哪种字符编码，如果我们想将一些数据从utf7mb8MySQL 表接管到 SQL Server 中，它会如何影响场景。

当我查看 SQL Server 中的数据类型定义时，我可以看到有 Unicode 和非 Unicode 类型。所以我想知道排序规则是否真的影响它的存储方式：

看来，如果您使用nchar,nvarchar或者nvarchar(max)您在使用 UTF-16 时处于安全状态。

但是，整理Latin1_General_CI_AS是什么意思？

例如，特别是如果你有中文字符，这会如何表现？

所以，我知道所有关于 Replace 函数和 char(0) 的错误。

我有一列 ( NVARCHAR(128)) 有一些NCHAR(0x0000)来自错误导入的字符。

我正在使用 SQL Server 2008 R2。

该列的排序规则是：SQL_Latin1_General_CP1_CI_AS。

我已经尝试了所有可能在网上找到的东西，但没有任何东西可以从列中取出臭气熏天的 char(0) 字符。

这是我的最新尝试，结果是 BAFFLING（sql server 中的错误？）。

我有一个循环遍历每个字符并用特定字符替换 0x0000 的函数。

ALTER FUNCTION dbo.ReplaceCharZero
(
  @testString NVARCHAR(MAX),
  @charToReplaceWith NCHAR(1) = ' '
)
RETURNS NVARCHAR(MAX)
AS
BEGIN
    DECLARE
        @i INT = 1 ,
        @fixedString NVARCHAR(MAX) = ''
    WHILE @i <= LEN(@testString)
        BEGIN
            IF SUBSTRING(@testString, @i, 1) = CHAR(0x00)
                BEGIN
                    --PRINT 'Found' + CAST(@i AS VARCHAR)
                    SET @fixedString = @fixedString + @charToReplaceWith …

SELECT datname, pg_encoding_to_char(encoding) 
FROM pg_database;

...列出所有数据库，每个数据库都有其编码类型。

但是，我试图找出PostgreSQL 服务器中可用的所有编码类型。我可以查询所有可用的编码类型吗？

还是在第 23.3 章字符集支持中列出了唯一可用的编码类型？