多语言页面看起来相同，为什么根域入口仍可能不是同一个地址

两个页面都写着相同的多语言名称，标题中的波斯文、中文与拉丁字母看起来也一致。读者复制入口后，却发现一个地址栏显示国际化字符，另一个显示以xn--开头的ASCII形式，重定向终点还可能落在不同主机。此时不能只问“字看起来是不是一样”，而要问浏览器究竟解析出了什么。

页面文字不是网络身份

页面标题、按钮和说明文字由网页作者控制。它们可以使用任何语言，也可以在不同网站重复。品牌文字相同，只能说明两段可见内容相似，不能证明域名、证书或运营主体相同。

地址栏主机属于URL结构。浏览器会把输入拆成方案、主机、端口、路径、查询等组成部分。真正影响同源边界的是解析后的结构，不是页面上自己写出的名称。

这一区别在多语言环境更重要。字形可能相似，字符编码可能不同；同一字符序列又可能因字体、方向和连接行为呈现不同。肉眼观察是入口核对的一层，但不是唯一一层。

波斯文连接控制符为何既正常又敏感

Unicode UTS #39说明，零宽非连接符ZWNJ与零宽连接符ZWJ在若干语言中有真实正字法用途。波斯文示例显示，插入ZWNJ会阻断草写连接，并可区分两个不同词义。把所有不可见控制符一律删除，会破坏正常文字。

但不可见差异在标识符中会增加风险。UAX #31指出，连接控制符属于默认可忽略字符；在通用标识符中，它们可能让两串看起来相同的文字拥有不同代码点序列。若某个应用领域没有明确语言需求，配置通常应排除这些字符。

这不是“全部允许”与“全部禁止”的二选一。自然语言段落需要尊重语言规则，账号、文件名和域名则需要更严格的上下文限制。核对入口时必须先确认当前对象是哪一种。

域名里的ZWNJ受上下文规则约束

RFC 5892把U+200C ZWNJ列为CONTEXTJ。它不是在域名标签任何位置都自动有效，只有建立相应规则且字符所在上下文满足条件时，注册或查询才可接受。

RFC附录同样承认波斯文正字法使用ZWNJ，并给出前后Joining_Type条件。这说明标准没有否认语言用途，而是把用途转换成可由算法检查的上下文。

因此，看见域名含有ZWNJ不能直接判定恶意；看见它在语言中合理，也不能跳过域名规则。正文正确与标识符有效是两个不同问题。

浏览器如何得到ASCII主机

WHATWG URL标准规定，域名解析会调用Unicode ToASCII。国际化标签经过处理后形成可用于网络协议的ASCII表示，常见结果以xn--开头。标准也定义了把已解析域名返回Unicode表示的算法，因此地址栏可能选择更适合阅读的Unicode形式。

Unicode显示与ASCII主机不是两套互不相关的地址，而是同一解析过程的不同表示。比较入口时，最好把两者同时保存：Unicode帮助检查语言与字形，ASCII形式便于逐标签比较和日志记录。

转换过程并非无条件成功。WHATWG的IDNA处理启用双向文本与连接符检查，输入不满足条件时域名解析可以失败。失败说明字符串不能按当前算法成为有效主机；成功则只说明通过了这一层语法与上下文处理。

ToASCII成功不等于网站可信

一个域名可以合法转换成ASCII，却仍属于完全不同的注册者、内容或服务。ToASCII没有查询经营主体，也不审查页面承诺。它解决字符如何成为主机标签，不解决“这个网站是不是我要找的”。

HTTPS也只增加另一层证据。证书验证当前连接是否匹配该主机并建立加密通道，不会比较页面品牌是否与读者记忆一致。锁形图标不能替代完整主机核对。

同形字符检测也有边界。UTS #39提供同脚本、混合脚本和整套脚本混淆检测，但明确指出连接控制限制只能减少视觉混淆，不能完全消除。字体、语言支持和界面策略仍会影响最终显示。

origin比页面名称更接近安全边界

网页来源通常由方案、主机和端口组成。两个页面主机文字相似，但只要其中任何一个结构成员不同，就不应自动视为同一来源。http与https不同，子域与根域不同，非默认端口也可能改变来源。

路径通常不改变origin，却会改变具体资源。一个主机下的登录页、帮助页和下载页可以共用来源，但内容与操作目的仍需分别核对。相反，重定向把浏览器送到另一个主机时，最终来源已经变化。

因此，入口记录至少要包含初始URL和最终URL。只保存截图中的品牌文字，会丢失最重要的结构信息；只保存短链接，也可能看不到跳转终点。

混合方向会改变阅读顺序

波斯文从右向左，拉丁字母与多数数字从左向右。同一行混入域名、端口、括号与标点时，Unicode双向算法会根据字符属性安排显示顺序。视觉上相邻的符号，复制后不一定按相同顺序出现。

这也是为什么手工抄写多语言URL风险较高。读者可能漏掉一个标签、把标点放错位置，或忽视一个不可见控制符。更稳妥的方法是复制完整地址，再交给URL解析器显示每个结构字段。

动态插入用户名、编号或书名时，Unicode建议把它作为独立方向单元隔离，避免影响周围文本。隔离改善排版，但不会修复错误字符或验证主机身份。

建立一条可复查的入口记录

第一项记录是原始字符串，包括从何处复制、复制时间和完整字符。不要先手工删掉看不见的字符，否则无法解释解析结果为何不同。

第二项是浏览器解析后的Unicode主机与ASCII主机。按点号分开比较每个标签，确认根域与子域关系。不要只比较最左边的名称，也不要忽略末尾可能不同的注册域。

