java中如何getchar_getch（）和getchar（）有什么区别？

标准C函数是 getchar() ，在 中声明 . 它基本上从一开始就存在 . 它从标准输入( stdin )读取一个字符，它通常是用户的键盘，除非它已被重定向(例如通过shell输入重定向字符 < 或管道) .

getch() 和 getche() 是旧的MS-DOS函数，在 中声明，在Windows系统上仍然很流行 . 它们不是标准C功能;它们并不存在于所有系统中 . getch 立即从键盘上读取一次击键，无需等待用户点击Return键，也无需回显键击 . getche 是相同的，除了它确实是回声 . 据我所知， getch 和 getche 总是从键盘上读取;它们不受输入重定向的影响 .

问题自然会出现，如果 getchar 是标准函数，你如何使用它来读取一个字符而不等待Return键，或者没有回显？这些问题的答案至少有点复杂 . (事实上，它们很复杂，我怀疑它们解释了 getch 和 getche 的持久受欢迎程度，如果没有别的东西很容易使用的话 . )

答案是 getchar 无法控制回声和输入缓冲等细节 - 就C而言，这些是较低级别的系统相关问题 .

但是理解 getchar 假设的基本输入模型很有用 . 令人困惑的是，通常有两种不同级别的缓冲 .

当用户键入键盘上的键时，操作系统的终端驱动程序会读取它们 . 通常，在其默认模式下，终端驱动程序会在键入时立即回显键击(因此用户可以看到他们正在键入的内容) . 通常，在默认模式下，终端驱动程序还支持一定量的行编辑 - 例如，用户可以点击Delete或Backspace键来删除意外类型的字符 . 为了支持行编辑，终端驱动程序通常在输入缓冲区中收集字符 . 只有当用户点击Return时，该缓冲区的内容才可供调用程序使用 . (仅当标准输入实际上是键盘或其他串行设备时，才会出现此级别的缓冲 . 如果标准输入已重定向到文件或管道，则终端驱动程序不起作用，并且此级别的缓冲不适用 . )

stdio包将操作系统中的字符读入其自己的输入缓冲区 . getchar 只是从该缓冲区中提取下一个字符 . 当缓冲区为空时，stdio包会尝试通过从操作系统中读取更多字符来重新填充它 .

因此，如果我们跟踪程序第一次调用 getchar 时发生的事情：stdio发现它的输入缓冲区是空的，所以它尝试从操作系统中读取一些字符，但是还没有任何字符可用，所以 read 调用块 . 同时，用户可能正在键入一些字符，这些字符正在终端驱动程序中累积，但仍然会返回 . 最后，用户点击返回，而阻塞 read 调用返回，返回整条 生产环境 线的身价字符 stdio 的，使用它们来填补其输入缓冲区，在外面它，然后返回第一个到初始调用 getchar ，这一直耐心等待 . (然后，如果程序调用 getchar 第二次或第三次，也可能有一些更多的字符 - 提供标准输入输出的输入缓冲区 getchar 立即返回对于多一点关于这个 - 上线用户键入的字符旁边，见section 6.2这些C course notes . )

但是在所有这些中，正如您所看到的， getchar 和stdio包无法控制回显或输入行编辑等细节，因为在步骤1中，这些在较低级别处理，在终端驱动程序中处理 .

因此，至少在类Unix操作系统下，如果要在不等待返回键的情况下读取字符，或者控制是否回显字符，可以通过调整终端驱动程序的行为来实现 . 细节有所不同，但有一种方法可以打开和关闭回声，以及一种打开和关闭输入行编辑的方式(实际上有两种方式) . (至少有一些细节，请参阅旧C FAQ list中的this SO question或question 19.1 . )

当关闭输入行编辑时，操作系统可以立即返回字符(无需等待返回键)，因为在这种情况下，它不必担心用户可能输入了需要"taken back"的错误键击删除或退格键 . (但出于同样的原因，当一个程序关闭终端驱动程序中的输入行编辑时，如果它想让用户纠正错误，它必须实现自己的编辑，因为它会看到---也就是说，连续对 getchar 的调用将返回 - 用户的错误字符和Delete或Backspace键的字符代码 . )