我有一个文本文件的完整的记录,其中每个记录中每个字段是一个固定的宽度。 我的第一个方法是分析简单地使用string.Substring()每个记录。 有没有更好的办法?
例如,该格式可以被描述为:
<Field1(8)><Field2(16)><Field3(12)>
并举例具有两个记录可能看起来像文件:
SomeData0000000000123456SomeMoreData
Data2 0000000000555555MoreData
我只是想确保我不会比俯瞰子串更优雅的方式()。
更新:我最终与正则表达式去像Killersponge建议:
private readonly Regex reLot = new Regex(REGEX_LOT, RegexOptions.Compiled);
const string REGEX_LOT = "^(?<Field1>.{6})" +
"(?<Field2>.{16})" +
"(?<Field3>.{12})";
然后我用下面的访问字段:
Match match = reLot.Match(record);
string field1 = match.Groups["Field1"].Value;
子听起来不错。 唯一的缺点我能马上想到的是,这意味着每次复制数据,但我不会担心,直到你证明这是一个瓶颈。 子是简单的:)
你可以使用正则表达式的整个记录在一个时间匹配和捕获等领域,但我认为这将是矫枉过正。
使用FileHelpers 。
例:
[FixedLengthRecord()]
public class MyData
{
[FieldFixedLength(8)]
public string someData;
[FieldFixedLength(16)]
public int SomeNumber;
[FieldFixedLength(12)]
[FieldTrim(TrimMode.Right)]
public string someMoreData;
}
然后,它是这么简单:
var engine = new FileHelperEngine<MyData>();
// To Read Use:
var res = engine.ReadFile("FileIn.txt");
// To Write Use:
engine.WriteFile("FileOut.txt", res);
为什么要推倒重来? 使用.NET的TextFieldParser类按照该如何做的Visual Basic 。
您可能需要注意,如果行的末尾不使用空格填补该领域,你的子不会没有一点摆弄制定出更多的线路有如何读取的工作。 这当然只适用于最后一个字段:)
不幸的是开箱即用的CLR只提供子字符串这一点。
在有人在CodeProject使用属性来定义字段做了一个自定义的解析器 ,你可能想看看那个。
你可以设置为固定格式文件中的ODBC数据源,然后访问它像任何其他数据库表。 这有额外的好处,文件格式的特定知识不会被编译到您的代码为命中注定的那一天,有人决定要坚持在中间的额外字段。