企业官网建设流程全解析

我一直觉得，Unicode 对照表这种内容属于“平时没人提，遇到问题全网找不到”的典型。这个系列写到“045_Unicode对照表十一”，后台收到的搜索关键词越来越多，尤其是最近一批热搜里反复出现“unicode的韩文字符可复制写出来”“unicode字符大全可复制”“arial unicode ms”这些词。很多人不是不知道 Unicode 这个概念，而是急需一张能直接复制、能查到码位、能解决显示乱码的对照表。这篇文章就把这段时间被问得最多的问题集中整理一遍，重点放在韩文音节、高频符号、字体渲染和工程代码里的实际用法上。

系列前面十期分别覆盖了 ASCII、拉丁扩充、CJK 基本区、标点符号、带圈数字、全角半角、数学符号、箭头、货币符号、拼音注音等内容。这一期之所以专门挑韩文和“可复制”这个需求来讲，是因为后台留言里出现了大量类似“我要在文档里写韩文，但输入法打不出来”“从网页复制的韩文粘贴后是问号”“Unicode 字符大全里能找到字，但复制到工程代码里就乱码”的求助。这些问题的根子，其实都指向同一个地方：你把字符放进文件之前，有没有想过它到底对应的是哪一个码点。

1. 为什么这个系列写到 045 还要继续讲对照表

先说一个听起来有点反常识的结论：Unicode 对照表到今天依然是刚需，而且需求比十年前更旺盛。原因不是大家不会用输入法，而是“跨系统、跨软件、跨字体”的场景越来越多。同一个字符，在 Windows 记事本里正常，粘贴到 Linux 终端变乱码；在 Chrome 里正常，放进老旧的财务系统导出 Excel 后直接变成问号。这时候你唯一能依靠的，就是一张准确的码位对照表。

1.1 热搜词背后藏着三种完全不同的需求

我把最近这批热搜词拆开看了一下，基本能分成三类。第一类是“我要找某个字符”，比如“笑哭的unicode”“unicode字符大全可复制”，这种需求最普遍，本质上是输入法覆盖不到的符号，需要靠复制或者码点来插入。第二类是“我要显示正常”，比如“arial unicode ms”“unicode字符显示器”，这类问题多数出在字体缺字形，而不是 Unicode 本身出了问题。第三类是“我要在不同系统之间转换数据”，比如“abap unicode解码”“unicode的韩文字符可复制写出来”，这就涉及到编码转换和码点换算。

这三类需求指向的是完全不同的能力。第一类只需要会查表，第二类需要懂一点字体渲染，第三类需要了解编码原理和编程接口。很多人搜“unicode对照表”其实是想一步到位解决所有问题，但现实是没有一张表能同时满足这三种场景。所以我这一期的做法是：先给可直接复用的对照表，再讲怎么判断一个字符是否能在你的环境里正常显示，最后给代码层面的处理方案。

1.2 “对照表”这个词本身就很误导人

还有一点必须提醒：网上搜“对照表”，会同时出现“ascii码对照表”“电阻阻值对照表”“pcb线宽电流对照表”“e96贴片电阻对照表”“pt1000分度表对照表”。这些完全是两码事。ASCII 码对照表属于字符编码领域，和 Unicode 是一家的；但电阻阻值、PCB 线宽、PT1000 分度表属于电子工程领域，它们跟 Unicode 没有任何关系。之所以会被一起搜出来，纯粹是因为“对照表”这三个字太通用。

我见过不少初学者，拿着“电阻阻值对照表”去对比字符编码，结果自然是牛头不对马嘴。这一期既然标题叫“Unicode 对照表”，就把边界说清楚：我们只讨论字符、码点和编码之间的对应关系。线径规格、导体电阻这些内容，属于另外一个专业方向，搜索引擎把它们推荐到一起，恰恰说明现代人查资料时“关键词太短”的问题有多普遍。

2. 先花三分钟理清：字符、码点、编码三者的区别

