基于Composer 0.19.0开发自定义钱包执行composer card list报错

从你的描述来看，虽然自定义钱包能正常导入卡片并完成交易，但composer card list命令触发了jszip的解析错误，这说明卡片的存储/导出格式和Composer CLI预期的标准Zip格式不匹配——交易场景可能只需要读取卡片的部分内容（比如凭证），而card list命令需要完整解析整个Zip包，所以格式问题在这个场景下暴露了。

下面是针对性的排查和修复步骤：

1. 检查自定义钱包的exportCard实现 #

Composer的卡片本质是包含connection.json、凭证等文件的Zip包，exportCard方法需要返回这个Zip包的原始二进制Buffer。对比composer-wallet-filesystem的实现，重点确认：

• 你是否在导出时修改了原始Zip数据？比如错误地将Buffer转成了UTF-8字符串再返回，导致二进制数据损坏。
• 是否正确使用jszip处理Zip数据？比如loadAsync和generateAsync的参数是否和官方实现一致，有没有额外的压缩/编码选项导致格式变化。

参考filesystem钱包的核心逻辑示例：

// 读取卡片时直接加载原始Buffer
const zip = new JSZip();
await zip.loadAsync(storedCardBuffer);

// 导出时生成标准Zip格式的Buffer
return zip.generateAsync({ type: 'nodebuffer', compression: 'DEFLATE' });

2. 验证存储的卡片数据格式 #

把自定义钱包存储的卡片数据导出，和filesystem钱包生成的卡片文件做对比：

• 用二进制编辑器查看数据开头，标准Zip文件的签名是PK\x03\x04，如果你的数据开头不是这个，说明存储时的二进制处理有误。
• 尝试用系统自带的Zip工具打开导出的数据，如果无法打开，直接证明数据不是标准Zip格式。

3. 检查卡片存储的写入逻辑 #

如果你的钱包是将卡片数据写入数据库、非本地文件系统等介质，要确保是按二进制格式写入，而不是文本格式：

• 在Node.js中，写入时避免使用utf8编码，改用binary或者直接写入Buffer。
• 比如写入数据库时，要确保字段类型支持二进制存储（如MongoDB的BinData，MySQL的BLOB），不要存成字符串。

4. 不要强行更新composer-cli的jszip依赖 #

Composer 0.19.0是较旧的版本，它依赖的jszip版本有特定的兼容性要求。强行更新到最新版jszip，可能会和CLI的解析逻辑冲突，反而引发更多问题。建议恢复composer-cli的原始依赖版本，通过修复自定义钱包的格式问题来解决错误。

如果以上步骤还没解决问题，可以进一步排查importCard方法——虽然导入成功，但可能导入时对卡片数据做了错误的转换，导致存储的内容本身就不符合Zip格式要求。

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