I think we mean "loses". "Loose" means not tight.
Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Steve Christensen <puns...@mac.com> Sender: cocoa-dev-bounces+zav=mac....@lists.apple.com Date: Thu, 22 Dec 2011 13:06:32 To: Alexander Reichstadt<l...@mac.com> Cc: Cocoa-Dev List<Cocoa-dev@lists.apple.com> Subject: Re: NSString looses Umlaute And just to add in one more bit about why it's important to separate the text from the binary header, -initWithData:encoding: "[r]eturns nil if the initialization fails for some reason (for example if data does not represent valid data for encoding)." (That is from the NSString docs.) On Dec 22, 2011, at 9:30 AM, Alexander Reichstadt wrote: > 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/zav%40mac.com This email sent to z...@mac.com
_______________________________________________ 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