很多人在这一步栽跟头。Unicode 对照表上写着“가 U+AC00”，但你把这个字符存进文件后再读出来，在内存里看到的可能是EAB080三个字节，也可能变成AC 00两个字节。为什么同一个字符，字节序列还不一样？因为 Unicode 是字符集，它只规定了“字符 → 码点”的对应关系；而 UTF-8、UTF-16 才是编码方案，它们规定了“码点 → 字节”的转换规则。

2.1 用生活类比解释这三层关系

把 Unicode 想象成一本巨大的户口本，每个字符都有一个唯一的身份证号，这就是码点。比如汉字“中”的身份证号是 U+4E2D，韩文“가”的身份证号是 U+AC00。但身份证号不能直接拿来当名字用，你得有一套规则把这个号写到各种表格里。UTF-8 是一套规则，它把 U+4E2D 写成E4 B8 AD三个字节；UTF-16 是另一套规则，它把 U+4E2D 写成4E 2D两个字节。

同一个字符，在不同编码方案下字节序列不同，但这不影响“中”就是 U+4E2D 这个事实。所以当你听到“Unicode 编码”这种说法时，其实是不严谨的。准确地说应该是“Unicode 码点”加上“某个编码方案”。查对照表时，你看到的是码点；做文件传输、数据库存储时，你操作的是编码后的字节。

2.2 对照表上的 U+XXXX 到底怎么读

U+ 后面的十六进制数字就是这个字符的码点。以韩文“한”为例，它的码点是 U+D55C。在 Python 里可以用ord('한')获得十进制码点，再用hex()转成十六进制；在 JavaScript 里用'한'.codePointAt(0).toString(16)也能拿到d55c。反过来，想从码点得到字符，Python 用chr(0xd55c)，JavaScript 用String.fromCodePoint(0xd55c)。

理解了这一点，你查表时就不会只盯着那个字符长什么样，而是会顺手把码点记下来。因为字符形态可能会因为字体不同而变化，但码点是永恒不变的。这也是为什么我每期都会在表格里同时列出“字符”和“码点”两列，你复制字符是为了用，记下码点是为了排查问题。

3. 本期重点：韩文音节区与高频可复制字符

这一期后台搜索量最大的一个具体需求是“unicode的韩文字符可复制写出来。写出20个”。这说明很多人需要在没有韩文输入法的设备上录入韩文，或者需要在代码里硬编码韩文字符。韩文在 Unicode 里的位置非常有规律，掌握规律后，不查表也能推算出来。

3.1 韩文音节的编码规律

韩文字母（谚文）在 Unicode 中主要分布在三个区域：谚文字母区（U+1100–U+11FF）、谚文兼容字母区（U+3130–U+318F）、谚文音节区（U+AC00–U+D7A3）。日常使用最多的“가나다라마바사”这些完整音节，全部落在音节区。

音节区的排列遵循“初声 × 中声 × 终声”的规则。每个音节由一个初声、一个中声、一个可选的终声组成。Unicode 把韩文音节按照“가 U+AC00”为起点，按一定顺序连续排列。这意味着你只需要记住一个起始码点 U+AC00，再用初声、中声、终声的索引按公式计算，就能得到任意韩语音节的码点。这个公式在你的编程环境里没法直接输入韩文输入法时特别有用：

# 初声19个，中声21个，终声28个（含无终声） # 音节码点 = 0xAC00 + (初声索引 * 21 + 中声索引) * 28 + 终声索引 def hangul_syllable(choseong, jungseong, jongseong=0): return chr(0xAC00 + (choseong * 21 + jungseong) * 28 + jongseong) # 例："가" = 初声0(ㄱ), 中声0(ㅏ), 无终声 print(hangul_syllable(0, 0)) # 가

实际开发中，很多韩国本地系统在传输数据时，如果编码声明错误，韩文就会出现乱码。拿到乱码后的第一步不是猜，而是把乱码字符逐个转成码点，看看它们落在哪个区块。如果码点全部落在 U+AC00–U+D7A3 区间内，说明数据本身没有问题，是显示层的字体或编码声明出了问题；如果码点变成了 U+C548、U+B2F5 这类看似正常但组合起来毫无意义的音节，那就要检查是 UTF-8 被按 EUC-KR 解码了，还是反过来。

