软件著作权源代码材料整理

关键词：软件著作权源代码、软著材料、源代码前30页后30页、软著源代码整理、计算机软件著作权登记办法、中国版权保护中心、软著源代码每页50行、软著材料自动化

软著源代码材料怎么整理？一份把 60 页材料自动化的脚本方案

软著（计算机软件著作权）登记材料里最让工程师头疼的就是"源代码材料整理"——前 30 页 + 后 30 页、每页 ≥ 50 行、加页眉（软件名+版本+页码）、单面打印、宋体小五号。手工复制粘贴 + Word 排版 + 加页眉，最少要 1-2 天，且容易出错。本文给技术团队一份用脚本把整套流程自动化的方案，从源头仓库到 PDF 一气呵成。

一、软著源代码材料的硬性要求（2024）

中国版权保护中心对软著源代码材料的要求：

1. 程序和文档鉴别材料：源程序 + 任何一种文档的"前 30 页 + 后 30 页"连续打印
2. 不到 60 页的全部提交
3. 程序每页 ≥ 50 行
4. 文档每页 ≥ 30 行
5. 页眉：标注软件名称、版本号，右上角标注页码
6. 单面打印
7. 宋体小五号（程序部分也可根据实际情况调整）

【插图一】源代码材料 5 步自动化流水线（抽取 → 脱敏 → 分页 → 页眉 → PDF）

【插图三】images/插图三.png（说明：软著源代码材料 7 项硬性要求对照清单——页数范围 / 行数要求 / 页眉格式 / 打印规范）

二、人工整理的痛点

手动整理源代码材料的过程：

1. 从 Git 仓库里找"哪 30 行代码能体现核心功能"
2. 复制到 Word 文档
3. 调行距、调字体、调页边距
4. 在每页加页眉（软件名+版本+页码）
5. 手动核对每页 ≥ 50 行
6. 导出 PDF

这个过程最耗时的是 1 和 4，且容易出错：

• 复制时容易把注释、空行也算进去，导致每页行数不足
• 页眉手动加容易漏页或格式不一致
• 整个过程需要人工反复核对，1-2 天是常态

三、用脚本自动化：5 步流水线

把上面 6 步手工流程压缩成 5 步自动化：

Step 1 · 递归抽取

从 Git 仓库根目录出发，遍历所有源代码文件（按配置白名单，如 .py / .js / .ts / .go 等），按"核心模块优先 + 大文件优先"排序。

Step 2 · 过滤脱敏

• 去掉空行、纯注释行（保留代码中的内联注释）
• 脱敏敏感信息（API Key、密码、邮箱、手机号、身份证号）
• 标准化行尾（统一 LF 或 CRLF）

Step 3 · 前后分页

按"前 30 页 + 后 30 页，每页 50 行"切分：

• 前 30 页：从抽出的代码开头取 30 × 50 = 1500 行
• 后 30 页：从抽出的代码结尾取 30 × 50 = 1500 行
• 中间代码被自动跳过——这是符合审查规范的"前 30 后 30"要求

Step 4 · 页眉生成

每一页自动添加：

• 左侧：软件名称 + 版本号
• 右侧：第 X 页 / 共 60 页
• 字号、字体按审查规范

Step 5 · 导出 PDF

一键导出为符合规范的 PDF（单面、宋体小五、A4 纸）。

四、核心 Python 脚本思路

下面给出一份可运行的 Python 脚本框架（基于 ReportLab + PyPDF2），生产环境可直接复用：

import os
from reportlab.lib.pagesizes import A4
from reportlab.pdfgen import canvas
from reportlab.lib.styles import getSampleStyleSheet
from reportlab.platypus import SimpleDocTemplate, Paragraph, Spacer, PageBreak
from reportlab.pdfbase import pdfmetrics
from reportlab.pdfbase.cidfonts import UnicodeCIDFont

# 1. 注册中文字体
pdfmetrics.registerFont(UnicodeCIDFont('STSong-Light'))  # 宋体

# 2. 配置
SOFTWARE_NAME = "风航知识产权管理系统"
VERSION = "V1.0"
REPO_PATH = "./src"
PAGE_LINES = 50
TOTAL_PAGES = 30

# 3. 递归抽取
def extract_code(repo_path, whitelist=(".py", ".js", ".ts")):
    files = []
    for root, _, fnames in os.walk(repo_path):
        for fn in fnames:
            if fn.endswith(whitelist):
                files.append(os.path.join(root, fn))
    # 大文件优先
    files.sort(key=lambda f: -os.path.getsize(f))
    return files

# 4. 过滤脱敏
def clean_lines(path):
    cleaned = []
    with open(path, encoding="utf-8", errors="ignore") as f:
        for line in f:
            stripped = line.strip()
            if not stripped:  # 空行
                continue
            if stripped.startswith(("#", "//", "/*", "*")):
                continue  # 纯注释
            cleaned.append(line.rstrip())
    return cleaned

