多语言与 resources.arsc：改了 XML 不生效，只改中文该动哪一份

先说清楚我们在讲什么。安卓修改大师智改工坊是一款 Windows 桌面工具，把"改 APK"这件事压缩成一句话：拖入安装包，用中文写需求，AI 在反编译出来的工程里改代码与资源，改完自动回编、对齐、签名、校验，最后一键装到手机或模拟器上看效果。它的介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

"我只想把中文改一下，别的语言别动" —— 这是改包需求里最常出现的一句话，也是翻车率最高的一句话。原因不在于改起来难，而在于同一个资源在包里往往不止一份：默认一份、中文一份、英文一份、可能还有繁体一份；它们在编译后被打包进同一张资源表，运行时由系统按设备语言挑出其中一份来显示。你改了 A，设备用的是 B，结果就是"改了没反应"；你改的是"默认那份"，结果所有没有专属翻译的语言全跟着变了 —— 又变成"我只想改中文，怎么全变了"。

这篇把这条链路讲完整：先弄清 values、values-zh、values-en 三者的关系；再讲清 resources.arsc 是什么、为什么"直接把 XML 换进去"不生效；然后是多语言场景下"改了没反应"的五种成因和三类需求的正确做法；再给一套"一句话把语言范围说清楚"的写法技巧；最后从工具实现角度说明这条链路是怎么被串起来的，并配两个自家应用的改包实例。

一、values / values-zh / values-en：一套资源，多个版本

Android 的资源体系是这样设计的：资源文件按"限定符"分目录存放，不带限定符的目录是默认版本，带限定符的目录是针对特定环境的版本。语言就是最常见的一种限定符。所以一个做过国际化的应用，你会在资源目录下同时看到：

目录	什么时候被选中	典型内容
values（默认）	设备语言没有专属版本时的兜底；也是"翻译意义上的原文"	通常是开发时的母语版本（国内应用多为中文）
values-zh	设备语言是中文（简体）时优先命中	中文文案，可能与默认版一致、也可能不同
values-en	设备语言是英文时优先命中	英文文案
values-zh-rTW 等更细的变体	限定符越具体，匹配优先级越高	地区化的差异文案

这套机制的关键在最后一行：匹配是"从具体到宽泛"逐级回退的。设备语言是中文时，系统先找最具体的匹配（比如地区变体），找不到就往回退到 values-zh；如果连 values-zh 都没有，就回退到默认 values。所以你"看到的那句话"，是这条链上任一层提供的 —— 到底哪一层在生效，取决于设备语言 + 包里实际存在哪些变体这两件事的组合。

这里有两个非常容易踩的认知偏差。第一个："默认版"不等于"中文版"。国内应用常常把中文直接写在默认 values 里，根本没有 values-zh —— 这时候"只改中文"实际就等于"改默认版"，而默认版是所有语言的兜底，理论上会影响其它语言；只不过如果这个应用压根没做过国际化，那也就没有别的语言受害。第二个：同一个资源不一定会出现在每个语言目录里。如果某个字符串只在 values-en 里有、默认版里没有，那设备语言是中文时它其实会回退到 values-en 那份 —— 这时"英文那份"反而在中文环境下生效，非常反直觉。

问题是怎么知道"这个包里到底有哪些语言版本"？答案在反编译之后：资源目录下会保留语言限定的分组，把带语言限定符的目录列一遍，这份清单就是"可能被命中的候选"。国内应用常见三种形态：只有默认 values（中文写在默认里，没做国际化）；默认中文 + values-en（做过英文）；默认英文 + values-zh + values-en + 其它（国际化做得比较全）。先确定属于哪一种，再谈"改哪份" —— 这一步花两分钟，能省掉后面半小时的反复试。

所以判断"该改哪一份"，正确的问法不是"这句话是中文还是英文"，而是：在目标设备语言下，这句话最终由哪一层提供？ 想清楚这一点，多语言改动就有一半把握了。

二、resources.arsc：为什么"直接改 XML"不生效

上一节讲的是"逻辑上有多份"，这一节讲"物理上它长什么样" —— 这决定了你能不能直接动手改。

Android 应用在编译时，会把所有资源编译成一张资源表（resources.arsc）以及与之一一对应的二进制资源文件。这张表里记录着：每个资源叫什么名字、属于什么类型、对应哪个编号，以及在每一种配置（语言、屏幕密度、系统版本等）下它的值是什么。字符串会进表里的字符串池，图片、布局等则以二进制形式存放。应用运行时读取资源，走的是这张编译后的表 —— 它不读你手里那份"人写得出来"的 XML。

