简介：SIMGUI是一款面向C++与Python开发者的代码查重工具，基于Electron与Element UI构建，内置SIM相似性检测算法，免安装解压后即可运行。它适合教学、学术研究、团队协作及代码质量管理场景，能有效识别结构或语法相似的重复代码，帮助规避抄袭纠纷并促进代码重构。压缩包共87个文件，涵盖exe主程序、dll动态库、pak多语言界面资源、png操作示意图、asar应用内核等，压缩包整体约69.94MB，免安装设计让部署更便捷。目前已有529人学习下载。借助直观的图形界面，用户无需了解算法底层实现，即可导入C++或Python代码，调整检测灵敏度、忽略大小写、空格与注释等参数，一键执行查重并对比可视化结果，还可导出报告存档；软件跨Windows、macOS与Linux平台，配合包内图示说明，能显著降低上手门槛，提升代码质量与开发规范性。
1. 代码查重不该靠肉眼：SIMGUI 免安装版到底解决了什么
交作业高峰期的深夜，我见过有人把两份 C++ 代码粘进 Excel，用逐字对比功能删空格比差异——那画面是真心酸。SIMGUI 免安装版把 Dick Grune 那套 SIM 查重内核封装成图形界面，解压双击就能跑，专门解决 C++ 和 Python 代码的相似度度量问题。它输出的不是“看起来像不像”的主观判断，而是两个文件之间的相似度百分比和匹配片段位置，课程作业抽查、团队代码复审、仓库重复代码排查都能直接拿它当第一道筛子。不需要配编译器，不要求代码能编译，只要手里有源代码文本，它就能比。下面这套操作方法和踩坑记录，都是我实际用它处理过几十批代码之后沉淀下来的。
2. SIM 的查重原理与免安装版的能力边界
2.1 从 token 流到 Karp-Rabin 指纹：SIM 为什么不是“逐行比对”
先把一个关键概念讲透：SIM 不是拿两段代码逐行比较的。逐行去重是 git diff 这类工具做的事情，它解决不了“换个变量名、调换函数顺序”这种抄袭。SIM 的做法是把源代码拆成 token，也就是把int a = 10;拆成int、a、=、10、;这样的最小语法单元。然后它对这个 token 序列做 Karp-Rabin 滚动哈希，用哈希值去匹配两个文件里的相同连续片段。匹配到的片段越长，说明两者在结构上越接近。
Karp-Rabin 是这套方案的核心。它不像 KMP 那样逐字符比较，而是先算出一个窗口的哈希值，再滑动窗口时复用前一个哈希的中间结果，把每个窗口的哈希计算成本压到 O(1)。SIM 在 token 流上用它找“最长公共子串”，找到一处相同片段之后，把两个文件按这段切分开，再递归地往剩余区域里继续找。于是，就算别人把两个函数的位置互换、把一段逻辑从函数 A 挪到函数 B，只要 token 序列是连续的，SIM 都能把它们捞出来。这是它跟 diff 工具最本质的差异。
变量重命名的处理，是 SIM 设计里最容易被低估的一点。C++ 的标识符名称和 Python 的变量名、函数名，在进入 token 流之后会被归并成同一类标识符 token，不再区分temperature和tempValue。关键字和运算符号则原样保留，因为它们是代码结构的骨架：for、while、if、return、{、}、+、*这些 token 一个都不会丢。注释和空行在 token 化之后基本退场，所以“删光注释、多打换行”这种处理手法对结果的改变非常有限。
Python 代码在 SIM 里的落点不一样。SIM 没有单独的 Python 前端，常见用法是走sim_text这个通用文本比较模式。它同样做 token 化，但面对的是没有显式类型声明、靠缩进表达块结构的 Python 代码，对语法的敏感度跟 C++ 不完全是一个量级。这就导出两个实操结论：第一，Python 查重不能照搬 C++ 的参数，必须单独标定；第二，sim_text模式把 Python 的装饰器、列表推导、f-string 处理得更碎，长匹配片段被稀释，相似度数字天然比 C++ 偏低。
顺带提一句边界：SIM 不识别代码语义，只认 token 结构。两份完全重写成不同思路、不同算法、不同数据结构的代码，在 SIM 眼里可能只有很低的相似度——这其实是正确行为，因为它本来就不是 AI，不负责“神似”层面的判断。
在选型上，用过 SIM 之后你会明白它为什么能在代码查重这个方向存续这么多年。它不做判决，只做筛选：用极低的本地计算成本把“结构上高度相似”的文件对捞出来，再交给人工判断。相比那些要把代码上传到云端、依赖机器学习模型的查重服务，SIM 在本地跑、代码不出网、不注册账号，这一条在很多学校和公司里是硬性要求。免安装版更是把这个优势放大到极致：没有安装向导、没有服务驻留、不写注册表，跑完删目录就行。代价是界面朴素、参数需要自己学，但属于能接受的旧工具通病。
2.2 免安装版的真实边界：支持语言、文件规模与运行环境
免安装版一般是一个压缩包，解压后的目录里能找到一个 GUI 可执行文件和一组命令行工具。典型结构大概是这样的：
| 文件 | 作用 |
|---|---|
sim_c++ | C/C++ 源码查重后端 |
sim_text | 通用文本比较后端（Python 等语言走这里） |
simgui | 图形界面入口 |
README.txt | 参数说明与简单的使用说明 |
解压顺序有个容易踩的细节：先看目录里有没有 README，不要直接双击 GUI。不同的人打好的包放的路径不一样，有的把sim_c++放在子目录里，有的在根目录；先把目录结构扫一眼，后边排查问题能快很多。我手上这个免安装包的 README 只有几行，但把-p和-s的含义写清楚了，这就是最关键的线索。
边界第一条是语言。SIM 的官方语言前端覆盖 C、C++、Java、Pascal、Modula-2 和文本，Python 不在其中。所以任何“SIM 查 Python”的方案，本质都是sim_text在做通用文本比较。C++ 查重应该用sim_c++，Python 查重用sim_text，选错后端得到的数字没有参考价值。如果你需要的是语法感知的 Python 专属查重，SIM 这一整套工具都不是最优解，建议去看别的方案。
边界第二条是文件规模。SIM 做的是两两比较，输入 N 个文件要跑 N×(N-1)/2 次比较。几十个文件在命令行下几乎是秒出，两百个文件开始能感到延迟，上千个文件建议直接分批跑。免安装版不会因为你文件多就崩溃，但等在上面的时间会越来越不划算。我的习惯是超过 200 个文件就按目录或按提交批次拆组，避免单次任务过大。
边界第三条是运行环境。Windows 上免安装版最常挂在 Microsoft Visual C++ Redistributable 上：如果机器里没有对应版本的 VC++ 运行库，双击 GUI 可能一闪就退，或者直接提示缺少msvcp140.dll。这跟工具本身没关系，先去把 VC++ 运行库装上再回来跑。Linux 或 macOS 上如果包里带的是 Linux 后端，可以直接跑命令行；如果包里只有 Windows 可执行文件，就只能换 Windows 环境。
还有一条很多人会忽略：免安装不等于可以把单个 exe 拷走。免安装版里的 GUI 和命令行后端之间有相对路径约定，配置文件、语言支持文件可能都放在同目录，单独拷一个simgui.exe到别的机器上，经常报缺文件。要迁移就整个目录打包带走，别只带主程序。
最后补一个规范上的建议：正式查重前确认你要比较的文件没有符号链接指向同一个物理文件。SIM 不会识别链接去重，两个路径指向同一个文件时，相似度直接 100%，纯属无效对。用ls -l或者readlink扫一遍待比较列表，能省掉不少困惑。
3. C++ 与 Python 查重完整操作：从命令行到 GUI
3.1 跑通 C++ 查重的最小命令：sim_c++ 参数逐个拆
免安装版最靠谱的用法，是先用命令行把后端跑通，再回去看 GUI。命令行模式出错容易定位，参数也可控。假设解压目录是F:\simgui，里面有两个 C++ 文件lab1_a.cpp和lab1_b.cpp，最小查重命令是这样：
cd /d F:\simgui sim_c++ -p5 -s20 lab1_a.cpp lab1_b.cpp这里-p5是最小匹配块大小，单位是 token。两个文件里长度少于 5 个 token 的相同片段不参与统计，这能避免把int i;这种三五个 token 的公共片段算成相似证据。-s20是报告阈值，相似度低于 20% 的文件对不会出现在结果里。终端里会输出一行类似lab1_a.cpp vs lab1_b.cpp: 57.3%的结果，这就是两个文件的相似度。
先解释这两个参数的选择逻辑。做 C++ 查重，-p取 5 到 8 之间比较合理。设成 3 会把a + b、x++这类极短公共表达式计入结果，误报率一下子就上去了；设成 20 会漏掉长度不到 20 个 token 的真实抄袭片段，只适合排查整段复制的场景。-s我一般先设 20，这只是起报线，不代表到 20% 以上就都该定罪。
命令跑完后，默认情况下只在终端输出相似度百分比。要看匹配片段在文件里的具体位置，常见做法是切换到 GUI 的详细视图；有些版本支持直接输出详细报告，参数名在 README 里能查到。如果包里的版本确实不带详细报告参数，那就老老实实把 GUI 当作查看匹配位置的入口，别在命令行上硬磕。
C++ 查重有一个绕不开的干扰项：头文件。当你把几十个.cpp和.h一起丢进去时，公共头文件里那堆声明和宏定义会拉高所有文件对的相似度基线。我在实际处理时会把.h先移出待比较集合，或者单独建一个目录放公共头文件，避免它们把结果洗成一片虚高。这个习惯能省掉后面大量复核时间。
如果你平时已经习惯在 VSCode 里配 C/C++ 环境，那对这个命令的路径感不会陌生——就是把编译命令换成查重命令，核心都是先确保可执行文件在当前搜索路径里。跑不通的时候，优先检查是不是sim_c++根本没有被解压到当前目录。
注意：Windows CMD 下可执行文件通常要写成
sim_c++.exe；如果提示“不是内部或外部命令”，先检查当前目录和路径名里的反斜杠。
3.2 Python 查重用 sim_text：语言选项与参数差异
Python 文件没有专门的sim_python，所以命令行换成sim_text。假设两个文件是task1_a.py和task1_b.py：
cd /d F:\simgui sim_text -p5 -s20 task1_a.py task1_b.py-p和-s的语义跟 C++ 一致，但sim_text的 token 化规则差别不小。Python 的def、class、import会被保留为结构 token，变量名一样被归并，但缩进不是 token，换行和冒号会切割语句边界。同样代码量下，sim_text给出的相似度经常比sim_c++略低——这不是代码真的不相似，而是 Python 的语法结构在 text 模式下被拆得更碎，长匹配片段的占比被稀释了。
所以 Python 查重我一般把-p降到 4 甚至 3，让被拆散的短匹配片段重新参与统计。代价是import os、from math import sqrt这种公共 import 也会被算作相似证据，于是-s要相应抬高，我常用-s30起手。-p4 -s30是我处理 Python 代码的默认组合，如果你的仓库公共代码特别多，再做上下微调。
sim_text支持一次列多个文件，全部两两比较：
cd /d F:\simgui sim_text -p4 -s30 *.pyWindows CMD 里*.py会被展开成文件列表，PowerShell 里行为差一点，建议先把路径展开确认一下。文件多的时候，我的做法是把文件列表写进一个文本文件，再由脚本循环喂给后端，后面第 5 章会展开。
两个常用参数在不同语言下的推荐值可以先用这张表起步，再按自己仓库的实际情况改：
| 参数 | 作用 | C++ 常用 | Python 常用 |
|---|---|---|---|
-p | 最小匹配块大小（token） | 5 – 8 | 3 – 5 |
-s | 输出阈值（百分比分子） | 20 – 30 | 25 – 35 |
这里的 Python 推荐值只适用于走sim_text的模式，因为它本质上不是语法感知的 Python 查重器。如果你的仓库里 Python 代码普遍带有大量类型注解或装饰器，sim_text会把它们拆得更碎，-p3都不一定够，需要跑一个小样看分布再做决定。
3.3 GUI 模式操作：目录选择、语言切换与结果导出
命令行跑通后，GUI 的价值是让你快速定位“谁跟谁异常相似”。免安装版 GUI 的常见布局是：左侧一个文件列表或目录树，右侧是相似度报告区域，顶部有语言选择和后端切换控件。流程一般是先选语言类型，再把文件拖进列表，或者选一个目录让 GUI 扫描。扫描范围建议用后缀限定，别让 GUI 把目录里的资源文本、日志文件一起卷进比较。
语言切换这一步最容易出错。某些 GUI 的“Python”选项其实就是“纯文本”模式，它不会对 Python 语法做任何额外处理。选完语言之后，留意 GUI 状态栏或日志窗口，确认它实际调用的后端是sim_text。如果它永远只调sim_text而界面里又写了“Python”，你最好知道这一点，别对结果做超出工具能力的解读。
结果导出方面，GUI 通常能把报告存成 HTML 或 CSV。导出格式具体是哪种、存到哪个目录，不同的免安装版实现不一样，但有两个标准你可以自己检验：第一，报告里是否带匹配片段的起始位置；第二，报告里是否记录了这次跑批使用的-p和-s参数。两个都满足，这份报告才能留档复用。
GUI 还有一个命令行没有的优势：两两比较的相似度矩阵可视化。几十个文件跑完后，报告区按相似度降序排列，超过阈值的文件对会被高亮或标色。颜色阈值一般在界面设置里可调，我的习惯是 30% 起黄、50% 起红，再按项目实际情况改。
4. 相似度判定与常见踩坑：百分比不是唯一标准
4.1 误报的三种形态：模板代码、公共库、作业框架
现象：两份没有任何抄袭关系的代码，SIM 给出 45% 的相似度，看着非常吓人。原因大概率落在下面三种情况里。
第一种是模板代码。课程作业最常见，老师给了 main 函数骨架、类定义框架、输入输出样例的固定写法，所有人都在同一份模板上改。模板代码 token 化之后不会被特殊豁免，会全部算进相似度分子。如果模板占代码总量 40%，哪怕实现部分完全不同，结果也会停在 40% 上下。拿这种数字定性抄袭，必然出冤案。解决手法是先把模板文件单独移出待比较集合，或者把模板当作基准和所有学生代码各查一遍，量出“模板本身的相似度基线”。
第二种是公共库和公共工具文件。两组代码各自引用同一个库或同一套公共头文件，高频出现的类名、函数名组合在 token 流里形成大量匹配片段，把相似度顶上去了。解决手法是先做减法：把公共库引用、公共工具模块、模板文件从待比较集合里排除，只保留学生或团队成员自己写的核心文件；或者单独拿模板文件互相查一遍，量出“模板本身就有的相似度基线”，在最后的结果里减去这条基线。
第三种是作业框架导致的结构性相似。题目规定实现一个冒泡排序、一个链表、一个 HTTP 客户端时，任何正确实现都必须写循环、必须写节点结构、必须处理边界条件，结构骨架天然重合。这种情况下不要盯着百分比看，要看匹配片段落在哪里：如果高相似度全部集中在“任何正确答案都不得不写”的骨架部分，而核心算法逻辑没有明显重合，应该判为不构成抄袭。把匹配片段的位置信息打开，是这一步最重要的操作。
4.2 免安装版闪退与乱码：VC++ 运行库和编码的坑
现象：双击免安装版 GUI，屏幕一闪就退，或者弹出0xc0000005访问冲突。原因大多数时候是机器缺少 Microsoft Visual C++ Redistributable 运行库。免安装版只是不需要运行安装向导，但它编译时可能静态链或动态链接了 VC 运行库，目标机器缺了msvcp140.dll、vcruntime140.dll就会崩。解决方法是装上对应版本的 VC++ 运行库再跑。注意补的是运行库，不是整个 Visual Studio。
现象：结果报告里中文注释和字符串显示成乱码。原因多半是源码编码不统一：Windows 上 C++ 源码常见 GBK/GB2312，而 SIM 工具默认按 UTF-8 或单字节解释。乱码不影响标识符比较的准确性，但会让匹配片段的可读性彻底消失。解决方法是先统一编码，把 GBK 源码用iconv批量转成 UTF-8 再放进查重集合：
iconv -f GBK -t UTF-8 lab1_a.cpp > lab1_a_utf8.cppPython 文件大部分情况下是 UTF-8，但老的 Python 2 脚本可能是 GBK，同样建议先转码再查。混编情况是最恶心的：同一份文件里一部分注释是 UTF-8、一部分是 GBK，SIM 在 token 化时会把多字节字符拆成不一致的 token，导致两份实际相同的文件得到不一样的结果。这种问题从结果上很难察觉，只能靠转码来预防。
提示：转码会生成新文件，别覆盖原文件，保留原始样本以便复现结果。
4.3 变量改名与代码重排：SIM 为什么仍然能抓到
现象：学生把变量名全改了、函数顺序打乱了，相似度依然高达 90%。这不是 SIM 出错，是它的标识符归并机制在起作用。sim_c++在 token 化时把fooBar归并成和bazQux同一类标识符 token，两个文件如果只有名字不同，token 流几乎完全一致，查重结果自然逼近 100%。
代码重排能逃掉一部分，但逃不掉全部。SIM 用最长公共子串把函数块全部捞出来，再递归匹配残余部分。如果两个文件包含同样一组函数、只是顺序不同，SIM 依然会把所有函数块逐个配对，得到很高的整体相似度。真正能有效规避 SIM 的操作是打散结构：拆函数、改逻辑、插干扰代码，这些成本已经远高于重写，不属于普通抄袭的范畴。
反过来讲，这个特性提醒我们一个误区：SIM 相似度高不等于“抄了”，更不等于“没抄”。它只能告诉你“两份代码的 token 结构几乎一致”。结构一致可能是抄，也可能是题目约束下的必然。把 SIM 当线索工具看待，不拿单一百分比做判决，是使用这套工具的人必须建立的意识。
4.4 阈值设多少才不算误杀：-s 与 -p 的配合
阈值没有黄金标准，但有两个经验值可以起步。对于实现方式比较开放的作业或项目，-s用 30 作为低风险线、50 作为高风险线；对于算法题这类实现高度同质的场景，基线相似度可能本身就站在 30% 以上，这时要先测模板基线，再在基线上加 20 个百分点作为警告线。
-p对结果的影响经常被忽视。同一组文件，我把-p3调到-p8，相似度从 61% 掉到 40%。原因很简单：短匹配片段被排除后，能拼进相似度分子的内容变少了。所以调参时不能只动-s，-p才是控制“什么叫匹配”的开关。低-p配高-s是宽松过滤，适合初筛；高-p配低-s是精准打击，适合复核。
我建议每接一个新的查重任务，先做一个标定小实验：准备 5 到 10 份你确定没有抄袭关系的独立实现，跑一遍批量查重，记录它们两两之间的最大相似度，把这个值往上加 10 个百分点，当作当前的-s值。这个方法比抄任何推荐参数都可靠，因为不同课程、不同团队、不同代码规范下的公共底数是完全不一样的。
5. 批处理查重与人工复核：把 SIMGUI 用成日常工具
5.1 批处理脚本：一次查完整个仓库的相似度
GUI 适合看单个项目，上百个文件还得靠命令行批量。我一般写一个脚本来跑全仓库，把全量结果和高阈值结果分开存，方便后面复核：
#!/bin/bash # 全量比较所有 .py 文件，-s0 表示不设过滤，全部输出 ./sim_text -p4 -s0 *.py > result_all.txt # 高阈值过滤，只保留相似度超过 30% 的文件对 ./sim_text -p4 -s30 *.py > result_high.txt先看全量分布，再盯高阈值配对，人工复核才不会被一两百行输出淹没。Windows 上把后缀改成.bat就能跑，路径含空格时记得用cd /d加引号。如果你手头刚好有一批 Python 爬虫脚本或量化策略代码要检查重复度，这个脚本可以直接套用，只要把*.py的路径指向对应目录。
5.2 人工复核三步法
拿到报告别急着按百分比排序下结论。我走三步：第一步，把模板和公共库文件移出集合重跑一遍，排除基线干扰；第二步，对剩余高相似度文件对，进 GUI 看匹配片段位置，确认重合部分是不是集中在不可避开的公共结构上；第三步，把匹配片段和参数信息一起导出存档，按“疑似 / 需面谈 / 无问题”分档，再做后续处理。我自己的习惯是把报告文件名写成check_20250122_cpp_p8_s30.html，把-p和-s写进文件名。查重最怕调完参数不记录，等别人质疑结果时没法复现。参数是查重报告的一部分，它跟相似度数字同样重要。把 SIMGUI 接进日常代码评审流程后，我一般是提交代码后先批量跑一遍，把高相似度文件对丢给人工审查，SIMGUI 负责缩小范围，人工负责判断。查重不替代评审，它只是在帮评审省时间。希望这几条参数经验和踩坑记录能帮到你。
本文还有配套的精品资源，点击获取
