I should add, you are right in that it also says: n+1, 1 byte, 0x0D stored as the Field Descriptor terminator.
Everything from byte 68 on is then a multiple of 48 bytes, so I can simply check on each 67+(n*48)+1 to see if that byte is 0x0D, which is the marker position of which to follow Mike's advise on getting the subdata. Alex Am 22.12.2011 um 17:29 schrieb Ken Thomases: > On Dec 22, 2011, at 9:54 AM, Alexander Reichstadt wrote: > >> The DBF file format documentation says the header is in binary, then there >> is a linefeed (\r), then there is the body. Each field has a fixed length, >> wether used or not doesn't matter, the unused rest is filled with spaces. >> >> So, I read the file as data, stringily it as DOSLatin1, split it at the >> linefeed and read the body according to the field definitions I am given. >> They are guaranteed, so maybe some day I get around to writing a nice DBF >> parser, but until then I go by the guaranteed field lengths. >> >> I tested it now on a couple of files and it works without a hitch. > > If the header is binary, then any of its bytes might be 0x0D, which is the > same as \r (or did you actually mean it when you said "linefeed" which is > 0x0A or \n?), so your approach will fail. In all probability, the header is > a fixed length and you can just skip that part of the data. Either way, if > this is meant for more than a casual, one-off, in-house app, you'll have to > find a more reliable technique. > > Regards, > Ken > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
