android如何将汉字转为url编码：一次讲清编码选择与实现
在 Android 里把汉字拼进 URL 查询参数，看起来只是调一个方法的事，实际却经常遇到服务端收到乱码、加号变成空格、路径里的中文被截断等问题。典型场景包括搜索关键词拼接、分享链接生成、WebView 跳转以及对接第三方接口。下面从编码选择讲到具体写法，再梳理容易出错的环节，帮助你写出行为稳定的转换逻辑。
在线工具URL编码
先想清楚：汉字在 URL 里到底该变成什么
URL 规范只允许一部分 ASCII 字符直接出现，汉字属于非 ASCII 字符，必须先按某种字符集转成字节，再把每个字节写成百分号加十六进制形式。这里有两个决定：用哪种字符集、以及编码后空格如何处理。
字符集选 UTF-8 是当下通行的做法，服务端和浏览器基本都按它解析。如果沿用旧项目里的 GBK，跨端联调时很容易出现一边正常一边乱码。空格在查询参数里通常写成 %20，而表单提交习惯用 + 表示空格，两者在不同场景下会被区别对待，这一点后面会细说。
还要区分 URL 的不同部分：查询参数的值、路径片段、整个 URL 字符串，编码规则并不完全一样。把整条 URL 一股脑丢进编码方法，会把 ://、?、& 这些分隔符也转义掉，链接直接失效。正确做法是只对需要转义的那一段做处理。
用 URLEncoder 处理查询参数
Android 自带 URLEncoder，它是处理查询参数值最直接的工具。使用前确认项目已能正常引用标准库，这一步不需要额外依赖。
第一步，确定待编码的原始字符串，比如用户输入的搜索词。第二步，调用 URLEncoder.encode(value, "UTF-8")，第二个参数必须显式传字符集名，不要用已废弃的单参数重载，那个版本依赖平台默认编码，在不同设备上结果可能不一致。第三步，检查返回值中的空格是否变成了 +。如果目标接口要求 %20，把结果里的 + 替换掉即可。第四步，把编码后的片段拼进完整的 URL，拼接时保留原有的分隔符。
一个容易忽略的点：URLEncoder 的设计初衷是处理表单数据，它对空格输出 +，对 * 等符号的处理也和严格的 URL 编码有差异。对接要求严格的接口时，最好在编码后再做一次针对性替换。
另外，编码方法会抛出异常，虽然指定了 UTF-8 后实际很少触发，但仍要按编译要求处理，不要用空的捕获块吞掉。
路径中的汉字与 Uri 的配合
如果汉字出现在路径里而不是查询参数里，URLEncoder 就不太合适了，它会把斜杠也编码掉。Android 提供了 Uri.encode，可以只对路径片段做转义，保留分隔结构。
用法上，先构造路径片段字符串，再调用 Uri.encode(segment)，然后把结果拼到路径位置。查询参数同样可以用它处理，但要注意它默认不会把空格转成 +，而是保留为 %20 形式，这恰好符合很多 REST 接口的预期。
选择哪种方式，取决于你拼的是表单风格还是标准 URL 风格。团队内部最好统一约定，避免同一个项目里两种写法混用，导致联调时反复确认。
常见错误与排查思路
服务端收到乱码，先看两端字符集是否一致。客户端用 UTF-8 编码，服务端却按 ISO-8859-1 解码，汉字必然错乱。排查时可以打印编码后的字符串，确认百分号序列是否符合 UTF-8 的字节特征。
链接里的加号变成空格，多半是服务端把 + 当成了表单空格。解决办法是在编码后把 + 替换为 %20，或者让服务端按原始查询串解析。
还有一种情况是重复编码：某段文字已经被编码过一次，又被整体编码一遍，百分号本身变成了 %25，服务端解出来仍是乱码。检查数据流经的每一层，确认只编码一次。
如果中文被截断或出现问号，留意是否在编码前就发生了字符集转换错误，比如从字节数组构造字符串时用错了字符集。这类问题往往出现在文件读取或网络响应解析环节，而不是编码方法本身。
写一个可复用的小工具
与其在每个调用点重复写编码逻辑，不如封装一个方法，内部固定使用 UTF-8，并统一处理空格替换。方法签名接收原始字符串，返回编码后的片段，调用方只负责拼接。
封装时把异常转换成明确的失败信号，比如返回空值或抛出带说明的异常，避免上层拿到半成品字符串。还可以加一个重载，允许调用方选择是否把空格转成 +，以适配不同接口。
测试环节值得单独列出来：准备包含汉字、空格、特殊符号和英文混合的样例，逐一验证编码结果能被服务端正确还原。这样后续改动时也有回归依据。
总结
在 Android 中把汉字转成 URL 编码，核心是选定 UTF-8 字符集，只对需要转义的片段调用 URLEncoder 或 Uri.encode，并注意空格是输出加号还是 %20。拼接时保留原有分隔符，排查时优先核对两端字符集和是否重复编码。
相关文章
- base64编码自定义方法：何时需要自己动手实现
探讨在标准库不适用时，如何设计符合特定需求的base64编码自定义方法，包括字符集替换、填充策略与流式处理思路。
- base64编码能转成字节输出流吗？
解释base64编码能转成字节输出流的含义、常见场景与解码注意点，帮助开发者在传输与存储环节正确还原原始数据。
- base64编码能解决什么问题？从传输到存储的实用解析
探讨base64编码在文本协议传输、数据嵌入等场景中的实际作用，并给出编码操作与错误排查的步骤。
- base64编码能存在空格吗？答案与处理建议
标准Base64字符表里没有空格，但实际数据中常混入换行、空白。本文说明空格从哪来、如何判断和清理，以及解码失败的排查思路。
- base64编码翻译：从困惑到清晰
理解base64编码翻译，掌握数据转换的要点与常见误区，让开发者不再困惑。
常见问题
Q1为什么编码后的汉字是一长串百分号，服务端却说是乱码？
先确认两端字符集一致。客户端用 UTF-8 编码，服务端也必须按 UTF-8 解码。若服务端按其他字符集解析，百分号序列会被错误还原，表现为乱码。
Q2URLEncoder 把空格变成了加号，接口不认怎么办？
这是表单编码的约定。把结果中的加号替换为 %20 即可，或者改用 Uri.encode 处理，它默认输出 %20 形式。
Q3能不能直接对整个 URL 调用编码方法？
不建议。整条 URL 编码会把冒号、斜杠、问号、与号等分隔符一并转义，链接结构被破坏。只对需要转义的参数值或路径片段处理。
Q4编码后的字符串又被编码了一次会怎样？
百分号会被再次转义，服务端解码后得到的仍是编码形态而不是原文。检查数据经过的每一层，确保只编码一次。
Q5路径里的汉字和查询参数里的汉字处理方式一样吗？
不完全一样。查询参数常用 URLEncoder 或 Uri.encode，路径片段更适合用 Uri.encode 保留斜杠结构，避免分隔符被误转义。