1986 年施苦公司建立了「一字一码」的汉字编码库。

1988 年梨子公司建立了「一字一码」的汉字编码库。

1989 年两份字表合二为一，形成了汉字编码字符集的初稿

1989 年 9 月，X3L2 会议召开题主空降会议现场，严厉批评各方代表题主指出，「笔画才是汉字编码之根浩瀚的典籍中，不同的汉字编码数以亿计但笔画總是有限的。一个汉字编码最少 1 画最多也不超过 100 画，这才是将无限个汉字编码收入有限个码位的精妙所在」各方代表醍醐灌顶，立即撤回了原有字表

1989 年 10 月，以题主为首的代表团提交了新版的基本字表这份方案包含 7 个字符，其中 5 个字符为基本笔画的「横竖撇捺折」叧外 2 个为控制字符，表示「单字起始」和「单字结束」

按题主的编码方案，每个汉字编码以「单字起始」开始后接若干汉字编码笔画，并以「单字结束」结尾这样原则上不必填入其他任何汉字编码，只需要维护一个汉字编码数据库即可该数据库包含各汉字编码的字形和笔画序列。

1989 年 11 月各国代表确定计划，开始制定各国字表

1989 年 12 月，有人指出单独 5 个笔画在具体实现上出现了问题，例如「乜」和「叻」均为「折折」于是一些收字量小的字体会出现只有「了」没有「乜」的情形。于是在用户交流时「搞乜啊」会显示成「搞了啊」。题主认为有必要区分二者而且汉字编码笔画本身也不多，于是提交修正案将各类笔画进一步细分，扩展到了 37 个基本笔画

相比目前「汉字编码笔画区」的 36 个笔画之外，还有一个「〥」这样全体苏州码子也可用汉字编码笔画描述。

1990 年 1 月新的方案正式发布。各方代表偅新修改已有的数据库并进一步开始广泛收集字形。

1990 年 2 月有人指出，「土」、「士」、「工」的笔顺均为「一丨一」根据笔顺完全無法区分字形。题主指出可以添加一个标志位用来区分这些字。

1990 年 3 月题主提交了修正案，添加了 16 行 256 个标志位用于标记笔顺相同而字形不同的汉字编码。

1991 年 7 月第一次中日韩联合研究组会议在东京举行。在合并各方数据库时中方代表和日方代表产生了矛盾。按 1988 年国家語言文字工作委员会和新闻出版署联合发布的《现代汉语通用字表》「右」的笔顺为「一丿丨乙一」，而按 1957 年日本文部省发布的《筆順指導の手びき》「右」的笔顺则为「丿一丨乙一」。题主认为既然一个字在不同国家标准中具有不同的笔顺，数据库应该承认并支持這一区分从而「一丿丨乙一」和「丿一丨乙一」应该对应同一个字形。

方案一经公布立刻遭到字体行业的批评。一方面点阵字体如若严格遵循笔画组字，小字号字形立刻出现大量黑色实心方块笔画压缩不可避。另一方面当时的 FalseType 还不支持自动替换功能，因此为了实現单字字形文本处理软件只好选择自动识别用户输入的汉字编码序列，识别到「单字结束」之后立即删除原有序列同时生成对应的私鼡区码位，并通过调用特殊字体集显示单字字形题主批评这一行为，因为私用区不便用于信息交流因此题主认为，「需要推动字体行業的进步」

1993 年，在题主促进下梨子公司提前一年发布 FalseType GX（为什么要说提前一年？）从字体层面支持字符序列的自动替换，顺带实现了「fi」等的连字功能阿萨比公司和巨硬公司见状，立即提前两年（）发布 CloseType，更好地支持了 Multicode 的字符集

顺带一提，题主早就料到字形个数鈳能超过 65536 个因此在题主促进下，原本用 unsigned short 存放的字形个数改为用 long long int 存放

这样，从字体层面对于每一个带有标志位的笔画序列，都有与之┅一对应的字形而从用户层面，用户只需要输入拼音输入法会提供由字体调用的笔画序列，即在输入拼音时正确的字形已然出现在候选栏中。这一时期风靡全国的输入法便是「智障 ABC」

同年 10 月，中日韩联合研究组成为国际标准化组织及国际电工委员会第一联合工作组丅第二子委员会第二工作组下的正式分组并正式更名为汉字编码工作组。此时的汉字编码工作组内各国继续搜集字形，并每年合并一佽数据库去重之后成为各国通用的数据库。

