很多人第一次接触 ASCII 艺术字第一反应是“这不就是字符拼图吗”——从某个字符素材库里去匹配字母 A 对应一套固定字符组合。早期的手工字符画确实这么干的但你要做一个“文字转 ASCII 生成器”走的路子完全不是这样。这个项目的核心其实不是“字符”而是“图像”。先把文字渲染成一张位图再把位图降采样成一个网格网格里每个格子的亮度对应一个字符。想明白这一点整个工具的实现逻辑一下子就通了。这个项目非常适合 Python 入门后想做点完整东西的阶段它涵盖命令行参数解析、图像处理、字体渲染、终端控制序列代码量不大但每一块都是真实工程里会用到的东西。做出来的东西也实用既能给命令行工具加个启动 banner也能生成 README 里的装饰标题还能顺手扩展成图片转字符画甚至视频转字符画。下面我把完整思路、实现代码和踩过的坑都写出来。1. 别把它当“字符拼图”文字转ASCII的真实原理1.1 一个反直觉的事实先渲染成图像再降级成字符我一开始也觉得文字转 ASCII 不就是拿文字本身去查表吗比如用户输入“HELLO”应该有个映射表把它转成一组可以拼出“HELLO”字样的字符组合。后来仔细一想不对ASCII 艺术字要展现的是“这行字长什么样”而不是“这行字的内容是什么”。换句话说输入的文字是作为图形出现的它的语义在生成后已经不重要了重要的是它的轮廓、粗细和明暗。所以这个项目正确的处理顺序应该是用字体把文字渲染成一张图像尺寸和字体由用户指定。把图像等比缩放到目标字符网格大小比如宽 80 字符、高 20 字符。遍历缩放后图像的每个像素根据灰度值映射成一个字符。把这些字符按行拼接输出到终端或保存为文本。这个过程本质上是一个“图像降采样 量化”的操作。字符只是替代像素的显示单元。想通这一点后续所有设计都顺了。1.2 灰度映射字符画最核心的那一步把文字渲染成图像之后我们拿到的是一张普通的位图。每个像素有 RGB 三个通道但字符画没有颜色至少黑白版没有所以第一步是把彩色像素转换成灰度值。常用的灰度公式是gray 0.299 * R 0.587 * G 0.114 * B这组系数来自 NTSC 亮度公式本质上是在模拟人眼对不同颜色的敏感度。人对绿色最敏感蓝色最不敏感所以绿色权重最高、蓝色权重最低。直接用三个通道取平均也能用但出来的字符画对比度会差一些尤其是遇到蓝色或红色内容时灰度层次不准确。实测下来用加权公式的观感更好。得到灰度值之后值域是 0 到 2550 代表纯黑255 代表纯白。然后我们把字符表看作一组“从密到疏”的灰度代替物按灰度值区间去切分。假设字符表是%#*-:. 从到空格字符的视觉密度依次递减。某个像素越暗就用越靠前的字符越亮就用越靠后的字符。索引计算的公式是index gray * (len(charset) - 1) // 255//是整数除法天然地保证了灰度 255 时索引刚好落在最后一个字符上灰度 0 时落在第一个字符上不会越界。这个写法比int(gray / 255 * len(charset))更安全因为后者在 gray 等于 255 时可能算出等于 len(charset) 的索引导致越界。1.3 字符表的顺序不是想当然要按“视觉密度”排网上很多教程给的字符表是 .:-*#%从亮到暗排。看着合理但实际跑出来的效果往往有点怪。原因在于字符的“视觉密度”不只看它在屏幕上占了多少个像素还跟字体渲染方式、终端显示比例有很大关系。我自己实测过几个常见字符表稳定的顺序大致是这样%#*-:. 如果背景是白色、字符是黑色那么这条表的最左边是视觉最重的字符最右边空格代表“没有内容”用来表现高光区域。有人说空格放最后会不会让亮部一片空白能问出这个问题说明还没犯过这个错——ASCII 字符画不是让你看出“字符串内容”而是让你看出“明暗形状”空白区域本来就是高光的一部分空格不占视觉重量反而能衬托出前面的暗部渐变。真正常出现的调试问题不是空格太多而是整张图灰蒙蒙一片、没有层次这种情况往往是字符表过短。字符表只有 10 个字符时灰度被切成 10 档很多中间调被合并了。实践下来默认字符表长度在 12 到 20 之间比较平衡。太短没层次太长则灰色区域会被各种细碎字符填满看起来像噪点。我目前默认用%#*-:. 共 10 个字符在大多数场景下表现稳定。如果你想要更细腻的渐变可以扩展成$B%8WM#*oahkbdpqwmZO0QLCJUYXzcvunxrjft/\\|()1{}[]?-_~i!lI;:,\^. 这是网上流传的 70 级经典表但说实话在普通终端里 70 级反而会显得脏我一般只在输出到 HTML 或高清图片时才用长表。还有一个容易忽略的细节字符表左右两端要“顶满”。如果最左边不是足够重的字符暗部会发虚最右边如果不是空白或接近空白的字符亮部会显得脏。选好字符表之后先用一张纯黑到纯白的渐变图测一测输出如果是平滑过渡说明表没问题。2. 从零搭建一个可用的命令行生成器2.1 环境准备Pillow 是唯一硬依赖Python 标准库本身不带图像处理能力所以这里绕不开 Pillow。网上也有人用 pyfiglet 做文字转 ASCIIpyfiglet 对英文支持很好但它本质上是预制字体拼接不是灰度映射而且不支持中文。如果你只需要纯英文大写字母的横幅效果pyfiglet 确实更快但要做真正通用的“文字转 ASCII 艺术字生成器”Pillow 才是正确的选择。安装很简单pip install pillow环境要求 Python 3.8 以上。项目里用到的argparse、shutil、os都是标准库不需要额外安装。2.2 参数设计面向使用场景而不是面向写死命令行工具和一次性脚本最大的区别在于参数设计。一个合格的生成器用户的需求可能是多样的有人要把文字渲染成终端里显示的 banner有人要输出到 HTML 展示有人想调整字符集获得不同的颗粒感。如果这些全在代码里写死每换一个场景就要改代码那不是生成器是个一次性玩具。我设计的核心参数如下参数类型默认值说明textstr必填要转换的文本支持多行用\n分隔--fontstr自动检测字体文件路径不传则自动查找系统中文字体--widthint终端宽度自适应输出字符列数控制字符画宽度--charsetstr%#*-:. 字符映射表按密到疏排列--colorboolFalse是否输出 ANSI 真彩色--outputstr终端输出到终端还是保存为文本文件--htmlboolFalse输出为 HTML 页面保留颜色和空格参数不是越多越好但不能缺少那些会直接影响输出效果的开关。--width是最重要的一个因为同样一段文字在 80 列和 120 列宽度下完全是两种颗粒度。2.3 核心代码拆解渲染、缩放、映射三步走先看完整代码然后逐段拆解。import argparse import os import shutil import sys from PIL import Image, ImageDraw, ImageFont DEFAULT_CHARSET %#*-:. FONT_CANDIDATES [ C:/Windows/Fonts/msyh.ttc, C:/Windows/Fonts/simhei.ttf, /System/Library/Fonts/PingFang.ttc, /System/Library/Fonts/STHeiti Light.ttc, /usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc, /usr/share/fonts/truetype/wqy/wqy-microhei.ttc, ] def detect_cjk_font(): for path in FONT_CANDIDATES: if os.path.exists(path): return path return None def render_text_to_image(text, font_path, font_size36, max_width_px1200): font ImageFont.truetype(font_path, font_size) line_height font.getbbox(Hg)[3] - font.getbbox(Hg)[1] 8 lines [] current for ch in text: if ch \n: lines.append(current) current continue test current ch if font.getlength(test) max_width_px: lines.append(current) current ch else: current test lines.append(current) width max(int(font.getlength(line)) for line in lines) 16 height line_height * len(lines) 16 image Image.new(L, (width, height), color255) draw ImageDraw.Draw(image) y 8 for line in lines: draw.text((8, y), line, fill0, fontfont) y line_height return image def image_to_ascii(image, width, charset): height max(1, int(width * image.height / image.width * 0.5)) small image.resize((width, height), Image.LANCZOS) pixels list(small.getdata()) lines [] for y in range(height): row pixels[y * width:(y 1) * width] line .join(charset[gray * (len(charset) - 1) // 255] for gray in row) lines.append(line) return \n.join(lines) def main(): parser argparse.ArgumentParser(description文字转ASCII艺术字生成器) parser.add_argument(text, help要转换的文本多行用\\n分隔) parser.add_argument(--font, defaultNone, help字体文件路径) parser.add_argument(--width, typeint, defaultNone, help输出字符列数) parser.add_argument(--charset, defaultDEFAULT_CHARSET, help字符映射表) args parser.parse_args() font_path args.font or detect_cjk_font() if font_path is None: print(未找到可用中文字体请用 --font 指定字体文件路径, filesys.stderr) sys.exit(1) image render_text_to_image(args.text, font_path) term_width shutil.get_terminal_size((80, 24)).columns output_width args.width or int(term_width * 0.9) ascii_art image_to_ascii(image, output_width, args.charset) print(ascii_art) if __name__ __main__: main()这段代码不长但每一步都值得说清楚为什么这么写。render_text_to_image里最关键的是换行逻辑。用户输入可能是一段长文本不能指望他手动插\n。所以我用font.getlength(test)去实时量宽度超过max_width_px就换行。这个逻辑比按字符数硬切要好因为中英文混排时字符宽度差异巨大按字符数切会出现一行特别挤一行特别空的情况。max_width_px设成 1200 是因为默认字号 36 的情况下大约能放 40 个汉字再宽容易超出字符画合理的宽高比。line_height的计算也有讲究。不能用font_size直接当行高因为不同字体的 ascent 和 descent 不同。我用font.getbbox(Hg)测量大写 H 和小写 g 的包围盒高度这样既能覆盖上行和下行又不会留太多空白。8是行距补偿避免两行文字贴在一起。image_to_ascii里有个 0.5 的系数这是整个工具能不能“像样”的关键。终端里一个字符单元格的高度大约是宽度的两倍也就是说同样的字符数量纵向视觉距离比横向大。如果直接按原始图像宽高比缩放出来的字符画会被拉高。乘上 0.5 之后输出的字符画在终端里看起来才接近原图比例。这个系数严格来说跟终端字体有关各平台略有差异但 0.5 在 Windows Terminal、iTerm2、GNOME Terminal 里表现都不错如果觉得变形可以通过修改系数微调。Image.LANCZOS是 Pillow 提供的高质量插值算法。降采样时如果直接用Image.BILINEAR或者最近的Image.NEAREST图像边缘会有锯齿灰度过渡也不平滑。LANCZOS 的计算量稍大但这种小尺寸图像完全感知不到性能差异用最好的插值算法是值得的。charset[gray * (len(charset) - 1) // 255]这个表达式前面解释过灰度 0 映射到第一个字符255 映射到最后一个字符。注意这里charset的方向是“暗在前、亮在后”所以DEFAULT_CHARSET最右边放的是空格。如果你的终端是白字黑底深色背景可以把字符表反转用一个参数切换--charset .:-*#%效果都合理。到这里一个能跑的最小版本就完成了。运行方式python ascii_art.py Hello World python ascii_art.py 你好世界 --width 100 python ascii_art.py 多行文本\n第二行 --font /path/to/font.ttf3. 字体渲染的坑中文输出、字符宽度、API变化3.1 中文全是“豆腐块”根子在字体而不是代码第一次跑通代码时我用的是ImageFont.load_default()渲染英文一切正常渲染中文全是空心的方块也就是传说中的“豆腐块”。很多人第一反应是代码有 bug其实问题很简单Pillow 默认字体根本不包含中文字形它不知道“你”字应该长什么样。解决办法是显式指定一个包含中文字形的字体文件。Windows 上通常是msyh.ttc微软雅黑或simhei.ttf黑体macOS 上是PingFang.ttc或STHeiti Light.ttcLinux 发行版一般是NotoSansCJK-Regular.ttc或文泉驿微米黑。detect_cjk_font做的事情就是依次探测这些常见路径找到第一个存在的文件就返回。这个“自动探测”能力看着不起眼但它决定了工具在别人机器上能不能开箱即用。有个细节Windows 的字体文件很多在C:/Windows/Fonts/下路径不含空格但有些自定义路径有空格比如C:/My Fonts/test.ttf。ImageFont.truetype对路径字符串的处理是正常的但如果你用Path对象传进去在某些 Pillow 版本下会报错。我踩过这个坑现在统一用str()包一层再传入。具体原因跟 Pillow 底层freetype库的接口有关它接受 C 字符串Path对象在部分版本上不能正确转换。3.2 中英文混排的宽度不对称问题中文和英文字符在渲染时的宽度不一致。中文通常是全角占两个英文字符的宽度英文字母和数字是半角只占一个。如果你在生成字符画时按字符数逐字符换行遇到中英文混排的输入就会出现一行长一行短右边界参差不齐。解决思路是把换行决策放到像素层面我们不关心当前行有多少个字符只关心这一行在字体渲染下的像素宽度是否超出限制。代码里用font.getlength(test)累加每个字符的渲染宽度超限才换行。这样中英文混排时中文自然会占用更多宽度英文占用较少换行位置完全由字体的实际度量决定不会出现“看起来很短却换行了”的怪异行为。类似的坑还有一个如果你把生成好的字符画粘贴到普通文本编辑器里中英文字符的显示宽度不一致ASCII 画会错位。这不是代码问题而是字符画天然依赖等宽字体。在终端里看没问题但放到网页或 Word 里就乱了。所以在项目 README 里我都会提醒一句请使用等宽字体查看包括空格和标点在 Monospace 环境下等宽。3.3 Pillow 版本变迁带来的兼容性问题Pillow 是一个变化比较大的库尤其最近几个版本砍了不少老 API。我最早写代码时用的是draw.textsize()来测量文本尺寸后来发现 Pillow 10 里这个方法被移除了换成font.getlength()和font.getbbox()。如果你运行时报AttributeError: ImageDraw object has no attribute textsize不是你的代码写错了是 Pillow 版本太新。getlength()返回的是字符串在指定字号下的像素宽度适合做换行判断getbbox()返回的是包围盒四元组(left, top, right, bottom)可以计算文本实际占用的矩形区域。这两个 API 是当前推荐做法新代码应该直接用它们。还有一个小坑ImageFont.truetype()的第二个参数是字号像素单位不是磅值。如果你想生成更大的图直接调大这个数字就行但要注意max_width_px也要相应调大否则换行会过于频繁字符画变得细高。另一个值得注意的兼容性细节是Image.new(L, ...)创建的是单通道灰度图但如果你想让输出支持彩色后面会讲就需要改为Image.new(RGB, ...)。接口上没有区别但后续像素读取时要处理的问题完全不同。我的建议是核心函数里用灰度图把彩色输出作为独立扩展层避免把逻辑混在一起。4. 从黑白到彩色终端颜色与输出适配4.1 纯黑白为什么总觉得不对劲用灰度映射生成文字后我对比了一下原图和字符画总觉得少了点什么。后来意识到文字本身是有颜色的比如一个红色 logo转换后红色和黑色在灰度上可能非常接近字符画里就糊成一片了。这是因为灰度映射只保留了亮度信息丢弃了色相和饱和度。解决方案很直接先用原来的灰度映射决定某个位置该用哪个字符再单独获取该位置在原始彩色图像中的 RGB 值用 ANSI 转义序列把字符染成那个颜色。这样字符的“形”和“色”分别来自两套采样逻辑互不干扰。实现起来需要同时拿到灰度图和彩色图。核心函数可以返回三样东西字符矩阵、每个位置的平均颜色、以及尺寸信息。处理流程变成创建 RGB 模式的图像渲染文字。把 RGB 图复制一份转成灰度图。灰度图按之前的方式缩放并映射成字符。RGB 图按相同尺寸缩放得到每个位置的 RGB 颜色。输出时用颜色码包裹字符。4.2 ANSI 真彩色和 Windows 兼容终端彩色输出的原理是 ANSI 转义序列。真彩色格式如下\033[38;2;R;G;Bm字符\033[0m其中\033是 ESC 字符38;2表示前景色使用 RGB 模式后面跟三个数值\033[0m重置所有属性。把每个字符都包上这段序列终端就能按照每个位置的原始颜色显示。代码写起来很简单def ansi_color(char, r, g, b): return f\033[38;2;{r};{g};{b}m{char}\033[0m但这里有一个很容易让 Windows 用户崩溃的坑老版本cmd.exe默认不解释 ANSI 转义序列输出全是乱码。解决方法是程序启动时执行一次os.system()。这一行看似什么都不做实际上它会启用 Windows 的 ANSI 转义处理机制。现代 Windows Terminal 和 VS Code 终端默认支持但用系统自带的cmd或 PowerShell 5.1 时需要这个技巧。macOS 和 Linux 的终端基本都支持 ANSI不用特殊处理。如果你要兼容更老的环境可以做一个降级检测到TERM环境变量为空或者平台是 Windows 且不是新终端时放弃颜色输出。这个检测并不复杂但说实话现在还在用不支持真彩色终端的人已经非常少了我的做法是默认开启彩色遇到问题再让用户自己关掉。4.3 把结果输出成HTML分享和记录都方便终端里显示字符画没问题但如果你想把结果发到博客、GitHub README或者发给同事看终端的效果就保不住了。Markdown 代码块会保留空格但丢颜色普通文本块连空格都可能被折叠。这时候输出成 HTML 是最稳的方案。思路是同彩色输出一样拿到字符矩阵和每个位置的颜色。把结果包在pre标签里因为pre保留空格和换行。每个字符用span stylecolor:rgb(r,g,b)字符/span包裹。生成一个pre块直接粘到 HTML 里就能展示。如果你要生成一个完整页面加一层简单的 CSS 设置黑色背景字符画瞬间从“终端风格”变成“海报风格”。代码逻辑def to_html(ascii_matrix, color_matrix): rows [] rows.append(pre style\background:#000;color:#fff;font-family:monospace;line-height:1.1;\) for line_chars, line_colors in zip(ascii_matrix, color_matrix): html_line for ch, (r, g, b) in zip(line_chars, line_colors): html_line fspan style\color:rgb({r},{g},{b})\{escape_html(ch)}/span rows.append(html_line \n) rows.append(/pre) return \n.join(rows)注意escape_html很有必要因为字符集如果包含、、这些字符串直接拼 HTML 会把标签打破。用html.escape()处理一下就安全了。这种输出方式对字符集长度很友好即使你用了 70 级长字符表渲染出一堆细碎字符在 HTML 里也不会显得太乱因为颜色重新给每个字符赋予了区分度。5. 进阶玩法图片、视频与真实应用场景5.1 性能问题的本质与优化第一次跑 120 列宽、40 行高的输出时我以为会卡一下结果毫秒级就完成了。后来想想也对总共 4800 个采样点Pillow 的resize在一瞬间就做完了映射循环也不过是 4800 次字符串拼接毫无压力。性能真正的瓶颈在哪里在于有些人会偷懒写一个双重循环逐个像素处理。比如for x in range(0, img.width, step): for y in range(0, img.height, step): # 求区域平均值这样逐块采样Python 解释器跑嵌套循环的效率很低而且区域平均值的计算更慢。正确做法是先用resize()一步到位降采样既得到目标尺寸又完成了像素融合。Image.LANCZOS本身就是高质量的图像缩放算法比你手动求平均要可靠得多。所以性能优化的核心思路不是“加速循环”而是“减少循环”让 C 层代码去处理重活。如果你需要处理超大字符画比如 300 列宽resize依然是合适的方案。字符串拼接 300 × 150 45000 次在 Python 里也就是几十毫秒的事。真正可能变慢的环节反而是终端输出45000 个字符一次性print会导致终端渲染卡顿。遇到这种情况可以用sys.stdout.write逐行写入并在行尾加\n避免构造一个巨大的输出字符串。5.2 图片转 ASCII 和视频转 ASCII 的扩展思路文字转 ASCII 的核心流程是“图像降采样 灰度映射”图片转 ASCII 则连“渲染文字成图像”这步都省了直接把图片加载进来就行。代码反而更短from PIL import Image def image_file_to_ascii(path, width, charset): img Image.open(path).convert(L) height int(width * img.height / img.width * 0.5) small img.resize((width, height), Image.LANCZOS) # 后续映射逻辑完全复用视频转 ASCII 的原理也完全一样只是把“一张静态图”换成“视频的每一帧”。用opencv-python读帧转灰度缩放映射然后清屏输出。演示效果很炫但注意两点第一不要用print(\033c)清屏太频繁否则终端会闪烁。更好的办法是用 ANSI 光标移动序列\033[H把光标移到左上角然后覆盖写同一块区域这样不会闪烁。第二帧率要克制。终端渲染字符画本来就不快10 帧每秒已经足够流畅了再高观众也看不清内容。视频转 ASCII 更多是炫技和教学用实际项目里很少需要实时处理离线逐帧转换更稳妥。5.3 几个我实际用上的场景项目做完之后我很快就在几个地方用上了命令行启动 banner。我维护的一个内部命令行工具启动时会打印一段大号“初始化系统”的 ASCII 标题。原来是用pyfiglet做的但 pyfiglet 对中文支持很差换了这套方案之后中英文都能正常显示而且可以自定义字体渲染出不同风格的启动画面。Spring Boot 项目里常见的banner.txt其实也是这个思路只是格式从字符画变成了普通文本拼接。README 封面图。我用彩色 HTML 输出把项目名生成了一张字符画放进 README 开头。效果比截图更统一因为它是纯文本不会因为屏幕分辨率不同而变形。配合深色背景看起来还挺有极客感。代码注释装饰。这个算是无聊但有趣的用法。在工具脚本头部加一段 ASCII 艺术字注释标出这个文件的用途效果比一行# 注意此脚本不可删除醒目得多。我用生成的字符画替代了原来的纯文字注释团队里看到的人还专门跑来问是啥工具做的。拼豆图纸的前置处理。拼豆Perler Beads的图纸本质上就是一个网格化、离散化的图像。和 ASCII 生成本质完全一样区别在于拼豆要求每个格子是一个色号而不是一个字符。我后来把这个项目的字符映射部分改成了色号映射输出网格矩阵再配合拼豆色号表就变成了一个简单的拼豆图纸生成器。可见“图像降采样 离散映射”这个模式的应用范围有多广。如果你也想做个类似的工具我的建议是手里先有一份可用的字符表、一个能自动探测字体的函数、一套终端宽度自适应逻辑这三点是刚需。字符表决定观感字体探测决定中文能不能用宽度自适应决定在不同终端里显示是否正常。围绕这三点逐步扩展彩色、HTML、图片视频支持每一步都有明确的收益和验证方式。跑通之后你会明显感觉到之前零散的参数解析、图像处理、终端控制知识在这个小项目里被串成了一条完整链路。