问使用CFDUMP查看二进制数据时不同

EN

(从评论中扩大)

我不是这个讽刺的意思，但这有什么区别，他们如何显示二进制？这只不过是数据呈现方式的不同而已。这并不意味着实际的二进制值不同。

它类似于处理日期的方式。在内部，他们是一个很大的数字。但是由于大多数人不知道1234567890代表的日期，所以应用程序选择以更人性化的格式显示这个数字。因此，SSMS可以将日期表示为2009-02-13 23:31:30.000，而CF可能将其表示为{ts '2009-02-13 23:31:30'}。尽管演示文稿各不相同，但内部的价值仍然相同。

就二进制文件而言，SSMS将其显示为十六进制。如果在查询列上使用binaryEncode()，并将二进制转换为十六进制，则可以看到它是相同的值。只是没有领先的0x

  writeDump( binaryEncode(yourQuery.binaryColumn, "hex") )

如果您对二进制文件有其他问题，请详细说明好吗？

更新：

不幸的是，我认为您无法轻松地将cfdump表示转换回二进制。与Railo的实现不同，Adobe的cfdump只是将单个字节的数字表示连接到一个大字符串中，没有分隔符。(破折号只是负数)。您可以通过循环遍历示例字符串的字节来再现这一点。下面的代码产生与您发布的数字相同的字符串。

   bytes = binaryDecode("004BC878B0CB9A4F...", "hex");
   for (i=1; i<=arrayLen(bytes); i++) {
       WriteOutput( bytes[i] );
   }

我认为理论上可以将该字符串转换为二进制，但这将非常困难。AFAIK，没有办法准确地确定一个数字(或字节)从哪里开始，另一个结束。有一些线索，但最终只能归结为猜测。

Railo的实现，显示以破折号"-“分隔的字节值。连续两个破折号表示一个负数。"0"，"75"，"-56"，.

0-75--56-120--80--53--102-79--122--48--11-44--99--21-104--108-1-0-0-0--44--42--115--104--56--105-84-37-38-73-121--49--71-45-20-101--126--61--115-116-89-123-73-95--121--2--96--101-104--88-68-10

因此，您可能可以将该字符串解析为一个字节数组。然后使用<cfqueryparam cfsqltype="CF_SQL_BINARY" ..>将二进制文件插入数据库。不幸的是，这对你没有帮助，但是这个解释可能对下一个人有帮助。

在这一点上，我认为您最好的选择是从数据库备份中恢复数据。