这解释了一个非常常见的困惑：为什么我把安装包当压缩包打开、把里面的资源 XML 替换掉，重新压缩回去，装上去却没反应？原因有两层，缺一不可：

正确的路径因此是固定的四段：反编译把包"摊平"成可读目录（二进制 XML 还原成文本、资源表按语言与类型拆回各种 values 目录）→ 在文本层面改你要改的那一份 → 回编把文本重新编译成资源表和二进制 XML → 对齐并重新签名。工具把这四段串成了自动流水线：回编、对齐、签名、校验四步依次执行，最后一步校验会读回签名证书信息，确认"这个包真的签好了"。

这里要补一个关键认知：反编译不是"换个格式存一份"，而是把编译产物还原成可编辑的源级文本。你改完之后重新回编，程序会把整棵资源树重新编译一遍，生成新的资源表与二进制 XML —— 也就是说，"改文本"这个动作之所以算数，是因为后面跟着"重新编译"。这一条解释了两种常见误解：其一，以为"资源表是二进制所以改不了" —— 改不了的是二进制本体，但你可以改还原出来的文本、让它重新编译；其二，以为"改了文本文件就完事了" —— 如果没有回编这一步（比如你只是改了反编译目录里的文件），包里什么都没变，自然也不会生效。

这里还有一个值得单独说的设计：打包之前，程序会往资源目录里的样式文件写一个名为 info 的打包标记（内容是"谁在哪台机器上打的这个包"的编码串），三种现场各有对策 —— 文件不存在就先造一个空壳、文件在但没有这个样式就插在结束标签之前、已经有了就整块替换成新的。它为什么偏偏选 values 目录里的文件？因为values 目录正是"会被回编编进资源表"的入口：写在这里的内容才真正进包。多语言的道理和它一模一样 —— 你要改的那一份，必须落在会被编进资源表的位置上，而且要是目标语言真正会命中的那一份。

顺带说清"资源表"这个概念对使用者的实际意义。你不需要理解它的二进制格式，只需要记住两件事：它是这一切的"最终真相"（运行时看的就是它），以及它是被"编译"出来的（所以只能通过改源级文本、再重新编译来影响它）。理解了这两点，很多"为什么这样改不行"的疑问会自己解开：改压缩包里的文件不行、只改反编译目录不回编不行、改了但不重新签名也不行 —— 三条其实是同一条道理的不同侧面。

三、"改了没反应"的五种成因：多语言场景特别版

把多语言场景下的"没反应"单独列一遍，因为这几种成因在别的场景里很少见，但在这里几乎人人中招。

1. 改错了语言层。 改了默认 values，但设备语言是中文、命中的是 values-zh —— 表现是"完全没变"；反过来，改了 values-zh，而设备其实跑在英文下，也一样看不到变化。
2. 被更具体的变体截胡。 你改了 values-zh，但包里还有 values-zh-rTW 或别的更细的变体，某台设备的语言正好命中那一份。测试机上是对的，另一台机器上就是旧的。
3. 改的是"没有的那一份"。 你以为改了默认版就万事大吉，但这个字符串只在某个语言目录里存在，默认版根本没有它 —— 那个语言下命中的还是它自己那份，你改的地方本来就没有这条资源。
4. 改的层次不对。 这句话是布局里内联的、或者代码里拼出来的，跟资源目录一点关系都没有。资源目录翻遍了也找不到，属于另一类问题（先说结论：这种要按"文字落点"的思路去布局或代码里找）。
5. 改完没有重新打包，或装了旧包。 反编译目录改了、包没重打；或者重打了但设备上没装成功。检查方法很直接：看打包产物目录里那份最终包的时间戳，和你安装的时间对不对得上。

关于"设备当前语言"这件事，还有两个实操提醒。第一，模拟器切语言比重启真机快得多：工具在打包后能自动把包装到模拟器上拉起，切一次语言、看一眼、切回来，整个验证循环可以在一个窗口里完成，非常适合多语言这种需要反复对照的改动。第二，桌面启动器会缓存应用名和图标 —— 改完应用名这类资源之后，如果桌面还是旧显示，先重启启动器或直接重装一次，再判断是不是真的没生效。这两个提醒都属于"知道就少折腾十分钟"的经验。

四、三类需求的正确做法：只改中文、只改英文、全都改

多语言改动看似只有"改哪句"一个问题，其实是三个问题的组合：改哪句、改哪几份、其它语言保持什么状态。把常见需求归成三类，每类给一套标准做法。

