Are your CSV file field delimited by spaces as you show? Are the text fields VarChar or fixed width? When you read your file, did you specify UNIX or WINDOWS line breaks?
I've seen this behavior in data originated in a UI where the entry method was free-form text with no edit-validation when written to the database. Any keystroke or combination is accepted as a "character" in the usual GIGO sense.
I would question the method by which the csv was created in the first place. I don't agree that citing Windows is enough to determine what's happening. Data is data, says this old dog, and the new tricks they give users just creates data headaches.
Franklin Evans
"Shared pain is lessened, shared joy increased. Thus do we refute entropy." -- Spider Robinson
I also agree, though if you look at the example, it seems that EmpID is the field that has the embedded carriage returns. One would think that a field such as that would not be free-form text, but you never know.
I would suggest getting with the provider of the file and having them clean it up, or you are probably going to have a fun time trying to clean it up on your own so you can load it. Since you say you are on UNIX, and this is a csv file, you could always run the file through a tr command to remove the carriage returns first. Personally, if the file was documented as being a CSV file, I'd make every attempt to have the provider of the file give you the file in proper format, but that's just me.
Please try the below for removing control-m and see if it helps.
1) dos2unix or
2) sed -e "s/^M//" filename > newfilename
To enter ^M, type CTRL-V, then CTRL-M. That is, hold down the CTRL key then press V and M in succession