目录与哈希
软著源程序文件目录怎么整理？附文件哈希清单示例
CCopyright 编辑团队内容核对：非官方指南
如果通知要求提供源程序文件目录结构及每个文件的哈希值，重点是让清单能对应到你实际提供的文件。目录树方便阅读，文件清单用于定位，哈希用于核对文件内容是否一致。
生成目录与哈希清单目录树、源程序正文与哈希清单是三种资料
目录树展示相对路径与层级；源程序鉴别材料展示程序正文；哈希清单记录各文件在本次整理时的内容摘要。不能用一页目录替代通知要求的源程序正文。
对于前端、后端或多应用项目，可以保留实际模块结构，不必为了看起来规范而改成另一种工程目录。
一份可核对清单应包含哪些字段
以下是整理建议，而非官方固定表格。示例只解释字段，不对应真实申请项目。
| 字段 | 填写方法 |
|---|---|
| 相对路径 | 例如 src/orders/service.ts；同名文件保留各自路径 |
| 字节数与算法 | 记录实际文件大小与 SHA-256，不能只写“已计算” |
| 哈希值 | 对原始文件字节计算，勿在计算前自动改行尾或编码 |
| 版本与范围 | 注明软件版本、源码快照，以及纳入和排除的目录 |
| 整理时间 | 记录这份清单的生成时间，不标成源码开发完成时间 |
第三方依赖、构建产物和敏感文件如何处理
先界定你要说明的源程序范围。依赖目录、缓存、构建结果不应在未说明的情况下混入自主源码清单。
本地工具默认排除 node_modules、.git、dist 等常见目录，以及 .env、私钥等敏感文件，并在导出结果中保留排除原因。这不是通用法律清单：若实际代码位于被排除目录，应先核对范围，不能把不完整清单表述为完整源码。
文件哈希与 Git 提交哈希有什么区别
逐文件 SHA-256 基于该文件字节；Git 提交号用于标识仓库中的一次提交。把同一个提交号填写到每个文件的“文件哈希”栏，不能替代逐文件计算。
源码、说明书所称版本和计算哈希的文件应一致。换行符、编码或文件内容发生变化，都可能导致哈希不同。请保留被核对的原始文件。
# PowerShell：对一个实际文件计算 SHA-256
Get-FileHash -Algorithm SHA256 -LiteralPath './src/orders/service.ts'在浏览器里生成目录和哈希清单
打开资料整理工具，选择项目文件夹并填写版本说明。文件内容在当前浏览器中处理，不上传到服务端。检查排除统计与预览后，下载 JSON 清单和目录文本。
若只有源码 ZIP，请先在本机解压并检查内容，再选择解压后的目录。工具不会执行其中代码；导出的清单应与保留的源码包一并核对。
常见问题
必须使用 SHA-256 吗？
本工具选择 SHA-256 作为内容核对算法。本轮检索没有确认所有软著补正统一指定该算法；通知若有具体要求，应按要求处理。
哈希值能证明代码是什么时候写的吗？
单独计算哈希不能证明历史形成时间或作者身份。它主要用于核对内容，需结合实际版本记录、可信来源和其他资料解释开发过程。
导出目录时需要加入 node_modules 吗？
不要默认将下载的第三方依赖当作自主源程序。本工具默认排除该目录并记录原因；具体提交范围仍应按项目情况和通知核对。
依据与资料来源
- 国家版权局：《计算机软件著作权登记办法》
第 9—11 条说明申请材料；第 22 条说明补正期限。
- Microsoft：Get-FileHash
文件哈希计算方法；SHA-256 是本工具采用的算法，不代表登记机构统一指定。
- Git 官方：git log
提交历史、作者时间与提交者时间的导出说明。