OPC Foundation《Part 3: Address Space Model》的5.2.4与5.2.5，分别说明BrowseName与DisplayName。当前所读版本标示v1.05.06。[1][2]

BrowseName被定义为非本地化、可供人阅读的名称。多个这样的名称能够组成浏览路径，使资料不只剩下一串孤立标识。不过，可读性并不等于唯一性：5.2.4明确说，不同节点可以具有同一个BrowseName，它不能像NodeId那样无歧义地识别节点。一个名称可以承担路径中的部分信息，却没有因此独自成为整个服务器的节点身份证明。[1]

该名称本身还包含命名空间与字符串两部分。文档以节点的Properties为例，说明不同组织可以使用相同字符串而赋予略有差别的含义，命名空间使这些组织定义在相应上下文中能够区分。这里的范围很重要：原文说的是某些节点上下文中的区分，并没有据此宣布服务器里每一个BrowseName都互不重复。[1]

名称空间也不必与NodeId逐项相同。规范说，服务器常可为二者采用同一空间；但提供标准Property时，其BrowseName须采用标准组织的空间，NodeId却可能反映本地服务器等另一空间。这个例子把“由谁定义属性名称”与“节点标识属于什么空间”放在同一对象上。保留这种对应，比仅凭两处都出现namespace就把数值来源合并更准确。[1]

大小写规则同样区分角色。客户端须将BrowseName的字符串部分视为大小写敏感；服务器则可以对服务请求中传来的名称采用不敏感处理。后一种接纳仍附有条件：名称唯一性不能依赖大小写。因而，服务器可能接受不敏感名称，并没有取消客户端的规则，也不是所有系统都能无条件忽略字母大小写。[1]

DisplayName转向面向用户的表达。5.2.5说，它包含节点的本地化名称，服务器可以保留一种或多种语言表示，客户端在打开会话时协商返回的locale。5.2.4也直接要求，显示节点名称应使用DisplayName，而非BrowseName。于是，地址空间里的稳定浏览用词与随语言呈现的用户名称可以并存，无须让一个字符串同时承担两种用途。[1][2]

规范还把标准类型定义单列说明：标准组织应将自身的命名空间同时用于TypeDefinitionNode的NodeId和BrowseName。这与前面的标准Property例子形成具体对照：Property的BrowseName来自标准组织，NodeId却可能属于本地服务器；标准类型定义节点则要求两者都用标准组织的空间。随后，规范为TypeDefinitionNodes、ReferenceTypes和DataTypes的BrowseName明确提出唯一性要求，用作入口的已知实例也须唯一，并举出另一部分规范定义的Root Node为例。因此，“不同节点可以同名”描述的是BrowseName不能普遍代替NodeId的限制；它不取消这些具名对象及入口的唯一性条件。整理定义时，既要保留一般名称可能重复，也要留下标准类型与入口的具体要求。[1]

信息来源

本文基于上述公开资料整理，未使用来源页面的图片、视频或嵌入媒体。