SQL Server Varbinary转Snowflake存储异常问题咨询

核心问题：二进制数据被错误当作字符串处理 #

SQL Server中的0x005056A0789A1ED88AA08620736740DC是纯二进制字节序列（varbinary类型），但插入Snowflake的不可控流程错误地将其按字符串编码逻辑处理，而非直接存储二进制数据，这是所有差异的根源。

具体编码映射差异拆解 #

对比原二进制字节与Snowflake中varchar值的hex_encode结果，差异来自两次错误转换：

• ASCII范围字节无变化：原字节0x50（P）、0x56（V）、0x20（空格）、0x73（s）、0x67（g）、0x40（@）属于ASCII（0x00-0x7F）范围，UTF-8编码与原字节完全一致，所以这部分字符和hex结果都匹配。
• 非ASCII字节被二次编码：流程先将原二进制字节按某字符编码（推测为Windows-1252或Latin-1）映射为Unicode字符，再将这些字符转成UTF-8存储到varchar中，导致原字节被改写：
  • 原字节0xA0 → 被映射为Unicode U+00E1（á）→ UTF-8编码为C3A1
  • 原字节0x9A → 被映射为Unicode U+00DC（Ü）→ UTF-8编码为C39C
  • 原字节0xD8 → 被映射为Unicode U+00CF（Ï）→ UTF-8编码为C38F
  • 原字节0x8A → 被映射为Unicode U+00E8（è）→ UTF-8编码为C3A8
  • 原字节0x86 → 被映射为Unicode U+00E5（å）→ UTF-8编码为C3A5
  • 原字节0xDC → 被映射为Unicode U+2584（▄）→ UTF-8编码为E29684
• 开头空字节被截断：原二进制开头的0x00（空字节）被字符串处理逻辑当作字符串结束符直接丢弃，所以最终结果中完全没有该字节的痕迹。

内容的提问来源于stack exchange，提问作者jh1111111111