你的需求	该动哪一份	副作用	怎么验收
只改中文	优先 values-zh；没有就先确认默认版是不是中文	最小。其它语言完全不受影响	中文环境看新文案；切英文确认没变
只改英文	values-en（若有更细变体，一并确认）	最小。中文不受影响	切英文看新文案；切中文确认没变
所有语言一起改	逐语言各改一份；或改默认版（兜底）	改默认版会波及所有"没有专属翻译"的语言	至少抽查中文与英文两种语言

先说"只改中文"。标准做法是直奔 values-zh：它命中中文设备、不碰其它语言，副作用最小。但有两个前置条件要先确认：第一，包里是否真的有 values-zh（很多国内应用把中文写在默认版里，根本没有这个目录）；第二，是否存在 values-zh 的更细变体（有的话，那些变体命中时会盖过 values-zh，需要一起看）。如果包里没有 values-zh、默认版就是中文，那么"只改中文"实际落到默认版上 —— 这时要多做一步确认：包里还有哪些语言目录，它们有没有同名资源；如果别的语言都各有自己的一份，那改默认版实际影响的就是"没有专属翻译的那些语言"，中文这侧是安全的。

再说"只改英文"，逻辑完全对称，只是换成 values-en。这类需求最容易出的错是"顺手把默认版也改了"：觉得"英文那份是翻译，原文在默认版，应该一起保持一致" —— 但如果默认版是中文，这一改中文也跟着变了。保持"只改目标语言那一份"的克制，是多语言改动最重要的纪律。

最后是"所有语言一起改"。有两种实现方式：逐语言各改一份（精确但工作量大），或者只改默认版、指望兜底生效（省事但不可靠）。为什么不可靠？因为凡是该语言有自己翻译的资源，都不会回退到默认版 —— 你改了默认版，有专属翻译的语言仍然显示它自己那份。所以"全都改"的正确姿势是逐语言确认、逐语言改；默认版可以作为兜底顺手改掉，但不能指望它包打天下。这也是很多"我明明改了默认版，英文界面还是旧文案"的根因。

还有一类介于两者之间的需求：只改某几个语言，或者连带地区变体一起改。例如"简体改、繁体不改"，或者"简体、繁体、香港都要改"。这类需求最容易漏的是地区变体：它们在目录名上往往只差一小截，视觉上一扫就过去了。稳妥的做法是在需求里把语言逐一点名，例如"简体中文与繁体中文都要改成这一句，英文及其它语言不动"，而不是笼统地说"中文相关的都改"。含糊的说法会让"改到哪一层"重新变成一次猜测。

五、一句话怎么把语言范围说清楚

做完了技术分析，回到实际操作：你面对的是一个输入框，怎么用一句话把"改哪一句、改哪几份"说清楚？这里给一套四要素写法。

要素一：位置。 "哪一屏、哪个元素" —— 例如"设置页最下面那条版本说明"。位置描述是缩小范围的第一把刀。

要素二：新内容。 给出目标文案的准确写法，包括标点和空格。含变量的句子要写清"变量部分保持不动"。

要素三：语言范围。 这是本文的重点。三种最常用的表述："只改中文，其它语言保持原样""中英文都要改，改成对应的两种文案""默认那一份也一起改"。注意：说"只改中文"时最好补一句"英文不要动" —— 明确的"不要动"和明确的"要动"同样重要。

要素四：验收。 "改完中文界面显示新文案，切到英文界面应保持原文案不变" —— 把验收标准写进需求，改动就会朝着这个标准去做。

如果你加了附件，记得把用途说明写足：附件说明要求不少于 10 个字，比如"这是新版中文应用名，只替换中文那一份"。同时程序会校验附件本身能不能用（存在、不是目录、不是 0 字节、能读出来），同一个文件重复添加会自动去重。这些约束不是找麻烦，而是把"AI 猜错素材用途"这类事故挡在源头。

写到这一步，如果你仍然不知道怎么措辞，界面里的话术库可以帮忙：6 大分类共 3000 条成型指令，每条都把"要做什么、细节要求、参数参考、范围、验收"写全，点「选择」直接填进输入框。话术库的写法本身就是一种示范 —— 尤其是"范围"那一项，多语言需求里最缺的就是它。库文件放在程序目录下，可以自己改，改完点刷新重新读。

六、工具把这条链路串成了什么样子

从你写下一句话，到设备屏幕上显示新文案，中间有五段工程动作。工具的做法是：把其中能自动化的都自动化，把必须由人决策的（改哪一份、改成什么）留给你。

6.1 导入与摊平：先让资源"看得见"

