浏览器地址栏出现一串熟悉的文字，字体、字形甚至整行长度都与常用入口相近。复制到文本工具后，却发现某个字母来自另一套文字，或者浏览器把主机转换成以 xn-- 开头的 ASCII 标签。画面相似，不等于地址相同。
国际化域名允许域名标签使用 Unicode 表示，让不同语言的使用者可以读到本地文字。浏览器和域名系统之间仍需要一套可处理的 ASCII 表示。核对入口时，必须把可见 Unicode、转换后的 ASCII 标签和最终解析主机分开记录。
先把“看起来一样”拆成字符序列
Unicode Technical Standard #39 把标识符视为指向特定实体的字符串，并说明不同字符序列可能在人眼看来非常接近。拉丁字母 a、希腊或西里尔文字中的近似字形，在某些字体和字号下几乎无法靠肉眼区分；全角、组合字符和不可见控制符也会改变底层序列。
第一步不是猜哪一个字符有问题，而是复制完整主机，保留原始字符串，再用能显示码位或脚本类别的工具查看。截图只能保留渲染结果，不能证明底层字符。手工重新输入也可能把可疑字符改成自己熟悉的字符，因此不能替代复制记录。
这项检查也要保留语言边界。UTS #39 指出，ZWNJ 和 ZWJ 在波斯文等语言中可能是正常文字所需；波斯文示例里，零宽非连接符会改变连写并区分词义。不可见不等于恶意，正确做法是判断它在当前语言和标识符政策中是否被允许，而不是把所有控制符一律删除。
Unicode 标签与 ASCII 标签是两种表示
WHATWG URL 标准规定，域名解析会使用相应的 ToASCII 处理，并定义将已解析域名显示为 Unicode 的过程。浏览器可能选择显示本地文字，也可能在风险较高时显示 ASCII 兼容编码。二者可能表示同一个已解析域名，也可能暴露出原先肉眼没有注意的差异。
记录时至少保留三列：地址栏原样、规范化 Unicode 主机、ASCII 主机。若 ASCII 主机不同，两个入口就不是同一域名标签；若 ASCII 主机相同，仍只能说明域名表示收敛，不能证明页面内容、所有者或业务可信。
路径和页面标题不能补救主机差异。两个页面都写“登录中心”，路径都含有 /auth/login，也不会因此成为同一来源。HTTP 与 HTTPS 的来源由协议、主机和端口组成；其中任一项改变，就应作为不同来源处理。
混淆检测是筛查，不是信誉结论
UTS #39 提供同脚本、混合脚本和整套脚本混淆检测。它适合指出两个字符串视觉接近或脚本组合异常，却明确不能消除所有混淆。检测没有报警，不代表入口可靠；检测报警也不等于该字符串一定用于欺骗。
受控比较可以说明这个边界。入口甲使用本地语言字符，转换后的 ASCII 标签与机构公布入口一致，证书主机和保存书签也一致。入口乙视觉上只差一个字形，ASCII 标签不同，证书对应另一个主机。即使两页布局完全相同，乙也不能因“看起来一样”被视为甲。
另一个反例是合法多语言品牌可能注册多个不同域名，再把它们重定向到同一主站。不同主机不自动表示恶意，但使用者应先从已保存书签、正式文档或可信目录确认关系，不能靠页面自己声称“官方”来证明。
从右到左文字要单独读主机边界
波斯语与英文、数字混排时，视觉顺序可能与字符存储顺序不同。WHATWG URL 标准特别提醒双向文字会让主机和路径边界更容易混淆，并建议在需要作出信任判断时突出主机。
因此不要沿着整行视觉顺序猜斜线属于哪里。把协议、主机、端口、路径分别复制到独立字段，主机按左到右隔离方式显示，再比较 ASCII 标签。问号后的查询参数和井号后的片段不参与主机身份，却可能让地址更长、更难看清。
移动设备地址栏经常省略协议、路径或部分子域名。此时应展开完整地址，或从页面信息中复制，而不是只依据被折叠的品牌文字。二维码也要先解码查看目标地址，再决定是否打开。
四步核对一个国际化入口
第一，保存完整原始 URL，不用截图或手工重打替代。第二，提取协议、主机和端口，分别记录 Unicode 与 ASCII 主机。第三，检查脚本混用、混淆字符和双向边界，同时保留正常语言字符的可能性。第四，从已知可信入口确认域名关系，并检查跳转后的最终主机。
若任务涉及登录、下载、付款或提交个人资料，核对标准应更严格。证书有效只表示当前连接对该主机建立了加密验证，不证明该主机就是使用者原本想访问的组织。相似页面、相同图标和 HTTPS 锁形图标都不能代替主机比较。
把结果写成可复查记录：原始地址、ASCII 主机、最终地址、确认来源、观察时间。这样另一位读者可以复现，不必依赖“当时看起来像”的记忆。
结论停在地址身份
国际化域名的价值是让本地语言进入地址系统，风险来自字符丰富度与人类视觉判断之间的落差。把 Unicode 字符、ASCII 标签和来源元组分层，不是要排斥非拉丁文字，而是让不同语言的入口都能用同一套结构核对。
这套方法可以判断两个地址是否具有相同技术来源，并发现需要进一步确认的混淆信号。它不能单凭字符串证明网站信誉，也不能把所有不同脚本组合定性为攻击。最终信任仍需结合已知入口、域名关系和具体任务风险。
资料依据：Unicode Consortium《Unicode Security Mechanisms》；WHATWG《URL Standard》。两份规范用于解释字符、域名表示和来源边界，不评价任何具体网站。
核对结果若需要交给他人，最好同时保存纯文本 ASCII 主机和原始 Unicode 字符串。只保存一个经过软件自动规范化的版本，会丢掉当时看到的输入；只保存截图，又无法重新计算字符与主机。两份记录共同保留，才能复查转换过程。
如果浏览器、邮件客户端和二维码扫描器显示结果不同，不要挑最顺眼的一种作为答案。分别记录各工具输出，再以域名解析后的主机和可信入口为基准解释差异。
资料来源
- Unicode Consortium：《Unicode Security Mechanisms, Unicode Technical Standard #39》，发布或更新于 2025-09-04
- WHATWG：《URL Standard》，发布或更新于 2026-07-06