# 5. 生成 PDF
def build_pdf(all_lines, out_path):
    c = canvas.Canvas(out_path, pagesize=A4)
    width, height = A4
    per_page = PAGE_LINES
    total = min(len(all_lines), per_page * TOTAL_PAGES)
    page_no = 0
    for i in range(0, total, per_page):
        page_no += 1
        chunk = all_lines[i:i+per_page]
        y = height - 60
        # 页眉
        c.setFont("STSong-Light", 10)
        c.drawString(50, height - 30, f"{SOFTWARE_NAME} {VERSION}")
        c.drawRightString(width - 50, height - 30, f"第 {page_no} 页 / 共 60 页")
        # 正文
        c.setFont("STSong-Light", 9)  # 小五
        for line in chunk:
            if y < 50:
                break
            c.drawString(60, y, line[:80])
            y -= 12
        c.showPage()
        if page_no >= 60:
            break
    c.save()

实际生产环境要加：

• 代码高亮：用 Pygments 渲染后再导出
• 版本号动态注入：从 package.json / pyproject.toml 读取
• 敏感信息扫描：用 detect-secrets / truffleHog 预检
• Git 元数据保留：把提交作者、时间作为材料真实性证据写入 PDF 元数据

五、文档材料（用户手册 / 设计说明）的自动化

源码材料解决了，还有文档材料（中国版权保护中心要求"任何一种文档前 30 后 30 页，每页 ≥ 30 行"）。文档通常用：

• 用户手册：基于 API 文档 + 用户故事生成
• 设计说明：基于代码注释 + 架构图生成
• 操作说明：基于产品截图 + 流程图生成

工具化的关键是复用代码库已有的资产：

• 代码注释 → 提取函数说明 → 转成段落
• API 文档（Swagger / OpenAPI）→ 转成接口说明
• 用户故事 / PRD → 转成操作步骤
• LLM 二次润色，把零散说明整合为连贯手册

六、人工 vs 脚本：源代码材料整理的边际效率

把整套整理流程的工时对比：

• 递归抽取：人工 2 小时 → 脚本 5 秒
• 过滤空行/注释：人工 2 小时 → 脚本 10 秒
• 前后分页：人工 1 小时 → 脚本 5 秒
• 页眉生成：人工 1 小时 → 脚本 5 秒
• 导出 PDF：人工 30 分钟 → 脚本 5 秒
• 人工复核：人工 1 小时 → 1 小时（必须保留）

整体从 7 小时压到 1.5 小时（含人工复核）。一年产出 10 件软著的团队，可节省 55+ 小时。

【插图二】手动 vs 脚本：5 环节工时对比（脚本全面碾压）

七、把脚本集成到 CI/CD 里

最理想的形态是把源代码材料生成做成 CI/CD 流水线的一部分：

# .github/workflows/rz.yml
on:
  workflow_dispatch:
    inputs:
      software_name:
        description: '软件名称'
        required: true
      version:
        description: '版本号'
        default: 'V1.0'

jobs:
  generate-rz:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: 生成软著材料
        run: |
          python tools/gen_rz_material.py \
            --name "${{ inputs.software_name }}" \
            --version "${{ inputs.version }}" \
            --output artifacts/
      - uses: actions/upload-artifact@v4
        with:
          name: rz-material
          path: artifacts/

每次需要申报软著时，运营同学只需填两个参数（软件名、版本号），CI 自动出 PDF 材料包，省去工程师手工整理的时间。

八、常见问题（FAQ）

Q1：软著源代码每页必须 50 行吗？ A：程序每页 ≥ 50 行（除特定情况），文档每页 ≥ 30 行。不到 60 页的全部提交。页眉必须标注软件名+版本号，右上角标注页码。单面打印。

Q2：源代码必须从登录页开始吗？ A：不一定。但最佳实践是从入口页开始（登录、初始化），一段前端代码 + 一段后端代码，按核心功能模块依次复制。审查员通过阅读前 30 页能快速判断"这是一个完整可运行的系统"。

Q3：能不能用 minified / obfuscated 代码？ A：不可以。软著材料要求源码可读、可理解，minified 代码无法证明"这是你的真实开发"。

Q4：如何处理敏感信息（API Key / 密码）？ A：用 detect-secrets 类工具扫描后脱敏，替换为占位符（YOUR_API_KEY_HERE）。注意保留脱敏痕迹作为"完整性"证据。

Q5：脚本生成的 PDF 能直接提交吗？ A：可以。脚本生成后由人工复核一遍（核对行数、页眉、格式），再打印 + 盖章 + 扫描上传。

Q6：多语言项目（前端 + 后端）怎么排版？ A：按"核心模块优先"原则抽 5-10 个文件，先展示前端（登录、首页），再展示后端（API、业务逻辑），最后展示数据模型。比例按功能模块划分。

Q7：可以包含开源代码吗？ A：可以，但需要标注（许可证、来源 URL、修改记录）。纯开源代码堆砌会被认定为"独创性不足"。

Q8：脚本工具要去哪里下载？ A：风航科技软著通桌面端自带"源代码材料生成"模块，注册后即可使用；同时也提供 GitHub 仓库可自行部署（地址见官网 www.zaipack.cn）。

九、写在最后

软著源代码材料整理对工程师来说，是把"提交材料"的机械活变成"一次开发、长期复用"的工程问题。一旦你把递归抽取、过滤脱敏、前后分页、页眉生成、CI 集成全部工具化，软著材料就不再是"每次突击几天"的负担，而是研发流程的自然产物——每次发版本，材料包就自动生成在 artifacts 目录里，随时可提。

注：本文涉及的周期、费用、年限、金额等具体数值，均以主管部门当期公告或官方规则为准，不适用于所有个案；加急等特殊情形请以其当期规定为准。