使用现代 PC 的人或多或少都会有这样的疑问：为什么 Windows 使用反斜杠作为路径分隔符，而世界上其他地方都使用正斜杠？明确的中间答案是 “因为 DOS 和 OS/2 使用反斜杠”。Windows 9x 和 NT 都直接或间接地源于 DOS 和 OS/2，当然也继承了 DOS 的大部分文化。
当然，这并不能说明什么。显然，下一个问题是，为什么 DOS 使用反斜杠作为路径分隔符？当 DOS 2.0 增加了对分层目录结构的支持时，它受到了 UNIX（或许更确切地说是 XENIX）的影响，使用斜杠作为路径分隔符是合乎逻辑的选择。这是大家都同意的。除此之外，事情就变得有点混乱了。
唯一清楚的是，微软和 IBM 负责在 DOS 2.0 中使用反斜杠作为路径分隔符。据报道，微软希望使用正斜杠作为路径分隔符，但 IBM 拒绝了这一想法，因为这会造成与 DOS 1.x 的不兼容，后者已经使用正斜杠作为切换字符来分隔命令选项。
微软的老前辈们都认为，IBM 坚决反对将斜杠作为切换字符。至于斜杠的特殊用法从何而来，他们就不太清楚了。
有一些愚蠢的理论，比如 “斜杠来自 CP/M”。其实不然。除了产品名称，没有任何证据表明 CP/M 在其他地方使用了斜杠。大多数 CP/M 命令根本没有选项。第三方 CP/M 工具（如 Micrsoft 的工具）很可能使用了斜杠，但操作系统本身没有使用。
像 “CP/M 从 VMS 中得到斜杠 “这样的无稽之谈显然是不可能的，因为 CP/M 比 VMS 早，而且 CP/M 无论如何也没有使用正斜杠。
SCP 的 86-DOS 同样没有使用正斜杠。也就是说，DOS 并没有从它的直接或间接前辈（86-DOS 和 CP/M）那里继承正斜杠。它肯定是从别的地方来的。我们能找出它的出处吗？
事实上，即使是 PC DOS 1.0（1981 年）也很少使用斜杠。FORMAT 命令有一个 /S 选项，用于复制系统文件；LINK 命令有一个 /P 选项，用于在写入可执行文件前暂停，以便交换软盘。仅此而已。
值得注意的是，LINK 和 FORMAT 都是由微软编写的。重要的一点是，PC DOS 1.0 在发布时确实使用了正斜杠作为选项分隔符。
PC DOS 1.1（1982 年）大幅增加了正斜杠的使用。COPY 增加了 /A、/B 和 /V 开关，DIR 增加了 /P 和 /W 开关，而 DISCKOMP、DISKCOPY 和 FORMAT 则增加了 /1 开关（用于单面软盘操作）。链接器也有了新的选项，如 /DSALLOCATION、/HIGH、/LINE、/MAP、/PAUSE 和 /STACK。
毫无疑问，IBM 坚持在 DOS 2.0 中保留这种斜杠用法的原因就在于此。改变斜杠语义显然有可能破坏数据，尤其是在运行为 DOS 1.1 编写的批处理文件时。像 “COPY FOO + BAR /A “这样，当 /A 是一个开关与 /A 是磁盘根目录中的一个文件或目录时，其语义是完全不同的。
现在回过头来看，为了保持与昙花一现的早期 PC 操作系统的向后兼容性而改变路径分隔符似乎很愚蠢，但事后诸葛亮，1982 年，UNIX 和 DOS（及其派生系统）的未来受欢迎程度是显而易见的。
无论如何，很明显，DOS 从 1.0 版开始就使用了斜杠，尽管它的前身 CP/M 和 86-DOS 并没有这样做。那么，它是从哪里来的呢？微软旧语言产品的手册提供了一个很好的提示。微软的 8080 工具（F80 FORTRAN 编译器、M80 宏汇编器、LINK 8080 链接器）都使用斜杠作为分隔命令行选项的开关字符，而且至少早在 1977 年就使用了。换句话说，在 8086 出现之前，微软就使用斜杠作为开关字符，并在基于 8086 的工具中继续使用。
斜杠用法是微软发明的吗？当然不是。微软编译器的老作者 Hans Spiller 在 Larry Osterman 的博客上提供了一个很好的提示。即使是这个提示看起来也是错误的，因为它声称的历史是 DEC TOPS-10 到 CP/M 再到 DOS，尽管 CP/M 本身并没有使用斜杠。但 TOPS-10 确实使用了斜杠。还有更多
加里-基尔达尔（Gary Kildall）在他的 Computer Connections 回忆录中声称（第 26 页），比尔-盖茨和保罗-艾伦使用的 DEC PDP-10 分时系统，几乎可以肯定运行的是 TOPS-10，他们窃取了其他用户的密码（因为操作系统会循环使用其他用户使用过的内存页，而不对其进行擦除，从而留下包括明文密码在内的信息）。
微软自己的《MS-DOS 百科全书》（1988 年）中提到，微软的一名早期雇员马克-麦克唐纳开发了一种名为 M-DOS 的 8 位多任务操作系统，它 “以 DEC TOPS-10 操作系统为模型”。此外，该书还明确指出，”MS-DOS 的 1.x 版本借鉴了 DEC 操作系统的传统，已经在命令行中使用正斜杠作为开关”。
在这里，我们有微软自己的说法，即正斜杠不是来自 CP/M，也不是来自 IBM，而是来自 DEC，而且还明确提到了 TOPS-10。我们能找到佐证吗？
是 TOPS-10！
DEC TOPS-10 可以追溯到 20 世纪 60 年代末，它的历史肯定足以让 CP/M 和 DOS 受到它的影响。另一方面，UNIX 的历史并不悠久，对 CP/M 的影响也不大，因为两者差不多是在 20 世纪 70 年代初同时开发的。虽然 UNIX 对 DOS 2.0 有很大影响，但几乎没有证据表明它对 DOS 1.x 有任何影响（CP/M 显然对它有很大影响）。
DEC PDP-10 大型机出现于 1966 年，自 1970 年起以 DECsystem-10 命名，运行 TOPS-10 操作系统。装有 TOPS-10 的 PDP-10 可能是第一个被广泛使用的分时系统，在 20 世纪 70 年代被许多大学使用。因此，包括盖茨和艾伦在内的许多早期微软人都熟悉 TOPS-10。
现在，我们很容易找到 TOPS-10 的使用手册，浏览一下就会有很大的启发。下面是一个简短的例子（第 2-220 页）：
.DIR PROG PROG FOR 1 <055> 10-SEP-79 DSKC: [27,5434] PROG REL 1 <055> 10-SEP-79 PROG EXE 68 <055> 10-SEP-79 TOTAL OF 131 BLOCKS IN 5 FILES ON DSKC: [27,5434]
DIR 命令列出目录内容。文件名有固定长度和三个字符的扩展名。可执行文件的扩展名为 .EXE。磁盘名称末尾有一个冒号。这看起来很像 DOS，而不像 UNIX。
请注意，方括号中的奇数是 TOPS-10 指定目录的方式。好在 DOS 没有采用这种方式。还要注意的是，DOS 复制了 “DIR PROG “等同于 “DIR PROG.*”的非显而易见的行为，并且会列出任何扩展名的文件。这不太可能是巧合。
TOPS-10 标准文件扩展名列表（手册附录 D）带来了许多 DOS 记忆。用于可执行文件的 .EXE 扩展名只是第一个；还有用于对象文件的 .OBJ、用于符号文件的 .SYM、用于交叉引用文件的 .CRF、用于系统文件的 .SYS、用于 BASIC 源文件的 .BAS 或用于 ASCII 文本文件的 .TXT。同样，这些文件扩展名与 DOS 非常相似，与 UNIX 完全不同。
TOPS-10 宏汇编器还使用了 MASM 中的 IRP 宏结构，但其他汇编器并没有使用这种宏结构（特别是英特尔的 ASM86 的宏语法与之截然不同）。微软极有可能从 DEC 的汇编程序中获得了 MASM 的灵感。
结案了吗？
也许只有微软的老前辈们才能回答这些问题，但有一点要特别注意，那就是人的记忆在 40 年后往往就不那么可靠了。不过，有历史证据表明微软使用了 TOPS-10，有非常有力的间接证据表明 DOS 的几个方面受到了 TOPS-10 的影响（包括使用正斜杠作为选项分隔符），而且 MS-DOS 百科全书中有明确的说明，正斜杠的用法来自 DEC 操作系统，其中提到了 TOPS-10。
可以说，今天的 Windows 使用反斜杠作为路径分隔符，是因为 50 年前的 TOPS-10 使用了正斜杠作为选项分隔符。
更新：发布这篇文章后，我意识到虽然文章很好地解释了为什么 DOS 不使用正斜杠作为路径分隔符，但对于为什么使用反斜杠却含糊其辞。答案就是 IBM F 型键盘。正斜杠和反斜杠在视觉上的相似性可能起到了一定的作用，但决定性因素还是人体工程学。
路径分隔符必须是一个不需要 Shift 键输入的按键，而且还没有固定的用法（如点、逗号或分号键，其中许多已被微软语言工具使用）。反斜点 (`) 可能是唯一可用的其他按键，但反斜杠更有意义。
由于没有考虑到非美国键盘的人体工学，因此在某些国家的键盘上（如德语）输入路径分隔符非常困难，这也许是一种反常的提醒：人体工学确实很重要。
本文文字及图片出自 Why Does Windows Really Use Backslash as Path Separator?
除了 MS 之外，其他一些 CP/M 程序也采用了相同的概念*，DRI 在 CP/M 3（又称 Plus）中将斜线编成了代码，不过他们也提供了 $ 作为命令行分隔符。因此，对于 IBM 希望能迅速移植到 PC-DOS 的程序来说，斜线几乎就是一种标准。
*约翰-埃利奥特（John Elliott）有一页介绍了将斜线引入非MS CP/M程序的历史。
我记得，Unix 最终使用的符号是基于 AT&T 在 70 年代早期购买的非同寻常的终端。这些终端缺乏传统键盘的全部按键，因此早期的绑定只是针对现有的按键，后来购买了更多按键的键盘，才增加了额外的绑定。复制 Unix 似乎一直不是个好主意，因为 Unix 总是在绕过电话公司的错误。
反斜杠可能是路径的最佳选择，因为它是 IBM PC 上仅存的几个不需要按住 shift 键的按键之一。至少有一种 DEC 操作系统使用 “砰”（！）作为路径分隔符，这很不方便，如果文件名经常使用区分大小写的默认设置，情况会更糟。
是的。还有一个小插曲–CP/M Plus 于 1983 年推出，与 DOS 2.0 差不多同时。
“然而，有历史证据表明微软使用过 TOPS-10，有非常有力的间接证据表明 DOS 的某些方面受到了 TOPS-10 的影响（包括使用斜线作为路径分隔符）”
……仅供参考，我认为你的意思是”……使用斜线作为选项分隔符”。
(在你链接到的 TOPS-10 手册扫描件的第 1-10 页和第 1-11 页中，似乎讨论了命令开关/选项。另外，不知何故，手册链接的 A 标记只包含了 “TOPS-10 manua”，而把 “manual “的最后一个 “l “给漏掉了）。
使用反斜线的另一个原因是，它至少有点像正斜线。它也是当时大多数（如果不是全部的话）现有软件很可能不使用的字符。在 7 位密钥代码中，它与小括号、方括号和大括号一起，被用于非美国国家字符，例如瑞典文的 åäöÅÄÖ。任何使用现有打印机或与其他旧系统交换数据的人，如果确实生活在世界上非英语国家，很可能不想使用这些字符。
顺便说一下，在一些非美国的键盘地图上，后斜线过去和现在都很不方便。例如，在瑞典语 “扩展 “键盘上，您必须按 AltGr 键，然后按 0（零）右边的键。
在没有 “扩展键盘 “的年代，您必须按住 ALT，然后按下与美国键盘布局相对应的键。或者按 CTRL+ALT+F1/F2 键，在美国和国内布局之间切换。
有一段时间，MS-DOS 中的键盘驱动程序不再支持在使用国内布局时使用 ALT 访问美国布局，因此如果没有 “扩展键盘”，就只能按住 ALT 键，在数字键盘上键入 092，然后松开 ALT 键，才能产生反斜杠。或者，你也可以尝试查找确实存在的第三方键盘驱动程序。事实上，第三方键盘驱动程序确实存在，这说明 DOS 确实很糟糕
题外话：不知从何时起，DOS 开始要求编写恼人的 “模式 Con “代码，这些代码对用户毫无用处，而且大多只会占用宝贵的内存。(从理论上讲，它可能做了一些有益的事情，比如改变非美国 ASCII 字符的排序顺序，使其遵循国家排序规则或类似规则，但至少对于 80 年代中期销售 PC 的国家来说，代码页垃圾没有任何实际用处）。
理查德-韦尔斯AT&T 当时使用什么终端？没有那么多终端可供选择…
需要准备模式控制代码？嗯……设置程序在我的 config.sys/autoexec.bat 中输入了这个代码，但我习惯把它注释掉，这样就能正常工作了，所以要求？
谢谢，已更正。
@MiaM：最初的 Unix 版本使用的 PDP-7 “Graphics Terminal II”（图形终端 II）使用的似乎是 Teletype ASR-33，字符集非常有限。几年后，Decwriter 中的字符集更大，包括用于表示管道的垂直线。
我找不到抱怨 70 年代中期贝尔实验室使用的终端的文章链接。对不起。
据我所知，ASR-33 是 Unix 终端的鼻祖。当然，DEC VT100（及其后续型号）也很有影响力，但不是很早，因为它在 1978 年才问世。
Teletype 公司的名字在”/dev/tty “中永垂不朽。
MiaM，你提出了一个有趣的问题。(我是美国人，但我也简单涉猎过 DOS i18n 的东西。）这当然是个笨办法，但也不像听起来那么可怕。当然，Michal 对 NLSFUNC + COUNTRY + DISPLAY + KEYB + MODE + *.CP[XI] 以及与之相关的无数设置了如指掌。这是一个相当大的雷区，但它会成为一篇有趣的文章！对我们中的一些人来说是这样！
至于输入某些有问题的字符，你显然需要一个更好的文本编辑器（VIM？）它们通常会提供宏、缩写、数字或其他帮助。(甚至编程语言也经常有一些变通方法（C89 三叉符”??/”或 C94 对角符；Pascal 的”(. “和”.) “以及 ISO Modula-2 的”(!”和”!)”，等等等等。是的，我知道这些字符并不都是反斜杠，但你知道我的意思，有些字符确实存在替代品）。同样，我相信 Michal 对此也有足够的了解。
当然，在实际的提示符下打字也很烦人，默认的 shell（或 DOSKEY）肯定帮不上忙。我确实意识到了这一点，而且我也认识到，为了避免这种乏味而编写 .BAT 本身就很乏味。不过，即使现在有更好的（兼容的）替代品，我们也无法回到过去。所以这可能没有实际意义。不过，不满情绪已经记录在案！
DRI 公司在 CP/M 3（又称 Plus）中将斜线编成法典，不过他们也提供了 $ 作为命令行分隔符。
什么？CP/M Plus 使用方括号表示选项。
实际上，我基本上不使用 DOS NLS 支持。在编程方面，美式键盘布局无可匹敌，所以我只用美式键盘。在写信或写报告时，情况就不一样了，但我在 DOS 中几乎不写这些东西（Windows 3.1 CE 又称中欧版很早就可用了）。我对 NLSFUNC 等程序的了解仅限于知道它很复杂，会占用宝贵的内存。
此外，当我开始使用 DOS 时，几乎没有官方支持。对于捷克语、波兰语、俄语以及我猜测的其他语言，自制的解决方案很常见（有用于键盘和显示支持的 TSR，其代码页完全非标准）。我想说的是，当 IBM/微软添加适当的支持时，DOS 已经不那么重要了。前东欧国家大规模引进个人电脑的时间，或多或少与 Windows 3.0 的推出时间完全吻合。老式 PC 和 XT 的装机量几乎可以忽略不计，大多数机器至少是带 VGA 的 286。
在我的记忆中，捷克斯洛伐克流行的基于 DOS 的文字处理器是 T602（国产），它有自己的 NLS。缺乏 NLS 严重限制了 WordPerfect、WordStar、MS Word 等的使用。1992 年底，Windows 3.1 CE 已经正式支持字体/代码页，因此人们可以使用 WinWord、Ami Pro 等。从那时起，再到 T602，没有人再关心 DOS 内置的 NLS。
我不知道波兰或俄罗斯的情况如何。我知道俄罗斯的 MS-DOS 4.01 出现在 1990 年，但我不知道它的影响有多大。
Larry Osterman 说，DOS 3.x 的 NLS 支持是 IBM 从他们的大型机系统移植过来的，这也许可以解释为什么它给人一种过度工程化的感觉（比如 CPI 头文件中的 “指针数量 “和 “指针类型 “字段，它们永远只能设置为 1）。
关于 DOS NLS，我一直觉得英国的 DOS/Win9x 安装程序被设置为使用 CP850 会很烦人，因为 CP850 用一堆英语中不使用的额外重音字符取代了许多 DOS 程序中常用的方块绘制字符。
由于在英国唯一常用的非 ASCII 字符（GDP 符号）已经包含在 CP437 中，我们根本不需要所有程序看起来都 “损坏”（以及相关的传统内存消耗）。愚蠢的决定
/rant
约翰-埃利奥特请参阅《CP/M Plus 用户指南 1982 年 11 月初版》第 35 页[第 5.1 节]，其中列出了许多特殊字符。方括号用于全局和局部选项，括号用于修改方括号内的选项。斜线和美元符号被列为 “命令行中的选项分隔符”。
鲍勃-伯纳（Bob Berner）的《ASCII 如何获得反斜线》（How ASCII Got Its Backslash）应该是一个很好的起点。
据我所知，”国家 + 显示 + 键盘…… “这种笨办法在苏联/前苏联并不流行。俄罗斯或其他前苏联加盟共和国的情况我不清楚，但在乌克兰，莫斯科科学院首先推出了 alfa（我想是 1985 年）：http://old-dos.ru/index.php?page=files&mode=files&do=show&id=5413。
但它并没有持续多久，几年后就被 keyrus 取代了：
另一方面，在德国，就我所知，DOS NLS 支持非常流行，我记得几乎所有人都在使用。像西门子 PC-D 这样的非 IBM 兼容电脑，其 BIOS/DOS 变体的默认设置就是这种布局（或类似布局）。
在上世纪 80 年代和 90 年代的相当长一段时间里，我 “算是 “知道了标准的美式布局，因为我必须在启动提示符下输入一些内容，或者在 DOS 启动盘上无法使用 “keyb gr”（具有讽刺意味的是，这需要按下其中一个被移调的键：yz）。
直到 90 年代末，我才发现美式键盘在编程时确实要方便得多，于是我主动改用了美式键盘（出乎我意料的是，根本没有遇到什么麻烦），从此再也没有回头。
这与我的经历不谋而合。运行 DOS 的德国电脑几乎可以保证配置了完全 “德国化 “的 NLS。我很熟悉 y/z 移位问题
因为我更喜欢使用美式布局，所以我从来没有想过，如果用 F5 启动 DOS，而键盘却有不同的表现，那该有多令人困惑。对于 DOS 而言，这很糟糕，因为冒号、反斜杠、管道和其他重要按键的位置不同。
我不会说这是个小把戏，它是 NLS 的正式实现，没有任何瑕疵。
1985 年，IBM/MS DOS 没有在俄罗斯（或东欧集团的任何地方）销售。IBM 或微软没有开发 NLS 的动力和渠道。但需求是存在的，而且得到了满足。1990 年后，官方开始提供支持，但此时自制的解决方案已经根深蒂固。
我不知道俄罗斯的情况，但在中欧，一个问题是官方支持（代码页 852）在一个代码页中涵盖了波兰语、捷克语、斯洛伐克语、匈牙利语以及我认为的其他语言。从全球角度来看，这完全合理，但与现有的特定国家 NLS 解决方案并不兼容。
Windows 以全新的面貌和早期支持起步。
事实上，Windows 1.0 早于 DOS（在 DOS 3.3 中）支持 NLS
Windows 使用 ECMA-94 作为字符集的基础。ECMA-94 于 84 年起草，85 年获得批准。与 DOS 所需的大量代码页相比，西欧、美洲、新西兰和澳大利亚使用一个代码页更为简单。大约在 Windows 3.1 面世时，Windows 增加了一组代码页，以扩展更多国家的字符集。幸运的是，Unicode很快就得到了支持，使我不必再像DOS的Word Perfect那样疯狂地实施代码页。
我不知道代码页在 DOS 中的扩散情况。CP 850（相当于 DOS 的 ISO 8859-1）几乎涵盖了所有西方语言。问题（至少就我的经验而言）在于它与 “原始 PC “代码页 437 相冲突，因为有些应用程序需要 CP 437 图形字符，而 CP 850 必须取代 CP 437。
NT 显然采用了通用性更强、最终也更简单的 Unicode 方法。
我想知道创建这个 “加拿大法语 “编码页的目的是什么：
https://en.wikipedia.org/wiki/Code_page_863
它看起来像是略微修改过的 CP 437，只做了足够的改动以支持加拿大法语。保留了图形符号，但删除了德语字符等。
86x 代码页（希腊文除外）看起来都是保留了画线字符的商业行变体。
https://www.aivosto.com/articles/charsets-codepages-dos.html 似乎是一份相当完整的 DOS 主要代码页清单，如果去网站的其他地方，可以看到一份长长的 IBM 代码页清单，它解释了为什么 437 是最初的 DOS 代码页。看完之后，我花了太多时间研究 898 和 899 是否与 DisplayWrite 使用的 EBCDIC 代码页的 ASCII 匹配。
还有一些生成的代码页没有正式的 IBM 代码页编号，IBM 代码页是随应用程序一起提供的，还有一些代码页是专门修改过的。WordPerfect 的最后一种做法会给其他一些代码页和字体工具带来问题。
CP850 并不完全符合 ISO 8859-1。FreeDOS 的常驻 i18n 专家
最近没见到他）Henrique Peron (.br) 是（或曾经是？
他是一个很好的询问对象。他知道很多东西。
作为一名世界语者（已失效？
8859-3，又称拉丁文-3。
大写字母。虽然也有 7 位的变通方法，但相当普遍）。
这也相当常见）。因此，根据有限的经验，我知道一些。我不
我不完全确定，因为我对 OS/2 一无所知，但一些有用的代码页
但有些有用的代码页（只有？例如，CP819（”真正的 “ISO 8859-1）、912、913
(拉丁-3）、914 等。
DR-DOS 7.03 有（未注明的）CP853，但缺少小写字母
“j^”字符。不过我认为它的 KEYB 不支持 E-o。而 FreeDOS 只
正式支持 CP853（与之相当，但仍不是 1:1 Latin-3
兼容，但它有一些应用程序显然需要使用的方框字符）。
CPX），其 KEYB 也支持它。有第三方
变通方法（Kosta Kostis 网站上的 ISOLATIN.CPI；一个 .nl 网站上的一些微弱的 TSR
在一个 .nl 网站上）。或者使用
辅助编辑器（Blocek、GNU Emacs、Mened）。或类似工具（iconv?
Sed？）目前 COUNTRY.SYS 不支持 E-o，所以
我不认为 NLSFUNC 可以工作（UCASE 表或其他）。
虽然我从来没怎么写过东西（更多的是阅读大量的电子印刷期刊
期刊），所以我只是出于好奇（因为 DOS
是我的最爱）。或者使用 “x metodo”（或正式的、但对机器不太友好的 “h metodo”）。
h metodo”）。
我相信你们欧洲人比我更能理解或解释！
不过，说真的，这可以写成一两篇很好的文章（但复杂得很
但复杂得要命，会引起很大的争议）。”Kia mondo!(世界真大）
我以为每个人都知道 CP 437 是什么 那是 IBM PC/XT/AT 硬件实现的，也就是在代码切换之前的唯一选择。
同样有趣的是，由于 CP 437 确实涵盖了多种语言，DOS 从 3.0 版（1984 年）开始就支持全国键盘，这比可切换的代码页要早得多。
CP 437 可能是字符 ROM 中的内容，但改变字符集是可以做到的。IBM PC 的 APL 必须用 APL 专用字符替换许多字符。这不是一种正式的代码页实现设计，而是一种类似的技术。
其他一些 IBM 产品也分配了独特的代码页，但我不知道 PC 的实现是否修改了字符集以与之匹配。我不打算买一个 3278/79 硬件适配器，只是想知道它是否支持完整的 3270 EBCDIC 代码页。我怀疑 DisplayWrite 是支持的，因为它可以使用和显示 EBCDIC 字符和符号代码页中的所有字符，包括 CP 437 中没有的一些字符。
代码页和相关概念的复杂程度远远超出了任何文档所能解释的范围。
除了在 MDA/CGA 上无法更改字符集之外，只有 EGA 及其后才有可加载字体。
实际上，我认为代码页的概念很简单，但由于代码页和软件包繁多，每个软件包都有自己的想法，因此现实非常复杂。
我还记得上世纪 90 年代中后期与设计糟糕的网页打交道的情形，这些网页使用了一些代码页（通常是 Windows 的默认设置），你只能猜测是哪个代码页，因为设计者从来没想过有人会用不同的操作系统/浏览器/配置来阅读网站，而且他们的软件也懒得在页眉中标注使用的编码。如今情况好多了。
GRAFTABL 用于 CGA，不是吗？
另外，关于 “复杂得令人发疯”，它不可能那么简单，因为没有人会满意。你肯定知道 ANSI C89 的 locale.h（以及几乎不存在的支持，尤其是对 DOS 编译器的支持），以及 C94（C99 之前）的 i18n 变化。你把它搞得有多复杂，它就有多复杂（但大多数人并不关心）。
哦，我想说的是，我认为有些国家的政府强制要求自己支持官方操作系统语言。所以，这不仅仅是业余爱好者的愿望，也不仅仅是为了方便，而是必须的。(如果你觉得这听起来很明显或很天真，很抱歉，但我从来不知道）。
是的，不过 GRAFTABL 仅用于图形模式。不知道它有多大用处。
自然语言很复杂（并不是说计算机语言就更好），这意味着 i18n 也很复杂。在大多数情况下，能够键入并显示/打印所需的字符才是用户真正想要的。排序、货币字符或小数分隔符、日期格式，所有这些都很有用，但很少是必需的。幸运的是，Unicode 解决了最大的问题，UTF-8 解决了 UTF-16 带来的大部分问题。
各国政府当然会规定特定的代码页等。如果你仔细想想，这确实是合乎逻辑的，因为如果没有这些，事情要么会变得更加复杂（需要来回转换），要么就是根本无法运行（字符混淆、排序不一致等）。
对我之前的评论做一些更正。用于 PC 的 IBM APL 在 CGA 图形模式下运行，并安装了图形字体。文本模式的特殊字体是非 IBM APL*Plus 字体，它显然与一个特殊的替换 ROM 一起提供。至少在 IBM 的一种 PC 实现中，3270 支持是通过具有多个字符集的 ROM 实现的。30 多年前的记忆确实很模糊。
Olivetti 使用 GRAFTABL 来处理欧洲所需的字符集。Olivetti MSDOS 文档用英语解释了它的工作原理，以及切换回美国代码页所需的热键和所有特殊字符输入和弦。使用类似于 GRAFTABL 的方法但早于 GRAFTABL 的 IBM 产品包括前面提到的 IBM APL 和 1983 年由 IBM 以色列公司编写的实用程序。
我一直在关注一些语言和字符集方面的工作。通常，开发工作的一半似乎都花在了语言的晦涩部分上，只有提出建议的学术界人士才会使用这些语言。我很庆幸，在我开始编程的时候，人们愿意根据技术的局限性调整语言的需求。没有小写字母，没有分音符，都没问题。我成功地忽略了大部分企业提出的专有国际化方案，只有在 Unicode 得到巩固后才不得不面对它。
GRAFTABL 所做的就是在内存中加载 8×8 字体的最后 128 个字符，并将 int 1F 向量指向它。
并将 int 1F 向量指向它。这样，int 10 函数 8,9,A（速度慢，因此很少使用）就可以在 CGA 图形模式下读写这些字符。遗憾的是，能在图形模式下运行的 DOS 程序不多，而那些能运行的程序（如 chiwrite、lexicon）则使用自己的字体并直接写入显存，虽然速度仍然比文本模式下慢（至少在 PC/XT 上是这样），但还可以接受。
总之，在 MDA/CGA 上使用西里尔字母的标准方法是更换视频 ROM 芯片。
是的，我还记得全大写无分隔符的打印输出，是由巨大的噪音打印机打印的，一次打印一整行。有趣的是，无分号比有分号要好得多。而 “破损 “无疑是 “让我们忽略 NLS “和 “运行 NLS “之间的一个句号。
日本的 DOS/Windows 使用 ¥ 代替 作为路径分隔符。算是吧。虽然是相同的十六进制字节，但用于 SJIS 字符集/编码的 1 字节部分的 JIS X 0201 字符集在 的字节位置上使用了 ¥ 字形。在老式的 NEC PC-98 布局和现代的 IBM OADG 布局中，键盘也有一个 ¥ 键，而不是 键。
好像他们想证明字形和码位之间的区别。
只有一个明显的评论：”十进制分隔符很少是必要的”。恰恰相反，我的朋友！在国际交易中，如果没有正确注意到逗号的位置，也没有就逗号的位置达成一致，就会造成巨额损失（有些人把逗号误认为句号，我认为这在欧洲很常见）。嘿，你能借我 5000 美元吗？毕竟今天是我生日。
事实上，7 月 1 日（美国为 07-01）是我的生日，但你们这些愚蠢的未来学家和你们愚蠢的时区 ….DOS 总是使用本地时间（不像 *nix 喜欢使用 UTC），文件时间的粒度为两秒，这对 makefile 很不利，但在慢机器上问题不大。
是啊，模棱两可让人恼火，尤其是在试图保持技术正确性的时候。即使是美式英语和英式（或其他）英语也有很多差异。这是不可避免的，我并不是在抱怨复杂性。但这不应被忽视或轻视。(我知道你同意，只是说说而已）。
当然，我明白–我必须经常注意这种事情，逗号和句号在我的美国银行账户和德国银行账户中的含义是不同的。
只是，操作系统中的 l10n 支持并不一定能起到多大作用，尤其是当它帮助我们输入错误字符时。
关于时间戳，还有一件有趣的事。当你使用（比如）DOS 软盘时，时间戳将是文件写入地的当地时间。当你用现代操作系统复制文件时，时间戳会转换为 UTC。怎么转换？那么，现代操作系统实际上就是编造了一些东西。当同一文件的多个副本因路径不同而出现不同的时间戳时，就会产生有趣的问题。
我猜想，如果设计者真的考虑过这个问题，他们就会认为没有必要询问用户文件是在哪个TZ创建的，因为用户可能也不知道。而注意到这个问题的人更是少之又少。
代码页 850 当然不是 Latin-1，尽管它可能包含 Latin-1 中的所有或至少大部分字符，但它的位置使其与代码页 437 更加兼容。
关于时间戳：”dos 媒体 “上的时间戳是由现代 Windows 等编写的，难道不是使用计算机设置的时区吗？(或者是当前用户将计算机设置为哪个时区）？
所有这些关于分隔符、日期格式等的东西在理论上都是好东西，但在实践中往往会造成问题，因为某个地方的某个人没有考虑到它们的存在，而其他人却考虑到了它们的存在，最终导致软件试图将一种格式的时间戳解释成另一种时间格式的时间戳。这样一来，即使用户远在美国，也不得不将地区设置设为美国。
也许最糟糕的是，当一家大型非 IT 公司与某家大型 IT 公司签订了提供定制软件的合同时，通常会出现这种情况，而任何修改，包括修复明显的错误/缺陷，都会向客户收费。(这也是一种蹩脚的商业道德，使得大公司的内部 IT 支持人员不会将微软 Outlook 97 的排序规则中 “移动 “的意思改为 “复制，然后删除，但前提是它在收件箱中”）。
哪些国家/政府在规定某些字符编码和类似内容方面取得了成功？当时，我们只能在个人电脑上使用 DOS 的所有代码页、Macintosh 独有的 8 位字符集，以及 ISO 拉丁文版本（在某些电脑上，即使你无法更改字符集，但-1 仍是默认设置，例如 Amiga 和后来的 VT 终端上的 “DEC 多语言字符集”）。