2026/9/10 4:26:12
FEATURED · 精选文章 
1. 为什么要给 Docker Desktop 做汉化Docker Desktop 是当前在 Windows 和 macOS 上跑容器最主流的图形化工具日常开发中不管是拉镜像、起容器、看日志还是管理卷和网络基本都离不开它。但默认安装完界面全英文对于不常接触英文界面的同学来说新建容器时那一堆参数选项、网络模式、端口映射的设置项看着确实有点懵。我当时第一次配置端口转发的时候硬是在 Publish a new port 那一栏犹豫了半天生怕填错格式把容器搞挂。所以这个项目并不是什么高深的技术活本质上就是给 Docker Desktop v4.65 做一次界面资源替换让它显示成中文。它的核心价值在于降低上手门槛尤其适合刚接触 Docker 的初学者以及日常用 Docker 但英语基础一般的开发者。我这次记录的汉化过程基于 v4.65 版本整个思路对其他版本也有参考价值但不同小版本之间资源文件结构可能存在差异不建议完全照抄操作而不做版本确认。提示Docker Desktop 本身官方并没有提供中文语言包所谓的“设置中文”是通过替换其内置语言资源文件实现的。这意味着升级 Docker Desktop 之后汉化会被覆盖需要重新处理。汉化本质上是对应用资源做二次加工过程中涉及到的工具和思路完全也能够沿用到其他 Electron 框架应用的界面修改上。读完这篇文章你不仅能照着给 Docker Desktop v4.65 汉化更关键的是理解“它为什么能被汉化”“汉化文件到底在哪个位置”“升级后为什么又变回英文”这一整条逻辑链。2. 汉化前必须做的准备工作2.1 确认版本号与资源文件路径汉化操作的第一步不是急着去下载语言包而是先确认你本机的 Docker Desktop 版本号。因为不同大版本的界面结构差异极大v4.65 的资源文件路径和内部结构与 v4.30 或者 v4.90 都有明显不同。万一你用的是其他版本照搬 v4.65 的汉化文件路径多半是找不到对应目录的。确认版本号的方法很简单打开 Docker Desktop点击右上角的设置图标然后选择 About 或 Troubleshoot界面里会直接显示版本号。也可以通过 Docker CLI 确认docker version输出内容中的 Client 和 Server 部分会显示版本号但需要注意这里显示的 Docker Engine 版本和 Docker Desktop 图形界面的版本并不是同一个概念。Docker Desktop 的版本号通常形如 4.65.0而 Docker Engine 版本号形如 27.x.x。我需要汉化的对象是前者也就是桌面应用本身的版本。确认版本号之后还需要找到 Docker Desktop 的安装目录。Windows 上默认路径是C:\Program Files\Docker\DockermacOS 上对应的路径是/Applications/Docker.app/Contents/Resources我这次记录的是 Windows 环境下的操作macOS 的汉化思路相同但文件锁签名、路径结构会有差异后续会单独说明。2.2 备份原始文件与关闭自动更新汉化操作虽然本身不复杂但它本质上是在修改应用程序的核心资源文件任何改动都有风险。我在实际操作前做了一件事把整个app.asar文件完完整整复制了一份到别的磁盘目录。这个文件是 Docker Desktop 的 UI 核心资源包后续所有汉化工作都围绕它展开。# 使用管理员权限的 PowerShell Copy-Item C:\Program Files\Docker\Docker\resources\app.asar D:\backup\app.asar.bak备份的作用是万一汉化过程中操作失误导致 Docker Desktop 无法启动可以随时把原文件恢复回去无缝回到未汉化状态。关闭自动更新同样关键。Docker Desktop 默认开启了自动更新机制如果汉化完成之后它悄悄进行了升级界面会瞬间变回英文汉化文件也会被覆盖掉。在设置里关闭自动更新的操作路径是打开 Docker Desktop → 点击设置 → 选择 General → 取消勾选 Automatically check for updates 选项。这样能保证汉化效果在短期内的稳定性但后续需要升级时记得先手动检查新版本的资源文件结构是否有变化再做一次汉化。2.3 准备汉化所需的工具汉化 Docker Desktop 本质上是对app.asar这个文件进行解包、修改、重新打包。我用到的工具清单如下工具用途下载/安装方式Resource Hacker查看和替换 Windows 可执行文件资源官网下载或命令行工具CFF Explorer编辑 PE 文件修改字符串资源官网下载已停止维护但可用asar 工具解包/打包 Electron 应用的 app.asarnpm 全局安装Visual Studio Code文本编辑与 JSON 格式处理官网下载其中最核心的是asar工具它专门用于处理 Electron 应用的应用包。在 Windows 上安装 Node.js 之后通过 npm 安装npm install -g electron/asar安装完成后通过命令行就可以对app.asar进行解包和重打包。注意Resource Hacker 和 CFF Explorer 这类工具在 Windows Defender 中会被标记为“不常见软件”下载时建议从官方源获取使用前最好先做一次病毒扫描反正我每次用这类工具都会先过一遍检查毕竟是要往系统目录写文件。3. 汉化原理与整体思路3.1 Docker Desktop 的界面结构分析要搞明白怎么汉化就得先知道 Docker Desktop 的界面到底是怎么构成的。Docker Desktop 是基于 Electron 框架开发的桌面应用Electron 应用的特点是界面部分使用 HTML/CSS/JavaScript 编写然后被打包成为一个.asar文件操作系统运行这个文件时实际上是在启动一个完整的 Chromium 内核来渲染界面。简单类比一下Electron 应用就像是一个“套了外壳的网页”。网页在浏览器里打开的时候浏览器负责渲染而 Electron 应用自己带了一个浏览器内核所以它不需要安装浏览器也能运行。app.asar这个文件就像是把这个网页的所有源码、图片、配置文件全部压缩成了一个包。Docker Desktop 的汉化难点在于它的语言资源并非像传统 Windows 软件那样集中存放在一个.lang或.resx文件里而是分散在前端 JavaScript 代码中。汉化方式就分为两种思路第一种是替换界面上的文本字符串即修改 JS 文件中硬编码的英文字符串为中文。第二种是寻找应用内置的国际化i18n机制看它是否支持外部加载语言包。我实际检查后发现Docker Desktop v4.65 内部其实引入了部分国际化支持但官方只内置了英文资源。因此汉化的切入点就很清晰找到语言资源文件把英文内容替换成中文再打包回去。3.2 语言文件定位与资源包解压使用asar工具将app.asar解包到工作目录。以一个干净的目录D:\docker-lang为例# 创建工作目录 mkdir D:\docker-lang # 解包 app.asar 到工作目录 cd D:\docker-lang npx electron/asar extract C:\Program Files\Docker\Docker\resources\app.asar ./解包完成后D:\docker-lang目录下会出现完整的应用源码结构。接下来需要找到语言相关文件。在 v4.65 中语言文件一般位于以下路径附近D:\docker-lang\dist\renderer\main.bundle.js D:\docker-lang\dist\renderer\*.chunk.js D:\docker-lang\resources\locales\其中resources\locales目录在 Electron 中默认存放的是 Chromium 自身的语言包如zh-CN.pak等这些文件对应的是浏览器内核部分的语言显示比如右键菜单、时区选择等系统级控件并不是 Docker 界面的主体资源。Docker 界面的主体文本和按钮文案都直接硬编码在 JavaScript 文件中。所以真正的汉化工作重心要放在纯英文业务界面 → 找到英文硬编码字符串 → 替换为对应的中文句式这一步上。这里就有个取舍问题硬编码字符串的替换无法做到 100% 全面覆盖因为部分字符串是动态拼接的、部分是和账号相关的服务端文案、部分散落在图表工具提示里。实际操作中能覆盖到 80%~90% 的常用界面已经达到“实用汉化”的标准。3.3 中文字体与资源编译的兼容性考虑在替换字符串时有一个细节容易忽略如果中文字符串直接写入原本是英文上下文的 JS 代码中可能会出现编码问题。我在实操过程中踩过一次坑用 VS Code 默认的 UTF-8 编码保存文件后重新打包并启动 Docker Desktop界面上的中文全部显示为乱码。排查之后发现原因有两个main.bundle.js文件虽然是 UTF-8 编码但某些字符串存在 Unicode 转义序列中直接粘贴中文后破坏了原有的转义结构。部分文件在 Windows 上默认使用 GBK 或 ANSI 编码打开保存后编码混乱。解决方案是所有修改操作统一使用 VS Code并且在保存时明确选择“UTF-8 with BOM”编码格式。这样一来重新打包后 Docker Desktop 就能正确识别中文字符。建议如果只是替换少量高频按钮文本如 “Containers”→“容器”、“Images”→“镜像”不建议直接修改 JS 文件因为风险较高、覆盖不全。可以先尝试用 Resource Hacker 对 Docker Desktop.exe 程序本身做一次简单的中文资源替换虽然效果非常有限但至少没有打包出错的风险。4. 分步实战Docker Desktop v4.65 汉化全流程4.1 利用旧版语言资源辅助定位在动手汉化之前需要先解决一个效率问题Docker Desktop v4.65 里的硬编码字符串数量很多如果靠肉眼去一个个找一晚上都未必能改完核心界面。这里有个更聪明的思路找一份旧版本 Docker Desktop比如 v4.20 或 v4.30的汉化补丁或者已经汉化过的app.asar文件下载下来做对比分析。旧版补丁能帮我们定位到高频的文本字符串以及对应的文件路径。虽然版本不同但 Docker 很多常用文案在多个版本间保持着一致性比如 “Containers” “Images” “Volumes” “Networks” “Settings” 这些基础概念。通过关键词搜索当前版本的 JS 文件# 在解包目录下搜索包含 Containers 字符串的文件 grep -r Containers --include*.js -l搜索出来之后用 VS Code 打开对应文件逐个定位并替换。这样就绕开了盲目的全文翻阅直接把精力聚焦到高频界面的文案上。4.2 核心文件的文本替换实操以容器列表页为例需要把英文标题 “Containers” 替换为 “容器”。在 VS Code 中打开包含该字符串的 JS/JSON 文件使用编辑器自带的全局替换功能。这样就将整个文件中所有出现的英文字符串一次性替换成中文不存在漏改的情况。但这里一定不能大意。有些字符串不能直接替换因为它在代码中承担着变量名、键名或功能标识的职责。比如 Docker 的 REST API 接口路径/containers如果也被替换成“/容器”那么整个应用就废了根本连不上 Docker Engine。所以安全替换的基本原则是只替换显示在界面上的用户可见文本不对键名、API 路径、变量名、样式类名做任何改动。具体判定的方法是在 JS 文件中如果一段字符串被单引号或双引号包裹且它的周围是return、textContent、label、title、placeholder这类属性多半就是界面文本如果它出现在对象的键位左侧即key: value结构中 key 的位置则绝对不动。我给自己制定的替换策略如下原始英文中文替换是否安全Containers容器安全Images镜像安全Volumes卷安全Networks网络安全Settings设置安全container name容器名称安全/containers不要动危险不能改id不要动危险不能改这条规则严格执行下来能最大程度避免“汉化后应用彻底打不开”的情况。4.3 重新打包并替换原始 app.asar所有文本替换完成后需要将解包后的目录重新打包成一个新的app.asar文件。使用如下命令# 在解包目录的上级目录执行打包 cd D:\docker-lang npx electron/asar pack D:\docker-lang\app D:\docker-lang\app.asar.new其中D:\docker-lang\app是之前解包得到的源码目录app.asar.new是新生成的打包文件。注意打包时的参数顺序pack后面第一个参数是源目录第二个参数是目标文件不要搞反。打包完成后需要把新的app.asar复制到 Docker Desktop 的安装目录中覆盖原始文件。这一步需要管理员权限Copy-Item D:\docker-lang\app.asar.new C:\Program Files\Docker\Docker\resources\app.asar -Force覆盖前确保 Docker Desktop 完全退出包括右下角系统托盘里的 Docker 图标也要退出。否则文件被占用复制会失败。注意有些 Windows 系统开启了“受控文件夹访问”功能会在向Program Files写入时弹出拦截提示。遇到这种情况可以临时关闭该功能或者将 Docker Desktop 安装目录加入白名单完成汉化后再恢复。4.4 启动验证与常见预期效果替换完成后重新启动 Docker Desktop。首次启动可能需要等待十到二十秒因为 Chromium 内核需要重新加载资源。正常情况下你会看到窗口标题栏、左侧导航栏、按钮文案都变成了中文。以我的实际操作结果来看v4.65 汉化后的生效范围包括左侧导航栏容器、镜像、卷、网络等入口信息面板容器状态、镜像仓库地址等设置窗口通用设置、资源分配、Docker Engine 配置等按钮标签运行、停止、删除、拉取等但同时也要有心理准备部分动态内容例如从 Docker Hub 拉取的镜像仓库描述、API 返回的部分错误提示信息、某些点击后弹窗中的详细说明文字仍然会显示英文。这些内容通常是从服务端请求得到的本地的语言资源文件无法覆盖属于正常现象不必太纠结。5. 汉化过程中的高频问题与排查方法5.1 Docker Desktop 无法启动遇到频率最高的一个问题就是汉化后 Docker Desktop 双击图标没有任何反应或者启动后 5 秒内自动退出。这种问题 90% 的原因是app.asar文件在重新打包时损坏了结构也有可能是替换了不应该替换的关键词导致 JS 语法报错。排查思路如下检查备份文件是否完整恢复原始的app.asar确认 Docker Desktop 能正常启动。如果能启动说明问题出在汉化后的文件上。检查 JS 语法用 Node.js 对修改后的 JS 文件做语法检查node --check D:\docker-lang\app\dist\renderer\main.bundle.js如果有语法错误的提示就说明在替换时破坏了引号或括号的配对需要退回原文件重新修改。检查编码确认文件是否为 UTF-8 编码不是的话用 VS Code 重新保存。恢复原文件的方式很简单把备份好的app.asar.bak重新复制回去即可。5.2 部分界面仍然显示英文这是一个非常普遍的现象而且基本无法彻底消除。前面提到过部分文本来自服务端动态加载不经过本地资源文件。还有一部分是隐藏在图表组件的 Tooltip 中这些字符串在 JS 代码里可能是通过内部变量动态拼接的无法用简单替换解决。我的处理原则是优先保证核心页面和常用功能的可读性。容器列表、镜像管理、卷管理这几个日常最高频的页面必须做到完全中文化对于动态加载的详细日志、数据卷驱动帮助文档这类低频阅读场景保留英文并不影响基本操作。5.3 中文显示成方块乱码这个问题和编码息息相关。macOS 上偶尔会看到Windows 上概率较低因为 Windows 中文字体渲染兼容性更好。替代方案是检查 Docker Desktop 内置的 Chromium 字体设置但这需要改更底层的配置风险较高。实际更稳妥的做法是在修改 JS 文件时将中文字符串写入 Unicode 转义序列如\u5BB9\u5668表示“容器”而不是直接粘贴原文。这样既不会破坏文件编码又能保证在任何环境下都能正确显示中文。不过这会让替换过程稍微麻烦一些适合对细节要求高的场景。5.4 系统提示文件已被占用覆盖app.asar时经常遇到“文件正在被另一进程使用”的提示。这是因为 Docker Desktop 即使在托盘区关闭了后台仍有部分进程在工作。彻底退出 Docker Desktop 的方法是先右键点击系统托盘的 Docker 鲸鱼图标选择 Quit Docker Desktop然后在任务管理器中确认以下进程全部结束Docker Desktop.execom.docker.build.execom.docker.backend.execom.docker.dev-envs.exe确认进程全部消失后再进行文件覆盖。6. 给新手的避坑指南与扩展建议6.1 汉化前必做的三件事根据我实际操作中的体会汉化前做好三条准备整个过程会顺很多备份原文件永远把恢复路径当作第一优先级。确认版本号不要照搬网络上其他版本的汉化资源。关闭自动更新否则辛苦汉化完的界面可能第二天就消失。这三点是我踩过几次坑之后总结出来的尤其是自动更新这一点第一次汉化时没有在意结果当天晚上它就自动升级到了新的版本所有修改瞬间归零。6.2 该汉化还是该适应英文这是我的一个个人观点对于 Dcoker Desktop 这类高频开发工具与其花时间去汉化不如直接用英文界面。原因有两个第一Docker 相关的大量技术文档、错误日志、命令行输出默认都是英文即便界面汉化了遇到问题搜索解决方案时还是会面对英文材料。第二Docker Desktop 的界面文本本身并不复杂核心操作就那么几个关键词Containes、Images、Volumes、Run、Stop、Prune来回使用几次就能记住。汉化这件事更适合给它装在自己电脑上想让家人或同事快速了解基础操作时使用对日常开发者而言英文界面其实更有利于长期学习。当然如果你是一个零基础的新手首次接触 Docker 时面对全英文界面确实有障碍那先用汉化版降低门槛等到基本概念熟悉后再换回英文也不失为一个合理的过渡方案。6.3 大型应用版本升级后的汉化可持续性还有一种情况我要单独提醒Docker Desktop 的版本更新频率不低。如果你习惯了使用汉化后的 Docker Desktop那么每次升级之后都需要重新走一遍解包、替换、打包的流程。这并不是一个“一劳永逸”的操作而是一个“每次升级都要重新做”的重复性工作。如果不想每次都手动操作可以考虑写一个 PowerShell 脚本来自动化这个流程。但脚本的难点在于不同版本之间字符串位置和文件结构可能变化自动替换逻辑需要兼顾容错。我目前没有把脚本做到全自动化因为每次版本更新后都要花时间检查新版的资源结构写死逻辑反而不灵活。人工做一次大概 20~30 分钟可以接受。最后再分享一个小技巧汉化过程中如果遇到拿不准的字符串先不要管它等启动应用后对照实际界面再决定改不改。这样比一次性把所有英文都替换掉要安全得多也省去了一堆来回排查的功夫。
Docker Desktop 汉化全攻略：原理、实操与避坑指南
1. 为什么要给 Docker Desktop 做汉化Docker Desktop 是当前在 Windows 和 macOS 上跑容器最主流的图形化工具日常开发中不管是拉镜像、起容器、看日志还是管理卷和网络基本都离不开它。但默认安装完界面全英文对于不常接触英文界面的同学来说新建容器时那一堆参数选项、网络模式、端口映射的设置项看着确实有点懵。我当时第一次配置端口转发的时候硬是在 Publish a new port 那一栏犹豫了半天生怕填错格式把容器搞挂。所以这个项目并不是什么高深的技术活本质上就是给 Docker Desktop v4.65 做一次界面资源替换让它显示成中文。它的核心价值在于降低上手门槛尤其适合刚接触 Docker 的初学者以及日常用 Docker 但英语基础一般的开发者。我这次记录的汉化过程基于 v4.65 版本整个思路对其他版本也有参考价值但不同小版本之间资源文件结构可能存在差异不建议完全照抄操作而不做版本确认。提示Docker Desktop 本身官方并没有提供中文语言包所谓的“设置中文”是通过替换其内置语言资源文件实现的。这意味着升级 Docker Desktop 之后汉化会被覆盖需要重新处理。汉化本质上是对应用资源做二次加工过程中涉及到的工具和思路完全也能够沿用到其他 Electron 框架应用的界面修改上。读完这篇文章你不仅能照着给 Docker Desktop v4.65 汉化更关键的是理解“它为什么能被汉化”“汉化文件到底在哪个位置”“升级后为什么又变回英文”这一整条逻辑链。2. 汉化前必须做的准备工作2.1 确认版本号与资源文件路径汉化操作的第一步不是急着去下载语言包而是先确认你本机的 Docker Desktop 版本号。因为不同大版本的界面结构差异极大v4.65 的资源文件路径和内部结构与 v4.30 或者 v4.90 都有明显不同。万一你用的是其他版本照搬 v4.65 的汉化文件路径多半是找不到对应目录的。确认版本号的方法很简单打开 Docker Desktop点击右上角的设置图标然后选择 About 或 Troubleshoot界面里会直接显示版本号。也可以通过 Docker CLI 确认docker version输出内容中的 Client 和 Server 部分会显示版本号但需要注意这里显示的 Docker Engine 版本和 Docker Desktop 图形界面的版本并不是同一个概念。Docker Desktop 的版本号通常形如 4.65.0而 Docker Engine 版本号形如 27.x.x。我需要汉化的对象是前者也就是桌面应用本身的版本。确认版本号之后还需要找到 Docker Desktop 的安装目录。Windows 上默认路径是C:\Program Files\Docker\DockermacOS 上对应的路径是/Applications/Docker.app/Contents/Resources我这次记录的是 Windows 环境下的操作macOS 的汉化思路相同但文件锁签名、路径结构会有差异后续会单独说明。2.2 备份原始文件与关闭自动更新汉化操作虽然本身不复杂但它本质上是在修改应用程序的核心资源文件任何改动都有风险。我在实际操作前做了一件事把整个app.asar文件完完整整复制了一份到别的磁盘目录。这个文件是 Docker Desktop 的 UI 核心资源包后续所有汉化工作都围绕它展开。# 使用管理员权限的 PowerShell Copy-Item C:\Program Files\Docker\Docker\resources\app.asar D:\backup\app.asar.bak备份的作用是万一汉化过程中操作失误导致 Docker Desktop 无法启动可以随时把原文件恢复回去无缝回到未汉化状态。关闭自动更新同样关键。Docker Desktop 默认开启了自动更新机制如果汉化完成之后它悄悄进行了升级界面会瞬间变回英文汉化文件也会被覆盖掉。在设置里关闭自动更新的操作路径是打开 Docker Desktop → 点击设置 → 选择 General → 取消勾选 Automatically check for updates 选项。这样能保证汉化效果在短期内的稳定性但后续需要升级时记得先手动检查新版本的资源文件结构是否有变化再做一次汉化。2.3 准备汉化所需的工具汉化 Docker Desktop 本质上是对app.asar这个文件进行解包、修改、重新打包。我用到的工具清单如下工具用途下载/安装方式Resource Hacker查看和替换 Windows 可执行文件资源官网下载或命令行工具CFF Explorer编辑 PE 文件修改字符串资源官网下载已停止维护但可用asar 工具解包/打包 Electron 应用的 app.asarnpm 全局安装Visual Studio Code文本编辑与 JSON 格式处理官网下载其中最核心的是asar工具它专门用于处理 Electron 应用的应用包。在 Windows 上安装 Node.js 之后通过 npm 安装npm install -g electron/asar安装完成后通过命令行就可以对app.asar进行解包和重打包。注意Resource Hacker 和 CFF Explorer 这类工具在 Windows Defender 中会被标记为“不常见软件”下载时建议从官方源获取使用前最好先做一次病毒扫描反正我每次用这类工具都会先过一遍检查毕竟是要往系统目录写文件。3. 汉化原理与整体思路3.1 Docker Desktop 的界面结构分析要搞明白怎么汉化就得先知道 Docker Desktop 的界面到底是怎么构成的。Docker Desktop 是基于 Electron 框架开发的桌面应用Electron 应用的特点是界面部分使用 HTML/CSS/JavaScript 编写然后被打包成为一个.asar文件操作系统运行这个文件时实际上是在启动一个完整的 Chromium 内核来渲染界面。简单类比一下Electron 应用就像是一个“套了外壳的网页”。网页在浏览器里打开的时候浏览器负责渲染而 Electron 应用自己带了一个浏览器内核所以它不需要安装浏览器也能运行。app.asar这个文件就像是把这个网页的所有源码、图片、配置文件全部压缩成了一个包。Docker Desktop 的汉化难点在于它的语言资源并非像传统 Windows 软件那样集中存放在一个.lang或.resx文件里而是分散在前端 JavaScript 代码中。汉化方式就分为两种思路第一种是替换界面上的文本字符串即修改 JS 文件中硬编码的英文字符串为中文。第二种是寻找应用内置的国际化i18n机制看它是否支持外部加载语言包。我实际检查后发现Docker Desktop v4.65 内部其实引入了部分国际化支持但官方只内置了英文资源。因此汉化的切入点就很清晰找到语言资源文件把英文内容替换成中文再打包回去。3.2 语言文件定位与资源包解压使用asar工具将app.asar解包到工作目录。以一个干净的目录D:\docker-lang为例# 创建工作目录 mkdir D:\docker-lang # 解包 app.asar 到工作目录 cd D:\docker-lang npx electron/asar extract C:\Program Files\Docker\Docker\resources\app.asar ./解包完成后D:\docker-lang目录下会出现完整的应用源码结构。接下来需要找到语言相关文件。在 v4.65 中语言文件一般位于以下路径附近D:\docker-lang\dist\renderer\main.bundle.js D:\docker-lang\dist\renderer\*.chunk.js D:\docker-lang\resources\locales\其中resources\locales目录在 Electron 中默认存放的是 Chromium 自身的语言包如zh-CN.pak等这些文件对应的是浏览器内核部分的语言显示比如右键菜单、时区选择等系统级控件并不是 Docker 界面的主体资源。Docker 界面的主体文本和按钮文案都直接硬编码在 JavaScript 文件中。所以真正的汉化工作重心要放在纯英文业务界面 → 找到英文硬编码字符串 → 替换为对应的中文句式这一步上。这里就有个取舍问题硬编码字符串的替换无法做到 100% 全面覆盖因为部分字符串是动态拼接的、部分是和账号相关的服务端文案、部分散落在图表工具提示里。实际操作中能覆盖到 80%~90% 的常用界面已经达到“实用汉化”的标准。3.3 中文字体与资源编译的兼容性考虑在替换字符串时有一个细节容易忽略如果中文字符串直接写入原本是英文上下文的 JS 代码中可能会出现编码问题。我在实操过程中踩过一次坑用 VS Code 默认的 UTF-8 编码保存文件后重新打包并启动 Docker Desktop界面上的中文全部显示为乱码。排查之后发现原因有两个main.bundle.js文件虽然是 UTF-8 编码但某些字符串存在 Unicode 转义序列中直接粘贴中文后破坏了原有的转义结构。部分文件在 Windows 上默认使用 GBK 或 ANSI 编码打开保存后编码混乱。解决方案是所有修改操作统一使用 VS Code并且在保存时明确选择“UTF-8 with BOM”编码格式。这样一来重新打包后 Docker Desktop 就能正确识别中文字符。建议如果只是替换少量高频按钮文本如 “Containers”→“容器”、“Images”→“镜像”不建议直接修改 JS 文件因为风险较高、覆盖不全。可以先尝试用 Resource Hacker 对 Docker Desktop.exe 程序本身做一次简单的中文资源替换虽然效果非常有限但至少没有打包出错的风险。4. 分步实战Docker Desktop v4.65 汉化全流程4.1 利用旧版语言资源辅助定位在动手汉化之前需要先解决一个效率问题Docker Desktop v4.65 里的硬编码字符串数量很多如果靠肉眼去一个个找一晚上都未必能改完核心界面。这里有个更聪明的思路找一份旧版本 Docker Desktop比如 v4.20 或 v4.30的汉化补丁或者已经汉化过的app.asar文件下载下来做对比分析。旧版补丁能帮我们定位到高频的文本字符串以及对应的文件路径。虽然版本不同但 Docker 很多常用文案在多个版本间保持着一致性比如 “Containers” “Images” “Volumes” “Networks” “Settings” 这些基础概念。通过关键词搜索当前版本的 JS 文件# 在解包目录下搜索包含 Containers 字符串的文件 grep -r Containers --include*.js -l搜索出来之后用 VS Code 打开对应文件逐个定位并替换。这样就绕开了盲目的全文翻阅直接把精力聚焦到高频界面的文案上。4.2 核心文件的文本替换实操以容器列表页为例需要把英文标题 “Containers” 替换为 “容器”。在 VS Code 中打开包含该字符串的 JS/JSON 文件使用编辑器自带的全局替换功能。这样就将整个文件中所有出现的英文字符串一次性替换成中文不存在漏改的情况。但这里一定不能大意。有些字符串不能直接替换因为它在代码中承担着变量名、键名或功能标识的职责。比如 Docker 的 REST API 接口路径/containers如果也被替换成“/容器”那么整个应用就废了根本连不上 Docker Engine。所以安全替换的基本原则是只替换显示在界面上的用户可见文本不对键名、API 路径、变量名、样式类名做任何改动。具体判定的方法是在 JS 文件中如果一段字符串被单引号或双引号包裹且它的周围是return、textContent、label、title、placeholder这类属性多半就是界面文本如果它出现在对象的键位左侧即key: value结构中 key 的位置则绝对不动。我给自己制定的替换策略如下原始英文中文替换是否安全Containers容器安全Images镜像安全Volumes卷安全Networks网络安全Settings设置安全container name容器名称安全/containers不要动危险不能改id不要动危险不能改这条规则严格执行下来能最大程度避免“汉化后应用彻底打不开”的情况。4.3 重新打包并替换原始 app.asar所有文本替换完成后需要将解包后的目录重新打包成一个新的app.asar文件。使用如下命令# 在解包目录的上级目录执行打包 cd D:\docker-lang npx electron/asar pack D:\docker-lang\app D:\docker-lang\app.asar.new其中D:\docker-lang\app是之前解包得到的源码目录app.asar.new是新生成的打包文件。注意打包时的参数顺序pack后面第一个参数是源目录第二个参数是目标文件不要搞反。打包完成后需要把新的app.asar复制到 Docker Desktop 的安装目录中覆盖原始文件。这一步需要管理员权限Copy-Item D:\docker-lang\app.asar.new C:\Program Files\Docker\Docker\resources\app.asar -Force覆盖前确保 Docker Desktop 完全退出包括右下角系统托盘里的 Docker 图标也要退出。否则文件被占用复制会失败。注意有些 Windows 系统开启了“受控文件夹访问”功能会在向Program Files写入时弹出拦截提示。遇到这种情况可以临时关闭该功能或者将 Docker Desktop 安装目录加入白名单完成汉化后再恢复。4.4 启动验证与常见预期效果替换完成后重新启动 Docker Desktop。首次启动可能需要等待十到二十秒因为 Chromium 内核需要重新加载资源。正常情况下你会看到窗口标题栏、左侧导航栏、按钮文案都变成了中文。以我的实际操作结果来看v4.65 汉化后的生效范围包括左侧导航栏容器、镜像、卷、网络等入口信息面板容器状态、镜像仓库地址等设置窗口通用设置、资源分配、Docker Engine 配置等按钮标签运行、停止、删除、拉取等但同时也要有心理准备部分动态内容例如从 Docker Hub 拉取的镜像仓库描述、API 返回的部分错误提示信息、某些点击后弹窗中的详细说明文字仍然会显示英文。这些内容通常是从服务端请求得到的本地的语言资源文件无法覆盖属于正常现象不必太纠结。5. 汉化过程中的高频问题与排查方法5.1 Docker Desktop 无法启动遇到频率最高的一个问题就是汉化后 Docker Desktop 双击图标没有任何反应或者启动后 5 秒内自动退出。这种问题 90% 的原因是app.asar文件在重新打包时损坏了结构也有可能是替换了不应该替换的关键词导致 JS 语法报错。排查思路如下检查备份文件是否完整恢复原始的app.asar确认 Docker Desktop 能正常启动。如果能启动说明问题出在汉化后的文件上。检查 JS 语法用 Node.js 对修改后的 JS 文件做语法检查node --check D:\docker-lang\app\dist\renderer\main.bundle.js如果有语法错误的提示就说明在替换时破坏了引号或括号的配对需要退回原文件重新修改。检查编码确认文件是否为 UTF-8 编码不是的话用 VS Code 重新保存。恢复原文件的方式很简单把备份好的app.asar.bak重新复制回去即可。5.2 部分界面仍然显示英文这是一个非常普遍的现象而且基本无法彻底消除。前面提到过部分文本来自服务端动态加载不经过本地资源文件。还有一部分是隐藏在图表组件的 Tooltip 中这些字符串在 JS 代码里可能是通过内部变量动态拼接的无法用简单替换解决。我的处理原则是优先保证核心页面和常用功能的可读性。容器列表、镜像管理、卷管理这几个日常最高频的页面必须做到完全中文化对于动态加载的详细日志、数据卷驱动帮助文档这类低频阅读场景保留英文并不影响基本操作。5.3 中文显示成方块乱码这个问题和编码息息相关。macOS 上偶尔会看到Windows 上概率较低因为 Windows 中文字体渲染兼容性更好。替代方案是检查 Docker Desktop 内置的 Chromium 字体设置但这需要改更底层的配置风险较高。实际更稳妥的做法是在修改 JS 文件时将中文字符串写入 Unicode 转义序列如\u5BB9\u5668表示“容器”而不是直接粘贴原文。这样既不会破坏文件编码又能保证在任何环境下都能正确显示中文。不过这会让替换过程稍微麻烦一些适合对细节要求高的场景。5.4 系统提示文件已被占用覆盖app.asar时经常遇到“文件正在被另一进程使用”的提示。这是因为 Docker Desktop 即使在托盘区关闭了后台仍有部分进程在工作。彻底退出 Docker Desktop 的方法是先右键点击系统托盘的 Docker 鲸鱼图标选择 Quit Docker Desktop然后在任务管理器中确认以下进程全部结束Docker Desktop.execom.docker.build.execom.docker.backend.execom.docker.dev-envs.exe确认进程全部消失后再进行文件覆盖。6. 给新手的避坑指南与扩展建议6.1 汉化前必做的三件事根据我实际操作中的体会汉化前做好三条准备整个过程会顺很多备份原文件永远把恢复路径当作第一优先级。确认版本号不要照搬网络上其他版本的汉化资源。关闭自动更新否则辛苦汉化完的界面可能第二天就消失。这三点是我踩过几次坑之后总结出来的尤其是自动更新这一点第一次汉化时没有在意结果当天晚上它就自动升级到了新的版本所有修改瞬间归零。6.2 该汉化还是该适应英文这是我的一个个人观点对于 Dcoker Desktop 这类高频开发工具与其花时间去汉化不如直接用英文界面。原因有两个第一Docker 相关的大量技术文档、错误日志、命令行输出默认都是英文即便界面汉化了遇到问题搜索解决方案时还是会面对英文材料。第二Docker Desktop 的界面文本本身并不复杂核心操作就那么几个关键词Containes、Images、Volumes、Run、Stop、Prune来回使用几次就能记住。汉化这件事更适合给它装在自己电脑上想让家人或同事快速了解基础操作时使用对日常开发者而言英文界面其实更有利于长期学习。当然如果你是一个零基础的新手首次接触 Docker 时面对全英文界面确实有障碍那先用汉化版降低门槛等到基本概念熟悉后再换回英文也不失为一个合理的过渡方案。6.3 大型应用版本升级后的汉化可持续性还有一种情况我要单独提醒Docker Desktop 的版本更新频率不低。如果你习惯了使用汉化后的 Docker Desktop那么每次升级之后都需要重新走一遍解包、替换、打包的流程。这并不是一个“一劳永逸”的操作而是一个“每次升级都要重新做”的重复性工作。如果不想每次都手动操作可以考虑写一个 PowerShell 脚本来自动化这个流程。但脚本的难点在于不同版本之间字符串位置和文件结构可能变化自动替换逻辑需要兼顾容错。我目前没有把脚本做到全自动化因为每次版本更新后都要花时间检查新版的资源结构写死逻辑反而不灵活。人工做一次大概 20~30 分钟可以接受。最后再分享一个小技巧汉化过程中如果遇到拿不准的字符串先不要管它等启动应用后对照实际界面再决定改不改。这样比一次性把所有英文都替换掉要安全得多也省去了一堆来回排查的功夫。 
