Line feed and carriage return are two different ways of how your computer sees the Enter key.
While for example the character M is interpreted the same way in Windows and in UNIX, the ENTER key is interpreted differently. This causes problems when transferring files and data from one platform to another one.
When transferring files from one platform to another, you can experience that ENTERs are not translated in a way thay you would expect.
Windows uses carriage return – line feed.
UNIX uses line feed.
Macintosh uses carriage return.
A line feed is expressed in hexadecimal as 0a. A carriage return is noted as hexadecimal 0d. Windows carriage return – line feed is 0a0d in hexadecimal notation.
How do I spot a problem with carriage return and line feed?
When you take a UNIX file and open it in Windows NOTEPAD, you will most likely see something like the following example:
<?php // $Id: blog.module,v 1.271.2.2 2007/04/23 17:05:11 dries Exp $log_user($type, &$edit, &$user) { if ($type == 'view' && user_accesa page that displays the most recent blog entries from all the users tion handbook <a href="@blog">Blog page</a>.', array('@blog' => 'httpORDER BY n.created DESC"), 0, variable_get('feed_default_items', 10))ser->uid) && user_access('edit own blog')) { $output = '<li>'. blog entries of all users. */ function blog_page_last() { global $object(db_query('SELECT i.*, f.title as ftitle, f.link as flink FROM ge) { // Breadcrumb navigation $breadcrumb[] = array('path' =may_cache) { $items[] = array('path' => 'blog', 'title' => t('Bloblog', array('title' => t('Read the latest blog entries.'))) .'</div>All the lines are compressed and enters are clearly missing. Well, they are not completely missing, they are just coded in a format that Notepad does not understand. Why this happens, you can find that at this page: Line termination: line feed versus carriage return.
How do I know what system a file was created in?
When you open the file in a HEX editor, you can tell by looking at the HEX code to find out whether your Enters were encoded as carriage returns, line feeds, or the pair of both.
This picture shows you that Enters have been encoded as line feed.
How do I fix a problem with carriage return?
One way to fix this is to open the file using a HEX editor and replace all the “bad” enters with the “good” ones. In our case, we would replace all references to 0a with 0d0a. Then, this file should be readable by Windows Notepad.
One very nice and easy fix is to:
-> open your file in Notepad,
-> copy the content of the file,
-> paste it into MS Word,
-> copy the text in MS Word,
-> and paste it back to Notepad
If you do this with the file pictured above, you will get the following result:
You can see that all Enters have been coded in a form of carriage return – line feed, that is 0d0a.
You can open the file in Windows Notepad and see the code nicely formatted line by line as they were on the UNIX computer.
Line termination: line feed versus carriage return 0d 0a
Line feed and carriage return are two different ways of computer interpretting the ENTER key. Line feed and carriage return are two different ways how lines are ended in the computer language. Both the line feed and carriage return originate in the typewriter age.
The best way to explain this is is to ask:
“What do you suppose your computer sees when you press the Enter key?”
You can rest assured that your computer translates the ENTER key stroke into something. But while for example the character A is interpreted the same way by all common platforms (Windows, UNIX, Mac), the ENTER key is interpreted differently.
This causes problems when porting files from one platform to another one.
How ENTER works in computer language?
When you press A on your keyboard, you will see letter A on the screen. When you press B on your keyboard, you will see letter B on the screen.
Each of these two characters gets translated into a code that the computer can understand. Each of these two characters is one byte long, and your computer has some algorithm for translating these human readable letters into code numbers.
The computer number assigned to the letter A happens to be 65 (you can find this in the ASCII table). In other words, the decimal representation of the letter or character A is 65. If you translate this into the computer zeros and ones, you will get 1000001, which is 8 bits, that is one byte.
Decimal binary hex or hexadecimal – What is it?
Characters’ code values are represented by various utilities using different numbering schemes. Some times we talk about the decimal number system. In this system, letter A is represented by number 65. Letter B is represented by number 66.
Some times (rarely) symbols are expressed in binary number system. In this numbering scheme, letter A would be 1000001 as we have already mentioned, and the letter B would be expressed as 1000010.
Quite often, symbols are expressed using the hexadecimal number system. Letter A in this system is expressed as 41 and letter B is 42.
Decimal 10000001, binary 65, and hexidecimal 41 are different numeric “languages” for the same letter.
There are other numbering schemes such as octal, but we won’t get into those.
So, what does my computer see when I hit ENTER?
When you look inside some file that you created, you can find out. All that you need for this job is some hexadecimal editor. You can use for example the PSPad editor.
Open a text file in the text editor and type the following sequence:
A
hit enter
B
hit enter
Now when you open the file in a hexadecimal editor in a HEX view, you should see the following:
Note that the letter A shows as 41 and the letter B shows as 42.
If your file was created in Linux, you would also see a single character 0a after each letter, that is, wherever you pressed the ENTER key.
If your file was created in Windows, the pair of characters 0d and 0a would appear any place where you pressed the ENTER key.
The hexadecimal 0a, a control character as opposed to a printing character, is called a line feed.
The hexadecimal 0d is called a carriage return.
Pretty much all the programs on the Windows platform understand and expect the hexadecimal 0a0d pair in text. The 0d0a pair of characters is the signal for the end of a line and beginning of another.
On the other hand, a UNIX program expects the single 0a character to denote the same thing.
A problem arises with cross-platform exchange of files. If you transfer files from Linux to Windows or Mac, the software sees something other than what it expects.
Windows versus UNIX versus Macintosh
As if it was not enough, Macintosh makes the whole story even more complicated. The original Mac operating system used carriage return 0d as the line separator.
So, to summarize, Windows uses carriage return – line feed, UNIX and newer Mac use line feed, and older Macs use carriage return.
Windows :
preceding text -> 0d 0a -> succeeding text
UNIX, Mac OS X :
preceding text -> 0a -> succeeding text
MAC (OS-9 and earlier):
preceding text -> 0d -> succeeding text