我正在做一个项目，其中包括制作一些 ASCII 艺术，但它不是真正的 ASCII 艺术，因为我使用了大量 Windows Alt 代码来制作它。无论如何，我想确保在我制作它时，它看起来与在 Windows 命令提示符终端会话中完全一样。因此，由于命令提示符默认为终端光栅字体，我想我会使用它。但我很快注意到，当我在文本编辑器中使用终端字体时，它不会呈现 ASCII 代码，要么根本无法呈现（大多数情况下都是这样），要么无法正确呈现。现在，我明白字体是否不支持非 ASCII 字符，但我不明白的是，字符在文本编辑器中无法正确显示，为什么它们在命令提示符中却可以正确显示。我检查了“chcp”的输出，它默认设置为 437，这正是我需要的。好吧，要么是 850，要么是 437，但最好是 437，因为他们删除了 437 中的一些图形并用其他拉丁字符替换它们。命令提示符终端设置显示我正在使用 8x12 字形大小的终端光栅字体。因此，我尝试在文本编辑器中使用 12 号字体，但效果不佳，即使将文本编码切换为 MS-DOS OEM-US（据说是 CP437 的替代名称）或 UTF-8 也是如此。我只是不明白为什么字符无法显示出来。
另外，如果有帮助的话，我制作的艺术作品基本上是我玩的一款名为 Dwarf Fortress 的游戏的修改后的屏幕截图，该游戏使用 Terminal/Curses 排版中的字符，或者至少这是那些制作图形集来替换默认字符集的人在论坛上报告的。但是，游戏实际上并没有使用系统的终端字体。游戏的数据文件包含一个位图图像，它是游戏使用的所有字符的网格。因此它使用此位图来渲染图形，而不是实际的字体文件：
我基本上想找一个文本编辑器，这样当我输入一些 ASCII 艺术看起来像《矮人要塞》的截图时，除了缺少颜色之外，它实际上看起来就像《矮人要塞》。有什么帮助吗？
答案1
可能的解决方案
如果您不需要代码页 437 字符 0 到 31，请尝试使用带有终端字体的记事本，并使用 Alt+032 到 Alt+0255（带前导零）。
如果要使用代码页 437 字符 0 到 31，请尝试打开这个文件在记事本中使用终端字体，然后复制并粘贴所需的字符。记事本会将字符 9 解释为制表符，将字符序列 13 10 和 13 13 10 解释为回车符。其他字符 0 到 31 以及字符 13 和 10 本身将显示终端字体中的符号。
如果您愿意放弃终端字体的像素外观，您可以使用带有 Lucida Console 字体的记事本，并使用 Alt+1 到 Alt+255 插入代码页 437 符号的 Unicode 等效项。保存文本文件时，请务必选择 Unicode 编码，例如 UTF-8。
更多信息
在 Windows 中，Alt+1 到 Alt+255 与 Alt+01 到 Alt+0255（带前导零）之间存在差异。
- 当您按 Alt+1 到 Alt+255 时，Windows 将尝试插入与代码页 437 符号 1 到 255 相同的符号的字符。
- 当您按下 Alt+032 到 Alt+0255 时，Windows 将插入正在使用的字体中的符号编号 32 到 255。
- 当您按下 Alt+01 至 Alt+031 时，大多数程序不会执行任何操作，但有些程序可能会将其中一些 Alt 代码解释为控制代码。例如，在记事本中，Alt+08 表示退格，Alt+09 表示制表，Alt+013 表示回车。
终端字体的作用类似于符号字体：它不与特定字符集相关联，也不映射到 Unicode 字符。因此，Alt 代码在终端字体中产生的视觉效果与其他字体不同。
代码页 437是一组屏幕符号，包含字符 0 到 31 的有效符号。文本文件和文本编辑器将使用 0 到 31 之间的部分或全部字符作为控制代码，这使得将这些屏幕符号存储在文本文件中变得困难。
编码用于打开或保存文件。编码决定了如何在文件中存储的字节和编辑器窗口中存储的 Unicode 字符之间进行转换。编码可能不会影响 Alt 代码的行为。