Is \n multi-character in C?

问题

I read that \n consists of CR & LF. Each has their own ASCII codes.

So is the \n in C represented by a single character or is it multi-character?

Edit: Kindly specify your answer, rather than simply saying "yes, it is" or "no, it isn't"

回答1:

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.

回答2:

In a C program, it's a single character, '\n'representing end of line. However, some operating systems (most notably Microsoft Windows) use two characters to represent end of line in text files, and this is likely where the confusion comes from.

It's the responsibility of the C I/O functions to do the conversions between the C representation of '\n' and whatever the OS uses.

In C programs, simply use '\n'. It is guaranteed to be correct. When looking at text files with some sort of editor, you might see two characters. When a text file is transferred from Windows to some Unix-based system, you might get "^M" showing up at the end of each line, which is annoying, but has nothing to do with C.

回答3:

It depends:

'\n' is a single character (ASCII LF)
"\n" is a '\n' character followed by a 0 terminator

some I/O operations transform a '\n' into '\r\n' on some systems (CR-LF).

回答4:

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.

回答5:

\n is a new-line -- it's a logical representation of whatever separates one line from another in a text file.

A given platform will have some physical representation of that logical separation between lines. On Unix and most similar systems, the new-line is represented by a line-feed (LF) character (and since Unix was/is so closely associated with C, on Unix the LF is often just called a new-line). On MacOS, it's typically represented by a carriage-return (CR). On a fair number of other systems, most prominently Windows, it's represented by a carriage return/line feed pair -- normally in that order, though once in a while you see something use LF followed by CR (as I recall, Clarion used to do that).

In theory, a new-line doesn't need to correspond to any characters in the stream at all though. For example, a system could have text files that were stored as a length followed by the appropriate number of characters. In such a case, the run-time library would need to carry out a slightly more extensive translation between internal and external representations of text files than is now common, but such is life.

回答6:

According to the C99 Standard (section 5.2.2),

\n "moves the active position [where the next character from fputc would appear] to the initial position on the next line".

Also

[\n] shall produce a unique implementation-defined value which can be stored in a single char object. The external representations in a text file need not be identical to the internal representations and are outside the scope of [the C99 Standard]

Most C implementations choose to define \n as ASCII line feed (0x0A) for historical reasons. However, on many computer operating systems, the sequence for moving the active position to the beginning of the next line requires two characters usually 0x0D, 0x0A. So, when writing to a text file, the C implementation must convert the internal sequence of 0x0A to the external one of 0x0D, 0x0A. How this is done is outside of the scope of the C standard, but usually, the file IO library will perform the conversion on any file opened in text mode.

回答7:

Your question is about text files.

A text file is a sequence of lines.
A line is a sequence of characters ending in (and including) a line break.
A line breaks is represented differently by different Operating Systems.

On Unix/Linux/Mac they are usually represented by a single LINEFEED
On Windows they are usually represented by the pair CARRIAGE RETURN + LINEFEED
On old Macs they were usually represented by a single CARRIAGE RETURN
On other systems (AS/400 ??) there may even not be a specific character that represents a line break ...

Anyway, the library code in C is responsible to translating the system's line break to '\n' when reading text files and do the reverse operation when writing text files.

So, no matter what the representation is on any given system, when you read a text file in C, lines will be ended by a '\n'.

Note: The '\n' is not necessarily 0x0a in all systems.