我在 SQL Server 2012 Enterprise Edition 中有一个表，其中包含约 100GB 的数据。这些数据的大部分归因于NVARCHAR(MAX)平均长度为 4500 个字符的单个列。它存储由不需要 Unicode 字符的应用程序压缩的数据。

由于NVARCHAR每个字符占用两个字节并VARCHAR占用一个字节，我推测我可以通过切换表来减少一些存储空间。但是，一旦我将列更改为VARCHAR(MAX)，表格就会膨胀到 155GB。

我知道 SQL 可能会使用Unicode 压缩，但文档指出这不适用于NVARCHAR(MAX)它，因此它不可能被使用。

那么为什么我的桌子变大了这么多？

桌子：

CREATE TABLE [dbo].[Table](
    [RecordLocator] [char](6) NOT NULL,
    [CreateDate] [date] NOT NULL,
    [SystemId] [varchar](40) NOT NULL,
    [EventXML] [nvarchar](max) NULL, --Not XML, compressed XML as characters
    [UpdateUTCTimeStamp] [datetime2](7) NOT NULL,
    [DeleteDate] [date] NULL,
 CONSTRAINT [PK_Table] PRIMARY KEY CLUSTERED 
(
    [RecordLocator] ASC,
    [CreateDate] ASC,
    [SystemId] ASC,
    [DeleteDate] ASC
)WITH (PAD_INDEX …

出于某种原因，MS SQL Server 2016 批量插入会误解/翻译 Unicode 字符：

• C9 (É) 变成 2B (+)
• A1 (¡) 到 ED (í)
• A0 ( ) 到 E1 (á)
• AE (®) 到 AB («)
• CB (Ë) 到 2D (-)
• D1 (Ñ) 到 2D (-)
• 92 (') 到 C6 (Æ)
• 96 (–) 到 FB (û)

即 Notepad++ 和 xxd 显示平面文件有 0xC9，但在批量插入后，表显示“+”，并在 SQL Server 中转换为 varbinary 显示为 0x2B。备份也有 0xC9。

我正在向 MS SQL Server 2016 中批量插入 25 个平面文件。它是 15Gb 数据，我正在使用管道 ( | ) 字段分隔符和CRLF行分隔符。

我批量插入到我提供的备份的截断结构中。当我与备份进行比较时，存在差异。注意：我必须等待 25 小时才能从数据源备份，但可以在 …

我有一个表格，里面有一些希腊文本行，如nvarchar(2000).

最近，我将列的类型更改为 ，varchar(4000)但我意识到一些希腊字符显示为问号。

所以，我试图改回以nvarchar(4000)修复它，因为我认为字符的 unicode 仍然保持不变。

我只是想知道，有没有办法解决这个问题，而不是在更改表之前恢复我创建的备份？

正如预期的那样，在“测试”中运行此结果：

SELECT
    REPLACE(NCHAR(1234), NCHAR(1234), N'test');

但是，运行此结果会生成“a?a”，其中没有“test”：

SELECT
    REPLACE(N'a' + NCHAR(1234) + N'a', NCHAR(1234), N'test');

我认为这可能与 haystack 而不是针的字符串连接有关，但是当我尝试这样做时，它仍然没有“工作”：

SELECT
    REPLACE(N'a' + NCHAR(1234) + N'a', N'' + NCHAR(1234) + N'', N'test');

结果：“a？a”

我怀疑这可能与它如何解释字符有关，所以我尝试指定一个二进制排序规则......并“修复”了这个问题：

SELECT
    REPLACE(N'a' + NCHAR(1234) + N'a' COLLATE Latin1_General_100_BIN2, NCHAR(1234), N'test');

结果：“atesta”。

为什么？

这种行为似乎对某些角色存在，但对其他角色不存在。

SELECT
    REPLACE(N'a' + NCHAR(23423) + N'a', NCHAR(23423), N'test');

结果：“atesta”（“作品”）

SELECT
    REPLACE(N'a' + NCHAR(5342) + N'a', NCHAR(5342), N'test');

结果：“a?a”（不“工作”）

为什么？

我一直在研究如何使用 SQL Server 解码 Base64，在网上搜索了许多解决方案（一些来自此处）后，似乎基于这种方法。

SELECT CAST(CAST('Base64StringHere' as XML ).value('.','varbinary(max)') AS VARCHAR(250))

当我有 ASCII 文本时，这非常有效。但是，当我有以下法语文本时，它会损坏（大概是由于 VARCHAR 的限制）。

Où est le café le plus proche?
T8O5IGVzdCBsZSBjYWbDqSBsZSBwbHVzIHByb2NoZT8=

并提供以下输出。

Où est le café le plus proche?

我认为相对简单的解决方法是将 to 更改为CAST，NVARCHAR但这会再次导致损坏。

SELECT CAST(CAST('T8O5IGVzdCBsZSBjYWbDqSBsZSBwbHVzIHByb2NoZT8=' as XML ).value('.','varbinary(max)') AS NVARCHAR(250) )

????????????????

我的搜索引擎技能可能让我失望，但我似乎找不到其他有我问题的人。

有什么想法吗？

我正在为地名构建一个新产品，其中阿拉伯语显示有点像这样：

^IArabic^I<202b>???????<202c>^I<202b>?????? ???????<202c>$

其实不完全是。这对我的 ASCII 喷出终端来说是一个真正的问题，所以我会例外并截屏文本。

我的问题是关于那些U202B“从右到左嵌入”（RLE）和U202C“流行方向格式”（PDF）。那些被存储为数据吗？我的第一个假设是字符被渲染而不是在文件中，但可惜它们在那里。

360    5E03 97E6 5171 548C 56FD 000A 0009 0041 0072 0061 0062 0069 0063 0009 202B 0632    ?????..Arabic..?
.............................................................................^HERE
389    0645 0628 0627 0628 0648 064A 202C 0009 202B 064F 062C 0647 0648 0631 064A 0629    ??????...???????
.....................................^HERE.....^HERE
422    0020 0632 0645 0628 0627 0628 0648 064A 202C 000A 0009 004E 006F 0074 0065 0073    .???????...Notes
...............................................^HERE

在数据库中存储阿拉伯语时，您通常存储\u202b, 和\u202c? 他们似乎在渲染角色而不是技术数据？我只是想处理此文本以将其放入数据库，并想知道这些字符是否应该存在于数据库中，或者在插入之前去除。

背景

• 屏幕截图是在终端 (Kitty) 中 …

从 SQL Server 2019 开始，它支持 UTF-8 作为排序规则。但是，根据以下查询：

SELECT COLLATIONPROPERTY('Arabic_100_CS_AS_KS_WS_SC_UTF8', 'CodePage')
SELECT COLLATIONPROPERTY('Latin1_General_100_CS_AS_KS_WS_SC_UTF8', 'CodePage');

两者都返回65001Windows 中的 Unicode代码页。此外，所有新_UTF8排序规则都使用代码页65001：

SELECT * FROM sys.fn_helpcollations() WHERE name LIKE '%_UTF8';

usingArabic_100_CS_AS_KS_WS_SC_UTF8和Latin1_General_100_CS_AS_KS_WS_SC_UTF8as 排序规则之间有什么区别吗？

是否可以从没有前缀的损坏的 nvarchar 中恢复 UTF8 数据N？

例如，在下面的代码片段中，我希望@n1_fixed基于以下内容获得正确的值@n1：

declare\n  @n1 nvarchar(10) = '\xe1\xb8\xbe\xe1\xba\xa5xi\xe1\xb8\xbf\xe1\xbb\xa9\xc5\x9b',\n  @n2 nvarchar(10) = N'\xe1\xb8\xbe\xe1\xba\xa5xi\xe1\xb8\xbf\xe1\xbb\xa9\xc5\x9b';\n\ndeclare\n  @n1_fixed nvarchar(10); -- somehow make it have the correct value, based on @n1\n\nselect iif(@n1_fixed = @n2, 1, 0)\n

我在 Ubuntu 14.04 上使用 Postgres 9.4。

我有一个 30GB JSON 文件，我正在尝试将其复制到 Postgres 中。

但我不断收到以下错误：

COPY <table>(comment_jsonb) FROM '<json file>' WITH (format csv, quote e'\x01', delimiter e'\x02', escape e'\x01');
ERROR:  unsupported Unicode escape sequence
DETAIL:  \u0000 cannot be converted to text.

我尝试搜索有问题的 Unicode 字符串来删除它，但因为它是 \u0000，即 NULL，所以我似乎无法使用正则表达式。当我将其打印到控制台时，我不知道 NULL 在哪里，因为（至少我的猜测是）它似乎什么也没有打印（尽管我不知道它实际上在做什么）。

有没有办法跳过这些错误？

或者，如何替换 JSON 文件中该 Unicode 的任何实例？

也许这是一个愚蠢的问题，或者我问错了。

我如何确定脚本（包含数千行）正在使用 ANSI 编码运行？

假设我们使用 Notepad++ 创建了一个脚本（程序员同时为 SQL 和 ORACLE 编写代码），并使用ANSI 编码保存它：

好的。然后，我们的脚本中有一个Â字符。如果我们的客户只是将此脚本复制到使用不同编码的某个工具中（真的，我不知道为什么，但有些用户这样做，我确定这不是为了发现错误），这Â 将被转换为：，但是由于我们的脚本有数千行，所以在客户端没有人会注意到这一点。

我们知道用户不会看到这一点，他们不会阅读整个脚本以确保一切正常。即使是付费的 DBA 也不会这样做（我是 DBA，我肯定会一直阅读所有脚本）。

那么，我怎么能确定，当用户按下 时F5，所有脚本都是用 ANSI 编码的，就像我们发送它的方式一样，没有这些奇怪的字符？我们只能通过正确的数据库整理来实现这一点吗？

我试图在脚本的第一行用 a case when asci character = the ascii(character) then ok else ERROR( using ascii to test )思考这样的事情：

Select CHAR(ASCII('ã')) As Teste_CHAR, CHAR(227) as Teste_CHAR_ASCII

所罗门，这是查询：

Select *,
Case
        When Teste_CHAR=Teste_CHAR_ASCII
        Then 'OK'
        Else 'Erro'
END as STATUS_TESTE,
Case
       When Teste_CHAR=Teste_CHAR_ASCII
       Then 'Everything is OK'
       Else 'Script will not …