如何在C++Builder中通过REST API获取并保存PDF文件？

你的代码无法正确保存PDF的核心问题是错误地将二进制PDF数据以Unicode字符串的方式处理，导致原始二进制结构被破坏。以下是具体的修正方案：

原代码问题分析 #

RESTResponse1->Content是UnicodeString类型，当API返回二进制PDF数据时，组件会尝试将原始字节转成Unicode编码（如UTF-16），这会改变PDF的原始二进制结构。再通过c_str()转成窄字符串写入文件，进一步损坏数据，最终导致PDF无法正常打开。

正确实现方式 #

方法1：使用RawBytes直接写入（推荐） #

RESTResponse1->RawBytes存储了API返回的原始二进制字节数据，完全保留了PDF的结构，直接写入文件即可：

TFileStream *FStream;
// 注意路径反斜杠需要转义，或使用正斜杠
FStream = new TFileStream(L"c:\\tmp\\test.pdf", fmCreate);
// 写入RawBytes中的原始数据，使用RawBytes的长度获取实际字节数
FStream->Write(RESTResponse1->RawBytes, RESTResponse1->RawBytes.Length);
delete FStream;

方法2：直接将响应写入文件流（适合大文件） #

如果PDF文件较大，可以在请求阶段就指定ResponseStream，让组件直接将响应写入文件，避免加载到内存：

TFileStream *FStream = new TFileStream(L"c:\\tmp\\test.pdf", fmCreate);
try {
    RESTRequest1->ResponseStream = FStream;
    RESTRequest1->Execute();
} __finally {
    delete FStream;
    RESTRequest1->ResponseStream = nullptr;
}

额外注意事项 #

• 路径中的反斜杠必须转义为\\，或者使用正斜杠/（如L"c:/tmp/test.pdf"），否则会被解析为转义字符导致路径错误。
• 优先使用RESTResponse1->RawBytes.Length获取实际字节数，避免依赖响应头中的ContentLength（可能存在不匹配的情况）。
• 确保RESTClient没有添加额外的编码相关请求头（如Accept-Charset），让组件默认处理二进制响应。

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