上个月我把 Gemini Assistant 生成的一段数据类代码直接复制进 Android 项目编译瞬间就报error: illegal character。我盯着代码来回看了两遍愣是没找到问题在哪。把光标挪到报错的那一行才发现一个完全看不见的字符插在空格和逗号之间。这不是个例——Android Studio 内置的 Gemini Assistant包括后来的 Agent 模式在代码块里显示各种“怪符号”已经是我在社区帖子和身边同事工位上反复看到的现象。这篇文章就把我这几天从“看着不对”到“编译报错”的完整排查过程整理出来先分类、再定位、后修复最后讲讲怎么从提示词和操作习惯上预防。只要你在 Android Studio 里用 AI 辅助写代码这篇应该都值得存一份。1. 先给“乱码符号”分类显示问题还是真实字符问题1.1 四类最常撞见的“怪符号”Gemini Assistant 代码块里的怪符号看起来都是“乱码”但成因完全不是一回事。我在实际排查里发现它们大致落在下面四类里。先看清楚是哪一类后面才能对症下药。表现常见 Unicode 字符一句话判断代码里出现·、␣、↹、¶U00A0、U2422、U21B9、U00B6大概率是编辑器“显示空白符”功能被打开了编译报 illegal character肉眼却完全看不出来U200B 零宽空格、U2060 单词连接符、UFEFF BOM真实数据污染字符真的写进了文件引号变成“”、‘’破折号变成—U201C/U201D、U2013/U2014模型输出或富文本复制带了“智能标点”代码块里冒出**、##、等标记普通 ASCII 符号Markdown 没有被正确剥离一串□、、’这类可见乱码UFFFD、字形缺失、编码错位字体不支持或文件编码混乱这里最容易踩的坑是把“显示层问题”当成“数据层问题”或者反过来。比如看到一堆□你以为是数据坏了其实文件内容完全正常只是当前字体没有对应字形又比如看到一段专门处理零宽空格的代码以为只是显示怪结果编译直接断了。我的建议是凡是报错位置指向行首或行尾附近、但你肉眼找不到异常字符的情况都先按数据污染处理。1.2 判断原则先怀疑显示层再怀疑数据层判断顺序其实很简单先把符号从 Gemini Assistant 面板复制到 Android Studio 的编辑器里看看现象还在不在。如果符号只在聊天面板或代码块预览里出现复制到编辑器后一切正常那基本可以确定是 Gemini 面板内部 WebView 的字体渲染问题。后续主要动字体设置就行。如果复制进编辑器后符号仍然在并且编译报错那就是真数据污染。接下来要做的不是换字体而是把字符找出来、清掉。还有一种中间态内容本身是合法字符但 Windows 中文环境下文件编码是 GBK粘贴进去后被错误解析成乱码。这种最容易和纯粹的字体问题混淆我后面专门讲。先搞清楚这一点能帮你省掉至少一半的无效操作。我自己一开始就在“换字体”上折腾了大半天后来发现文件里那个字符压根不是字体能解决的。2. 一步步做字符体检从肉眼到码点的完整排查链路2.1 编辑器内正则扫射30 秒定位不可见字符拿到一段可疑代码最直接的办法就是让编辑器自己把问题字符“揪”出来。在 Android Studio 里按CtrlShiftFWindows/Linux或CmdShiftFmacOS打开全局查找切到正则模式搜索[\x00-\x1F\x7F\u200B-\u200D\u2060\uFEFF\u00AD]这一串正则会匹配控制字符、零宽空格、零宽连接符、单词连接符、BOM 和软连字符。如果搜索有命中说明代码里确实藏着肉眼不可见或半可见的字符。把搜索范围限定到当前文件看到命中位置后直接跳过去大概率就是编译报错的那个点。更粗暴一点的写法是直接搜\p{C}它匹配 Unicode 里所有“不可见控制类字符”范围更广可能把正常文本里的换行符也搜进来但用来做地毯式排查很高效。搜出来之后结合报错位置再进一步确认。2.2 用 Python 脚本把可疑字符的 Unicode 码点打出来正则能告诉你字符存在但不能告诉你它具体是什么字符。遇到命中结果多且零散的情况我习惯写个十行左右的 Python 脚本把文件里所有可疑字符的码点、Unicode 名称和所在行都列出来。假设你要检查的是MainActivity.kt把下面这段存成inspect_chars.py放到项目根目录跑一下from pathlib import Path import unicodedata path Path(MainActivity.kt) text path.read_text(encodingutf-8) for line_no, line in enumerate(text.splitlines(), 1): for ch in line: if ch in ( , \t): continue cat unicodedata.category(ch) # Cc控制符 Cf格式符 Co私人用区 或直接当作非 ASCII 处理 if cat in (Cc, Cf, Co) or ord(ch) 127: name unicodedata.name(ch, ?) print(fline {line_no}: U{ord(ch):04X} [{cat}] {name} - {ch!r})输出会类似这样line 23: U200B [Cf] ZERO WIDTH SPACE - \u200b line 23: U2019 [Po] RIGHT SINGLE QUOTATION MARK - \u2019看到U200B这种结果就别再纠结是显示问题了这个字符已经被 Clean Code 标准认定为看不见的“脏数据”直接处理掉。这个脚本对 Gradle 脚本、XML 布局文件、以及任何 Gemini Assistant 生成的文本文件都适用不只是 Kotlin。2.3 编译器报错位置是最诚实的证据有时候你拿不准该不该信编辑器里显示的“乱码”最佳参考对象其实是编译器。Android 项目里最常见的场景是 Kotlin 编译器直接报error: illegal character而且报错信息会精确到行有时候还会在当前字符下面画条波浪线。但这里有个反直觉的地方报错光标很多时候并不落在那个不可见字符上而是落在紧挨着它的下一个可显示字符上。你看到光标指着一个正常的逗号或右括号就以为问题在逗号上来回删改半天其实真正的元凶是逗号前面那个零宽空格。所以遇到这种报错别急着改可见字符先把那一整行复制出来放进 2.2 的脚本里扫一遍码点或者直接用编辑器正则搜那一行的所有不可见字符。编译器的报错是“结果”字符体检才是“原因”。2.4 文件编码检查GBK/UTF-8 错位是怎么来的如果你在 Windows 上开发、Android Studio 界面又设置成了中文还有一个非常隐蔽的来源文件编码不是 UTF-8但 Gemini Assistant 面板标准输出的是 UTF-8 字符。举个真实例子Gemini 输出的字符串里带了一个弯引号’U2019这个字符在 UTF-8 下是三个字节E2 80 99。如果你的.kt文件实际编码是 GBK三个字节会被拆成 GBK 里的两个字符显示出来就是’这种怪东西。原文UTF-8 字节GBK 下误读显示’(U2019)E2 80 99’“(U201C)E2 80 9C“零宽空格 (U200B)E2 80 8B​怎么快速判断看 Android Studio 窗口右下角的编码指示器。如果显示的不是UTF-8而是GBK或windows-1252之类那问题就可能是编码错位。处理方式是点右下角编码按钮选择UTF-8弹窗后选Convert不要选Reload。Reload 会重新按新编码读取并可能破坏原本的文件内容Convert 才是把内容重新保存成 UTF-8 的正确操作。3. 深挖源头Gemini Assistant 与 Agent 产生怪符号的几条真实路径3.1 大模型默认输出的智能标点和 Markdown 残留很多用户以为“代码块”就是纯代码其实并非如此。Gemini Assistant 在聊天面板里的输出本质上是 Markdown 渲染结果它给代码加语法高亮、加代码块围栏、加粗重点内容这些都是渲染层行为。当你点击代码块上的“复制”按钮时绝大多数情况复制到的是纯文本代码但偶尔会把这些 Markdown 控制符号一起带出来。更让人头疼的是“智能标点”。大模型的训练语料里充满了出版级排版字符比如弯引号、长破折号、短破折号。模型在生成Hello时理论上应该输出 ASCII 双引号但如果你不明确要求它可能输出“Hello”。这在普通文本里无所谓一旦进入 Kotlin 或 Java 代码编译器只会认为你写了一个未知字符。我见过最离谱的一个例子是 Gemini 在生成 Gradle 依赖配置时把implementation com.example:lib:1.0.0里的单引号换成了 U2018/U2019Gradle 直接拒绝执行。3.2 Agent 直接改文件时patch 里的隐藏字符会原样落盘Gemini Assistant 的 Agent 模式会直接操作你的工程文件不是简单地在面板里给代码让你复制而是通过“编辑文件”的方式把改动应用进去。这带来了一个不同于手动复制的问题Agent 生成的补丁里如果带隐藏字符它们会原样写入磁盘。中间没有剪贴板、没有人工审查、没有格式转换模型吐出来什么文件里就是什么。大部分情况下这是好事因为太方便了。但隐患在于Agent 的改动会绕过你平时在复制粘贴时养成的“看一眼再贴”的习惯。它的代码块预览里如果出现了零宽空格或智能引号你点“Apply”之后这些字符就安静地混进你的代码里。等到编译报错你甚至不记得是哪一次让 Agent 动过文件。所以我现在的原则是Agent 改完文件先到 Version Control 的 Local Changes 里看一眼 diff再继续下一步动作。3.3 聊天面板和编辑器字体不一致导致的“假乱码”还有一类情况代码块里的符号看着很吓人但实际数据是干净的。Android Studio 的 Gemini Assistant 面板用的是内嵌的 WebView 渲染它用的字体栈和编辑器字体完全是两套逻辑。编辑器里 JetBrains Mono、新宋体、微软雅黑等字体可以自由配置但 WebView 内部只能用 Chromium 自己的默认字体和系统回退。在中文 Windows 系统上WebView 对某些特殊 Unicode 字形的回退经常失败结果就是代码块里出现□、空方块、或者看起来像乱码的占位块。判断方法是标题 1.2 那句老话复制到编辑器里看。如果数据层没问题那这就是一个纯粹的“观感问题”。解决浏览器/WebView 内部字体要等 Android Studio 后续版本改善但你可以通过调整编辑器字体让最终进入工程的那份代码显示得足够舒服。3.4 中文输入法、全角符号和剪贴板格式的“三连坑”在中国开发者环境里还有三个坑经常叠在一起出现。第一个坑是中文 Windows 的默认输入法。用户在 Gemini Assistant 里用中文写提示词有时输入法正处于全角模式于是打出来的逗号是、括号是、引号是“”。这些全角字符会进入提示词上下文模型看着样例里全都是全角标点生成代码时也可能“学坏”。第二个坑是剪贴板格式。从 WebView 面板复制内容时Windows 剪贴板里同时存在纯文本和 HTML 富文本两种格式。默认CtrlV粘贴时Android Studio 有时会把 HTML 格式一起带上导致粘贴结果多出不可见样式信息或特殊字符。最稳妥的做法是使用“粘贴为纯文本”后面我会给具体快捷键。第三个坑是语言混合。Android Studio 界面中文版 系统输入法中文 代码文件 GBK 编码三个因素单独看都不致命组合在一起一次简单的“从 Gemini 复制字符串资源到 strings.xml”的操作就可能制造出顽固乱码。很多新人卡在’这种字符上大半天实际上就是编码和输入法共同作用的结果。4. 修复实操从关闭渲染开关到正则清洗的完整工具箱4.1 先关掉“显示空白符”相关设置排除视觉干扰先检查一个最容易被忽略的设置。Android Studio 的编辑器有一个“显示空白符”功能开启后会把空格、制表符、换行符都用特殊符号画出来比如空格显示成·、tab 显示成→、换行显示成¶。普通空格小声说tab 小声说但这些符号对不熟悉的人影响很大——你会觉得“代码块里全是怪符号”。关掉它的路径是Settings Editor General Appearance把Show whitespace的勾选去掉或者点旁边的设置图标只勾选你确实需要看的那几项比如Leading、Trailing。如果你之前不小心按到某些切换快捷键也可能开启这个模式检查一下就能恢复正常的代码显示。4.2 换字体不是玄学哪个环节最需要它Android Studio 编辑器字体设置在Settings Editor Font。如果你发现编辑器里代码的某些字形显示成方块常规操作是选择一个覆盖字符范围广的等宽字体比如 JetBrains Mono、Source Code Pro 或更纱黑体。设置好Fallback font回退字体。Android Studio 的字体设置里可以指定回退字体当主字体缺少某个字形时会从回退字体里找。常见设置为“JetBrains Mono Microsoft YaHei UI”的组合基本能覆盖 ASCII 和常用 CJK。需要特别说明的是这个设置只能解决“编辑器里文件内容的字形缺失”不能解决 Gemini Assistant 面板内部的字形缺失。面板是 WebView走的是另一套渲染链路。如果你看到的怪符号只存在于代码块预览里复制到编辑器后消失那就别在编辑器字体设置里白费力气了。4.3 纯文本粘贴的快捷键与正确姿势从 Gemini 面板复制代码后不要直接CtrlV改用“粘贴为纯文本”。Android Studio 的默认快捷键是平台快捷键Windows / LinuxCtrlAltShiftVmacOSCmdAltShiftV粘贴后如果弹出一个选择框选Plain Text。这个操作会把剪贴板里的 HTML 富文本信息全部丢弃只保留纯字符内容。它能解决富文本格式污染但要注意如果字符本身就是智能引号或零宽空格纯文本粘贴并不会帮你把字符“翻译”成 ASCII那些字符在你按下粘贴键之后依然存在。所以“纯文本粘贴”是必要的一步但不是完整方案得配合下面的正则清理。4.4 正则批量清理几组可直接用的表达式面对已经污染的文件我通常用 Replace in Files 做批量清理。入口是CtrlShiftRWindows/Linux或CmdShiftRmacOS开启 Regex选择当前文件或整个项目目录。下面是我日常清理时直接抄用的替换表目标正则表达式替换为零宽空格、零宽连接符、BOM[\u200B-\u200D\u2060\uFEFF]留空软连字符\u00AD留空不换行空格\u00A0普通空格智能双引号[\u201C\u201D]智能单引号[\u2018\u2019\u02BC]长破折号、短破折号[\u2013\u2014]-不可见控制字符[\x00-\x08\x0B\x0C\x0E-\x1F\x7F]留空有人会问全角字符要不要替换比如、、。我的建议是分场景处理如果出现在 Kotlin/Java 代码的语法位置肯定要换回半角但如果在字符串字面量或注释里尤其是中文文案里全角字符可能是合法的直接批量替换会破坏文案内容。所以全角字符不要无脑全局替换最好看完匹配上下文再手动决定。批量替换前确保你的改动在 Git 控制之下或者至少备份一份。替换完成后直接用 2.1 的正则再搜一次确认命中数为零才算清理干净。4.5 Reformat Code Inspect Code官方组合拳清理完不可见字符后再做一个收尾动作Code Reformat Code快捷键CtrlAltL/CmdAltL。它能统一缩进、空格、换行符风格把之前混乱的排版恢复成一个标准状态。注意它不会自动删除非法字符但能让文件“视觉上看起来正常”为后续检查制造一个干净的基线。接着跑一遍Analyze Inspect Code让 Android Studio 的静态检查扫一遍。Inspect Code能在编译之前告诉你哪里的字符串字面量包含了可能混淆的字符哪里的代码风格不符合规范。有些版本还会对弯引号给出 “Convert to plain ASCII” 一类的 Quick Fix点一下就能把当前文件里的弯引号批量转成 ASCII。这个组合拳不能保证改掉所有“人造脏数据”但用来兜底很有效。4.6 最省事的是不让它发生用 Apply 而不是 Copy聊完所有修复手段我想强调一个从源头切断问题的方式优先使用 Gemini Assistant/Gemini Agent 代码块上的“Apply”或“Insert at Cursor”按钮而不是“Copy”。当你点 Copy数据要经过WebView → 系统剪贴板 → 编辑器粘贴解析中间每一环都可能引入格式或编码污染。而点 Apply 或 Insert 时Android Studio 直接通过编辑器 API 把模型返回的内容写入缓冲区绕过了剪贴板也绕过了富文本格式转换。对 Agent 模式来说直接在 diff 里 Review 再 Apply比“把代码拷到编辑器再自己合进去”更安全。在实际操作里我碰到 Gemini 面板右上角有“打开文件”“插入到编辑器”“应用”等按钮时第一选择永远是那些按钮只有找不到任何插入入口时才会退而求其次复制并且复制后立刻用纯文本粘贴。5. 防患于未然让 Gemini 少产出、不残留的提示词与习惯5.1 提示词里写清楚“只要纯代码不要 Markdown”被坑过几次之后我在每次让 Gemini Assistant 或者 Agent 生成代码时都会在提示词里加一段明确要求请用纯 Kotlin 输出不要使用任何 Markdown 格式包括代码围栏、粗体、列表标记。 所有字符串使用 ASCII 双引号不要使用弯引号和长破折号。 不要生成任何不可见的 Unicode 字符例如零宽空格、BOM、软连字符。 一次只给一段代码不要附加解释。这段提示词不是百分百可靠但确实能让模型少犯至少一半的“排版病”。尤其是在长对话里刚开始两句模型还记得遵守后来会慢慢放松我一般每隔几轮就会重申一次“remember: ASCII quotes only, no Markdown”。如果你用的是 Agent 模式在描述任务时也顺手加一句“修改文件时不要引入额外 Unicode 字符所有新增代码使用 ASCII 标点”Agent 在生成 patch 时会更小心。5.2 检查 Agent 改动的 diff别直接 trustAgent 模式的省事程度恰恰是它的风险点。它直接改文件你如果不看 diff等于是把一个黑盒写进项目。最好的做法是Agent 报告改完任务后打开Version Control Local Changes。逐个文件双击看 diff。重点关注新增行里是否有非 ASCII 字符以及是否出现了 Gemini 面板里同样的“怪符号”。有任何不确定就用第 2 章的 Python 脚本扫一遍改动文件。我现在养成的习惯是Agent 每完成一个阶段我先在 diff 里确认改动符合预期再让编译跑一轮。这样即便它偷偷塞了零宽空格我也能第一时间发现而不用等 CI 跑到一半才开始往回追。5.3 把编码和自动清理做成工程规范个人设置只能保护你自己的机器保护不了整个团队。更稳妥的做法是把编码规范写进工程配置。在项目根目录创建或更新.editorconfigroot true [*] charset utf-8 end_of_line lf insert_final_newline true trim_trailing_whitespace true [*.{kt,java,xml,gradle}] indent_size 4同时在Settings Editor File Encodings里把 Global Encoding、Project Encoding 和 Properties Files 都设为 UTF-8。.editorconfig的最大价值在于它随项目走团队成员不管用 Windows 还是 macOS打开文件后 IDE 会自动应用这套编码和换行规则。这样 Gemini Assistant 复制出来的一块代码即使带着系统默认的换行差异在保存时也会被统一成规范里的格式很大程度上减少了 CRLF 与 LF 混淆导致的显示问题。5.4 额外提醒隐藏字符不只是烦还可能是安全缺口最后说一个容易被忽视的点。隐藏字符不只是“编译报错”这么简单某些 Unicode 控制字符可以改变代码的视觉顺序。比如双向文本控制符能让一行代码在编辑器里看起来是一种顺序实际执行却是另一种顺序。这种手法在开源社区被讨论过很多次原理同样适用于 AI 生成的代码如果你从不可信的来源包括被污染的提示词拿到代码里面混入几个方向控制符肉眼很难发现。所以我在清理时有一个额外动作用 2.1 的正则搜完不可见字符之后再搜一遍[\u202A-\u202E\u2066-\u2069]双向文本控制符区间。正常项目里这个区间几乎不可能出现一旦出现基本可以确定代码来源有问题直接改写而不是尝试保留。到现在为止这件事已经被我固化成了固定流程Gemini/Agent 出代码 → 优先点 Apply/Insert 按钮 → 在 Local Changes 里看一眼 diff → 用正则搜一遍零宽字符和双向控制符 → 编译确认。整个过程加起来不到二十秒但已经很久没被这种“看不见的问题”再坑过一次。你要是也遇到代码块里乱冒符号先从第 2 章的字符体检脚本开始基本五分钟内能判断出到底是显示层的字体问题还是文件里的数据污染。