拖入安装包之后，程序用工作目录里的解析工具读出图标、应用名、包名、版本号、最低与目标系统版本、启动页，并把这些信息写进项目配置；随后在后台线程里反编译，把整包摊平到项目目录下。多语言的机会就在这里浮现 —— 反编译之后，资源目录下带语言限定的各个目录一目了然，"这个包里到底有哪些语言版本"第一次变得可见。反编译失败不影响项目本身，配置与源包副本都已落地，日志留给 apktool.log。

6.2 需求成型：你的原话 + 附件说明 + 环境约定

点「立刻修改」时送出去的文本是三段拼起来的：需求原文、附件说明（形如"序号. 文件路径 —— 用途说明"）、以及一段固定环境说明（把工作目录切到当前项目、改完在项目目录里留一个标志文件、不需要自动打包）。需求原文连同日期写进修改历史，附件说明不进历史 —— 所以历史里回看永远是"你自己说的那句话"，想照着再改一遍，点一下「选择」就填回输入框。

等待改完的信号是一个文件：AI 在项目目录里生成标志文件，主窗口每 2 秒轮询一次，读到就删掉并自动弹出打包窗口；开始等待前会先清一次同名残留，保证等的是这一轮的信号，等待上限 1 小时。这套约定之所以用文件而不是接口，是因为 AI 那边是聊天窗口、没法回调本程序，而"写文件、看文件"是它最容易照做、出错也不卡住任何一方的形式。

环境说明里还有两个小细节，理解它们能少走弯路。第一，说明里用的是一个占位符来指代当前项目的工作目录，发出去之前才替换成真实路径 —— 所以无论你把工作目录放在哪个盘、项目目录叫什么随机名字，约定里的路径永远是当下这一份，不会串到别的项目上。第二，"改完再生成标志文件、中途不要生成"这句话是特意强调的：标记文件一旦提前出现，主窗口就会以为已经改完并开始打包，等于把"改到一半"的中间状态封进了包里。如果你自己给 AI 追加要求，尽量不要动这两条约定。

6.3 回编与签名：文本重新变回资源表，再盖上章

打包四步：回编（把文本重新编译成资源表和二进制 XML）、对齐、签名、校验。产物落在项目目录的 build 子目录里，全过程写进 pack.log。第四步的校验绝不是走过场：前几步只反映命令有没有跑完，"签名是否真的成立"要它说了算 —— 密钥格式不对这类问题，只有这一步会明确报出来。签名用的密钥放在工作目录根目录，可以换成你自己的。回编之前，程序还会往资源目录里写好那个打包标记（不存在就造空壳、没有该样式就插在结束标签前、已有就整块替换）—— 它同样是"必须落在会被编进资源表的位置"的例证，前面已经讲过。

6.4 装机与验收：语言要切着看

打包后可以勾选自动运行：程序用 adb 找到设备、装包并拉起。拉起用 am start 而不是 monkey（新系统镜像里已经不带它，而且它失败时退出码仍是 0，容易把失败误判成成功）；启动入口按三档查找（项目配置里记的启动页 → 问设备 → 最后兜底），起来之后还会用系统命令复核前台应用是不是它。手机的画面用投屏投到电脑上，模拟器则把窗口提到最前面。装不上时也有明确说法：签名不一致会提示先卸载再装，设备上版本更高会尝试降级安装。

多语言场景的验收有一个额外动作：切着语言看。改中文就切到中文看一眼新文案，再切到英文确认没被动；反过来也一样。这不是多此一举 —— 本文讲的所有"改了没反应"的成因，几乎都能被这个动作提前发现。顺手说一句：如果设备上完全没连上手机或模拟器，程序也会提示（比如手机没点"允许 USB 调试"、模拟器装了但没连上 adb），该连的会自动连、该开窗口的会帮你开。

最后补一句环境相关的事：工具链（java、解析工具、回编工具、对齐与签名工具等）都放在工作目录的 tools 目录里，程序会自动递归搜索，不需要手工登记；「参数设置」页里有一次工具链体检，会逐个检查并给出完整路径，改包跑不起来时先看这一页比翻日志更快。工作目录本身是启动时自动挑的：依次尝试 D、E、F、G，取第一个可读写且剩余空间足够的盘，都不行才退回 C 盘 —— 多语言改包通常要跑好几轮，工具齐全、空间充足，验证循环才转得起来。

七、两个自家改包实例

下面两个例子都来自我们自己团队的场景，用的是自家应用、自家素材，重点看"以前怎么做、现在一句话怎么做、改完怎么验证"三步。

实例一：自家「记账助手」国内版，只改中文的那句口号。

