GB/T 40474-2021 银行业应用系统 代码与编码处置指南

　　ICS 35 . 240 . 40 CCS A 1 1

　　中 华 人 民 共 和 国 国 家 标 准

　　GB/T 40474—2021

　　银行业应用系统 代码与编码处置指南Bankingapplicationsystem—Guidelineforhandlingwithcodeandidentifier

　　2021-07-20 发布 2022-02-01 实施

　　国家市场监督管理总局国家标准化管理委员会

　　发

　　布

　　GB/T 40474—202 1

　　GB/T 40474—202 1

　　前 言

　　本文件按照 GB/T 1 . 1—2020《标准化工作导则 第 1 部分：标准化文件的结构和起草规则》的规定起草。

　　请注意本文件的某些内容可能涉及专利。 本文件的发布机构不承担识别专利的责任。

　　本文件由中国人民银行提出。

　　本文件由全国金融标准化技术委员会(SAC/TC 180)归口 。

　　本文件起草单位：中国人民银行科技司、中国农业银行股份有限公司、中国外汇交易中心暨全国银行间同业拆借中心、中国人民银行清算总中心、中国建设银行股份有限公司、交通银行股份有限公司、农信银资金清算中心有限责任公司、中国金融电子化公司。

　　本文件主要起草人：李伟、杨富玉、曲维民、李宽、王鹏、马骏、王锋、杨明英、葛洪慧、崔婉昱、赵刘韬、叶昱、梁军、景芸、王灿雍、陆原鹏、杨倩、谢彦丽、刘书元、王思源。

　　GB/T 40474—202 1

　　引 言

　　在应用系统的建设中，在服务器和客户端都可能要使用数据的代码和编码，以避免可能存在的数据不一致性，提高处理效率。 从这些代码和编码的发展历史看，随着业务量的变化和管理需求的增加，很有可能改变代码的值域，也可能改变编码的规则。

　　进入 21 世纪以来，我国的婚姻状况代码从 GB/T 4766—1984《婚姻状况代码》规定的 1 位数字调整到 GB/T 2261 . 2—2003 规定的 2 位数字，居民身份证的号码由 GB 11643—1989《社会保障号码》规定的 15 位数字升级到 GB 11643—1999 规定的 18 位数字字母，很多信息系统均因原来处理对应代码和编码的字段长度和类型直接按照当时有效的标准设计，故在标准升级后，导致了大规模的系统改造。

　　因此，本文件提出了在应用系统中处理数据代码和编码的指南，当银行业应用系统之间交换的数据代码与编码发生变化时，可以有效减少对业务目标的影响。

　　GB/T 40474—202 1

　　银行业应用系统 代码与编码处置指南

　　1 范围

　　本文件提供了在银行业应用系统中存储、加工、使用代码和编码的建议。

　　本文件适用于银行业应用系统的构建和改造。 与银行连接和产生信息交换的系统参照使用。

　　注：本文件未涉及数据代码与编码的属性。

　　2 规范性引用文件

　　下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。 其中，注 日期的引用文件，仅该日期对应的版本适用于本文件;不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。

　　GB/T 17710—2008 信息技术 安全技术 校验字符系统

　　ISO 17442-1 : 2020 金融服务 全球法人识别编码(LEI) 第 1 部分：分配[Financial services—

　　Legal entity identifier (LEI)—Part 1 : Assignment]

　　3 术语和定义

　　下列术语和定义适用于本文件。

　　3.1

　　应用 application

　　应用系统 applicationsystem

　　通过计算机来收集、存储、处理和展现数据的系统。

　　[来源：ISO/IEC/IEEE 24765:2017,3 . 167]

　　3.2

　　代码 code

　　将第一组元素映射到第二组元素的规则集合。

　　[来源：ISO 18308:2011,3 . 13]

　　示例：代码实际上是一个“关键字-含义”对应表;存在多少个“关键字-含义”对是明确的，每个关键字都是预先定义的 。GB/T 2261 . 1—2003、GB/T 2260—2007、GB/T 12406—2008 均为代码的例子 。

　　3.3

　　编码 identifier

　　数字编码 digital identifier

　　与数字、非数字或抽象实体字符相关的紧凑字符序列。

　　[来源：ISO 24622-1:2015,2 . 9]