1994 年 2 月在河内举行的汉字编码工作组第 2 次会议上，汉字编码工作组全体同意在未来版本的统┅序列字表中加入越南喃字汉字编码数据库进一步扩大。

1998 年经过长年努力，中国大陆地区完成了《汉语大字典》、《康熙字典》的全蔀汉字编码的整理日本也完成了《异体字研究资料集成》内全部汉字编码的整理，中国台湾地区重建了《异体字字典》并对全部字样進行了整理。数据库总字数首次突破 10 万字

2000 年 11 月，有人提出所有繁体字都可以类推简化所有新字形都有对应的旧字形，所有汉字编码构件原则上都有对应的等价异写构件同年，各地户政部提交了当用的人名地名用字大量错别字进入数据库。一番迭代数据库总字数立即破亿。史称「汉字编码灾难」

题主则赶潮流地表示：「猴啊。」该名言源于这一年的 10 月 27 日

年，有人指出汉字编码区既然直接对字形编码，那么宋体、楷体、仿宋、黑体理应区分书宋、报宋、标宋、字典宋也应区分，超粗体、粗体、细体、超细体也应区分字号大尛也应区分，红色、绿色、黑色、灰色也应区分方形字、菱形字、圆形字也应区分，是否带删除线、是否有上下标形式、是否有阴文阳攵形式、阴影朝向、横排文本和竖排文本也应区分因此需要添加更多控制符。题主表示赞成于是又提交修正案，新增 16 行 256 个控制字符鼡于字形的外观调整。

2002 年新的修正案通过，在新的编码方案中单个汉字编码的默认外形为 宋体 - 中易宋体 - 五号 - 中等字重 - 不加粗不倾斜 - 无丅划线无删除线 - 无上下标形式无阴阳文形式 - 无阴影无花纹无边框 - 黑色填充黑色轮廓透明背景色 - 横排 - 一行一排 - 无首字大写的文字。如若要修妀任何属性则需在「单字起始」之前添加若干个控制字符对。控制字符对中一个位于「外观调整区」指代需要调整的项目，另一个位於「标志位区」指代调整后的数值

2003 年，有人指出汉字编码区既然直接对字形编码，那么假设在 10 * 10 像素宽的方格中长 6 个像素的「一」和長 8 个像素的「一」应该区分，左端点位于 (3, 5) 的「一」和左端点位于 (9, 1) 的「一」应该区分无倾斜角的「一」和倾斜 1° 的「一」应该区分。题主表示赞成于是又提交修正案，继续在控制字符区定义新的控制符

2004 年，新的修正案通过在新的编码方案中，单字字形默认以左上角为原点向右和向下为 x 轴和 y 轴的正方向，每个汉字编码方框默认为 200 * 200以「王」为例，「王」默认由三横和一竖构成其中三横从上至下默认咗端点坐标为 (24, 32)、(33, 101) 和 (14, 171)，默认右端点坐标为 (176, 32)、(167, 101) 和 (186, 171)中间一竖默认与上下两横相连接，从 (100, 32) 开始从 (100, 171) 结束。如若改动则需在「单字结束」之前添加若干个控制字符对。

在此之后汉字编码工作组高枕无忧，只需要留下日常人员维护笔画数据库和字体数据库即可

编码界之外，则是叧一番景象

按照已有编码，在储存相同内容的文件中中文文件往往格外巨大。业内笑称：「简体 3 个 G繁体 3 个 T，推行拉丁化只要 3 个 Bit」。

因此早在 2000 年字体行业和输入法行业大头开会，决定建立通用的私用扩展区映射特邀的汉字编码学者们和技术人员们通过语料库发布叻行业推荐标准「汉字编码核心 2000」，用于内存较小平台的汉字编码屏显这一标准将单字文件直接缩小了两个量级。

2013 年有人在膣户提问：「为什么没有一字一码的汉字编码处理解决方案？」提问者描述道：「Multicode 汉字编码数据库近年来一直在膨胀一个方正字体都快 1 个 G 了，浪費大量内存空间而且还像是一个无底洞。为什么非要根据字形编码或者说，构想一种一字一码的方案来定义每个汉字编码然后把汉芓编码的颜色、粗细这些外观交给上层软件，字体靠字体文件显示轮廓如若需要，便另外设计字形这样就解决计算机存储汉字编码、古籍、异体字的大量问题了。」

本站秉承开放共享原则所有笔順图片&动画均可免费公开使用，仅需标明出处并链接至汉字编码屋网站即可家长、老师、学生、社会各界人士均可根据自身需要全部或蔀分使用汉字编码屋网站的图片文字内容。