Uniswap v3 quoteExactInput调用时eth_abi字节编码异常求助

核心问题说明 #

你看到的「!p」「&」这类字符是字节序列的ASCII可视化表现，本身不是异常——这些字符对应地址字节的ASCII值（比如!对应0x21，正好是你第一个地址0x2170ed...的首字节）。真正的错误是：你用了Solidity标准ABI编码（每个类型固定32字节），但Uniswap V3的path参数要求的是紧凑字节流（address占20字节，uint24占3字节）。

正确的Path编码规则 #

Uniswap V3的路径格式（以两个token+单手续费池为例）是：

token0地址(20字节) + 手续费等级(uint24, 3字节) + token1地址(20字节)

注意：这里不需要ABI编码的32字节填充，必须是紧凑的字节拼接。

修正后的代码实现 #

直接手动处理字节拼接，不要用eth_abi.encode：

def path_to_encoded_path(self, path, fee):
    # path格式：['token0地址', 'token1地址']，fee为手续费等级（如500）
    # 处理token0地址：去掉0x前缀，转20字节bytes
    token0_bytes = bytes.fromhex(path[0][2:])
    # 处理手续费：转3字节大端序bytes
    fee_bytes = fee.to_bytes(3, byteorder='big')
    # 处理token1地址：去掉0x前缀，转20字节bytes
    token1_bytes = bytes.fromhex(path[1][2:])
    
    # 拼接成最终path字节流
    bytePath = token0_bytes + fee_bytes + token1_bytes
    # 打印十六进制格式更易读（可选）
    print("bytePath hex:", bytePath.hex())
    return bytePath

为什么之前的方法错误？ #

eth_abi.encode和已废弃的web3.eth.abi.encodeParameters都是遵循Solidity ABI规范：

• address类型会被填充前导零到32字节
• uint24类型也会被填充前导零到32字节

但Uniswap V3 Router合约的quoteExactInput函数要求的path是自定义的紧凑字节格式，不是标准ABI编码参数，所以用这些函数生成的字节流长度不对（你之前的bytePath是32+32+32=96字节，而正确的应该是20+3+20=43字节），导致调用失败。

替代工具 #

如果不想手动实现，可以使用专门的Uniswap V3 Python工具库来处理路径编码，这类库会内置正确的编码逻辑，避免手动处理字节的麻烦。

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