cascii.app 暂未发现付费内容

ASCII 图表（diagrams）就是用键盘上能直接打出来的字符——- | + / \ < > 以及各种方框符号——拼出方框、箭头和连线，从而在纯文本里表达流程、结构或层级关系。它适合的场景很明确：内容要放进代码注释、README、终端输出、邮件或纯文本笔记，而这些地方不方便贴图片。如果你的图表最终会出现在网页或文档里且允许插图，用绘图软件通常更省事；ASCII 图表的价值在于“任何能显示文字的地方都能显示它”。

ASCII 图表能表达什么

常见的几类：

• 流程图：方框表示步骤，箭头表示走向。
• 结构图 / 层级图：用缩进和树状连线表示父子关系。
• 时序图：用竖线表示时间轴，横向箭头表示消息传递。
• 表格与布局草图：用边框字符画出界面分区。

基本元素只有几种，掌握后就能组合出大部分图形：

手工画一个简单流程图

以“用户提交表单 → 校验 → 通过则保存，否则报错”为例，步骤是：

1. 先定骨架：确定有几个方框、怎么排列。横向排还是纵向排，先想清楚再动手。
2. 画方框：用 + 做四角，- 做上下边，| 做左右边。
3. 连箭头：从方框边缘引出 - 或 |，末端加 > < ^ v。
4. 填文字：文字放在方框内部，保持左右留白对称。
5. 对齐检查：逐行数宽度，确保竖线在同一列。

结果大致是这样：

+----------+     +----------+     +----------+
| 提交表单 | --> |  校验    | --> |  保存    |
+----------+     +----------+     +----------+
                       |
                       v
                 +----------+
                 |  报错    |
                 +----------+

验证方法：把这段文字粘到目标环境里（代码注释、终端、Markdown 代码块），看竖线是否仍然对齐。如果错位，说明某一行少了或多了空格。

手工画 vs 用工具生成

手工画灵活、零依赖，但改一处往往要重排一片。工具（例如 CASCII 这类 ASCII 图表构建器）的思路是让你在画布上摆放方框和连线，再导出成字符文本，省去逐行对齐的体力活。

选择条件可以这样看：

• 只画一次、图形很小：手工更快，不用学工具。
• 图形复杂、需要反复调整：用工具，改动时对齐由工具保证。
• 环境不允许装东西：手工，或找纯网页版的工具。
• 需要精确控制每个字符：手工，工具导出后仍可能要微调。

CASCII 是一个用原生 JavaScript 写的免费、开源 ASCII 图表构建器（来源：cascii.app 站点描述）。它属于“在浏览器里摆放元素再导出文本”这一类工具，适合不想手工数空格的人。具体功能以站点实际提供的为准。

最容易踩的坑：对齐和字符宽度

ASCII 图表翻车几乎都出在对齐上，原因通常有两个：

一是等宽字体。 ASCII 图表只有在等宽字体下才对齐。放到比例字体（很多网页正文、部分聊天窗口）里，| 会立刻歪掉。所以它最适合代码块、终端、代码编辑器这类默认等宽的环境。

二是全角字符宽度。 中文字、日文假名在等宽字体里通常占两个英文字符的宽度，而 - | 只占一个。方框里写中文时，如果按“一个字符一格”来数，边框就会错位。解决办法：

• 方框内文字尽量用英文或数字；
• 必须用中文时，按“一个汉字 = 两个半角字符”计算宽度，左右补空格凑齐；
• 或者干脆用 Unicode 制表符（─ │ ┌ ┐）配合支持它的字体，视觉上更整齐，但兼容性不如纯 ASCII。

检查清单：换到目标环境后，确认①字体是等宽、②每行总宽度一致、③中文按双宽计算、④| 没有被 Markdown 表格或某些语法吃掉。

什么时候该用它，什么时候不该

适合：代码注释里的模块关系、README 里的架构草图、终端工具的界面示意、纯文本邮件里的流程说明、需要随代码一起版本管理的图。

不适合：需要精确比例或大量数据的图（用真正的图表工具）、需要颜色和图形的展示（用图片）、读者环境是比例字体且无法控制（对齐无法保证）。

一句话判断：图要跟着纯文本走，就用 ASCII；图要好看或要精确，就别用它。

