背景

用户输入是平台获取用户信息的重要途径，也是用户自我表达的重要方式，社区业务场景下尤其如此，输入过程的流畅性、精准性、丰富性都是我们要重点保障的。下图是最近的一个产品需求，「圈内好物」板块下允许用户自定义「商品分组」。

产品&设计同学有两个核心诉求：

1. 支持输入汉字、英文、数字、emoji，且：

• 一个英文/数字的长度为 0.5

• 一个汉字的长度为 1

• 一个 emoji 表情的长度为 1

2. 输入过程中超出长度限制自动截断，阻止继续输入

要解决的问题

任务目标明确：

1. 编写字符串的长度计算功能

• 对于长度计算部分，需要区分字符种类（汉字，英文，emoji），并按照定义的长度计算总长度。

2. 用户输入超出限定长度文本的时候做自动截断

• 在拿到文本长度的基础上，需要处理用户 input 事件，并合理做出截断。

常规解决方案

对于 input 的字数限制，首先想到的应该就是原生的 maxlength 参数了。传统的 maxlength 参数控制输入框的最长输入长度。在限制输入字符的同时，也有着不错的交互体验，能截断超出长度的输入内容。

但 maxlength 与设想的一样，并不能区分中英文字符长度。

再试试 emoji。

看了看 MDN 文档。

原来是这样，maxlength 限制的是字符串的编码长度，而产品需要的长度定义又和编码长度不一致，所以直接使用 maxlength 并不能符合产品需求，需要另辟蹊径。总结一下 maxlength 的两个核心问题：

• 汉字、英文、emoji 无法区分；

• emoji 长度计算困难。

string 编码与长度计算1. Unicode 与 Javascript string 编码

为了解释上面的问题，先来了解一下 Unicode 的字符点。在 Unicode 中，一个字符由 U+_hhhhhh _六位 hex decimal 字符点表示。Unicode 又把连续的 65,536 字符点（Code Point）作为一个字符平面（Plane），如 U+000000 - U+00FFFF 就作为 Plane 0。而我们常用的中英文本字符都在这个区域内进行编码。

Plane 0 也被称为基本多文种平面（BMP）。

Javascript 的字符串使用 UTF-16 进行编码，由 16-bit 字节序列组成。这里可以注意到，常用的字符（U+000000 - U+00FFFF）都可以用一个 16-bit 字节表示。这就解释了为什么传统 maxlength 计算中，汉字和英文的编码长度是一样的。而对于常用的字符，Unicode 定义了一个个区段方便区分，如字符点范围 U+4E00-U+9FFF 就为中日韩统一表意文字 (CJK Unified Ideographs) ，所以我们可以直接根据字符点的所在范围计算长度。

2. Emoji 的编码方式

Emoji 编码的话就比较特殊了。emoji 存在于 Plane 1（U+010000 - U+01FFFF），所以不能直接使用一个字符点来表示。在 UTF-16 编码中，emoji 由字符点代理对（Surrogate Pair）进行编码。以