3.2 直接可复制的 20 个高频韩文音节对照

下面这组字符可以直接复制使用，我建议你同时把码点抄进自己的笔记里。它们是韩文里出现频率最高的一批音节，覆盖了打招呼、人称、常用动词和格式化文本中最常见的字。

这里多说一句，很多网页展示韩文时会出现“字符存在但字形不显示”的情况。你复制下来粘贴到 Word 里正常，粘贴到某些老系统里变成方框，这不是韩文字符有问题，而是字体文件里没有对应的 glyph。解决办法是换用支持韩文的字体，比如系统自带的 Malgun Gothic（韩文版 Windows 默认）、Noto Sans KR，或者是热搜里反复出现的 Arial Unicode MS。后面我会专门讲字体这条排查链路。

3.3 其他高频可复制符号速查

除了韩文，这几次热搜里还有几个高频字符值得单独列出来。第一个是“笑哭”表情 U+1F602，它在主流系统和手机上都显示正常，但在一些老旧企业软件里会变成空白方块。第二个是带圈数字 ①–⑳，分布在 U+2460–U+2473，Excel 里偶尔会用到。第三个是中文全角空格 U+3000，很多人排版时为了对齐空格，从网页复制一个看起来是空格的东西，其实是 U+3000 全角空格，和普通半角空格 U+0020 完全是两个码点。

这些字符单独看没什么，但放在“对照表”这个主题下就特别值得记。因为它们的共同特点是：字符本身没坏，码点也正确，但换一个环境就可能出现显示异常。你能做的就是先确认码点，再去判断是字体还是编码问题。

4. 拿到的码点，怎么在工程代码里落地

有些读者不是为了在文档里写几个韩文符号，而是要在程序里处理用户输入、做数据清洗、拼接接口返回值。这时候“对照表”的用法就变了，你不再需要人类可读的表格，你需要的是编程语言里的转换函数。我整理了三个最常见的场景。

4.1 Python 里的码点转换

Python 3 对 Unicode 的支持已经非常成熟。ord()和chr()是最常用的一对双向函数。ord接收一个字符，返回码点；chr接收十进制码点，返回字符。要注意的是，对于码点大于 U+FFFF 的字符，比如表情符号，用chr()也可以直接处理，不需要额外操作。

# 字符 → 码点 print(hex(ord('가'))) # 0xac00 print(hex(ord('😂'))) # 0x1f602 # 码点 → 字符 print(chr(0xac00)) # 가 print(chr(0x1f602)) # 😂

如果是从 JSON 接口读到\uac00这种转义格式，Python 的json.loads()会自动把它转成韩文字符；但如果字符串是双反斜杠\\uac00，说明前端把这个转义序列又转义了一层，你需要先处理成单反斜杠再交给 JSON 解析，否则得到的会是字面上的\uac00六个字符。

4.2 JavaScript 里容易被忽略的细节

JavaScript 的String.fromCharCode()只能处理 U+0000 到 U+FFFF 范围内的码点，处理不了表情这种增补平面字符。如果你用String.fromCharCode(0x1F602)，得到的是一个乱码一样的两个字符组合。正确做法是使用 ES6 提供的String.fromCodePoint()，它专门用来处理超过 U+FFFF 的码点。

// 错误写法 console.log(String.fromCharCode(0x1F602)); // 输出乱码 // 正确写法 console.log(String.fromCodePoint(0x1F602)); // 😂 // 反向取码点 console.log('😂'.codePointAt(0).toString(16)); // 1f602

这个坑我在实际项目里踩过一次。当时是从手机端传表情符号到 Web 端展示，后端 Java 用char存储，结果表情被切断成两个不可见字符。原因就是 Java 的char是 16 位，只能表示 BMP（基本多文种平面）里的字符，而 🎉 这类 emoji 位于增补平面，必须用代理对表示。最终是用codePointAt配合辅助函数解决的。类似的问题在 ABAP 老系统里更突出，后面我会专门提一下。

