Soap 有人听说过asciihex编码吗？

这种类型的编码在soap消息中使用。。。 我收到一条用ASCIIHEX编码的消息，虽然我对编码方法有清晰的描述，但我对该编码的实际工作方式没有任何想法：

如果使用此模式，则每个原始字节都被编码为两个字符的十六进制序列。因此，如果原始字节为0x0a，则传输的字节为0x30和0x41（ASCII中的“0”和“a”）

收到的缓冲区：“1F8B080000000000A58E4D0AC2400C85F78277E811F2665329975BBAE500F2022DD29785FF95715AE82CDCF9415EFEC823C6710247582D5965C32C65AAB0F5FC0A5204C415855E7C190EF61B34710BCD7486D2BAB8A4910D022D5E107D211ED345F2F37A103ADB1F619AB7FDB13B63998C7DFBDEC3aCF3F399EE152E010000”

实际文件包含以下内容：“63CD13C1697540000000662534034000030000120011084173878R 0000000 1000018600000000010046000009404872101367219 000000000000 DNSO\U 038114 00000000 2001160023替换M000000333168625 N0000 00000000”

提供程序向我发送了包含上述字符串的文件。我试图从缓冲区字符串开始，得到与提供者发送的结果相同的结果，但没有结果。我还试着搜索这个“asciihex”编码和相同的编码。如果有人知道这个编码或可以给我任何建议，我会非常感激。我几乎没有使用SOAP服务的经验

---

根据以上评论，缓冲区可能被压缩。它以压缩签名

1F 8B

开始。见下文

将对应于十六进制字符串的字节写入文件。使用

gz

或

tar.gz

扩展名命名该文件，并尝试提取它或使用某个文件归档工具打开它

---

您可以尝试的另一件事是不发送请求中的

Compress

元素，假设它是可选字段，您可以这样做。如果可以，请检查缓冲区是否发生了变化，并且长度是否正确，您可以看到与原始内容类似的模式（例如，对于末尾的零）。

您确定内容和缓冲区代表相同的字符串吗？定义是“如果使用这种模式，每个原始字节都被编码为两个字符的序列，用十六进制表示”。这看起来像是字节的简单十六进制表示。但是字符串不匹配。长度不对，图案不对。例如，在实际文件中有一堆编码中看不到的零。因此，要么这些例子是不正确的，要么是发生了其他事情。你不能要求提供者提供一些源代码来将一个转换成另一个，反之亦然吗？还有一件事。我在您的请求中看到一个

Compress

元素。这是否意味着缓冲区可以是压缩文件？你知道它是什么类型的文件吗？总是发短信吗？二进制文件？我收到了一个文件，它的名称与我在SOAPUI中试图获取的文件完全相同。同样的文件，同样的一切。该文件名为“CD13_C169754_RICEC150_4270590”，他们还确认了所有这些。这只是一个500字节的文件扩展名。最有可能的问题是压缩…非常感谢，我会尽快尝试，我会回来的结果：我真的很感激！我回来了，我试图从调用中删除compress参数，但现在没有检索到任何内容。。。正如您所说的文件是一个gzip，我在这里添加了一个文件的屏幕截图，希望这是有用的信息。。。