先明确：核验的对象是什么
对于具体平台的历史公告，核验通常包含两个问题：一是某份文字、图片或文件在某个时间之前是否已经存在；二是它是否确实由对应平台或其授权主体发布。前者属于文件存在性和时间顺序核验，后者属于来源真实性核验。仅凭一张截图，通常无法同时证明这两点。
“e币网”这一具体项目或品牌的公告真实性，不能仅依据通用密码学标准直接得出结论。RFC 3161和数字签名标准说明的是核验工具与技术逻辑，并不证明某个平台使用过这些工具，也不证明某一则公告真实有效。
第一步：固定原始材料和访问线索
应尽量保存公告页面的完整内容、页面标题、网页地址、显示时间、附件文件、页面中的发布主体和相关链接。保存时不要只截取结论段落，还应保留上下文，以便检查是否存在删改、断章取义或版本差异。对于动态网页，可同时记录页面源文件、下载文件的文件名和本地保存时间。
不同来源之间应相互独立。例如，平台官方公告页、平台官方账号发布记录、可验证的网页存档或同时期的正式通知，可以分别作为证据来源。搜索引擎摘要、聊天转发和未经说明的截图适合作为线索，不宜单独作为最终依据。
第二步：核对内容摘要与时间戳
RFC 3161描述的时间戳服务，会对文件的哈希摘要生成带时间信息的令牌。核验时，先对当前保存的文件重新计算哈希值，再检查时间戳令牌中的摘要是否一致。如果摘要不一致，说明当前文件与被时间戳确认的内容不是同一份，不能直接视为原始版本。
时间戳主要能够支持“某份特定数据在某个时间点之前已经存在”这一判断，不能单独证明文件内容真实、发布者身份真实，或公告中的事实没有错误。还应检查令牌的签名、时间戳服务的证书标识、哈希算法、随机数等字段；RFC 3161要求接收方验证这些信息，验证失败时应拒绝该令牌。
第三步：核验发布主体与数字签名
若公告文件带有数字签名，应检查签名是否对应当前文件、签名证书是否属于预期发布主体，以及证书在相关时间是否有效。数字签名的核心作用是检测数据是否被未经授权地修改，并帮助确认签名所对应的身份。验证时还应关注证书链、用途限制和撤销状态，而不是只看文件上是否出现“已签名”字样。
网页本身没有数字签名时，可比较域名、页面结构、官方账号之间的相互指向，以及公告编号、发布时间和附件版本是否连贯。域名相似、使用品牌名称或带有平台标识，并不自动证明页面属于该平台。涉及重大争议时，应把网页证据与平台注册主体、可验证的官方联系方式及同期公开记录分开核对。
第四步：形成可复核的证据记录
建议为每份材料建立记录表，至少包括：材料名称、来源地址、获取时间、文件哈希、页面显示时间、发布主体、是否有数字签名、是否有时间戳、与其他来源是否一致，以及尚未解决的疑点。对网页内容和附件分别计算摘要，避免把页面更新后产生的新文件误认为旧版本。
证据记录应区分“已验证”“部分支持”和“无法确认”。例如，时间戳匹配只能把文件存在性列为部分或较强支持；如果缺少官方发布渠道或身份签名，就不能进一步写成“平台已确认”。这种分层表达比直接给出真伪二选一更准确。
常见问题与适用边界
问：截图上有日期，能否证明公告当日发布？答：不能单独证明。截图可能被裁剪、修改或重新制作，最好结合原始页面、独立存档、文件摘要或数字签名。
问：网页现在打不开，是否代表公告不存在？答：不能据此下结论。页面失效只说明当前无法访问，应继续查找同期独立记录、保存的原始文件和可验证的时间证据。
问：有时间戳是否就代表公告内容真实？答：不是。时间戳确认的是特定数据与时间的关联，不能替代对发布主体、事实内容和授权关系的核验。本文方法适用于一般电子公告、附件和网页证据的技术核对，不构成对任何具体平台公告真伪的结论。