★ FEATURED ARTICLE 简介JD-GUI 1.4官方MAC版本是面向苹果Mac用户的Java反编译工具专为开发者、逆向工程师及Java学习者设计。它通过图形界面直接展示.class字节码对应的源码在软件逆向、程序调试和源码分析等场景中非常实用。压缩包共14个文件大小约7.53MB以jar程序库、sh启动脚本、plist配置、icns图标及app应用包等类型为主解压后可运行JD-GUI.app。已有1035人学习下载。工具支持拖拽加载类和搜索函数变量能快速定位代码逻辑但需注意反编译结果可能因编译器优化或混淆而损失细节。总体而言这款工具可帮助你深入理解Java类结构、方法调用和内部实现即使原始源码缺失也能高效开展阅读与分析工作。1. JD-GUI 1.4 官方 MAC 版本为什么到现在还有人找它很多 Mac 用户第一次接触 JD-GUI 是从某个网盘里下到的“绿色版”解压后不是提示已损坏就是启动后卡在启动画面。折腾半天最后意识到要找 JD-GUI 1.4 官方 MAC 版本——不是第三方重新打包的东西而是原版发布里能直接在 macOS 上跑的那一份。JD-GUI 是 Java 反编译器里历史最久的桌面工具之一1.4 这个版本虽然没有后来 1.6.x 的新特性但胜在轻量、启动快、源码导出干净至今仍被许多运维和客户端开发拿来快速分析线上 JAR 包。这篇笔记面向需要在 Mac 上做 JAR 反编译、看第三方库实现、或者排查包内类冲突的从业者从环境准备到踩坑给你一条能直接照做的路径。2. 把 JD-GUI 1.4 在 Mac 上跑起来Java 环境、启动命令与 Gatekeeper2.1 先确认你拿到的是官方 MAC 版本而不是第三方打包JD-GUI 的官方发布形态通常是一个压缩包里面既有一个可执行的 JAR也有打包好的 macOS 应用目录。很多人下载到的“MAC版本”其实是别人改了图标、加了脚本或者塞了捆绑软件的重新打包版这类东西在 macOS 上最容易触发 Gatekeeper 拦截或者运行时行为异常。判断是否官方先看压缩包内文件结构官方包解压后会出现一个以jd-gui或JD-GUI命名的.app目录同时还有原版jd-gui-1.4.0.jar注意版本号与名称要一致。第三方打包通常只有一个 App或者缺 jar。提示如果包内只有一个伪装成 App 的可执行文件且没有.jar兜底建议直接放弃改用官网或 Maven 中央仓库里的jd-gui-1.4.0.jar。接下来在终端里验证一下文件完整性和架构。macOS 上可以这样看cd ~/Downloads lipo -info JD-GUI.app/Contents/MacOS/UniversalJavaStub 2/dev/null || file JD-GUI.app/Contents/MacOS/*这个命令的作用lipo -info查看二进制支持的 CPU 架构能输出x86_64或arm64。JD-GUI 1.4 时代还没有适配 Apple Silicon官方 MAC 版本基本是x86_64在 M 系列 Mac 上需要 Rosetta 转译。如果你的包里出现了arm64大概率不是原版而是别人用新 JDK 重新打包的。file命令是兜底在lipo不可用时查看文件类型。这一步不复杂但能帮你避开网上发布的大多数“魔改 MAC 版”。2.2 用 Homebrew 准备好 Java 8 运行环境JD-GUI 1.4 官方版本是 2014 年左右的软件编译目标停留在 Java 8。虽然用新版 JDK 偶尔也能跑但会遇到模块化系统拒绝访问内部 API 的问题最常见的就是启动时报UnsupportedClassVersionError或者ClassNotFoundException。稳妥做法是在系统里装一个独立于默认 JDK 的 Java 8只给 JD-GUI 用。常见做法是用 Homebrew 安装 OpenJDK 8brew install --cask temurin8然后确认安装路径和版本/usr/libexec/java_home -Vjava_home -V会列出机器上所有已安装的 JDK每个版本对应一个路径。记下 Temurin 8 的路径比如/Library/Java/JavaVirtualMachines/temurin-8.jdk/Contents/Home后面启动脚本要用。不要直接改全局JAVA_HOME否则影响你其他 Java 项目。如果你只想临时让 JD-GUI 1.4 用 Java 8在终端里这样设变量并启动即可。2.3 三种启动方式app、jar、双击没有反应时的兜底第一种是直接双击.app。官方包拖到「应用程序」后第一次运行会遇到 Gatekeeper 的“已损坏”或“无法验证开发者”警告原因是原版发布没有重新签名。处理方式不是关闭 SIP而是右键点 App 图标选「打开」在弹窗里确认一次。这个操作只对当前 App 生效比sudo spctl --master-disable安全得多。第二种是跑 JAR。在终端里用绝对路径指定 Java 8export JAVA_HOME/usr/libexec/java_home -v 1.8 $JAVA_HOME/bin/java -jar ~/Downloads/jd-gui-1.4.0.jar这里-jar会忽略CLASSPATH直接以 JAR 内META-INF/MANIFEST.MF里声明的 Main-Class 作为入口。JD-GUI 1.4 的默认堆内存比较小反编译大包时容易卡建议启动时加大堆空间$JAVA_HOME/bin/java -Xms256m -Xmx2g -jar ~/Downloads/jd-gui-1.4.0.jar-Xms256m是初始堆大小-Xmx2g是最大堆。如果你只想查看、不导出大工程512m够用要同时展开多个 JAR2g起步。第三种是双击 App 没反应时不双击改用命令行直接调起open -a JD-GUI --args -J-Xmx2gopen -a会交给 Launch Services 启动应用--args后的参数会透传给 JVM。这里是给 JVM 指定最大堆。如果这样还是闪退不要继续猜直接到控制台看崩溃日志log show --last 5m --predicate process JD-GUI | grep -i exceptionlog show是 macOS 统一日志查询--last 5m只看最近五分钟--predicate过滤进程名。能看到具体的异常栈问题多半出在 JDK 版本不匹配或缺少某个.jnilib本地库上。看到栈里提到AWT或Cocoa相关错误时优先换回 Temurin 8因为 JD-GUI 1.4 的 Swing 渲染和 macOS 原生画面的适配只在这个版本上最稳定。3. 反编译一个真实 JAR打开、定位、导出全部源码3.1 从 JAR 到类先看 JD-GUI 1.4 的内部逻辑JD-GUI 1.4 的核心是一个 Java 反编译引擎它读取 JAR 里的.class字节码通过常量池、方法表、异常表和局部变量表反向还原出 Java 源代码。它不是文本解密而是语法树的逆向重建所以还原出来的代码不是原始作者写的样式而是等价逻辑。这一点先想清楚后面看导出结果就不会觉得是工具坏了。启动 JD-GUI 1.4 后直接把 JAR 文件拖进窗口或者用File - Open File选择。界面左边是包结构右边是反编译后的源码。JD-GUI 1.4 打开 JAR 时会自动解析META-INF/MANIFEST.MF把主类标出来但不会像 IDE 那样帮你建好工程。它适合做“我要看某个类里面到底写没写日志”这类精确判断不适合做全量代码审查。打开一个类后先看右侧上方的下拉框这里可以切换Source、Bytecode和AST视图。Source是反编译结果Bytecode是 class 文件里的实际字节码AST是语法树。遇到反编译结果明显有问题时切到Bytecode对比一下字节码里的字符串常量能判断是工具还原问题还是代码本来就被混淆了。混淆过的类字段名和方法名会变成a、b、cJD-GUI 1.4 对这类代码还原率不高但字符串常量往往保留照样可以搜到关键信息。反编译引擎对 Java 8 之前的语法支持最完整。如果你手里的 JAR 是用 Java 11 编译的里面含有invokedynamic指令和 nest 伙伴类JD-GUI 1.4 解析时可能会把 lambda 还原成内部类调用的形态或者直接报错。这时候看字节码视图比看源码视图更有参考价值。字节码里的invokevirtual、invokestatic能看出真正调用了哪些方法配合栈上的ldc常量反而更容易还原意图。3.2 导出全部源码与资源保存一个可编译的工程JD-GUI 1.4 支持把当前打开的所有 JAR 一次性导出成源码工程。菜单File - Save All Sources会弹出一个对话框让你选择保存目录。它做的事是把每个类按包路径生成.java文件同时把 JAR 里非.class的资源文件比如.xml、.properties、.png复制到对应目录。注意JD-GUI 1.4 的资源复制是“按包结构平铺”不会自动处理META-INF/services中的 SPI 配置所以导出后你用 IDE 打开工程时可能会发现jar包能跑工程却编译不过。想导出可编译工程我一般不打钩默认选项而是手动做三件事。第一步先导出源码# JD-GUI 没有公开的 CLI 导出参数这一步必须在 GUI 里完成 # 但你可以用 jd-cli 做同样的事下面按 jd-cli 举例 brew install jd-cli jd-cli -i ./service.jar -o ./service-srcjd-cli是 JD-GUI 项目下的命令行工具-i指定输入 JAR-o指定输出目录。它能做到 GUI 里 “Save All Sources” 同样的事但不用手动点窗口。导出的目录可以直接用 IntelliJ IDEA 打开。第二步从原 JAR 里单独解压资源mkdir -p service-resources cd service-resources unzip ../service.jar -d . rm -rf ./com ./org思路是先把 JAR 完整展开再删掉反编译过的包路径只留下META-INF、assets和其他资源。unzip -d指定解压目录rm -rf清理与源码重复的字节码目录。第三步把资源目录并入源码工程里这样编译时能识别到 SPI 配置和静态文件。三步做完得到的工程才接近 JAR 本来的面貌。这里要特别留意META-INF。很多框架通过META-INF/spring.factories、META-INF/services/xxx做服务发现JD-GUI 1.4 导出时经常把这些文件漏掉。如果只把.java源码拿去看业务逻辑没问题如果要把工程跑起来必须保留原 JAR 的META-INF和所有非 class 文件。所以“导出源码”和“导出工程”是两个动作不要混淆。3.3 关键字检索与跳转快速定位崩溃点排查线上问题经常不是从头读代码而是直接查某个字符串。JD-GUI 1.4 有字符串搜索但有一个老毛病它只搜已经展开的类。如果一个 JAR 包含几千个类默认不会全部反编译只有你点开过的类才会进入搜索索引。所以在搜索前先把包根目录展开到底或者按CmdShiftR触发全部加载。注意这个操作在十几年前的电脑上会卡很久在 M 系列上也要等几十秒。搜到一个结果后JD-GUI 1.4 支持跳转到类、方法定义。右键任意标识符选Jump to Declaration能定位到当前 JAR 里的定义。如果是跨 JAR 引用则跳不过去因为它不会自动加载依赖 JAR。这时候手动File - Open File按依赖顺序打开先jdk相关类不看把业务 JAR 放第一个依赖库放后面。需要快速看调用关系时CmdB是向后跳CmdShiftB是向前跳比鼠标点按钮快。提示JD-GUI 1.4 的搜到结果列表不支持正则只支持通配符。搜LoggerFactory.*会没有结果搜LoggerFactory就正常。如果你非要正则先把源码导出到本地再用rg搜那是另一套流程。另一个有用的操作是右键类名选择Copy FQCN把类的全限定名复制出来。这个全名在后续用jdeps分析依赖或写日志过滤器时非常有用。JD-GUI 1.4 的剪贴板操作不会带行号所以如果你要引用代码位置还是得手动看右侧状态栏的行号。这与现代 IDE 的体验有差距但足够应付大多数查证工作。4. Mac 上跑 JD-GUI 1.4 的 5 个踩坑记录4.1 双击没反应Dock 一闪就消失现象从 dmg 拖到应用程序双击后 Dock 上图标出现一下随即消失没有错误弹窗。原因JD-GUI 1.4 官方 MAC 版针对 x86_64 构建M 系列 Mac 上依赖 Rosetta另一常见原因是 Java 8 未安装或java命令指向了新版 JDK导致启动脚本找不到运行环境。解决先确认 Rosetta 已装终端执行softwareupdate --install-rosetta或直接运行arch -x86_64 /usr/bin/java -version能通过就说明转译层正常。然后把JAVA_HOME固定到 Temurin 8并改用 2.3 里的命令行方式启动。如果命令行能起来问题就出在.app的启动脚本路径里修复方式是编辑 Info.plist 里的JVMVersion设置为1.8或者干脆以后都用 jar 启动。这个坑之所以高频是因为很多下载站只提供了.app压缩包里面根本没有 jar。一旦.app里的JavaApplicationStub找不到默认 JDK就会出现闪退。所以我的习惯是下载后先解压把 jar 单独复制到固定目录后续一直用命令行启动绕开 Launch Services 这一层。4.2 反编译中文注释变成乱码现象源码里的中文注释显示为???或类似乱码。原因class 文件的注释字符串在常量池中用的是修改过的 UTF-8modified UTF-8JD-GUI 1.4 读取时默认按平台编码解码。macOS 上默认区域可能不是 UTF-8老版本工具没按文件头解析。解决临时设置环境变量启动JAVA_TOOL_OPTIONS-Dfile.encodingUTF-8 \ $JAVA_HOME/bin/java -jar ~/Downloads/jd-gui-1.4.0.jarJAVA_TOOL_OPTIONS会被 JVM 自动读取等效于在启动命令里加-Dfile.encoding。如果还乱码确认你的 class 文件确实编译成了 UTF-8部分老项目用 GBK 编译那乱码是源码本身编码不是工具问题。此时把系统环境变量LC_ALLzh_CN.UTF-8再试一次JD-GUI 1.4 有时会参照 locale 决定解码方式。还有一种情况是 JAR 包里的注释字符串本来就是 Unicode 转义后的\uXXXX这类内容在旧版本里会原样显示。你可以在 Bytecode 视图里看常量池对应的字符串如果那里显示正常说明是反编译显示层的问题如果那里也乱说明 class 文件在构建时已经做了转码工具无能为力。4.3 源码导出后资源文件缺失现象用File - Save All Sources导出后只看到.java文件JAR 里的META-INF和一堆配置文件不见踪影。原因JD-GUI 1.4 的导出逻辑只处理类文件对非 class 资源是“可选复制”而且遇到同路径下同时存在 .class 和 .properties 时可能只保留前者。网上流传的“导出完整工程”多半是配合 unzip 手工补资源。解决按 3.2 的三步走不要依赖导出对话框。先unzip完整解压原 JAR 保留资源再单独反编译classes目录。注意unzip解压后目录里的.class在编译源码时可删可不删建议留着因为 IDE 编译时会先清理输出目录源文件不受影响。关键点是不要用 JD-GUI 的导出结果当作最终交付物它只负责给你一份可读源码。如果你确实需要从 GUI 里导出单个类的源码可以用File - Save Source保存当前类这种单文件导出是可靠的。批量导出时我一般先搜到关键类逐个保存而不是一次性全量导出。全量导出适合归档不适合临时查证。4.4 高清屏下字体发虚现象Retina 屏上字体模糊尤其左侧包结构树字身像蒙了一层雾。原因JD-GUI 1.4 的依赖使用 JDK 8 的 Swing而 JDK 8 官方在 macOS 上没有完整支持 HiDPI。它不会自动适配 2 倍缩放只按 1 倍分辨率渲染。这不是配置能解决的是 JVM 层面问题。解决换采用较新 JDK 的替代工具如 JD-GUI 1.6.x能原生支持 Retina但标题锁定 1.4。折中方案是把屏幕分辨率临时切为“更多空间”的缩放档字体边缘会锐利一些或者用-Dapple.awt.graphics.UseQuartztrue启用 Quartz 渲染能在部分机型上改善$JAVA_HOME/bin/java -Dapple.awt.graphics.UseQuartztrue \ -Dsun.java2d.opengltrue -jar ~/Downloads/jd-gui-1.4.0.jarsun.java2d.opengl让 2D 渲染走 OpenGL 管线降低模糊感。副作用是某些 Intel 显卡机型上滚动条渲染异常如果出现去掉这个参数。另外在“系统设置 - 显示器”里把缩放改为“默认”也能减轻字体发虚。代价是整个操作界面变大但 JD-GUI 1.4 本身界面元素不多牺牲一点屏幕空间换取可读性是划算的。如果你平时外接 4K 屏建议把缩放调到 1080p 档字体反而比“looks like 1440p”更清晰。4.5 打开大 JAR 后内存溢出现象打开一个几百 MB 的 JARJD-GUI 1.4 在展开类列表时直接卡死控制台报OutOfMemoryError: Java heap space。原因JD-GUI 1.4 会把所有类元数据加载进内存默认堆上限是 256MB看启动命令。一次性展开几千个类会把堆撑爆。解决启动时把-Xmx调到 JAR 体积的 2~4 倍但不是越大越好因为 macOS 的虚拟内存会因此变慢。另外不要一次拖入多个 JAR逐个打开看完一个关闭一个。遇到特别大的包用jd-cli只反编译指定类jd-cli -i ./big.jar -o ./big-src --include com/example/service/.*--include是正则只反编译com/example/service包下的类比 GUI 里全量展开省内存。这个命令的实际效果是控制反编译范围避免一次性处理全部。如果你必须在 GUI 里打开大 JAR建议先把 JAR 拆成模块再用 JD-GUI 分别打开。比如 Spring Boot 的 fat jar先unzip把BOOT-INF/classes和BOOT-INF/lib下的依赖 JAR 分出来业务代码单独看。这样既快又不会因为内存溢出丢失已经做好的代码定位。5. JD-GUI 1.4 的边界替代工具与命令行场景5.1 为什么 CFR/Procyon 能弥补 JD-GUI 的不足JD-GUI 1.4 的还原率对现代 Javalambda、switch 表达式、记录类很差因为它的语法树构建规则停留在 2014 年。如果你要反编译的 JAR 是用 Java 8 以上版本编译的会用上很多更新的字节码指令。JD-GUI 遇到这些指令时要么报解析错误要么把代码还原成非常别扭的 whileswitch。CFR 和 Procyon 是另外两个开源反编译器。它们不是 GUI 工具但可以在命令行直接运行。比如 CFR 是一个独立的 jarjava -jar cfr.jar ./service.jar --outputdir ./service-src参数--outputdir指定输出目录CFR 会按包路径生成文件。Procyon 则需要通过procyon-decompiler启动参数类似。选哪个看场景主要看匿名内部类和 lambda选 CFR需要处理复杂泛型推导选 Procyon。JD-GUI 1.4 在这些场景下基本不占优势它唯一的强项是“图形界面 直观跳转”这套浏览体验。下面是 JD-GUI 1.4、CFR、Procyon 在 Mac 本地使用时的对比对比项JD-GUI 1.4CFRProcyon操作方式GUICLICLI最新语法支持差好较好批量处理手动天然支持天然支持资源文件处理会丢需额外处理需额外处理适合场景临时查类、浏览工程化反编译泛型复杂代码从表格能看出JD-GUI 1.4 的胜场在于快速浏览CFR/Procyon 胜在场外操作。我自己的习惯是先拿 JD-GUI 1.4 打开 JAR 看整体结构遇到关键类还原不理想再用 CFR 单独反编译那个类做交叉验证。两者结合比只依赖任何一个都靠谱。5.2 用 jd-cli 在 Mac 上做批量反编译前面多次提到 jd-cli这里完整说明。jd-cli 是 JD-GUI 同一个作者开发的命令行版语法与 JD-GUI 共享核心引擎所以你从 GUI 里熟悉的结果风格在命令行输出也一样。很多 Mac 用户不知道它的存在装完 JD-GUI 1.4 之后就只靠鼠标点一次处理多个 JAR 就容易烦了。安装 jd-cli如果没有 brew 包可以直接用官方发布 jarbrew install jd-cli然后批量处理当前目录下所有 JARfor jar in *.jar; do jd-cli -i $jar -o ${jar%.jar}-src done循环的意义是每个 JAR 单独输出到以源文件名结尾的目录避免混在一起。${jar%.jar}是 shell 参数扩展去掉.jar后缀。注意 jd-cli 不支持递归反编译外部依赖它只处理你指定的 JAR 内部类。如果涉及多个 JAR 之间的交叉引用输出结果里每个类都是独立解析的不会自动合并成一个工程。jd-cli 还有一个常用参数--skipResources或者不提供时默认情况。具体参数不同版本有差异我一般先跑jd-cli --help确认。不要凭记忆写参数因为 0.9 之前和 1.x 的参数风格不一样。在本机确认过的命令才可靠。批量任务的另一个好处是可以配合find过滤出你要的 JARfind ~/lib -name *.jar -maxdepth 2 | xargs -I{} jd-cli -i {} -o ~/decompiled/find走深度 2xargs把每个路径替换到{}位置输出统一放到~/decompiled/。不过要注意不同 JAR 可能有同名包输出会相互覆盖。所以批量场景我更推荐前面那种每个 JAR 独立目录的循环写法安全且好排查。5.3 和反编译器配套的包管理工具反编译不是终点拿到源码后通常还要做依赖分析。Mac 上做这步常见的是用jar命令和jdeps。JDK 自带jdeps可以直接分析 class 文件的依赖关系jdeps -verbose:class ./service.jar | grep com.example-verbose:class会输出每个类引用了哪些外部类grep过滤出自己关注的包。这比人肉在 JD-GUI 里逐个跳转快得多。另外如果 JAR 被混淆过JD-GUI 1.4 反编译结果里的类名全不可读此时先用jar -tf列出真实类名jar -tf ./service.jar | head -50-tf列出归档内所有条目head只取前 50 行。配合 JD-GUI 里搜字符串能很快定位混淆后的关键逻辑所在类。jdeps的另一个用处是找出某个类依赖了哪些外部包方便在反编译后重建构建配置。例如输出显示com.example.Foo依赖org.slf4j.Logger你就知道要引入 slf4j-api 才能编译。这在分析老系统时很省事比逐个看 import 快。配合jd-gui导出的源码jdeps能帮你快速搭出一个可编译的工程骨架。6. 验证你的反编译结果一个 10 分钟的验收流程6.1 用编译回验和关键字抽查当你把某个 JAR 用 JD-GUI 1.4 导出成源码后不要直接信先做三个验证。第一重新编译在导出目录用 javac 编译如果编译通过说明语法层面还原成功编译失败不一定是工具错也可能是缺少第三方依赖。第二抽一个核心类对比原 JAR 里的字符串常量和反编译源码中的字符串常量是否一致用javap -verbose看常量池再在源码里搜。第三检查方法数量用javap -classpath a.jar -p -c 类名列出方法对比源码里方法的数量确认没有整段丢失。一个实用的技巧是把 JD-GUI 1.4 的输出和 CFR 的结果对照。同一类分别反编译两份差异集中在 lambda 和 try-with-resources 上说明该类的还原存在歧义。这时我习惯以实际运行日志为准跑一下被测 JAR观察日志中输出的方法名与行号再去源码里对应行找这样最可靠。最后的习惯每次反编译前记录下 JAR 的md5md5 ./service.jar这样等你改完代码回头对比时能确定你分析的就是当时那个包。这个动作成本几乎为零但能避免因为工具打开错版本而白干一晚上。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
