1978年8月，数字设备公司（DEC）推出了VT100终端。这台设备成为计算机历史上最重要的终端之一，不仅因为它的商业成功，更因为它首次大规模普及了ANSI转义序列——这套至今仍在使用的终端控制协议。
将近五十年后的今天，当你在终端里输入printf "\033[31mHello\033[0m"看到红色文字时，你使用的仍然是VT100奠定的技术基础。但终端颜色远比大多数人想象的复杂：从最初的8色，到16色、256色，再到现代终端支持的24位真彩色，每一级演进都涉及协议设计、硬件限制和软件兼容性的复杂权衡。
一个字符如何变成颜色
当程序向终端输出文本时，它发送的不仅是可显示的字符，还可能包含控制序列。这些序列以ESC字符（ASCII 27，写作\033或\x1b）开头，告诉终端"接下来的内容不是要显示的文字，而是命令"。
最常用的控制序列类型是CSI（Control Sequence Introducer），格式为ESC[后跟参数和命令字符。设置颜色的命令称为SGR（Select Graphic Rendition），命令字符是m。
ESC[31m # 设置前景色为红色
ESC[0m # 重置所有属性
当终端解析到ESC[31m时，它知道这是一条SGR命令，参数31表示"设置前景色为红色"。终端随后会将这个状态保存起来，之后输出的所有文字都使用红色显示，直到收到重置命令或新的颜色命令。
这套机制被称为"带内信令"（in-band signaling）——控制命令和数据混在同一个流中传输。它的优点是不需要额外的通信通道，缺点是如果程序输出的文本恰好包含ESC字符，终端可能会错误地将其解释为命令。这也是为什么某些二进制文件直接输出到终端时会产生乱码或意外行为。
8色的物理起源
ANSI标准最初只定义了8种颜色：黑、红、绿、黄、蓝、品红、青、白。这不是随意的选择，而是基于RGB颜色模型的直接映射。
颜色编号 颜色名 RGB原理
0 黑 无光
1 红 红光
2 绿 绿光
3 黄 红+绿
4 蓝 蓝光
5 品红 红+蓝
6 青 绿+蓝
7 白 红+绿+蓝
这种排列形成了一个3位二进制编码：最低位代表红，中间位代表绿，最高位代表蓝。编号0-7恰好覆盖了所有组合。这个设计来自早期的彩色CRT显示器，它们的电子枪可以独立控制红、绿、蓝三个荧光粉。
但这里有个问题：为什么编号顺序是"红绿黄蓝品红青"而不是按照RGB值排序？答案是历史兼容性。早期的字符终端和打印机有自己的颜色命名传统，ANSI标准试图在新的编码体系和旧的习惯之间找到平衡。
从8色到16色：“加粗"的意外演化
ANSI标准中，SGR参数1表示"加粗”。但在早期的终端实现中，加粗效果是通过增加亮度来实现的——让红色变得更红，绿色变得更绿。这产生了8种额外的"高亮"颜色。
后来，aixterm（IBM AIX系统的终端）直接为这些高亮颜色分配了独立的SGR代码：90-97用于高亮前景色，100-107用于高亮背景色。这成为了事实标准，几乎所有现代终端都支持这种扩展。
但"加粗等于高亮"的副作用保留了下来。在大多数终端中，ESC[1;31m（加粗红色）和ESC[91m（高亮红色）会产生相似的视觉效果，尽管语义上它们是不同的属性。
256色：xterm的 pragmatic 扩展
随着图形显示器的普及，16种颜色显然不够用。1999年，xterm引入了256色支持，这成为后来所有终端的事实标准。
256色调色板的构造体现了务实的设计哲学：
索引 0-15: 标准16色（兼容原有代码）
索引 16-231: 6×6×6颜色立方体（216色）
索引 232-255: 24级灰度
6×6×6颜色立方体的计算方式是：
def color_256_to_rgb(n):
if n < 16:
return standard_16_colors[n]
elif n < 232:
n -= 16
r = (n // 36) % 6
g = (n // 6) % 6
b = n % 6
# 将0-5映射到RGB值
return (r * 40 + 55 if r > 0 else 0,
g * 40 + 55 if g > 0 else 0,
b * 40 + 55 if b > 0 else 0)
else:
# 灰度
gray = 8 + (n - 232) * 10
return (gray, gray, gray)
使用256色的转义序列格式为：
ESC[38;5;Nm # 设置前景色，N为颜色索引
ESC[48;5;Nm # 设置背景色
为什么选择6×6×6而不是更精细的划分？这反映了当时的技术现实：256色是8位能表示的最大颜色数，而6×6×6=216正好留出空间给灰度梯度和原有颜色。这种权衡使得同一个调色板能够满足程序员的多种需求——需要精确颜色时用RGB索引，需要灰度时有连续的灰阶可用。
24位真彩色：突破调色板限制
现代终端支持直接使用RGB值指定颜色，称为"真彩色"（True Color）。这意味着终端理论上可以显示超过1600万种颜色。
ESC[38;2;R;G;Bm # 设置前景色为指定RGB
ESC[48;2;R;G;Bm # 设置背景色
例如，ESC[38;2;255;128;0m设置前景色为橙色（RGB: 255, 128, 0）。
真彩色的引入解决了一个长期存在的问题：256色调色板无法精确匹配设计稿中的颜色。开发者经常不得不在终端支持的有限颜色中选择"最接近"的颜色，导致视觉效果的偏差。
但真彩色也带来了新问题：如何检测终端是否支持？256色可以通过检查$TERM环境变量（如xterm-256color）来判断，但真彩色没有统一的报告机制。目前最可靠的方法是检查$COLORTERM环境变量是否包含truecolor或24bit。
if [ "$COLORTERM" = "truecolor" ] || [ "$COLORTERM" = "24bit" ]; then
# 终端支持真彩色
fi
调色板的动态修改
终端的颜色方案不是固定的。通过OSC（Operating System Command）序列，程序可以动态修改调色板中的颜色。
ESC]4;N;rgb:RR/GG/BBEL # 设置调色板索引N的颜色
例如，ESC]4;1;rgb:ff/00/00BEL将索引1（红色）重新定义为纯红。这使得终端主题可以动态切换，而不需要修改应用程序代码。
Vim等编辑器利用这个特性实现"真彩色主题"——即使终端不支持真彩色，也可以通过重新定义调色板来精确控制颜色显示。当然，这种方法一次只能有256种颜色同时显示。
终端渲染的现代架构
理解终端颜色如何工作，还需要了解终端渲染的内部机制。传统的终端模拟器使用CPU逐个字符渲染到屏幕缓冲区，然后由操作系统绘制窗口。这种方式简单直接，但在高刷新率、大字体、复杂Unicode场景下性能不足。
现代GPU加速终端（如Alacritty、Kitty、WezTerm）采用了完全不同的渲染架构：
- 字形缓存：将每个字符的字形（glyph）渲染一次，存储在GPU纹理中
- 颜色属性分离：颜色信息作为顶点属性传递，不重复存储字形数据
- 批量渲染：将整个屏幕的内容打包成一次GPU绘制调用
Contour终端开发者Christian Parpart在文章中描述了这个过程：终端首先将文本按SGR属性分组，对每组进行文本整形（text shaping），生成字形索引和位置，然后将这些数据上传到GPU。颜色信息作为每个字符的顶点属性传递，GPU着色器将其与字形纹理混合产生最终颜色。
这种架构的关键优势是：当只有颜色变化时（如光标移动、高亮选择），不需要重新进行文本整形，只需更新颜色属性缓冲区。这使得现代终端能够以极低的CPU占用实现流畅的滚动和动画效果。
替代屏幕缓冲区
你可能注意到，运行vim或less时，退出后之前的命令历史仍然显示在屏幕上。这不是魔法，而是"替代屏幕缓冲区"功能。
ESC[?1049h # 切换到替代屏幕缓冲区
ESC[?1049l # 切换回主屏幕缓冲区
当程序激活替代屏幕时，终端创建一个新的空白缓冲区用于显示。程序退出时切换回主缓冲区，之前的内容完好无损。这个功能来自xterm扩展，现在是所有现代终端的标准功能。
这解释了为什么有时vim退出后屏幕会"闪烁"——那是终端在两个缓冲区之间切换。某些终端配置中，这个行为可以被禁用（导致vim退出后内容仍留在屏幕上），这就是为什么有些人报告vim"不保存历史"。
括号粘贴模式：安全的细节
终端粘贴文本时，默认行为是将剪贴板内容直接插入输入流。这看起来自然，却有安全隐患：如果粘贴的文本包含换行符，shell会执行这些内容。
括号粘贴模式（Bracketed Paste Mode）解决了这个问题：
ESC[?2004h # 启用括号粘贴模式
ESC[?2004l # 禁用括号粘贴模式
启用后，粘贴的内容被特殊序列包裹：
ESC[200~ 粘贴内容开始
... 粘贴的实际内容 ...
ESC[201~ 粘贴内容结束
应用程序可以识别这些序列，知道"这段文字是粘贴的，不是用户输入的"，从而决定如何处理。Bash 4.2+和Zsh默认启用此功能，粘贴后不会立即执行，而是等待用户按回车确认。
这个看似微小的功能，实际上是终端安全的重要一层。想象一下，如果你不小心粘贴了从网页复制的命令，其中包含隐藏的换行符和恶意代码…
Windows的追赶
Windows终端生态有着独特的历史。早期的Windows命令提示符（cmd.exe）完全不支持ANSI转义序列，需要加载ANSI.SYS驱动才能获得最基本的颜色支持。这使得Windows成为终端应用的"二等公民"。
2016年，Windows 10的1511版本突然宣布支持ANSI转义序列。这个更新是为了支持Windows Subsystem for Linux（WSL），让Linux终端应用能在Windows上正常运行。2019年发布的Windows Terminal进一步巩固了这个支持，现在Windows终端用户可以享受与其他平台相同的颜色和样式功能。
启用Windows控制台的虚拟终端处理需要显式调用API：
DWORD mode = 0;
GetConsoleMode(hStdOut, &mode);
mode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING;
SetConsoleMode(hStdOut, mode);
这个历史遗产解释了为什么许多终端颜色库（如Python的colorama）需要特殊处理Windows——它们需要检测平台并调用适当的初始化代码。
终端颜色的未来
终端颜色技术的发展没有停止。当前的趋势包括：
语义颜色：不再是硬编码RGB值，而是使用语义名称（如"error"、“warning”）。终端根据主题设置将语义映射到实际颜色。这使得同一应用可以在不同主题下自动适配。
颜色配置文件：高级终端支持ICC颜色配置文件，确保颜色在不同显示器上保持一致。这对于依赖精确颜色的应用（如终端图像查看器）尤其重要。
扩展下划线样式：Kitty终端协议扩展了下划线样式，支持波浪线、双线、点线等样式，并为下划线本身设置颜色。这在代码诊断和差异显示中有重要应用。
写在最后
终端颜色看起来简单——不就是几个转义序列吗？但深入了解后，你会发现这是一个积累了近五十年历史的技术栈：从VT100的硬件限制，到xterm的实用主义扩展，再到现代终端的GPU渲染架构。每一层设计都是在特定历史条件下，为解决特定问题而做出的选择。
当你下次在终端里设置颜色时，想想这条信息路径：你的代码发送ESC序列，终端解析命令，查找调色板或计算RGB值，字形引擎渲染字体，GPU绘制像素。所有这些在毫秒级别完成，让文字以你期望的颜色出现在屏幕上。
这就是终端颜色的完整故事——一套既古老又现代的技术，承载着计算历史，同时服务于今天的开发者。
参考文献
- ECMA-48: Additional Control Functions for Character-Imaging I/O Devices, 5th Edition, June 1991
- VT100 User Guide, Digital Equipment Corporation, 1978
- XTerm Control Sequences, Thomas E. Dickey, https://invisible-island.net/xterm/ctlseqs/ctlseqs.html
- Julia Evans, “Standards for ANSI escape codes”, https://jvns.ca/blog/2025/03/07/escape-code-standards/
- Christian Parpart, “A Look into a terminal emulator’s text stack”, https://dev.to/christianparpart/look-into-a-terminal-emulator-s-text-stack-3poe
- Terminal Colors Standard, https://github.com/termstandard/colors
- Console Virtual Terminal Sequences, Microsoft Learn, https://learn.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences
- Jim Fisher, “How less works: the terminal’s alternative buffer”, https://jameshfisher.com/2017/12/04/how-less-works/
- “Bracketed Paste Mode”, https://cirw.in/blog/bracketed-paste