QR 码默认编码任意字符串，扫描后仅原样显示；若希望其中的 URL 被识别为可点击链接并自动唤起浏览器，需在生成端遵循 URI Scheme 规范（如 https:// 单独编码），而非混入普通文本——zxing 本身不决定扫描行为，终端扫码 App 的解析逻辑才是关键。
qr 码默认编码任意字符串，扫描后仅原样显示；若希望其中的 url 被识别为可点击链接并自动唤起浏览器，需在生成端遵循 uri scheme 规范（如 `https://` 单独编码），而非混入普通文本——zxing 本身不决定扫描行为，终端扫码 app 的解析逻辑才是关键。
要实现“扫描后自动跳转 URL，同时保留其他文本信息”，核心前提必须明确：标准 QR 扫码器（如微信、支付宝、iOS 相机、Google Lens）仅对符合 URI 格式的独立有效 URL 做智能识别与唤起处理；它们不会主动从一段混合文本中提取并高亮链接。因此，"ABCD https://www.google.com fgh" 这类复合字符串被扫码后，绝大多数 App 会直接显示整段文本，而不会自动点击中间的 URL。
✅ 正确做法是：将 URL 单独编码为 QR 码内容，这是唯一能可靠触发系统级跳转的方式。若业务上必须“同时携带非 URL 文本”，则需采用分层设计：
方案一：双模式 QR 码（推荐）
生成两个 QR 码：
- 主 QR 码：仅含
https://www.google.com→ 扫描即跳转； - 辅助信息（如
"ABCD XYZ"）以明文印在二维码旁，或通过短链服务嵌入 URL 的 query 参数中（见下文）。
// ✅ 正确：只编码 URL —— 确保被识别为可点击链接 String urlOnly = "https://www.google.com"; BitMatrix bitMatrix = qrCodeWriter.encode(urlOnly, BarcodeFormat.QR_CODE, width, height, hints);
方案二：URL + 参数承载上下文（EMVco 兼容）
若你使用 EMVco 规范（如支付场景），其标准要求 URL 作为主指令，其余字段（如 ABCD、XYZ）应作为查询参数附加，构成完整 URI：
// 示例：构造带业务参数的标准 URI（符合 EMVco/URI Scheme）
String baseUrl = "https://www.example.com/pay";
String payload = "ABCD";
String suffix = "XYZ";
String fullUri = String.format("%s?ref=%s&tag=%s",
baseUrl,
URLEncoder.encode(payload, "UTF-8"),
URLEncoder.encode(suffix, "UTF-8")
);
// 编码该 URI —— 扫码后将打开网页，并由后端或前端解析参数
BitMatrix bitMatrix = qrCodeWriter.encode(fullUri, BarcodeFormat.QR_CODE, width, height, hints);⚠️ 注意：
URLEncoder是必需的，避免空格、、<code>>等非法字符破坏 URI 结构；EMVco 明确禁止在 URL 前后添加<code>>符号或多余空格。
❌ 为什么你的原始代码无效？
-
ABCD https://www.google.com fgh是纯文本，不是合法 URI； - zxing 只负责“画图”，不解析语义；扫码 App 收到的是字节流，按 MIME 类型（默认
text/plain）渲染； - 即使正则提取出 URL（如答案中
split("\s+")），那也只是应用层后处理逻辑，无法改变扫码器初始行为——它仍先显示整段文本。
补充：扫码端适配建议
- 在移动端 Web 或 App 中，可监听扫码结果，用 JavaScript 自动检测并跳转：
const result = "ABCD https://www.google.com fgh"; const urlMatch = result.match(/https?://[^s]+/); if (urlMatch) window.open(urlMatch[0], '_system');
但这属于客户端增强，不改变原生扫码体验。
总结：QR 码的本质是数据载体，不是富文本渲染器。要获得“点击跳转”体验，请始终编码一个有效的、独立的 URI 字符串。 混合文本 + URL 的需求，应通过参数化 URL、双码协同或客户端解析来实现，而非依赖扫码器智能提取。
