以太坊JSON-RPC编码：数量与数据分别怎么用0x
通过JSON-RPC读写以太坊数据时，数量（quantities）和未格式化数据（unformatted data）都采用十六进制编码并以“0x”开头，但格式要求不同。按以太坊开发者文档的JSON-RPC约定，数量要求最紧凑表示：零写作“0x0”，禁止前导零；未格式化数据要求每个字节对应两个十六进制数字，十六进制位数须为偶数，字节中的零不能省略。这一约定适用于以太坊执行客户端的JSON-RPC API。
数量：最紧凑，零也不能省掉那一位
数量指整数、数字类取值。文档要求编码为十六进制、加“0x”前缀，并采用最紧凑表示，即去掉所有不必要的前导零：十进制65写作“0x41”，十进制1024写作“0x400”。零是边界情况，应写作“0x0”。文档把“0x”列为错误——它后面没有任何数字，不构成合法数量。同样，“0x0400”错误，因为存在前导零；“ff”错误，因为缺少“0x”前缀。这三类错误分别对应空数字、前导零、缺前缀，是数量编码中最常见的格式问题。
未格式化数据：每字节两位，零要保留
未格式化数据指字节数组、账户地址、哈希、字节码数组等。规则同样是十六进制加“0x”前缀，但要求每个字节对应两个十六进制数字，因此“0x”之后的位数必须为偶数，字节的高位零不能省略。例如“0x41”表示大小为1的字节数组；“0x004200”表示大小为3的字节数组，其中第一个字节是0x00；空字节数组写作“0x”，这是合法的，因为大小为零。文档列出的错误包括“0xf0f0f”，位数为奇数，不满足每字节两位；“004200”缺少“0x”前缀。可见未格式化数据在“0x”之后允许出现零，甚至必须以成对的零保留字节内容，这与数量禁止前导零正好相反。
两套规则怎么分界
区分两套规则的关键是判断传输的是“数值”还是“字节序列”。数值用于表达高度、计数、余额等整数语义，采用最紧凑十六进制；字节序列用于表达地址、哈希、代码等原始字节，采用每字节两位的十六进制。文档仅把“0x0400”列为数量编码错误，原因是它违反禁止前导零的规则，不应据此推断其他含义。反过来，若把“0x004200”改写成“0x4200”，就会丢失开头的零字节，改变数据长度和含义。文档还提示，数量编码中“0x”不被接受，而未格式化数据中“0x”表示空字节数组，二者不可混用。另一个共同错误是漏掉“0x”前缀，文档对两类数据都把无前缀的十六进制列为错误。
适用范围与核对口径
上述约定来自以太坊开发者文档的JSON-RPC页面，主要适用于以太坊执行客户端的JSON-RPC API。该页面同时说明，共识客户端也有自己的RPC API，记录在Beacon API页面；节点内部还使用Engine API供共识客户端与执行客户端交换数据。这些接口各有文档，不能把执行客户端JSON-RPC的编码约定直接套到其他接口上。实际编码时，可先确认字段语义是数量还是未格式化数据，再按对应规则检查：数量看是否有“0x”、是否最紧凑、零是否为“0x0”；未格式化数据看是否有“0x”、十六进制位数是否为偶数、每个字节是否用两位表示。按此口径核对，即可避开文档列出的典型错误。