简介这份基于Java实现的论文查重系统源码面向计算机相关专业学生及Java初级开发者解决论文相似度检测与重复率计算问题。系统采用SimHash算法进行文本指纹比对通过命令行传入原文、抄袭版论文及输出答案文件路径即可完成检测配套性能优化分析与单元测试用例适合课程设计或毕业设计参考。压缩包共65个文件包含11个Java源文件与11个class编译文件另有15个xml配置文件、10个txt测试文本、11张项目截图以及Maven/IDEA工程配置大小461KB整体结构清晰完整。当前已有110人浏览学习。具体可拿到完整工程目录、SimHash查重核心实现、10组以上测试用例及分支覆盖率检查配置并附有不同干扰程度的样例文本删除、添加、替换等便于验证算法在不同场景下的表现对理解文本去重与工程化开发流程均有帮助。1. 论文查重系统Java 课设里最容易被问倒的一个“基于Java的论文查重系统”光看标题你可能以为它只是个普通的课程设计——能传两篇文档、算个相似度、出个报告就交差了。但真正上手你会发现这是 Java 课设里少有的“看着简单、做起来全是坑”的题目。文件上传、文本解析、相似度算法、数据库设计、并发处理每一个环节都能问出两三道面试题。你交上去的版本能不能跑只是及格线老师问一句“你的相似度怎么算的”就能区分你是真懂还是抄了一套框架。这篇笔记从我的实际开发经验出发把一个 Java 论文查重系统拆开讲清楚技术栈选什么、SimHash 和余弦相似度怎么落地、PDF 和 Word 里的文字怎么抽出来、为什么同一篇论文换个格式查重结果差 20%。要复现这套系统的同学可以直接照着后面的代码块和表结构搭参数和踩坑点我都标出来了。目标人群是大三大四做课设、准备毕设以及想用这个题目练手 Java Web 的开发者。2. 框架选型与项目结构为什么用 Spring Boot 而不是 Servlet 手写查重系统本质上是一个 Web 应用接收用户上传的文档后端解析文本、计算相似度、存储并返回报告。选型这件事在动工前就该定下来因为后续所有的代码都建立在它之上。我见过不少同学用纯粹的 JSP Servlet 写这个题目不是说不行而是文件上传、数据库连接池、JSON 返回这些都要一行行手写工作量翻倍而且出 bug 的概率也高。2.1 Spring Boot MyBatis Plus 的组合理由主流做法是用 Spring Boot 2.7.x 搭配 MyBatis Plus前端用 Vue 或者纯 HTML Ajax 都可以。Spring Boot 自带 Tomcat 和文件上传限制配置MyBatis Plus 让 CRUD 不用写 XML这对查重系统这种“表不多但字段杂”的项目来说非常省事。Java 版本建议 JDK 1.8不是越新越好——很多学校的服务器环境还停留在 1.8选 JDK 11 或 17 反而可能因为版本问题导致部署失败。另外要明确这个系统不需要 Redis不需要消息队列更不需要微服务。它就是单机应用最多几十个学生同时上传用 MySQL 足够。我见过有人往课设里硬塞 Redis 做缓存结果答辩时老师一问“缓存的 key 怎么设计”直接卡住。技术栈越简单越容易讲清楚。2.2 核心模块划分与 Maven 依赖项目按包结构分四层controller 接收请求service 处理业务逻辑mapper 操作数据库util 放分词和相似度算法的工具类。这不是什么高深设计但能让你在答辩时清晰说出“我的系统分了几层每层干什么”。dependencies !-- Web 启动器内置 Tomcat -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId version2.7.18/version /dependency !-- MyBatis Plus简化数据库操作 -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.5/version /dependency !-- MySQL 驱动 -- dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency !-- 文件上传解析 Word / PDF -- dependency groupIdorg.apache.poi/groupId artifactIdpoi-ooxml/artifactId version5.2.5/version /dependency dependency groupIdorg.apache.pdfbox/groupId artifactIdpdfbox/artifactId version2.0.31/version /dependency /dependencies这里有个容易踩的坑POI 的版本和 JDK 版本强相关POI 5.x 需要 JDK 1.8 以上但如果你用的 JDK 正好是 1.8.0_181 之前的版本某些 docx 文件解析会报奇怪的异常。建议直接上 JDK 1.8 最新小版本或者把 POI 降到 4.1.2——功能上没区别查重系统用到的 XWPFDocument 两个版本都支持。3. 文本相似度算法核心源码怎么改、参数怎么调查重系统的灵魂是算法。很多人的代码里写了个“相似度”方法但追问下去连自己也说不清算的是什么。明确告诉你论文查重最常用的是余弦相似度和 SimHash你至少要懂一个并且能说出为什么不用另一个。3.1 分词与特征向量构造先把文档拆成句子还是整篇作为一个向量很多人在这里从一开始就做错了。整篇文档算相似度只要两篇论文的“结论”部分相似整体相似度就会被拉得很高这不合理。正确做法是分段计算把论文按章节或按自然段切分对每个段落分别做向量化然后取最大值或加权平均。分词这一步查重系统里最省事的是用现成的分词库。HanLP 和 Ansj 都可以但对于课设来说它们引入的 jar 包很大加载也慢。简单方案是手动基于标点符号和空格分词中文论文本身以词为单位的特征不明显停用词表过滤掉“的、了、和、是”这类虚词后用二元词组就能跑出不错的效果。public class TextVectorizer { // 停用词表实际使用时可扩充到几百个 private static final SetString STOP_WORDS new HashSet(Arrays.asList( 的, 了, 和, 是, 在, 我, 有, 就, 不, 人, 都, 一, 一个, 上, 也, 很, 到, 说, 要, 去, 你, 会, 着, 没有 )); public static ListString segment(String text) { // 先按非中文字符切分再过滤停用词 ListString words new ArrayList(); Pattern pattern Pattern.compile([\\u4e00-\\u9fa5]{2,}); Matcher matcher pattern.matcher(text); while (matcher.find()) { String chunk matcher.group(); // 按长度 2 切分为二元词组 for (int i 0; i chunk.length() - 1; i) { String term chunk.substring(i, i 2); if (!STOP_WORDS.contains(term)) { words.add(term); } } } return words; } }这段代码的思路是把中文论文切成语义单元二元词组的粒度对相似度计算最稳。切分成一元词时两篇无关论文都会因为出现大量“研究”“方法”“结果”这类高频词而拉高相似度切分成三元词组则对句式变化太敏感换个说法就查不出来。二元组是课程设计阶段性价比最高的参数。3.2 余弦相似度的完整实现与评分映射余弦相似度把每一篇文本的向量看作高维空间中的一个方向方向越接近则越相似。实现上不需要真的定义几百维的数组——用 Map 记录词频即可。public class CosineSimilarity { public static double calculate(MapString, Integer vecA, MapString, Integer vecB) { if (vecA.isEmpty() || vecB.isEmpty()) { return 0.0; } double dotProduct 0.0; double normA 0.0; double normB 0.0; for (Map.EntryString, Integer entry : vecA.entrySet()) { String term entry.getKey(); int freqA entry.getValue(); int freqB vecB.getOrDefault(term, 0); dotProduct freqA * freqB; normA freqA * freqA; } for (Integer freq : vecB.values()) { normB freq * freq; } if (normA 0.0 || normB 0.0) { return 0.0; } return dotProduct / (Math.sqrt(normA) * Math.sqrt(normB)); } // 把相似度映射为查重率0.9 以上视为重复文本 public static double toDuplicateRate(double score) { // 原始余弦相似度在 0~1 之间但 0.5 的两篇论文实际已经有明显重复 // 所以做一次非线性放大 if (score 0.3) return 0.0; return Math.min(1.0, (score - 0.3) / 0.7); } }代码里的 toDuplicateRate 是一个关键的参数设计。余弦相似度直接当作查重率的话你会发现两篇无关论文的相似度也在 0.2 左右直接显示 20% 重复会让用户困惑。所以要做映射低于 0.3 的一律视为不重复0.7 以上快速爬升到 100%。这个阈值你可以根据测试结果微调我推荐先用这组参数跑几十篇文档观察误报率再改。4. 文档解析与数据库设计PDF 里抽文字遇到的编码坑算法再好拿不到文档里的文字也是白搭。论文查重系统要处理的文件格式无外乎 doc、docx、pdf。这里有个现实问题绝大多数的论文是 PDF 格式但 PDF 的文字提取是所有格式里最不稳定的。4.1 用 PDFBox 和 POI 实现多格式文本抽取docx 是 Zip 包用 POI 的 XWPFDocument 直接读段落。doc 是老格式POI 用 HWPFDocument 读但兼容性一般遇到加密文档会直接抛异常。PDF 用 PDFBox 的 PDFTextStripper注意它提取的是“字符流”不是按段落组织——也就是说它会把 PDF 排版产生的换行完全打乱。public class TextExtractor { public static String extractText(MultipartFile file, String ext) throws IOException { if (pdf.equalsIgnoreCase(ext)) { try (PDDocument document PDDocument.load(file.getInputStream())) { PDFTextStripper stripper new PDFTextStripper(); // 按页提取保留分页符便于后续按章节切分 stripper.setSortByPosition(true); return stripper.getText(document); } } else if (docx.equalsIgnoreCase(ext)) { try (XWPFDocument doc new XWPFDocument(file.getInputStream())) { StringBuilder sb new StringBuilder(); for (XWPFParagraph para : doc.getParagraphs()) { sb.append(para.getText()).append(\n); } return sb.toString(); } } else if (doc.equalsIgnoreCase(ext)) { try (HWPFDocument doc new HWPFDocument(file.getInputStream())) { return doc.getDocumentText(); } } throw new IllegalArgumentException(不支持的文件格式: ext); } }PDFBox 有个参数要专门提setSortByPosition(true)。如果不设置PDFBox 按内部内容流顺序取文本扫描版 PDF图片型和复杂排版的 pdf 会出现文字顺序错乱。设置之后按坐标排序提取至少能保证正文顺序基本正确。还有一点PDFBox 对中文的支持依赖系统字体Linux 服务器上如果没装中文字体提取出的中文可能是乱码或空字符——这是部署时的常见坑后面避坑章节再展开。4.2 查重记录表的字段设计与索引优化存储需求很简单用户上传的原始文件、抽取后的纯文本、查重结果。但表结构设计能看出你是否考虑到扩展性。CREATE TABLE paper_record ( id bigint NOT NULL AUTO_INCREMENT, user_id bigint NOT NULL COMMENT 上传用户, file_name varchar(255) NOT NULL COMMENT 原始文件名, file_type varchar(10) NOT NULL DEFAULT docx COMMENT doc/docx/pdf, text_content longtext COMMENT 抽取出的全文用于比对和展示, word_count int NOT NULL DEFAULT 0 COMMENT 字数统计, status tinyint NOT NULL DEFAULT 0 COMMENT 0-待处理 1-已完成 2-解析失败, similarity decimal(5,2) DEFAULT NULL COMMENT 最高重复率百分比形式 0-100, detail_json json DEFAULT NULL COMMENT 分段相似度明细, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;几个关键设计解释一下。text_content 用 longtext因为一篇 3 万字的论文抽取出来也就 60KB 左右完全放得下不要为了“节省空间”把它拆成多个表。similarity 存的是百分比数字比如 36.50比存 0.365 直观得多。detail_json 用来存每段的相似度明细比如某篇论文第 3 段和第 5 段的重复率分别是多少——这个字段在报告展示时非常有用而且 MySQL 5.7 可以直接用 JSON 函数查询。不要给 text_content 建全文索引。中文全文索引需要指定分词器MySQL 默认的全文索引对中文支持不好查重时你要的也不是数据库全文检索——你的算法会直接读取该条记录的 text_content 到内存和另一篇比。这里把数据库当存储用不要把业务逻辑往 SQL 里塞。5. 完整查重流程的落地从文件上传到报告生成的代码骨架有了算法和解析还差一条线把它们串起来。查重系统最完整的一个业务流程是上传论文 → 选择比对库范围 → 后端解析 → 分段计算相似度 → 保存结果 → 展示报告。这一章把这条线的关键代码写全你可以直接照着拼出能跑的项目。5.1 控制器接收上传和查重请求RestController RequestMapping(/api/paper) public class PaperController { Autowired private PaperService paperService; PostMapping(/check) public Result checkPaper(RequestParam(file) MultipartFile file, RequestParam(value compareScope, defaultValue all) String compareScope) { if (file.isEmpty()) { return Result.error(上传文件为空); } String fileName file.getOriginalFilename(); if (fileName null || !fileName.matches(.*\\.(doc|docx|pdf)$)) { return Result.error(仅支持 doc/docx/pdf 格式); } // 限制文件大小比如不超过 20MB防止内存溢出 if (file.getSize() 20 * 1024 * 1024) { return Result.error(文件大小不能超过 20MB); } try { PaperRecord record paperService.processCheck(file, compareScope); return Result.success(record); } catch (Exception e) { return Result.error(查重失败: e.getMessage()); } } }文件大小限制是必须的。如果不限制有人传 500MB 的 PDF 进来PDFBox 直接把它读进 JVM 内存Tomcat 默认最大上传也就 2MB但你要是改大了限制却没设上限内存溢出的问题迟早来找你。20MB 是一个比较合理的阈值论文正常都在 5MB 以内。5.2 比对库的持久化存储与查重主流程查重系统必须有个“文献库”或者“已提交论文库”——新上传的论文要和历史记录比对否则只能做两两比对没法产生“这篇论文的重复率”这个结论。在课设场景里常见做法是把所有已提交并解析成功的论文记录作为比对库新论文和库里的每一条都要比一次。Service public class PaperServiceImpl implements PaperService { Autowired private PaperRecordMapper recordMapper; Override public PaperRecord processCheck(MultipartFile file, String compareScope) throws Exception { // 1. 解析文件 String ext getExtension(file.getOriginalFilename()); String text TextExtractor.extractText(file, ext); if (text.trim().length() 50) { throw new Exception(文档解析后内容少于 50 字可能不是可解析的文本型 PDF); } // 2. 保存待查记录 PaperRecord newRecord new PaperRecord(); newRecord.setFileName(file.getOriginalFilename()); newRecord.setFileType(ext); newRecord.setTextContent(text); newRecord.setWordCount(text.length()); newRecord.setStatus(0); recordMapper.insert(newRecord); // 3. 取出比对库中的所有已完成记录 QueryWrapperPaperRecord wrapper new QueryWrapper(); wrapper.eq(status, 1); wrapper.select(id, file_name, text_content); ListPaperRecord library recordMapper.selectList(wrapper); // 4. 分段查重取最高重复率 double maxSimilarity 0.0; String maxMatchedPaper 无; ListMapString, Object details new ArrayList(); for (PaperRecord libRecord : library) { double score TextSimilarity.compareThesis(text, libRecord.getTextContent()); if (score maxSimilarity) { maxSimilarity score; maxMatchedPaper libRecord.getFileName(); } MapString, Object item new HashMap(); item.put(targetFile, libRecord.getFileName()); item.put(similarity, String.format(%.2f, score)); details.add(item); } // 5. 更新状态和结果 newRecord.setSimilarity(maxSimilarity); newRecord.setStatus(1); MapString, Object detailMap new HashMap(); detailMap.put(maxMatchedPaper, maxMatchedPaper); detailMap.put(items, details); newRecord.setDetailJson(JSON.toJSONString(detailMap)); recordMapper.updateById(newRecord); return newRecord; } }这段代码里的 TextSimilarity.compareThesis 是核心。它的逻辑是把待查文本按空行或标题切成段落对每一段在比对文中找同长度窗口的相似度最后把高于 0.3 的段落相似度按段落长度加权得到整篇的重复率。代码量不大但容易出错我在下一章把避坑点集中展开。注意步骤顺序先插入新记录再比对是因为查重过程中如果新文件和库里的某条完全一样你还能保留上传痕迹否则一条失败记录都没有用户不知道发生了什么。6. 遇到这 5 个问题别慌都是查重系统的“经典翻车现场”做这个系统的人十个里有九个会踩到下面这些坑。不是技术难度有多大而是没人提前告诉你该注意什么一旦报错排查时间往往比写代码还久。6.1 中文 PDF 在 Linux 服务器上提取出空白现象本地 Windows 上跑得好好的部署到服务器后同一份 PDF 解析出来全是空格或乱码。 原因PDFBox 提取文字依赖系统字体映射服务器没有安装中文字体包字符映射失败。 解决在服务器安装 fonts-wqy-microhei 或 msttcorefonts。CentOS 上执行 yum install -y fontconfig 后把 Windows 的 simsun.ttc 复制到 /usr/share/fonts/chinese/ 重启 Java 进程。这个坑在第一次部署时几乎必踩提前在服务器上验证一次解析最稳妥。6.2 POI 解析 docx 报别名为 ooxml 的异常现象解析某些 docx 文件时抛出 ClassNotFound 或 NoClassDefFound 的异常中间带 poi-ooxml 字样。 原因POI 的老版本和 poi-ooxml-schemas 版本不匹配或者 docx 文件内部引用了老版本的 XML 命名空间。 解决把 poi 和 poi-ooxml 锁定到完全相同的版本不要一个 5.2.5 一个 4.1.2。如果版本一致仍报错用 SXSSFWorkbook 的方式先另存一份再做解析本质是规避不规范 docx 中的异常标记。6.3 上传大文件时前端报 413现象文件超过 10MB 后Ajax 请求直接返回 413 Request Entity Too Large。 原因Spring Boot 的 spring.servlet.multipart.max-file-size 默认只有 1MB超出后不同版本 Tomcat 的处理表现不同。 解决在 application.yml 中配置spring: servlet: multipart: max-file-size: 20MB max-request-size: 25MB注意 max-request-size 要比 max-file-size 大一些因为上传请求除了文件本身还有表单字段。6.4 两篇完全不同的论文相似度高达 40%现象拿两篇不同方向的论文测重复率显示接近 40%明显不合理。 原因停用词表太小“研究”“基于”“方法”“实验”“结论”这些高频学术词没有被过滤分词语义被通用学术词汇主导。 解决扩充停用词表把论文领域的通用高频词加进去至少达到 200 个词以上。我常用的做法是拿 5 篇不同方向的论文跑一遍分词统计前 100 个高频词并手动加入过滤表。这个优化一次能让整体相似度平均下降 10 到 15 个百分点。6.5 比对库越大查重越慢单篇论文等了 30 秒现象库里存了 500 篇论文后每查一篇新论文耗时线性增长用户体验极差。 原因代码是嵌套循环每篇新论文要和 500 条记录全文两两计算余弦相似度每组 3 万字文本处理时间约 50ms串行计算就是 25 秒起步。 解决入库时预计算每篇论文的词频向量MapString, Integer以 JSON 格式存到表里。查重时读取的是预计算好的向量而不是重新分词。向量比对消耗远小于分词和文本清洗耗时能压到原来的五分之一以下。这是查重系统设计里最重要的优化点答辩时主动说出来会加印象分。7. 进阶优化SimHash 大文本去重与查重阈值调整技巧基础版能跑通之后你可能会遇到另一个问题对比库扩大到几千篇时不管怎么优化分词计算量还是太大。这时候就该上 SimHash 了。SimHash 的思路是把文本压缩成一个 64 位指纹两篇论文的指纹汉明距离小于等于 3 时判断为重复。它的优势在于比对复杂度是 O(1) 的——只需要做一次异或运算而余弦相似度每对文档都需要遍历词频表。具体做法把分词后的每个词映射成一个 64 位哈希按词频加权累加得到 64 个浮点数正数置 1 负数置 0得到一个二进制串。这样一篇 3 万字的论文预处理一次后后续的每一次比对都只做 64 位整数的异或。但 SimHash 对短文本不敏感——低于 500 字的段落几乎无法用汉明距离判断相似度。所以我的建议是混合策略先用 SimHash 做粗筛汉明距离在 3 以内的候选再用余弦相似度精确计算。查重阈值的调整也要说一句。不要固定用一个阈值要看你的比对库质量。比对库里的论文原本就高度相似比如大家抄了同一个模板阈值可以调高到 0.35 再判定重复比对库文本差异大就调到 0.25。我一般在测试阶段跑 20 组已知相似和已知不相似的文档画出相似度分布图取分布曲线的谷底作为阈值这比拍脑袋定 0.3 靠谱得多。最后是我做这套系统时最深刻的教训永远不要在解析失败时直接删掉原始文件。我在开发时遇到一份被密码保护的 docx程序抛异常后我把上传文件清空了结果答辩前需要演示却找不到原文件。后来所有流程都改成软状态管理——上传文件先落盘保存解析成功的才做后续失败的保留文件只更新状态字段。这样做还有一个好处你可以随时拿“失败”文件重新测试解析逻辑排查问题不再需要重新找样本。希望这篇笔记能帮你把查重系统一次跑通。本文还有配套的精品资源点击获取