4.3 ABAP 里处理 Unicode 解码的常见姿势

热搜里出现了“abap unicode解码”这个词，说明确实有 SAP 开发者在查这个问题。ABAP 从 Unicode 系统开始，字符串变量内部就是 Unicode 编码，不再需要像老系统那样手动转换。但外部接口传进来的字节流，仍然需要按正确的编码声明去解析。

假设你收到一个字节流，已知它来自 UTF-8 编码的韩文，但按默认代码页解析后显示成乱码，处理思路是先把字节流根据 UTF-8 转成字符串，再进行后续逻辑。ABAP 中常用CL_ABAP_CONV_IN_CE这个类来创建转换器，指定编码后执行读取。核心代码大致长这样：

DATA(lo_conv) = cl_abap_conv_in_ce=>create( encoding = 'UTF-8' input = lv_byte_string ). lo_conv->read( IMPORTING data = lv_unicode_string ).

这段代码的关键在于encoding参数必须和实际编码一致。如果你拿到的是 EUC-KR 流，却用 UTF-8 去解，解出来的每个字符都会变成替换符 �。遇到这种情况，先确认源系统的字符集声明，再看字节流的高位规律，而不是盲目解码。

5. 复制粘贴乱码的排查链路，从字符到字体

“为什么我复制过来的 Unicode 字符变成问号/方块/乱码”是后台提问率最高的问题。这其实不是单一原因造成的，我总结了一条排查链路，你照着走一遍，基本能定位 90% 的显示问题。

5.1 第一步：判断字符本身是否完整

把出问题的字符复制到一个绝对支持 Unicode 的编辑器里，比如 VS Code 或者 Notepad++，然后把光标放在字符旁边，看编辑器的状态栏显示的码点。VS Code 的“选择字符后查看状态栏”能直接显示字符的 Unicode 码点。如果编辑器里显示正常，说明字符本身没坏，问题出在目标软件上；如果编辑器里也显示异常，说明源数据在复制之前就已经损坏了。

源数据损坏常见于“网页显示正常，但复制后粘贴内容变了”。原因可能是网页用了 CSS 伪元素、图片字体（iconfont）或者自定义字体来显示某个图标。比如你用 iconfont 显示一个“购物车”图标，页面上看着是个小图标，但复制到文本编辑器里，得到的可能是空字符，或者是某个私人使用区的码点 U+E604 之类。私人使用区码点在不同字体下含义完全不同，复制出来当然没法用。

5.2 第二步：检查目标程序是否支持该字符

字符本身没问题，粘贴到目标程序后出现方块，这大概率是字体问题。常见的罪魁祸首就是我前面提到的字体缺字形。比如 Excel 默认字体在某些版本里对“😂”支持不好，Word 里正常粘贴却显示一个空心方块。

解决办法有几个：一是给目标程序切换支持该字符区块的字体。Arial Unicode MS 是 Google 早期在很多文档里选用的全字集字体，覆盖范围很广，适合做显示兜底。韩文相关优先选 Malgun Gothic、Noto Sans KR；CJK 相关选宋体、微软雅黑、思源黑体；表情符号需要 Segoe UI Emoji（Windows）、Apple Color Emoji（macOS）。二是对于不支持 emoji 的老系统，接受降级显示为黑白符号或方块，不要在这个问题上过度纠结。

5.3 第三步：确认编码转换没有二次破坏

还有一种情况是，字符本身、字体都没问题，但你在传输过程中经历了多次编码转换。比如从数据库取出 UTF-8 字符串，写入文件时被系统按 GBK 编码保存，再被另一个程序按 UTF-8 读取。这种情况下，最终显示的字符串其实是由“错误解码”产生的其他字符组成的，通常表现为一串毫无意义的汉字或者中文乱码，比如“鐢叉柟”这种。

遇到这种问题，回溯链条比较麻烦，我的建议是：尽早统一编码，最好不要在链路中出现“先按 A 编码保存，再按 B 编码读取”的环节。如果已经出错了，可以尝试把当前乱码字符串重新按错误编码编码成字节，再按正确编码解码回来。这个操作在 Python 里就是s.encode('gbk').decode('utf-8')之类的反向操作，但前提是你知道之前错误地用了哪种编码。