第三项是方案与端口。记录当前连接是http还是https，是否使用非默认端口。第四项是重定向后的最终地址，尤其要保存最终主机。

第五项才是页面证据：标题、可见名称、来源提示和页面任务。它们可用于说明内容是否符合预期，却不能覆盖前四项结构差异。

如果入口涉及登录、下载或敏感资料，在结构无法核对时停止操作。从已保存的可信书签或服务内导航重新进入，不要把一个看起来相似的主机手工改成自己猜测的拼写后继续。

哪些结论不能由这些检查推出

字符序列一致，不能证明服务器相同；ASCII主机一致，不能证明当前页面内容未被替换；HTTPS有效，不能证明经营者承诺真实；同形检测没有报警，也不能证明不存在其他欺骗方式。

反过来，Unicode显示不同也不一定是攻击。浏览器版本、语言设置、字体和安全策略可能选择Unicode或ASCII呈现。差异是需要进一步比较的信号，不是自动定罪。

最可靠的做法不是寻找一个万能图标，而是保存多层证据。页面文字回答“它如何自称”，原始字符回答“输入是什么”，URL解析回答“主机是什么”，origin回答“浏览器把它归入哪个来源”，最终地址回答“连接最后到了哪里”。

多语言入口的难点不在于某种文字不安全，而在于显示、字符与网络身份容易被混为一谈。尊重波斯文连接规则，同时严格核对域名上下文，才能既不破坏语言，也不把相似字形当成身份。

子域名相似也不能只看最左边

读者常把地址最左侧的标签当成品牌。例如login.example.test与login.example-other.test都以login开头，但可注册域部分不同，来源也不同。判断根域关系必须从完整主机标签着手，不能只认第一个词。

反过来，support.example.test与www.example.test虽然子域不同，却可能属于同一个可注册域的不同服务。它们仍是不同主机，是否共享登录和凭证范围要由协议与服务配置决定，不能仅凭共同后缀推断。

保存记录时应把主机按点号分段，并同时保留最终地址。截图若裁掉地址栏右侧或只显示页面名称，会让后续复查失去结构证据。

复制与重新输入为什么会得到不同结果

复制操作保留字符序列，手工重输则会根据键盘布局、输入法和自动纠正生成新的代码点。两个波斯文字形可能看起来相同，却来自阿拉伯文与波斯文不同字符；不可见控制符也可能在复制时保留、重输时消失。

Unicode规范化可以处理部分等价序列，但不能把所有视觉相似字符变成同一个字符。规范化也不会判断某个域名是不是读者预期的网站。

因此，比较时要同时保存复制字符串与解析结果。若手工输入后得到另一ASCII主机，应停止继续，把差异视为需要查明的证据，而不是挑一个看起来更熟悉的版本。

重定向会把初始入口与最终来源分开

短链接、地区入口或登录流程可能经过多个HTTP重定向。初始主机只说明用户从哪里开始，最终主机才说明浏览器最后把请求送到哪个来源。

正常服务也会使用重定向，例如从http升级到https、从根域进入www或跳到统一身份来源。重定向本身不是异常，但每次主机变化都应记录，尤其是在输入账号、下载文件或授权前。

如果页面在展示内容时仍留在一个主机，点击登录却跳到另一个主机，读者需要分别核对内容来源与身份来源。两者的标题可以相同，origin仍然不同。

证书与字符检查分别回答什么

Unicode和IDNA规则回答主机字符串怎样处理；TLS证书回答当前连接呈现的身份是否匹配已解析主机，并能否建立受信任路径。前者通过不能替代后者，后者通过也不能验证网页自述的品牌关系。

如果域名解析失败，浏览器没有有效主机可连接；如果解析成功但证书名称不匹配，连接仍不能自动认证服务。若两者都通过，读者仍要从可信记录确认这是否为预期入口。

把这些层级串起来，可以避免把一个绿色图标或一次转换结果当成全部证据。

一个安全的比较表应该记录哪些字段

记录表可以包含观察时间、原始复制字符串、Unicode主机、ASCII主机、方案、端口、初始URL、最终URL和页面任务。每项保持原样，不在记录阶段修改字符或补写猜测。

页面任务说明当时为什么访问，例如查看帮助、登录或下载。它能帮助评估风险，却不参与主机相等判断。备注栏可写字体、语言设置与浏览器版本，因为这些条件会影响Unicode呈现。

记录完成后，再与可信书签、正式资料或既有内部记录比较。若完整主机和最终来源不一致，停止敏感操作；若只有显示形式不同而ASCII主机一致，则可继续核对证书与页面任务。

不要把语言差异本身当成风险标签

波斯文、阿拉伯文或其他非拉丁文字不是危险信号。风险来自把字形相似误当身份相同，或让不可见差异逃过标识符规则。正确做法是增加结构化核对，而不是排斥某种语言。

同样，ASCII形式也不天然更可信。xn--只是国际化域名的一种编码表示，仍需比较完整标签、证书和最终来源。

当系统既保留语言可读性，又提供ASCII、origin和最终地址等结构信息时，使用者不必在“看得懂”与“可核对”之间二选一。

资料来源

• Unicode Consortium：《Unicode Security Mechanisms, Unicode Technical Standard #39》，发布或更新于 2025-09-04
• Unicode Consortium：《Unicode Standard Annex #31: Unicode Identifiers and Syntax, Version 17.0.0》，发布或更新于 2025-08-20
• WHATWG：《URL Standard》，发布或更新于 2026-07-06
• IETF / RFC Editor：《RFC 5892: The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)》，发布或更新于 2010-08-01