开源软件指源代码公开、允许他人查看、修改和再分发的软件。它不等于免费，也不等于没有版权——是否收费、能否商用、二次发布要满足什么条件，取决于具体的开源许可证。对普通人来说，判断一款开源软件值不值得用，关键看三点：许可证是否匹配你的用途、项目是否仍在活跃维护、以及它能否解决你的具体任务。下面按这三个维度展开。

开源软件和"免费软件"不是一回事

很多人把开源等同于免费，这是最常见的误区。开源描述的是源代码的获取与使用权利，免费描述的是价格。两者可以重合，也可以分离：

• 有的开源软件完全免费，靠社区或捐赠维护；
• 有的开源软件本身免费，但官方提供付费的技术支持、托管或企业版；
• 也有软件免费但不开源（只给可执行文件，不给源代码）。

所以看到"开源"两个字，不要直接推断"免费"或"可以随便用"。真正决定你能怎么用的，是它附带的许可证。

常见许可证决定你能做什么

许可证是开源软件的使用规则。同样是开源，不同许可证对"修改后要不要也开源""能不能闭源商用"的要求差别很大。下面是最常见的几类：

对普通用户来说，日常使用（自己装来用、不修改不分发）几乎不受许可证限制。真正需要留意许可证的是两类人：把开源代码嵌进自己产品再发布的开发者，以及想基于开源项目做二次分发的人。如果你属于这两类，务必先读项目根目录下的 LICENSE 文件，而不是凭印象判断。

开源不等于安全，也不等于好用

"源代码公开所以更安全"是一种想当然。公开确实让更多人能审查代码，但有没有人真的去审查、发现问题后有没有人及时修，才是安全的关键。判断一个开源项目是否可靠，可以看这些信号：

• 最近提交时间：仓库几个月甚至几年没更新，遇到漏洞可能没人修；
• issue 和 PR 的响应：大量长期未处理的 issue，说明维护者精力有限或已放弃；
• 发布节奏：是否有稳定的版本发布，还是长期停在某个旧版本；
• 社区规模：文档、论坛、问答是否活跃，出问题能不能找到人。

反过来，一个更新频繁、社区活跃的小众开源工具，往往比一个多年不更新的大牌项目更值得信任。

按用途挑选开源替代品

选开源软件，先明确你要完成的任务，再看有没有成熟替代品。以图像处理为例，ImageOptim 就是一类面向"压缩图片、减小文件体积"任务的开源工具，它的定位是替代"导出为 Web 格式"这类操作，而不是替代完整的图像编辑软件。这说明一个重要思路：开源替代品常常只覆盖某个具体环节，而不是一比一替换整个商业软件。

按用途大致可以这样找：

• 图像/媒体处理：先想清楚是"编辑"还是"压缩/转换"，前者找编辑器，后者找专用工具；
• 办公文档：找能读写通用格式（如 docx、xlsx）的套件，注意复杂排版可能走样；
• 开发工具：这类开源生态最成熟，编辑器、版本控制、包管理基本都有开源方案；
• 系统工具：压缩、清理、格式转换等小工具，开源选择非常多。

挑选时的通用检查清单：

1. 它能不能完成你的核心任务（先看功能，不看名气）；
2. 最近一次更新是什么时候；
3. 有没有清晰的安装说明和文档；
4. 出问题时去哪里求助（issue 区、论坛、聊天群）。

安装和使用中的常见卡点

开源软件的安装方式比商业软件更杂，遇到问题先分清是哪一类：

• 来源不明：只从项目官网或官方代码仓库下载，不要用来路不明的第三方打包版本；
• 依赖缺失：部分工具需要先装运行环境或其他组件，报错信息通常会指出缺什么；
• 权限与系统限制：某些系统会拦截未签名应用，需要手动允许，操作前确认来源可信；
• 版本混乱：同一工具有稳定版和开发版，日常使用优先选稳定版。

遇到问题时的求助顺序

1. 先查官方文档：多数基础问题文档里就有答案；
2. 搜 issue 区：你的问题很可能别人已经提过，看有没有解决方案或临时绕过办法；
3. 看社区论坛/聊天群：适合文档没覆盖的使用经验类问题；
4. 自己提 issue：写清版本、系统、复现步骤和报错信息，越具体越容易被回应。

提 issue 时不要只写"用不了"，而要写"在什么系统、什么版本、执行了什么操作、期望什么结果、实际报了什么错"。这几乎决定了你能不能得到有效帮助。

