csv文件示例_自己动手？ -一个简单的CSV解析器示例

csv文件示例

• Download source code - 2.7 MB

  下载源代码2.7 MB

目录 (Table of Contents)

• Introduction

  介绍

• • The Dataset

    数据集

  • The Class it Goes Into

    进入的班级

  • The Code

    代码

  • The AliasedProperty Method

    AliasedProperty方法

  • The Populate Method

    填充方法

  • Using the Parser

    使用解析器

  • Supporting Code

    支持代码

  Implementation Time!

  实施时间！

• Unit Tests

  单元测试

• F# Implementation Without Generic Class

  没有泛型类的F＃实现

• F# Implementation with SimpleCsvParser<'a>

  使用SimpleCsvParser <'a>的F＃实现

• Conclusion

  结论

• History

  历史

介绍 (Introduction)

I was having this conversation with a coworker about using a third-party library vs. rolling your own, specifically regarding parsing a comma separated value (CSV) data, or more generally, any text data separated by a known delimiter.

我正在与一位同事进行对话，讨论使用第三方库而不是滚动自己的库，特别是解析逗号分隔值(CSV)数据，或更一般而言，解析由已知定界符分隔的任何文本数据。

This subject has been pretty much beaten to death and there definitely are many libraries in every language under the sun to parse CSV files. My coworker brought this particular article to my attention: CSV Parsing in .NET Core which is a useful example (which I ignore here) of some edge cases -- certainly not all of them. The article references a couple projects, CsvHelper and TinyCsvParser and one can easily find several CSV parsers on Code Project:

这个主题已经被打死了，在阳光下肯定有很多使用每种语言的库都可以解析CSV文件。 我的同事引起了我这篇特别的文章： .NET Core中的CSV解析，这是一些极端情况的有用示例(在此我忽略)，当然不是全部。 本文引用了CsvHelper和TinyCsvParser两个项目，并且可以在Code Project上轻松找到几个CSV解析器：

• Light and Fast CSV Parser

  轻快的CSV解析器

• CSV File Parser (by #realJSOP!)

  CSV文件解析器 (通过#realJSOP！)

• Why to build your own CSV parser (or maybe not)

  为什么要建立自己的CSV解析器(或者可能不是)

That last link is quite comprehensive in parsers that Tomas Takac evaluated and has a great graph of the finite state machine to parse CSV data. Even more interesting (to me at least), he references RFC-4180 which documents Common Format and MIME Type for Comma-Separated Values (CSV) Files. Pretty cool.

最后一个链接在Tomas Takac评估的解析器中相当全面，并且具有用于解析CSV数据的有限状态机的图形。 更有趣的是(至少对我而言)，他引用了RFC-4180 ，该文件记录了逗号分隔值(CSV)文件的通用格式和MIME类型。 很酷

That said, having looked at a few myself and having some very basic requirements (really no edge cases), the question again came up as to whether to roll my own or use a library. Some of the discussion points were:

就是说，在看了几个我自己并且有一些非常基本的要求(真的没有极端情况)之后，再次提出了一个问题，就是要自己动手还是使用一个库。 一些讨论要点是：

• What if there's a bug in the roll-your-own code?
  如果您自己的代码有错误怎么办？
• What if it needs to be extended?
  如果需要扩展怎么办？
• What if the file specification changes?
  如果文件规格更改怎么办？

My answers here are biased of course, but they still might be of some value:

我在这里的答案当然是有偏见的，但它们可能仍然有价值：

What if there's a bug in the roll-your-own code?

如果您自己的代码有错误怎么办？

Well, given that the actual parser is 80 lines long (not including extension methods and helper functions), how hard is it to have bugs? And there's unit tests, which actually are 3x more lines of code! My first reaction to rolling my own is always a question to complexity: how complex is the problem to be solved, and how complex are the third party libraries out there that solve that problem? The fewer lines of code, the less bugs and the fewer unit tests one has to write. It cannot be guaranteed that a third-party library is bug free or has implemented decent unit tests. Granted, this is all rather moot for non-edge cases anyways. Still, looking at the code for some of these libraries, in which the implementation is in the thousands of lines of code, I really really can't justify adding that to my code base -- the npm install, nuget install, and so forth are so easy that they preclude any thinking about what you're about to do. This is really a dangerous situation, especially when packages have hidden dependencies and you're suddenly installing 10s or 100s of additional, breakable, dependencies.

好吧，考虑到实际的解析器长80行(不包括扩展方法和帮助器函数)，漏洞有多难？ 还有单元测试，实际上是多三倍的代码行！ 我对自己动手