　　示例：编码实际上是给出一个规则，每个编码均依据这个规则产生;最多可以存在多少编码是明确的，但某个编码是否存在并不明确且可能是动态变化的。 GB 11643—1999 的公民身份号码即为编码的例子，由 GB 32100 — 2015 的统一社会信用代码也是编码的例子。

　　GB/T 40474—202 1

　　3.4

　　内源性数据 endogenousdata

　　产生规则由银行确定，并可在需要时由银行产生、变更、废止使用的数据。

　　[来源：GB/T 31186 . 1—2014,3 . 7]

　　3.5

　　外源性数据 exogenousdata

　　由银行外部产生，且产生的规则可能公开也可能不公开，可在银行不知悉的情况下新增、变更、废止使用的数据。

　　[来源：GB/T 31186 . 1—2014,3 . 8]

　　4 总则

　　在银行业应用系统中处理的代码与编码宜符合如下总体原则。

　　a) 留足充分的扩展能力，以能够适应外源性数据的变化。

　　b ) 作为标识码的编码使用内源性数据，以避免不能获取外源性数据，或外源性数据可能出现的重复。

　　5 代码

　　5 . 1 新引入代码

　　新引入代码时，采用如下策略。

　　a) 宜分析可能产生数据交换的系统代码，依据其中划分粒度最细的代码建立代码枚举集。

　　注 1 ：此处的系统代码是指系统的分类代码而不是系统应用程序的源代码或目标代码。

　　b ) 在代码枚举集中，宜设计“不可获知”和“不能适用”两个代码的值。

　　c) 在未能证明代码不会出现扩充的情况下，宜设计至少一个“临时代码”。对赋予“临时代码”的代码，宜在可能时立即定义新的代码并进行替换，以使“临时代码”随时可用。

　　d) 对设置“其他”代码的，宜由代码分配者明确“其他”代码的许用条件和禁用条件，不将可分类或待分类的代码放入“其他”代码。

　　注 2：“临时代码”不是“其他”，“其他”是一种可以长期存在的、不归属于已经赋值的所有代码的代码，而“临时代码”

　　是一种对新遇到情况但又不能归属于“其他”类的代码。

　　注 3：在进行数据治理时，“其他”代码中的内容是重点关注对象。

　　e) 代码的定义域宜设计为数字字母码，即取值范围为“0”~“9”和“A”~“Z”,在使用顺序上，惯常使用数字代码的，可先采用全部数字编码，然后从末位(或其他认为适宜的位数)使用字母编码 。在取值范围包括“A”~“Z”时，明确仅为大写、大小写含义相同、大小写同时存在三种情况之一，且：

　　1) 仅为大写时，不接受输入的小写;

　　2) 大写字母是和小写字母表示的含义相同时，宜全部按大写方式显示和记录，也可全部按小写方式显示和记录，但不宜同时使用大写字母和小写字母记录和显示;

　　3) 大小写字母同时存在时，宜有代码使用者易于理解的说明且建立有可能大小写字母输入错的提示。

　　f) 对代码为“0”~“9”和“A”~“Z”且可能由人工输入和(或)人工阅读的：

　　1) 不宜含有输入和(或)阅读时可能产生混淆的数字或字母;

　　2) 宜避免代码存在谐音释义，使代码存在使用代码的人群中认为不雅、不吉的代码谐音

　　GB/T 40474—202 1

　　释义。

　　示例 1 ：在代码中不包括元音字母(A、E、I、O、U),甚至也不包括半元音字母(W、Y),将使得代码不能形成读音，是一个避免谐音的方法。

　　示例 2：对汉语拼音的缩写导致的不良谐音，通过特定的字典进行过滤是一个避免谐音的方法。

　　g) 代码的位数，宜为现有外源性代码最多位数的 2 倍，且至少多于现有外源性代码最多位数2 位 。

　　注 4：系统开发时自己设置的代码位数仅考虑业务发展趋势和管理需求，不考虑与外源性代码位数的关系。

　　h) 对代码全部为数字的，也不宜采用数字类型进行描述。

　　i ) 同一枚举集宜采用等长编码，代码位数不足全部长度的，左补零。

　　5 . 2 现有代码

　　对已经使用的现有代码，采用如下策略。