6. 顺带排掉几个非 Unicode 领域的“对照表”干扰

前面说了，现在搜索“对照表”的人可能是在找“0603电阻阻值对照表”或者“pcb线宽电流对照表”。我完全理解这些需求，因为我自己以前搞硬件原型的时候也经常查这些表。但我想借这期文章给同时搜到两个领域的读者提个醒：不同领域的“对照表”，查法、精度、单位体系完全不一样。

6.1 电子领域对照表和字符对照表的本质差异

电阻阻值对照表查的是 E 系列标准值，比如 E96 系列里 10.0、10.2、10.5 这些标称值，它对应的是工程上对电阻精度的规整；PCB 线宽电流对照表查的是“铜箔厚度 + 线宽 + 温升 → 最大电流”的经验关系；PT1000 分度表查的是“温度 → 电阻值”的传感器特性。这些表描述的是物理量之间的换算关系，而 Unicode 对照表描述的是“人类字符 → 数字码点”之间的约定关系。两者唯一的共同点就是都以“表”的形式出现，仅此而已。

如果你是因为搜“电阻阻值对照表”误打误撞点进了这篇文章，那么我建议你直接忽略字符部分，去查 EIA 标准委员会的电子系列阻值表，那才是硬件设计的正确依据。同样，如果你是来找字符对照表的，也不用去研究 E96 贴片电阻是 10.2 还是 10.5，那只会让你更头大。搜索时把关键词加长，比如“0603 1% 贴片电阻阻值表”或者“unicode 韩文字节 码点表”，结果会精确很多。

6.2 为什么这个系列本身也像一张“分度表”

Unicode 对照表的价值，跟 PT1000 分度表其实有异曲同工之处。PT1000 分度表让你在知道电阻值时查温度，Unicode 对照表让你在看到一个字符时查码点，或者反过来。它们都是“翻译工具”，把一种形式的数值翻译成另一种形式。理解了这层类比，你就知道为什么这类基础表永远不会过时——工程界永远需要精确的翻译工具。

7. 这一期我最想分享的三个实操忠告

作为写这个系列的人，我实际操作中踩过的坑比查过的表还多，最后挑三个最值得说的。

第一个忠告：别把“复制”当成获取字符的唯一方式。看到“unicode字符大全可复制”这类搜索词，我知道很多人就是想在网页上找到字符直接用鼠标复制。这个办法对单字符有效，但如果你要批量生成一串韩文，或者程序中需要拼接多个特殊字符，还是花几分钟学一下chr/fromCodePoint更划算。用代码生成 100 个字符比手动复制 100 次可靠得多。

第二个忠告：记录字符时养成“字符 + 码点 + 编码”三者同时记录的习惯。我以前做数据清洗项目时，遇到过一个全角空格问题，后来发现数据源头有半角空格、全角空格 U+3000、不间断空格 U+00A0 三种空格混杂在一起，光看显示根本分不出来，只能靠码点区分。从那次以后，我在所有处理文本的代码里，都会把“不可见字符”的码点打印出来做日志。这个习惯救了我无数次。

第三个忠告：字体选型要提前做，不要等出问题再换。如果你写的是面向多个系统分发内容的模板，建议默认选用覆盖范围大的字体，并且不要直接指定某个第三方字体文件，而是用字体回退机制。在 CSS 里就是font-family: "Noto Sans KR", "Apple SD Gothic Neo", "Malgun Gothic", sans-serif;这样一段声明，让系统自动在可用字体里找最合适的。最大程度避免“字体缺失造成的方块字”。

这个系列做到 045，我越来越感觉到，Unicode 对照表其实不是一张静态的表，而是一种“字符世界的定位思维”。你不需要把几万个码点背下来，但你要知道字符为什么会乱、码点怎么查、字体和编码分别影响什么。掌握这套排查链路之后，再遇到任何奇怪的字符问题，你都比大多数人多走三步。