当前位置：文江博客话题详情

C语言中\n是多字符吗？

发布于 2024-09-18 11:03:59 字数 161 浏览 7 评论 0原文

我读到 \n 由 CR & 组成。低频。每个都有自己的 ASCII 代码。

那么C中的\n是用单个字符表示还是多字符表示呢？

编辑：请具体说明您的答案，而不是简单地说“是的，它是”或“不，它不是”

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

素年丶 2024-09-25 11:03:59

在 C 程序中，它是单个字符，'\n'表示行尾。然而，某些操作系统（尤其是 Microsoft Windows）使用两个字符来表示文本文件中的行尾，这可能就是混乱的根源。

CI/O 函数负责在 '\n' 的 C 表示形式与操作系统使用的任何内容之间进行转换。

在 C 程序中，只需使用 '\n' 即可。保证是正确的。当使用某种编辑器查看文本文件时，您可能会看到两个字符。当一个文本文件从 Windows 传输到某些基于 Unix 的系统时，你可能会在每行末尾出现 "^M"，这很烦人，但与 C 无关。

回复收藏 0 原文

一绘本一梦想 2024-09-25 11:03:59

一般来说：'\n'是单个字符，代表换行符。 '\r' 是单个字符，代表回车符。它们是自己独立的 ASCII 字符。

出现问题的原因是，在实际的文件表示中，基于 UNIX 的系统倾向于单独使用 '\n' 来表示您在键盘上按“enter”或“return”时所想到的内容，而 Windows使用 '\r' 后直接跟随 '\n'。

在文件中：

"This is my UNIX file\nwhich spans two lines"
"This is my Windows file\r\nwhich spans two lines"

当然，像所有二进制数据一样，这些字符都是关于解释的，并且该解释取决于使用数据的应用程序。在制作 C 字符串时坚持使用 '\n'，除非你想要字面回车，因为正如人们在评论中指出的那样，操作系统表示与您无关。 IO 库（包括 C 库）应该自行处理此问题并将其从您手中抽象出来。

为了满足您的好奇心，以十进制表示，ASCII 中的 '\n' 为 10，'\r' 为 13，但请注意，这是 ASCII 标准，而不是 C 标准。

Generally: '\n' is a single character, which represents a newline. '\r' is a single character, which represents a carriage-return. They are their own independent ASCII characters.

Issues arise because in the actual file representation, UNIX-based systems tend to use '\n' alone to represent what you think of when you hit "enter" or "return" on the keyboard, whereas Windows uses a '\r' followed directly by a '\n'.

In a file:

"This is my UNIX file\nwhich spans two lines"
"This is my Windows file\r\nwhich spans two lines"

Of course, like all binary data, these characters are all about interpretation, and that interpretation depends on the application using the data. Stick to '\n' when you are making C-strings, unless you want a literal carriage-return, because as people have pointed out in the comments, the OS representation doesn't concern you. IO libraries, including C's, are supposed to handle this themselves and abstract it away from you.

For your curiosity, in decimal, '\n' in ASCII is 10, '\r' is 13, but note that this is the ASCII standard, not a C standard.

回复收藏 0 原文

北方。的韩爷 2024-09-25 11:03:59

这取决于：

'\n' 是单个字符 (ASCII LF)
"\n" 是 '\n' 字符后跟一个0 终止符

某些 I/O 操作在某些系统 (CR-LF) 上将 '\n' 转换为 '\r\n'。

回复收藏 0 原文

命硬 2024-09-25 11:03:59

当您使用 Windows C stdio 库将 \n 打印到文件时，该库会将其解释为逻辑换行符，而不是文字字符 0x0A。文件的输出将是 Windows 版本的换行符：0x0D0A (\r\n)。

编写

示例代码：

#include <stdio.h>
int main() {
    FILE *f = fopen("foo.txt","w");
    fprintf(f,"foo\nbar");
    return 0;
}

快速cl /EHsc foo.c之后，您就可以

0x666F6F 0x0D0A 0x626172 (separated for convenience)

在十六进制编辑器下进入foo.txt。

需要注意的是，如果您以“二进制模式”写入文件，则不会发生这种转换。

读取