"我的"页面里有一句用了很久的口号，只应该出现在中文版里 —— 英文版有自己的对应说法，且这次不动。以前的做法是：先反编译，然后面对一个问题：这句话到底在默认 values 里还是在 values-zh 里？如果在默认版里直接改，理论上会波及所有语言的兜底；如果在 values-zh 里改，又要先确认包里到底有没有这个目录。于是流程变成：翻目录确认语言版本、确认目标文案位置、手改、回编、签名、装机、切语言检查英文有没有跟着变 —— 一次小小的文案修改，前后要装两次、切两次语言。

现在一句话：把自家安装包拖进安卓修改大师智改工坊，在需求框里写"把『我的』页面里那句口号改成『每一笔都算数』；只改中文，英文和其它语言保持原样；改完中文界面显示新文案，英文界面应保持原来的文案"。点「立刻修改」，需求进历史，右侧窗口开始改；改完留标志文件，主窗口读到后自动弹打包窗口，四步跑完给出最终包。

改完怎么验证：装到设备上打开"我的"页面看中文新文案；再去系统设置里把语言切成英文，回到同一个页面确认文案没变 —— 这两眼做完，"只改中文"才算被真正验证过。如果反过来发现英文也跟着变了，说明这份文案源自默认版且没有专属英文，那时再把语言范围的要求改成"把中文和英文分开处理"，按历史里那条记录点一下就能重来。

这个例子里"以前"最耗时的其实不是改，而是确认改了哪一份、改完有没有连累别的语言：翻目录、对照资源名、切语言检查，每一步都要人工做一遍。现在的做法把"确认范围"提前到了需求描述里 —— 需求里"只改中文，英文保持原样"这句话，同时约束了改动范围与验收标准；改完的历史记录还留着这句原话，下次同类改动可以原样复用。

实例二：内部「出差报销」中英双语工具，只改英文的登录提示。

这个工具是给海内外同事共用的，做了中英双语。登录页的提示语英文版要调整措辞。以前踩过的坑是"顺手改了默认版"：改完英文是对的，中文却也跟着变成了英文原文 —— 因为默认版就是中文那份，一改全变。那次返工之后，团队里多了一条经验：改双语应用时，先问"默认那份是哪国语言"。

现在同样是一句话："把登录页的提示语英文版改成『Sign in with your work account』；只改英文，中文不要动。"加不加附件都可以（这次文案直接写在需求里）。改完自动打包、装到设备上，切换系统语言到英文看一眼登录页，再切回中文确认提示语没动 —— 两边都对，改动才算完成。

这个例子里还有一处值得回头说：为什么当初"顺手改默认版"会造成中文也变了？因为那个应用的默认版就是中文的母版 —— 英文那份是翻译、有自己的一份，而中文（以及所有没有专属翻译的语言）都从默认版兜底。改了默认版，等于动了所有还没翻译过的语言。这个规律不只适用于中英两种语言：任何"只改了默认版"的改动，都会在"没有专属翻译的语言"上生效。理解了这一点，你就能提前预判每一次多语言改动的波及范围，而不用靠安装之后才发现。

两个实例都指向同一条经验：多语言改动的关键不在"改"的技术，而在"改哪一份"的决策。决策做对了，改动本身是几秒钟的事；决策做错了，改动再漂亮也是白改。而做对这个决策需要的两个信息 —— 包里有哪些语言版本、目标语言命中的是哪一份 —— 恰好是反编译之后最容易看到、也最值得先花两分钟确认的东西。

八、用户评价：他们是怎么处理多语言的

以下引述来自内部试用与技术交流群里的使用体验整理，属于体验性反馈（文案性内容，非官方统计口径），供你对照自己的场景参考。

九、结语：先弄懂"哪一份"，再动手

把这篇收成三句话：一句话可能有很多份，命中的那一份由设备语言决定；能改的只有"会被编进资源表的那一份"，直接替换包里的文件既不生效、也会破坏签名；只改中文就直奔中文那一份，别顺手动默认版。 这三条想清楚，多语言改包就不再是"玄学"，而是一道有标准答案的判断题。

回头看，工具在这条链路上做的其实是"把判断之外的事全部自动化"：反编译让语言版本可见，附件与需求文本让范围可描述，标志文件让等待可感知，四步流水线让回编签名可依赖，装机链路让验收可完成。你要做的只剩下两件人类最擅长的事 —— 说清楚要改什么、看一眼前面是不是你想要的样子。

于是回到那句口号 —— 只需说话，就能让应用变成你想要的样子。多语言这件事恰好是它最好的注脚：过去要跨过资源表、语言限定符、签名三个门槛才能完成的事，现在被折叠成一句写清了范围的中文需求。产品介绍页与下载入口：https://www.apkeditor.cn/ai-version.aspx（官网 www.apkeditor.cn）。