我一直在研究如何使用 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) 中 …

我发现许多 Web 服务（我想到的是 Stripe）对其 UUID 使用特殊的编码。它们将使用特殊的字母表（通常是小写、大写字母和数字）进行编码，而不是a44521d0-0fb8-4ade-8002-3385545c3318通常的编码，这会产生类似mhvXdrZT4jP5T8vBxuvm75. 两者都表示相同的 UUID，但编码不同。

我想知道这些服务如何处理这些 ID？特别是 Postgres 是否可以在数据库中直接使用这种短 ID 编码？（换句话说，任何选择或插入都将使用短 ID）

或者将这些短 ID 直接作为文本保存在数据库中是否有意义？

我找不到关于此的太多信息，所以我不确定这里的最佳实践是什么。

我正在将一个 SQL 表/列中的值插入到另一个中。由于其他原因，这些列的数据类型不同，但我不明白为什么 nvarchar(10) 源和 char(10) 目标有时会在 SQL Server 2014 中导致错误：

字符串或二进制数据将被截断。

len(sourcecol) = 10 和 datalength(sourcecol) = 20。

可能是因为 nvarchar 类型的源列中存储了一些不可见的空格/字符？

该场景是一个 SQL Server 实例，一个主要使用 BULK INSERT 操作提供数据的数据库，并且插入的一些文本包含特殊字符，例如\xc3\xb1因为我在西班牙语环境中工作。

因此，在最初的小测试之后，我意识到当我运行简单的时，这些特殊字符没有正确显示select，所以我开始检查我能想到的所有内容：

\n
• 文件编码：要批量插入的文件具有正确的编码：ANSI
\n
• 数据库编码：数据库具有正确的编码（感谢上帝）：select collation_name from sys.databases where name='DBNAME';结果为SQL_Latin1_General_CP1_CI_AS\n\n
  \n
  • Latin1：使用的字符集。这很适合我
  \n
  • 一般：这里没什么真正有趣的
  \n
  • CP1：这意味着它使用代码页 1，简而言之，意味着用于编码 WIN-1252 的代码页 1252 <=> 代码页，与 Latin1 非常相似
  \n
  • CI：不区分大小写
  \n
  • AS：区分重音，因此 \xc3\xa1 与 a 不同
  \n
\n
• 将数据导出到文件并检查：文件编码是ANSI ，但数据显示不正确，没有特殊字符，而是我发现一些其他字符使文本难以阅读。
\n

通过这些测试，我得出结论，数据未正确存储，这就是数据未正确显示和导出的原因。我在互联网上找到的几乎每个解决方案都建议使用nvarchar而不是varchar字符串数据类型字段，但这并不能解决这种情况。是什么破坏了我的插入？

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

我如何确定脚本（包含数千行）正在使用 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 …

加载 CSV 文件后，有各种单词错误地“写入”到数据库中。

一些例子：

• Diã¡ria 应该 Diária
• Crã©dito 应该 Crédito
• Ligaã§ãµes 应该 Ligações
• Usuã¡rio 应该 Usuário
• Nãºmeros 应该 Números

有没有办法将符号转换为正确的字符？

我已经做了多次测试不同collations，并functions可能在互联网上搜索，但没有成功。

我有一个纯文本数据文件，其中包含由不可打印字符"File Separator" (0x1c) 分隔的字段的记录。我正在尝试使用 SQL Server 的 bcp 实用程序将此数据加载到我的数据库中。然而，当使用文件分隔符的十六进制编码值作为 TERMINATOR 时，出现语法错误。

我试过使用

• 十六进制编码值： "0x1c"
• XML 编码值作为十六进制： ""
• XML 编码值作为十进制： ""

这些都不起作用，但是当对可打印字符使用相同的编码时，例如tab，这确实有效：	, 	(0x9没有。不足为奇，因为这是一个 XML 文件。）

结论似乎是不支持不可打印的字符。是这种情况吗？这将是具有讽刺意味的，因为不可打印的分隔符正是为此目的而创建的......

您可以在下面找到重现此问题的所有代码：

XML 格式文件：test.xml

<?xml version="1.0"?>
<BCPFORMAT xmlns="http://schemas.microsoft.com/sqlserver/2004/bulkload/format" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <RECORD>
  <FIELD ID="1" xsi:type="CharTerm" TERMINATOR="&#x1c;" MAX_LENGTH="10" COLLATION="Latin1_General_CS_AS_WS"/>
  <FIELD ID="2" xsi:type="CharTerm" TERMINATOR="\r\n" MAX_LENGTH="41"/>
 </RECORD>
 <ROW>
  <COLUMN SOURCE="1" NAME="COL1" xsi:type="SQLVARYCHAR"/>
  <COLUMN SOURCE="2" NAME="COL2" xsi:type="SQLNUMERIC" PRECISION="4" SCALE="0"/>
 </ROW>
</BCPFORMAT>

数据文件：test.txt
这只是一行，作为一个测试用例。StackExchange 不会在下面的行中显示分隔符，但是当您单击此帖子的“编辑”时，分隔符已包含在内，您应该能够复制粘贴它。

1111111112008

命令行

bcp TEST_DB.dbo.UL_TEST in "test.txt" -T -f "test.xml"

我有一个术语数据库，由一组用户添加到其中，并由另一组用户查询。

当人们在数据库中查询表情符号并且我的 React 应用程序会抛出错误（奇怪的是 CORS 错误，但这是一个不同的问题）时，我遇到了问题。我最终通过将表的字符集更改为utf8mb4带有utf8mb4_unicode_ci排序规则来解决这个问题。

现在，我在添加新术语时遇到错误，例如，“beyonc\xc3\xa9”的重复行已存在。但是，当我在数据库中查询“beyonc\xc3\xa9”时，它返回其中包含“beyonce”的行。是否有字符集和排序规则的组合可以正确处理这个问题？

我的数据库是在 Amazon RDS 上运行的 MySQL 5.6.40。

我的理解是，比较 Unicode 字符串文字的排序规则是由数据库排序规则决定的。

我的数据库正在使用SQL_Latin1_General_CP1_CI_AS排序规则。

当我将 N\'\xc3\x9f\' 与 \'ss\' 进行比较时，我预计比较会失败。但事实并非如此。我正在尝试找出原因。这是复制品：

    set nocount on \n    go\n    use tempdb\n    go\n    \n    SELECT \n       @@version as SqlServerVersion,\n       CONVERT(nvarchar(128), SERVERPROPERTY(\'collation\')) as SqlServerCollation,\n     DB_NAME() AS DatabaseName\n    ,DATABASEPROPERTYEX(DB_NAME(), \'Collation\') AS CollationUsedBySQLServerDatabase\n    GO\n    declare @ss varchar(255) = \'ss\'\n    declare @Nscharfess nvarchar(255) = N\'\xc3\x9f\'\n    declare @scharfess varchar(255) = \'\xc3\x9f\'\n    \n    select case  when @Nscharfess   = @ss then \'Unicode : Strings match\' else \'Unicode : Strings do not match\' end,\n            case when @scharfess    = @ss …