如果您使用相同的工具读回文件，也在 Windows 上，如果您尝试与 \n 匹配，“windows EOL”将被正确解释。

时

#include <stdio.h>
int main() {
    FILE *f = fopen("foo.txt", "r");
    char c;
    while (EOF != fscanf(f, "%c", &c))
        printf("%x-", c);
}

因此

 66-6f-6f-a-62-61-72-

，唯一与您相关的时间是您在

mac/unix 和 windows 之间来回移动文件。 Unix 在这里不需要真正的解释，因为 \n 在这些平台上直接转换为 0x0A。（OSX 之前的 \n 在 mac iirc 上是 0x0D）
将文本放入二进制文件中，请务必小心执行此操作
尝试找出为什么您的二进制数据在以下情况下会被弄乱你打开了文件“w”，而不是“wb”
根据文件的大小估计一些重要的东西，在 Windows 上，每个换行符都会有一个额外的字节。

When you print the \n to a file, using the windows C stdio libraries, the library interprets that as a logical new-line, not the literal character 0x0A. The output to the file will be the windows version of a new-line: 0x0D0A (\r\n).

Writing

Sample code:

#include <stdio.h>
int main() {
    FILE *f = fopen("foo.txt","w");
    fprintf(f,"foo\nbar");
    return 0;
}

A quick cl /EHsc foo.c later and you get

0x666F6F 0x0D0A 0x626172 (separated for convenience)

in foo.txt under a hex editor.

It's important to note that this translation DOES NOT occur if you are writing to a file in 'binary mode'.

Reading

If you are reading the file back in using the same tools, also on windows, the "windows EOL" will be interpreted properly if you try to match up against \n.

When reading it back

#include <stdio.h>
int main() {
    FILE *f = fopen("foo.txt", "r");
    char c;
    while (EOF != fscanf(f, "%c", &c))
        printf("%x-", c);
}

You get

 66-6f-6f-a-62-61-72-

Therefore, the only time this should be relevant to you is if you are

Moving files back and forth between mac/unix and windows. Unix needs no real explanation here, since \n directly translates to 0x0A on those platforms. (pre-OSX \n was 0x0D on mac iirc)
Putting text in binary files, only do this carefully please
Trying to figure out why your binary data is being messed up when you opened the file "w", instead of "wb"
Estimating something important based on the size of the file, on windows you'll have an extra byte per newline.

回复收藏 0 原文

忆沫 2024-09-25 11:03:59

\n 是一个换行符——它是文本文件中将一行与另一行分开的任何内容的逻辑表示。

给定的平台将具有线路之间逻辑分隔的某种物理表示。在 Unix 和大多数类似系统上，换行符由换行 (LF) 字符表示（并且由于 Unix 曾经/现在与 C 密切相关，因此在 Unix 上 LF 通常简称为换行符）。在 MacOS 上，它通常由回车符 (CR) 表示。在相当多的其他系统上，最突出的是 Windows，它由回车/换行对表示 - 通常按此顺序，尽管偶尔您会看到某些东西使用 LF 后跟 CR（我记得，Clarion 过去常常这样做）这样做）。

理论上，换行根本不需要对应于流中的任何字符。例如，系统可能具有存储为长度后跟适当数量的字符的文本文件。在这种情况下，运行时库需要在文本文件的内部和外部表示之间进行比现在常见的稍微更广泛的转换，但这就是生活。

回复收藏 0 原文

伊面 2024-09-25 11:03:59

根据 C99 标准（第 5.2.2 节），

\n“将活动位置[fputc中的下一个字符将出现的位置]移动到下一行的初始位置”。

还

[\n] 应生成唯一的实现定义值
它可以存储在单个 char 对象中。文本文件中的外部表示
不需要与内部表示相同，并且超出了 [C99 标准] 的范围

由于历史原因，大多数 C 实现选择将 \n 定义为 ASCII 换行符 (0x0A)。然而，在许多计算机操作系统上，将活动位置移动到下一行开头的序列需要两个字符，通常是 0x0D、0x0A。因此，在写入文本文件时，C 实现必须将内部序列 0x0A 转换为外部序列 0x0D、0x0A。如何完成此操作超出了 C 标准的范围，但通常文件 IO 库将对以文本模式打开的任何文件执行转换。