先确认手里的是区块头，不是整个区块
查询区块链区块头结构，第一步是限定具体协议和数据对象。比特币开发参考把区块头定义为固定八十字节的序列化结构；完整区块还包括交易数量与交易数据。因此，一份完整区块的原始内容明显超过八十字节，并不表示头部格式出错。
网页可能把原始字节显示为十六进制文字。八十字节对应一百六十个十六进制字符，不包括空格、换行或显示前缀。字符数和字节数需要先换算，再对照文档，不能把复制出来的说明文字也算进区块头。
六个字段的长度相加，才能得到边界
按参考文档顺序，版本号占四字节，前一区块头哈希占三十二字节，默克尔根占三十二字节，时间、nBits和nonce各占四字节。四个四字节字段加上两个三十二字节字段，合计正好八十字节。
如果从零开始计算字节偏移，它们分别从零、四、三十六、六十八、七十二和七十六开始。这个排列说明nonce位于最后四字节。偏移来自前面字段长度的累加，不是凭某段十六进制文字看起来像时间或哈希来猜位置。
读对位置以后，还要读对整数顺序
比特币参考说明，头部两个哈希字段使用内部字节顺序，其余数值使用小端顺序。小端把数值的低位字节放在前面。用一个与真实区块无关的例子说明：四字节01 00 00 00，按小端无符号整数读是1，按大端读则是16777216。
MDN的DataView.getUint32说明，该方法从指定字节偏移读取四字节，默认按大端解释，只有显式选择小端才符合这里的无符号字段约定。因此，默认值不是“自动识别网络格式”；阅读时间或nonce时，需要同时核对偏移、宽度和字节序。
相同宽度不意味着相同数据类型
版本字段在参考中写作有符号int32，时间、nBits与nonce写作无符号uint32；两个哈希字段则是三十二字节序列。不能因为都来自同一段头部，就一律用一个四字节无符号读取方法解释全部内容，哈希也不是读取一次就得到的普通小整数。
nBits还多一层含义：读出这四字节的整数表示，不等于已经得到完整的目标阈值。文档另列紧凑编码的规则。数据类型负责说明怎样读，字段语义负责说明读到的值代表什么，这两层应当分开核对。
结构核对不是区块有效性结论
八十字节长度正确、字段边界正确，只能说明这份数据符合所检查的结构条件，不能据此证明它已经属于主链，或其中关联交易均有效。参考文档明确序列化头部还参与工作量证明计算；完整验证涉及的规则不止字节切分。
保存阅读笔记时，可以附上协议名称、原始资料位置、字段表和使用的字节表示。不同网络的头结构应分别查原始说明，历史文档中的升级状态与容量数字也不能顺手当作当前值。本文只解释稳定的比特币头部格式，没有对真实区块执行链上验证。