　　a) 在代码的定义域允许的情况下，在代码枚举集中：

　　1) 未设计“不可获知”“不能适用”的，宜增加上述 2 个代码;

　　2) 在未能证明代码不会出现扩充的情况下，宜增加至少一个“临时代码”。

　　b ) 采用数字类型作为代码的，宜在应用系统改造时转换为使用数字字母代码。

　　c) 代码的位数与相关标准一致的，宜在应用系统改造时扩充其长度。 扩充长度可在数据库和传输报文中一并进行，也可分别进行。

　　d) 已经产生的数据中，采用空值或空串描述代码的，宜在进行数据清理时，根据情况转换为“不可获知”或“不能适用”对应的代码。

　　6 编码

　　6 . 1 新引入编码

　　新引入编码时，采用如下策略。

　　a) 作为客体标识的编码宜为内源性数据。

　　b ) 对所有外源性数据编码，宜与编码一同指定其编码的数据源。

　　c) 只要在可能的情况下，宜使用无含义编码。 编码中的有含义部分是面向客户的而不是面向内部管理和系统控制的。

　　注 1 ：有含义编码与无含义编码的比较，参见附录 A。

　　d) 编码的校验位采用高效和检查效果良好的算法，宜采用 GB/T 17710—2008 中表 1 给出的校验字符系统冠名为“ISO/IEC 7064 , MOD 97-10”的算法，且宜与 ISO 17442-1 : 2020 中 5 . 1 有效的校验位范围为 02 到 98 的内容一致。

　　e) 在编码为数字字母码时，宜采用 GB/T 17710—2008 中表 1 给出的“ISO/IEC 7064 , MOD 97- 10”进行校验码计算，即：

　　A = 10 B = 11 C = 12 D = 13 E = 14 F = 15 G = 16 H = 17 I = 18 J = 19

　　K = 20 L = 21 M = 22 N = 23 O = 24 P = 25 Q = 26 R = 27 S = 28 T = 29

　　U = 30 V = 31 W = 32 X = 33 Y = 34 Z = 35

　　f) 在业务需要时，可采用校验位不置放于编码末端的编码规则。

　　g) 编码的定义域设计为数字字母码，宜即取值范围为“0”~“9”和“A”~“Z”,在使用顺序上，惯常使用数字编码的，可先采用全部数字，然后从首位或末位(或其他认为适宜的位数)使用字母。在取值范围包括“A”~“Z”时，明确仅为大写、大小写等义、大小写同时存在三种情况之一，且 ：

　　1) 仅为大写时，不接受输入的小写;

　　GB/T 40474—202 1

　　2) 大写字母是和小写字母表示的含义相同时，宜全部按大写方式显示和记录，也可全部按小写方式显示和记录，但不宜同时使用大写字母和小写字母记录和显示;

　　3) 大小写同时存在时，宜有编码使用者易于理解的说明，且建立有可能大小写输入错的提示。

　　h) 对编码为“0”~“9”和“A”~“Z”且可能由人工输入和(或)人工阅读的：

　　1) 不宜含有输入和(或)阅读时可能产生混淆的数字或字母;

　　2) 宜避免代码存在谐音释义，避免代码存在使用代码的人群中认为不雅、不吉的代码谐音释义。

　　示例 1 ：在代码中不包括元音字母(A、E、I、O、U),甚至也不包括半元音字母(W、Y),将使得代码不能形成读音，是一个避免谐音的方法。

　　示例 2：对汉语拼音的缩写导致的不良谐音，通过特定的字典进行过滤是一个避免谐音的方法。

　　i) 宜避免在编码中存在非数字字母的符号。 为可读方便而提供的符号，宜在输入时自动提示，在显示时格式化展示，且不存储在数据库中。

　　示例 3 : “-”“_”“/”“|”为常见的非数字字母符号。

　　j) 对企业级唯一的编码，宜确定保证唯一编码发生器的机制。

　　注 2：在应用系统设计中，确定只有一个编码发生器是一种唯一编码发生器的方法;将编码分段，采用多个发生器源也是一种唯一编码发生器的方法，但如果对编码客体的识别依赖于外部信息，则考虑同一外部信息在两个发生器源均申请了编码，而导致的编码客户的识别与合并问题。