一句话决策

日常自己用、不修改不分发，选开源软件主要看功能是否够用 + 项目是否还在维护；要把代码嵌进自己的产品再发布，才需要认真读许可证。开源是权利和协作方式，不是质量或免费的保证——把它当成一个需要核实的选项，而不是一个可以放心的标签。

用 ASCII 字符“画图”指的是：在纯文本环境里，用 + - | / \ 这类 ASCII 符号，以及 Unicode 的制表符、箭头、块元素，拼出方框、连线、表格、流程图等图形。它不产生像素或矢量图像，产物是一段可以复制进代码注释、终端、聊天窗口的文本。适合需要“图跟着文字走”的场景；如果你要的是可缩放、带颜色的正式插图，应该用图形软件而不是字符画。

它和普通绘画、图形软件的区别

关键机制是“网格对齐”：字符画把画面切成一个个等宽的字符格子，每个格子放一个符号，靠行列位置表达形状。所以它成立的前提是显示环境使用等宽字体，且所有字符占同样的宽度。

能画哪些图

• 方框与边框：用 + 做角、- 做横线、| 做竖线，围出矩形或分区。
• 箭头与连线：用 ->、<--、--> 表示方向，用 |、/、\ 走折线。
• 表格：行列用 + 和 - 分隔，内容填在格子里。
• 树状图：用 |、+--、\-- 表达层级，常见于目录结构。
• 流程图：方框加箭头，串起判断和步骤。
• 时序图：竖线代表参与者，横向箭头代表消息，按时间从上往下排。

常用字符集

ASCII 基础符号（兼容性最好，任何环境都能显示）：

+  -  |  /  \  <  >  ^  v  *  =

Unicode 制表符与箭头（更整齐、更省字符，但需要字体支持）：

┌ ┐ └ ┘ ├ ┤ ┬ ┴ ┼ ─ │
→ ← ↑ ↓ ▶ ◀ ▲ ▼
█ ▓ ▒ ░  （块元素，可做填充或进度条）

选择原则：如果目标环境可能不支持 Unicode（老终端、某些代码页），优先用 ASCII；如果确定字体支持，Unicode 制表符能让边框连续、少用角字符，观感更好。

基本画法

1. 先定网格：在纸上或编辑器里想好每行放什么、每列多宽，确定整体尺寸。
2. 画外框：先搭最外层矩形，确定边界。
3. 填内容与连线：在框内写文字，用箭头和折线连接各块。
4. 检查对齐：在等宽字体下逐行核对竖线是否在同一列、横线是否连续。
5. 验证：把结果粘贴到最终使用环境（终端、代码注释、聊天）里再看一遍，确认没有变形。

手工对齐在图形复杂时很费时，可以用 CASCII 这类 ASCII 图表构建器来降低对齐成本——它是在浏览器里运行的 ASCII 图表工具，用纯 JavaScript 写成，属于免费、开源项目。用它可以在可视化界面里摆放方框和连线，由工具处理字符位置，减少手工数格子的错误。

常见失败与卡点

• 字体非等宽：比例字体会让竖线错位、方框歪斜。解决方法是确认使用等宽字体。
• 中英文混排宽度不一致：一个汉字通常占两个英文字符宽，混排时列会对不齐。要么统一用英文，要么按“汉字算两格”预留宽度。
• 复制后变形：粘贴到聊天、网页或不同编辑器时，换行、字体或空白处理可能改变布局。解决方法是粘贴后重新检查，必要时改用 ASCII 基础符号提高兼容性。
• Unicode 符号显示为方块：目标环境字体不含该字符。回退到 ASCII 符号即可。
• 制表符与空格混用：Tab 的宽度因环境而异，容易破坏对齐，建议统一用空格。

Unicode 是一套字符编号标准：它给世界上每个字符分配一个唯一编号（码点），但不规定这些编号在文件或网络里怎么变成字节。ASCII 是它之前的英文专用字符集，只有 128 个字符；UTF-8、UTF-16 则是把 Unicode 码点实际存成字节的编码方式。遇到乱码时，问题几乎总是出在“编码方式”这一层，而不是 Unicode 本身。

三个概念，各管一件事

