Kitty graphics 与 Sixel 有何不同 —— 怎么选？

三大差异：(1) 编码 —— kitty 用 base64 包装原始 RGBA / PNG 字节，置于类 DCS 的 APC 包络（\x1b_G … \x1b\\）；Sixel 用 base-6 打包位图编码，对低色数图更小、对照片膨胀更严重；(2) 分块传输 —— kitty 用 m=1 续传标记把大图拆进多个 APC 包；Sixel 整图单包络发出，于是 kitty 能干净处理 50 MB 照片，Sixel 则把输入循环噎住；(3) 持久化与定位 —— kitty 按 id 引用已上传图像，可在 z 序 / 鼠标格坐标定位；Sixel 只在当前光标处一次性绘出。要尺寸与交互选 kitty；要可移植性选 Sixel（xterm、foot、mlterm 开箱即用；kitty graphics 需要 kitty / Ghostty / WezTerm）。

发图像前如何检测终端是否支持 kitty graphics？

用 kitty graphics 协议发一张 1×1 透明 PNG，置 q=1（仅查询，不显示），并附唯一 id（i= ）：\x1b_Gi=42,q=1,f=100; \x1b\\。支持的终端在约 100 ms 内回 \x1b_Gi=42;OK\x1b\\；不支持的终端沉默（请设 200 ms 读超时）。id 用于避免应答与无关图形回复抢答。也可用 XTVERSION \x1b[>q 拿终端名 + 版本，按白名单（kitty、Ghostty、WezTerm、konsole 24.04+）放行。

Kitty 图形协议 —— 内联像素图像（ESC _ G … ESC \）

Sixel 的现代替代：通过 Kitty APC 帧把 PNG / RGBA 字节流式发送给终端，配合合理的分块与放置协议。

字节形式

涵盖所有常见的字符串字面量写法，方便正反查找。

\\x1b[\x1b_Ga=T,f=100,m=1;BASE64_CHUNK\x1b\\

\\033[\033_Ga=...;PAYLOAD\033\\

\\e[\e_G a=...;PAYLOAD \e\\

ESC [ESC _ G key=value,... ; BASE64 ESC \

hex1b 5f 47 ... 1b 5c

说明

Kitty 图形协议 —— kitty.sh 设计的 Sixel/iTerm-img 现代替代 —— 使用 APC（Application Program Command）帧：引导符 \x1b_（ESC _），字面 G 标识图形命令，逗号分隔的 key=value 控制头（a=T 传输并显示、f=100 PNG、f=24 RGB、f=32 RGBA、s v 像素宽高、m=1 还有后续分块/m=0 最后一块、i=ID 图像 ID 便于重新放置），;，然后每块最多 4096 字节的 base64 载荷，以 ST（\x1b\\）结尾。kitty + ghostty + wezterm 原生支持；konsole 部分支持。iTerm2 自家 \x1b]1337;File=... 协议是另一选项；两者正逐步向 Kitty 的设计靠拢。Sixel（DCS Pq）是两者均不支持时的传统回退。

规范出处: Kitty Graphics Protocol (sw.kovidgoyal.net/kitty/graphics-protocol/)

示例

bash

# Display a PNG file inline (one-shot, no chunking):\nb64=$(base64 -w0 cat.png)\nprintf '\033_Ga=T,f=100;%s\033\\' "$b64"

python

import base64, sys\npng = open('cat.png','rb').read()\nsys.stdout.write('\x1b_Ga=T,f=100;' + base64.b64encode(png).decode() + '\x1b\\')

data, _ := os.ReadFile("cat.png")\nfmt.Printf("\x1b_Ga=T,f=100;%s\x1b\\\\", base64.StdEncoding.EncodeToString(data))

javascript

import fs from 'node:fs';\nconst b64 = fs.readFileSync('cat.png').toString('base64');\nprocess.stdout.write('\x1b_Ga=T,f=100;' + b64 + '\x1b\\')

/* read PNG into buf, base64-encode, then: */\nprintf("\x1b_Ga=T,f=100;%s\x1b\\\\", b64);

在哪里用到

实际会发出该序列的工具——把抽象字节锚定到你已经用过的命令上。

kitty `icat` (kitten icat)随 kitty 发行版提供为 `kitten icat <file>` —— 催生 kitty-graphics 协议需求的标志命令。读取 PNG / JPEG / GIF / WebP，发出分块 `\x1bGa=T,f=100…\x1b\\` DCS 流，在终端当前光标位置内联渲染
mpv terminal output (`--vo=kitty`)mpv 0.37+ 自带 `kitty` 视频输出驱动 —— `mpv --vo=kitty video.mp4` 把视频作为一系列 kitty-graphics 帧在终端播放。帧率受终端 blit 速度限制（kitty / WezTerm / Ghostty 上约 15-30 fps）；用于无头预览和 SSH 上的播放
fastfetch / neofetch image rendering积极维护的 fastfetch（及其前身 neofetch）在 `--kitty` 或自动检测到 kitty / WezTerm / Ghostty 时，用 kitty-graphics 渲染系统徽标块 —— 取代早期的 Unicode 块回退，在支持的终端上获得明显更高保真的渲染效果
presenterm terminal slide deckspresenterm 用 kitty-graphics 在终端幻灯片中内联渲染 markdown 图片引用 —— 翻页时发 `a=d`（全部删除）帧清理残留，避免相邻幻灯片图像重叠
yazi file manager preview paneyazi（Rust TUI 文件管理器）检测 kitty / WezTerm / Ghostty 等支持 kitty-graphics 的终端，在右侧窗格通过 kitty-graphics 渲染图像预览 —— 启动时根据 terminfo 能力探测回退到 sixel 或 Unicode 块

常见问题

针对这条序列，开发者真正会去搜索的问题的简短回答。

Kitty graphics 与 Sixel 有何不同 —— 怎么选？: 三大差异：(1) 编码 —— kitty 用 base64 包装原始 RGBA / PNG 字节，置于类 DCS 的 APC 包络（\x1b_G … \x1b\\）；Sixel 用 base-6 打包位图编码，对低色数图更小、对照片膨胀更严重；(2) 分块传输 —— kitty 用 m=1 续传标记把大图拆进多个 APC 包；Sixel 整图单包络发出，于是 kitty 能干净处理 50 MB 照片，Sixel 则把输入循环噎住；(3) 持久化与定位 —— kitty 按 id 引用已上传图像，可在 z 序 / 鼠标格坐标定位；Sixel 只在当前光标处一次性绘出。要尺寸与交互选 kitty；要可移植性选 Sixel（xterm、foot、mlterm 开箱即用；kitty graphics 需要 kitty / Ghostty / WezTerm）。
发图像前如何检测终端是否支持 kitty graphics？: 用 kitty graphics 协议发一张 1×1 透明 PNG，置 q=1（仅查询，不显示），并附唯一 id（i=<rand>）：\x1b_Gi=42,q=1,f=100;<base64-1px-png>\x1b\\。支持的终端在约 100 ms 内回 \x1b_Gi=42;OK\x1b\\；不支持的终端沉默（请设 200 ms 读超时）。id 用于避免应答与无关图形回复抢答。也可用 XTVERSION \x1b[>q 拿终端名 + 版本，按白名单（kitty、Ghostty、WezTerm、konsole 24.04+）放行。

常见错写 / 易混形

开发者常从 Stack Overflow 粘贴的错误写法 —— 看起来对其实不对，附上规范的正确写法。

\x1b_Ga=T,f=100,t=d;<raw-png-bytes>\x1b\\ (raw binary in the DCS payload)\x1b_Ga=T,f=100,t=d;<base64-of-png-bytes>\x1b\\ (always base64-encode the payload)
kitty 图形协议的负载必须 base64 编码 —— DCS / APC 帧是纯 ASCII，PNG 内首个 \x1b 或 ST 序列会让原始二进制字节冲出帧外。t=d 参数表示「内联传输数据」；与 f=100（PNG）组合时，; 后的数据是 base64 编码的 PNG 字节（不是原始）。发原始会立即破坏 kitty 解析器，图像不渲染（终端在该行剩余时间内也会混乱 —— 之后可见提示符损坏）。可移植的 Python 发送：base64.b64encode(open('img.png','rb').read()).decode()。
transmit a 200KB image as one huge APC: \x1b_Ga=T,...,t=d;<200KB-base64>\x1b\\chunk it: \x1b_Ga=T,...,t=d,m=1;<chunk-1>\x1b\\\x1b_Gm=1;<chunk-2>\x1b\\...\x1b_Gm=0;<last-chunk>\x1b\\ (final chunk has m=0)
kitty 规范建议大于 4096 base64 字节的负载分块，以防终端的读缓冲 / 解析栈溢出。除最后一块外每块用 m=1（最后块用 m=0 或省略 m）表示「还有后续块」。忘了最后 m=0 让 kitty 永远等下一块 —— 图像永不渲染，之后发的序列被追加到半成图缓冲。反向错误 —— 每块都 m=0 —— 让 kitty 把每块当成独立完整图像渲染，得到 N 个残 PNG（或 N 个错误图块）而非一张图。
\x1b_GA=T,F=100,T=d;<payload>\x1b\\ (uppercase parameter names)\x1b_Ga=T,f=100,t=d;<payload>\x1b\\ (parameter names are LOWERCASE, values can be either case)
kitty 图形协议的参数名严格小写：a（action）、f（format）、t（传输介质）、m（更多块）、i（图像 id）、q（静默模式）等。值是 T（传输并显示）、t（仅传输）、d（直接）、f（文件）、t（临时文件）等记号 —— 值也区分大小写。发 A=T,F=100 会被拒为「未知参数 A」，图像无法渲染。常见混淆：规范把 action 值写成大写（T、t、d、q、a），让人以为参数名也该匹配 —— 并不。生成这些字符串的工具应模板化 {action,format,transmission}=... 而非 {ACTION,FORMAT,TRANSMISSION}=...。

终端支持

xterm: 不支持
Linux console (fbcon): 不支持
macOS Terminal.app: 不支持
iTerm2: 部分
Windows Terminal: 不支持
cmd.exe / ConPTY: 不支持
kitty: 支持
alacritty: 不支持
WezTerm: 支持
Ghostty: 支持
GNOME Terminal: 不支持
Konsole: 部分
tmux: 不支持
GNU screen: 不支持

xterm	Linux console (fbcon)	macOS Terminal.app	iTerm2	Windows Terminal	cmd.exe / ConPTY	kitty	alacritty	WezTerm	Ghostty	GNOME Terminal	Konsole	tmux	GNU screen
不支持	不支持	不支持	部分	不支持	不支持	支持	不支持	支持	支持	不支持	部分	不支持	不支持

在家族食谱中

DCS 食谱 · 2. 流内画图 —— Sixel 与 Kitty 图形

字节形式

说明

示例

在哪里用到

常见问题

终端支持

相关序列

在家族食谱中