知识文章 · 编写日期 2026-11-10
91数字文本：两个数字为何不等于码位91
因为“91”作为文本包含两个字符9和1；而“十进制码位91”是在字符表中寻找编号为九十一的那个字符，它是左方括号[。把两位数字读成一个码位编号，是额外解释步骤，并不是保留原文。
延续91媒介档案的数字辨名与原文记录主题，解释导出表和编码说明里数字的不同角色。仅用ASCII范围的9、1和左方括号作例子，不推测任何同名平台身份；编码表查阅为Unicode 18.0，UTF-8关系依据RFC 3629。
先分清三个问题，而不是看数字外观
“原文写了哪些字符”问的是文本；“把这段十进制数字读成多少”问的是数值；“这个整数在字符表里对应谁”则问码位。三者可以按规则转换，但不能在资料卡里省略转换动作。
例如标题原文写91，保存原文时应保留字符9接字符1。只有字段说明明确要求输入十进制码位，才把91当成一个字符编号查询；否则将它替换成[，就改变了记录对象。
字符9、字符1各自有自己的编号
Unicode基本拉丁字符表列出9为U+0039、1为U+0031。[1] U+后使用十六进制：0039换成十进制为3×16＋9＝57，0031为3×16＋1＝49。这里57与49是字符编号，不是把9和1相加或拼成的数。
所以文本91可记成码位序列“U+0039、U+0031”。先写9再写1是有顺序的两项；把它们合成一个整数91，或者把57与49相加，都会变成另一项运算。
码位91为什么对应左方括号
十进制91＝5×16＋11，十六进制的11用B表示，因此该码位写作U+005B。Unicode表将U+005B列为左方括号。[1] 图右先明确“按十进制码位寻找字符”，再画出[，没有声称数字名称91本身就是括号。
还要保留进制说明。十六进制5B与十进制91表示同一个整数，而十六进制91与十进制91不是同一个值。看到文件里一串91，不能在没有字段定义时猜它到底采用哪套写法。
编码字节也能看出两条路径不同
RFC 3629说明U+0000至U+007F范围在UTF-8中保持对应的单字节值。[2] 因此文本91的两个字节按十六进制写为39 31；左方括号则只有一个字节5B。这里的空格分隔字节，不是文本里额外加了一个空格。
本站用本地纯字符串运算复核了这两组结果，见图；没有连接外部平台或读取任何账号数据。它只验证字符与编码对应，不能验证资料来源。实际文件若另含换行、BOM或HTML标记，整体字节数还会不同，不能用图中的2与1概括整个文件。
动手核对
- 保存看到的原始文本，并记录它来自名称栏、数值栏还是码位栏。
- 核对进制及解释规则，不把十进制数和U+十六进制写法直接混读。
- 需要验证时逐字列出码位及编码结果，处理副本与原始记录分开。
常见问题
写成U+0091也是左方括号吗？
不是。U+采用十六进制，左方括号是U+005B；不能把十进制91直接抄到U+后。
文本91能按十进制解析成九十一吗？
可以，在明确进行数值解析时如此。但解析出的整数与原始两字符文本应分栏记录，转换不代表字段原本就是数值。
这是否说明任何数字名称都应转成字符？
不是。名称按原文保存。只有任务明确需要码位解释时才使用对应规则。
依据与延伸阅读
- [1] Unicode 18.0：C0 Controls and Basic Latin（Unicode Consortium，核验日期 2026-11-10）
U+0031、U+0039与U+005B的字符对应；图是自行绘制的三字符对照，不复制原码表或字体。
- [2] RFC 3629 §1–3：UTF-8定义与记号（IETF / RFC Editor，核验日期 2026-11-10）
U+记号为十六进制，ASCII范围对应UTF-8同值单字节。