　　6 . 2 现有编码

　　对已经使用的现有编码，采用如下策略。

　　a) 对使用外源性数据作为客体标识且进行了扩充的，宜评估其与外部编码规则的一致性，在适宜时机，将其转换为内源性数据。

　　b ) 当前编码已经使用了有含义编码的，宜在适宜时机改为通过属性表示这些含义，而逐渐将这些编码转换为无含义编码。

　　c) 对确立了唯一编码的技术要求但采用多数据源模式的，宜在适宜时机改造为单一数据源模式。

　　GB/T 40474—202 1

　　附 录 A

　　(资料性)

　　有含义编码与无含义编码的比较

　　A.1 有含义编码的优点

　　有含义编码的优点如下。

　　a) 便于人对编码的记忆。 这是其最大的优点，也是很多系统编码采用有含义编码的首要原因。

　　b ) 便于描述编码对象的部分属性。 当编码对象的部分属性内容确定且适宜为广大使用人员所知时。

　　A.2 无含义编码的优点

　　无含义编码的优点如下。

　　a) 不存在编码的结构性浪费，在同样的编码长度下可使用更多的有效编码。

　　示例 1 ：假定数字编码只能以 6 和 8 开头，则可实际使用的编码容量受到开头数字的限定，在十进制前提下，只有没有限制情况的全数字编码容量的 1/5。

　　b ) 编码对象的属性不会被无意泄露。

　　注：这里编码对象属性的泄露不仅仅是直接泄露某些值，这些值可能本身并不敏感，但这些值可能还能够映射说明一些情况，这些情况可能是敏感的。 例如在将 1 位的婚姻状态列入编码中时，就意味着很有可能不具备处理两位婚姻状态的能力;在一个编码中的客户是按省编码的，就意味着很可能是以省为一级管理中心。

　　c) 编码对象属性取值的变化不会影响编码本身。 将编码对象的属性作为编码的一部分，在编码空间的分配上如果不考虑预留增加的属性取值，则可能导致在发现有新的取值之后，无法保持编码属性的含义;而如果保留预留的空间，又不知道何时属性可能发生变更，造成编码的浪费。

　　示例 2：例如某种编码采用编码来识别性别，为了使得编码得到充分利用，使用 0、2、4、6、8 作为一种性别的编码，而采用 1 、3、5、7、9 作为另一种性别的编码。 这样编码的前提，是在编码时一定能够获知编码对象的性别且性别不会变更;但在实际运行中，发现在有些情况下编码对象的性别是不能准确识别或可能变更的，但编码的空间已经完全分配，故只能将对编码对象的初始的性别作为其编码的性别，从而失去了通过编码判别编码对象性别的意义。

　　d) 不会导致对编码对象属性的误判。 在采用编码对象的属性作为编码的一部分时，至少在编码的初期，在绝大多数的情况下，编码所隐含说明的编码对象的属性是正确的，因此，会有部分人员通过编码去判定编码对象的属性而不再去查询编码对象实际具备的属性。 随着时间的推移，编码的内容可能已经不能正确反映编码对象的属性，但编码的使用人员并不了解或不关注这种情况，且依旧可能通过该编码的值对编码对象的属性进行判定。

　　GB/T 40474—202 1

　　参 考 文 献

　　[1] GB/T 2260—2007 中华人民共和国行政区划代码

　　[2] GB/T 2261 . 1—2003 个人基本信息分类与代码 第 1 部分：人的性别代码

　　[3] GB/T 2261 . 2—2003 个人基本信息分类与代码 第 2 部分：婚姻状况代码

　　[4] GB 11643—1999 公民身份号码

　　[5] GB/T 12406—2008 表示货币和资金的代码

　　[6] GB/T 31186 . 1—2014 银行客户基本信息描述规范 第 1 部分：描述模型

　　[7] GB 32100—2015 法人和其他组织统一社会信用代码编码规则

　　[8] ISO 18308 : 2011 Health informatics—Requirements for an electronic health record archi- tecture

　　[9] ISO 24622-1 : 2015 Language resource management—Component Metadata Infrastructure (CMDI)—Part 1 : The Component Metadata Model

　　[10] ISO/IEC/IEEE 24765 : 2017 Systems and software engineering—Vocabulary