关键区别在于：字符集回答“这个字符的编号是多少”，编码方式回答“这个编号写成几个字节、什么顺序”。 两者是分开的，所以同一段 Unicode 文本可以用 UTF-8 存，也可以用 UTF-16 存。

ASCII 为什么不够用

ASCII 诞生于英文环境，用 7 位表示 128 个字符，刚好够英文字母、数字和常用符号。它的问题很直接：

• 没有中文、日文、韩文、阿拉伯文、俄文等任何非拉丁字符；
• 没有 emoji 和大量数学、货币符号；
• 各国后来各自扩展出本地编码（如 GBK、Shift-JIS、Latin-1），互不兼容。

结果是同一串字节，用不同本地编码解读会得到完全不同的文字——这就是早期中文网页“乱码”的根源。Unicode 的目标就是用一个统一编号表取代这些互不兼容的本地字符集。

为什么同一段文字会乱码

乱码不是字符坏了，而是写入时用的编码和读取时用的编码不一致。

例如“中”这个字：

• 在 UTF-8 里是 3 个字节：E4 B8 AD
• 在 GBK 里是 2 个字节：D6 D0

如果文件实际是 UTF-8，但打开时按 GBK 解读，就会显示成“涓”之类的怪字。反过来也一样。UTF-16 与 UTF-8 之间误读，还会出现大量夹杂空字节或问号的情况。

判断和处理的顺序通常是：

1. 先确认来源：网页看 HTTP 响应头或 <meta charset>；文件看编辑器状态栏或保存选项。
2. 用工具验证：多数编辑器（VS Code、Notepad++、Sublime）能显示当前编码，并支持“以某编码重新打开”。
3. 再转换：确认正确编码后，另存为目标编码。命令行可用 iconv -f UTF-8 -t GBK input.txt > output.txt。
4. 验证结果：重新打开，确认中文、emoji、特殊符号都正常，没有问号或方块。

常见卡点：

• 只改文件内容里的编码声明，没改实际字节，等于没改；
• 数据库连接、表、字段三层编码不一致，只改一层仍会乱；
• 终端本身编码不对，文件正确也会显示乱码。

日常怎么选

• 网页和新建文件优先用 UTF-8：它兼容 ASCII，英文不浪费空间，又能覆盖全部 Unicode，是当前事实标准。
• 遇到乱码先查编码声明，不要急着重打内容；多数情况重新按正确编码打开即可恢复。
• 只在必须对接旧系统时用 GBK 等本地编码，并明确记录，避免后续再次误读。
• ASCII 仍有用：纯英文场景、日志、协议头里它简单可靠；但一旦涉及多语言，就该交给 Unicode + UTF-8。

一句话记住：Unicode 是“字符名单”，UTF-8 是“把名单写成字节的规则”，ASCII 是这份名单出现之前的英文小册子。 乱码出在规则不匹配，不在名单本身。

ASCII 是一套把 128 个字符（编号 0–127）映射为数字的编码标准，1963 年由美国标准协会制定，目的是让不同设备对同一串二进制数据给出一致的字符解释。今天你几乎不会直接“使用 ASCII”去存中文或表情，但只要涉及终端输出、配置文件、日志、代码，ASCII 仍然是最底层、最不容易出错的那一层。理解它的关键不是背下 128 个编号，而是分清三件事：哪些是可见字符、哪些是控制字符、以及 ASCII 和 Unicode/UTF-8 是什么关系。

ASCII 到底规定了什么

ASCII 全称 American Standard Code for Information Interchange（美国信息交换标准代码）。它把 0 到 127 这 128 个整数各对应一个字符，例如：

注意 0 这个字符和数字 0 不是一回事：字符 0 的编号是 48。ASCII 里每个字符占 1 字节（8 位），但只用了低 7 位，最高位恒为 0。这也是为什么 ASCII 能安全地塞进各种协议里——它不依赖字节序，也不会因为高位被截断而变形。

可见字符与控制字符

128 个位置里，0–31 和 127 是控制字符，它们不显示成图形，而是指挥设备做动作：

• LF（10）换行、CR（13）回车：Windows 文本常用 CR LF 两个字符表示一次换行，Unix/Linux 只用 LF。这就是为什么跨系统传文本偶尔会看到多余的空行或整段挤在一行。
• TAB（9）：制表，宽度由接收方决定，所以同一份文本在不同编辑器里对齐效果可能不同。
• BEL（7）：响铃，早期终端会发出提示音，现在多被忽略。
• ESC（27）：转义，终端用它开始一段控制序列，比如设置颜色。

