# Re: Advice on handling malformed CSV with FasterCSV

**URL:** <https://www.ruby-forum.com/t/re-advice-on-handling-malformed-csv-with-fastercsv/79769>\
**Category:** Ruby\
**Created:** [December 18, 2006, 10:00pm UTC](https://www.ruby-forum.com/t/re-advice-on-handling-malformed-csv-with-fastercsv/79769 "2006-12-18T22:00:32Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![phrogz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/2acd7d/32.png) [@phrogz](https://www.ruby-forum.com/u/phrogz)\
**Post date:** [December 18, 2006, 10:00pm UTC](https://www.ruby-forum.com/t/re-advice-on-handling-malformed-csv-with-fastercsv/79769/1 "2006-12-18T22:00:32Z")

</div>

From: Wes G.

> 1. Is there a way to get FasterCSV to accept input like the  
> above? How can I set up a custom parsing scheme?

I don’t know the answer to this question.

> 1. Should I modify the FasterCSV parser directly to accept  
> this sort of input?

I would personally say no. Keep the core library powerful and  
streamlined; don’t ‘fix’ it to accept crazy data.

> 1. Should I pre-process the file to eliminate/modify these sorts of  
> cases to improve the likelihood of a successful FasterCSV parse?

That’s what I would suggest. It gives you the power to decide how you  
want to handle it. If your input data is:  
“data”,'otherdata",moredata  
then I think you’d much prefer to decide how to clean that up (to match  
your legacy system, perhaps) rather than hoping that someone put code in  
the library that handles it the same way.