Contents

mysql -u root -p --one-database SPECIFIC_DATABASE < fulldump.sql

sed -n '/^-- Current Database: SPECIFIC_DATABASE/,/^-- Current Database: `/p' fulldump.sql > specific_base.sql

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) {&nbsp;&nbsp; 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')) {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $output = '<li>'. blog entries of all users.&nbsp; */ function blog_page_last() {&nbsp;&nbsp; global $object(db_query('SELECT i.*, f.title as ftitle, f.link as flink FROM ge) {&nbsp;&nbsp;&nbsp;&nbsp; // Breadcrumb navigation&nbsp;&nbsp;&nbsp;&nbsp; $breadcrumb[] = array('path' =may_cache) {&nbsp;&nbsp;&nbsp;&nbsp; $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

ASCII is a standard for character encoding used by computers and communications equipment to represent text. ASCII is short for American Standard Code for Information Interchange. You can find the ASCII table below.

Computers can only understand numbers, so a code ASCII is the numerical representation of a character such as M or 8 or $ or an action of some sort. ASCII uses a single byte to represent each character. A byte is generally the smallest addressable unit of data on a computer. It is a continuous sequence of eight bits, that is zeros or ones.

This means that one byte could represent any of 256 characters ranging in binary notation from 00000000 to 11111111. Eight bits allows 256 combinations of zeros and ones.

ASCII table

This following ASCII table lists the ASCII characters and their decimal, octal and hexadecimal numbers.

Below you can find the 128 standard character encodings in US-ASCII, which is the original and most basic version of ASCII. Each of these numbers in the ASCII table is a seven digit binary number between 00000000 and 01111111. The eighth bit (the left-most bit) was originally reserved for use as a parity bit.

The first 32 ASCII codes in the ASCII table below (zero through 31 in decimal notation, or 00000000 through 00011111 in binary) are reserved and are called control characters. These are non-printing ASCII characters. They were originally intended to control devices, most importantly printers. These characters appear in the most left column. The ASCII non-printing characters are rarely used for their original purpose these days.

Char	Dec	Oct	Hex	/	Char	Dec	Oct	Hex	/	Char	Dec	Oct	Hex	/	Char	Dec	Oct	Hex
null byte	0	0000	0x00	|	space	32	0040	0x20	|	@	64	0100	0x40	|	`	96	0140	0x60
start of heading	1	0001	0x01	|	!	33	0041	0x21	|	A	65	0101	0x41	|	a	97	0141	0x61
start of text	2	0002	0x02	|	“	34	0042	0x22	|	B	66	0102	0x42	|	b	98	0142	0x62
end of text	3	0003	0x03	|	#	35	0043	0x23	|	C	67	0103	0x43	|	c	99	0143	0x63
end of transmission	4	0004	0x04	|	$	36	0044	0x24	|	D	68	0104	0x44	|	d	100	0144	0x64
enquiry	5	0005	0x05	|	%	37	0045	0x25	|	E	69	0105	0x45	|	e	101	0145	0x65
acknowledge	6	0006	0x06	|	&	38	0046	0x26	|	F	70	0106	0x46	|	f	102	0146	0x66
bell character	7	0007	0x07	|	‘	39	0047	0x27	|	G	71	0107	0x47	|	g	103	0147	0x67
backspace	8	0010	0x08	|	(	40	0050	0x28	|	H	72	0110	0x48	|	h	104	0150	0x68
horizontal tab	9	0011	0x09	|	)	41	0051	0x29	|	I	73	0111	0x49	|	i	105	0151	0x69
newline	10	0012	0x0a	|	*	42	0052	0x2a	|	J	74	0112	0x4a	|	j	106	0152	0x6a
vertical tab	11	0013	0x0b	|	+	43	0053	0x2b	|	K	75	0113	0x4b	|	k	107	0153	0x6b
formfeed	12	0014	0x0c	|	,	44	0054	0x2c	|	L	76	0114	0x4c	|	l	108	0154	0x6c
carriage return	13	0015	0x0d	|	–	45	0055	0x2d	|	M	77	0115	0x4d	|	m	109	0155	0x6d
shift out	14	0016	0x0e	|	.	46	0056	0x2e	|	N	78	0116	0x4e	|	n	110	0156	0x6e
shift in	15	0017	0x0f	|	/	47	0057	0x2f	|	O	79	0117	0x4f	|	o	111	0157	0x6f
data link escape	16	0020	0x10	|	0	48	0060	0x30	|	P	80	0120	0x50	|	p	112	0160	0x70
device control 1	17	0021	0x11	|	1	49	0061	0x31	|	Q	81	0121	0x51	|	q	113	0161	0x71
device control 2	18	0022	0x12	|	2	50	0062	0x32	|	R	82	0122	0x52	|	r	114	0162	0x72
device control 3	19	0023	0x13	|	3	51	0063	0x33	|	S	83	0123	0x53	|	s	115	0163	0x73
device control 4	20	0024	0x14	|	4	52	0064	0x34	|	T	84	0124	0x54	|	t	116	0164	0x74
negative acknowledge	21	0025	0x15	|	5	53	0065	0x35	|	U	85	0125	0x55	|	u	117	0165	0x75
synchronous idle	22	0026	0x16	|	6	54	0066	0x36	|	V	86	0126	0x56	|	v	118	0166	0x76
end of trans block	23	0027	0x17	|	7	55	0067	0x37	|	W	87	0127	0x57	|	w	119	0167	0x77
cancel	24	0030	0x18	|	8	56	0070	0x38	|	X	88	0130	0x58	|	x	120	0170	0x78
end of medium	25	0031	0x19	|	9	57	0071	0x39	|	Y	89	0131	0x59	|	y	121	0171	0x79
substitute	26	0032	0x1a	|	:	58	0072	0x3a	|	Z	90	0132	0x5a	|	z	122	0172	0x7a
escape	27	0033	0x1b	|	;	59	0073	0x3b	|	[	91	0133	0x5b	|	{	123	0173	0x7b
file separator	28	0034	0x1c	|	<	60	0074	0x3c	|	\	92	0134	0x5c	|	|	124	0174	0x7c
group separator	29	0035	0x1d	|	=	61	0075	0x3d	|	]	93	0135	0x5d	|	}	125	0175	0x7d
record separator	30	0036	0x1e	|	>	62	0076	0x3e	|	^	94	0136	0x5e	|	~	126	0176	0x7e
unit separator	31	0037	0x1f	|	?	63	0077	0x3f	|	_	95	0137	0x5f	|	delete	127	0177	0x7f

Note that lower and upper case characters are understood by the computer differently.