32–126 是可打印字符：空格、标点、数字、大小写字母。127 是 DEL（删除），也属于控制字符。

ASCII、Unicode、UTF-8 是什么关系

一句话：ASCII 是 Unicode 的一个子集，UTF-8 是 Unicode 的一种编码方式，而 UTF-8 对 ASCII 完全兼容。

• Unicode 是字符集，给世界上每个字符分配一个编号（码点），比如 A 是 U+0041，汉字“中”是 U+4E2D。
• UTF-8 是把码点变成字节的规则。U+0000 到 U+007F 的字符，UTF-8 用一个字节表示，且字节值和 ASCII 编号完全相同。
• 因此，一段纯 ASCII 文本，按 ASCII 读、按 UTF-8 读，结果一模一样。这是 ASCII 能存活至今的核心原因：它不需要被替换，只需要被兼容。

反过来不成立。汉字、日文、emoji 在 UTF-8 里占 2–4 字节，按 ASCII 解读就会变成乱码。ASCII 只有 128 个位置，装不下这些字符。

为什么纯文本里还在用它

ASCII 的价值不在“字符多”，而在“约定最少”：

• 终端和命令行：几乎所有 shell、日志、CLI 工具默认输出 ASCII 可打印字符，颜色和光标移动靠 ESC 控制序列实现。
• 配置文件：.ini、.env、.gitconfig 这类文件用 ASCII 写键值对，任何编辑器、任何系统都能读。
• 日志与协议：HTTP 头、SMTP 命令、CSV 表头等长期限定在 ASCII 范围内，避免编码协商带来的歧义。
• 纯文本图表：用 + - | 画框、用 -> 画箭头，不依赖字体和渲染引擎，复制到哪都保持形状。

遇到乱码怎么判断

乱码通常不是 ASCII 本身出错，而是“写入时用的编码”和“读取时假设的编码”不一致。可以按这个顺序排查：

1. 看乱码形态。é、’ 这类“多出一个字符”的乱码，常见于把 UTF-8 字节按 Latin-1 解读。
2. 看内容范围。如果原文只含英文、数字和常见标点，那它本来就是 ASCII，乱码多半来自换行符（CR LF vs LF）或终端控制序列没被识别。
3. 用工具确认。file -i 文件名 能看系统猜测的编码；hexdump -C 文件名 | head 能看前几个字节，ASCII 文本的字节都在 0x20–0x7E 或 0x09/0x0A/0x0D 范围内。
4. 统一编码。把读写两端都固定为 UTF-8，是当前最省事的做法，因为它向下兼容 ASCII。

想画 ASCII 图表可以用什么

如果目的是手工拼出对齐的框线图，纯文本编辑器就够，但手动数空格很容易错位。这时可以用专门的工具，例如 CASCII（cascii.app）——一个用原生 JavaScript 写的开源 ASCII 图表构建器，支持 ASCII 和 Unicode 字符。它的定位是帮你在浏览器里摆放字符、对齐边框，而不是替你决定图表内容。

选择时看两点：一是输出是否只含 ASCII 可打印字符（要贴进终端或代码注释就选这种）；二是是否需要 Unicode 制表符（┌ ─ ┐ 这类看起来更整齐，但部分老终端可能显示为方块）。两者没有绝对优劣，取决于接收环境。

常见问题

ASCII 能表示中文吗？ 不能。ASCII 只有 128 个位置，没有汉字。中文需要 GBK、UTF-8 等更大的编码。

ASCII 和 ANSI 是一回事吗？ 不是。Windows 语境里的“ANSI 编码”通常指本地代码页（如 GBK、Windows-1252），是 ASCII 的扩展，不是 ASCII 本身。

为什么我的文件明明是英文却提示编码错误？ 可能混入了不可见的控制字符，或从网页复制时带进了非 ASCII 的引号、破折号（如 “ ” —）。把它们替换成 " ' - 即可。

UTF-8 会取代 ASCII 吗？ 在存储和传输层面，UTF-8 已经是主流，且完全兼容 ASCII。但 ASCII 作为“最小公共字符集”的约定仍然有效，很多协议和格式至今只保证 ASCII 范围内的行为一致。