Re: NSString looses Umlaute

On Dec 22, 2011, at 10:04 PM, Charles Srstka wrote: > On Dec 22, 2011, at 11: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 by

Re: NSString looses Umlaute

I second this. I had to write code to parse a DBF file as part of a suite to handle "shapefiles" (GIS) and it was really not a huge effort. These formats are designed to be pretty straightforward to parse. --Graham On 23/12/2011, at 3:04 PM, Charles Srstka wrote: > On Dec 22, 2011, at 11:30

Re: NSString looses Umlaute

On Dec 22, 2011, at 11: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 tha

Re: NSString looses Umlaute

I think we mean "loses". "Loose" means not tight. Sent from my Verizon Wireless BlackBerry -Original Message- From: Steve Christensen Sender: cocoa-dev-bounces+zav=mac@lists.apple.com Date: Thu, 22 Dec 2011 13:06:32 To: Alexander Reichstadt Cc: Cocoa-Dev List S

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 2

Re: NSString looses Umlaute

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

Re: NSString looses Umlaute

The header cannot be of a fixed length, as it contains the fields, their length and their types, which can vary. What it says there is: n above is the last byte in the field descriptor array. The size of the array depends on the number of fields in the table file. More on this here:

Re: NSString looses Umlaute

On 22 Dec 2011, at 15:54, Alexander Reichstadt wrote: > Thanks, but I have not tried. My thinking went along the lines of if I read > the string directly from the URL I have no control over what encoding is > being used for reading or it defaults to something. If I first read as data, > I can

Re: NSString looses Umlaute

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,

Re: NSString looses Umlaute

Thanks, but I have not tried. My thinking went along the lines of if I read the string directly from the URL I have no control over what encoding is being used for reading or it defaults to something. If I first read as data, I can do with those bytes as I please. The DBF file is not in one con

Re: NSString looses Umlaute

On 22 Dec 2011, at 09:59, Alexander Reichstadt wrote: > Thanks, it works. The following solved the problem, where theChoice is a URL > to a local file from an NSOpenPanel: > >NSData *theData = [NSData dataWithContentsOfURL:theChoice]; >NSString *theContent = [[NSString alloc] in

Re: NSString looses Umlaute

Thanks, it works. The following solved the problem, where theChoice is a URL to a local file from an NSOpenPanel: NSData *theData = [NSData dataWithContentsOfURL:theChoice]; NSString *theContent = [[NSString alloc] initWithData:theData encoding: CF

Re: NSString looses Umlaute

Le 22 déc. 2011 à 10:42, Alexander Reichstadt a écrit : > OK, I found a way to import it into FileMaker. It looks good when I use DOS > Encoding. But when I use kCFStringEncoding derivates I had no luck. I know CF > and NSString is toll free bridged, but does this apply to the encodings as > w

Re: NSString looses Umlaute

On Thu, Dec 22, 2011 at 1:42 AM, Alexander Reichstadt wrote: > OK, I found a way to import it into FileMaker. It looks good when I use DOS > Encoding. But when I use kCFStringEncoding derivates I had no luck. I know CF > and NSString is toll free bridged, but does this apply to the encodings as

Re: NSString looses Umlaute

> OK, I found a way to import it into FileMaker. It looks good when I use DOS > Encoding. But when I use kCFStringEncoding derivates I had no luck. I know CF > and NSString is toll free bridged, but does this apply to the encodings as > well? There is some post from 2000 by Ali Ozer that would s

Re: NSString looses Umlaute

OK, I found a way to import it into FileMaker. It looks good when I use DOS Encoding. But when I use kCFStringEncoding derivates I had no luck. I know CF and NSString is toll free bridged, but does this apply to the encodings as well? There is some post from 2000 by Ali Ozer that would suggest i

Re: NSString looses Umlaute

On 21 dec 2011, at 16:45, Alexander Reichstadt wrote: > NSString eats the Umlaute. How do I tell NSString to not do that? If you provide the correct encoding when creating a NSString from an external representation, all will be well. If you don't, then you'll end up with the type of issues th

Re: NSString looses Umlaute

> Yes, tried NSUTF8StringEncoding, I really tried all the ones I found in the > NSString encoding documentation. > > When I import this file as DBF into FileMaker Pro it looks just as bad. But > when I import it into a MySql it works fine. > > Here an example of what NSLog says: > > "R\U00

Re: NSString looses Umlaute

Yes, tried NSUTF8StringEncoding, I really tried all the ones I found in the NSString encoding documentation. When I import this file as DBF into FileMaker Pro it looks just as bad. But when I import it into a MySql it works fine. Here an example of what NSLog says: "R\U0094h.", "R\U009

Re: NSString looses Umlaute

Le 22 déc. 2011 à 09:13, Alexander Reichstadt a écrit : > Yes, you are right, but it does not make a difference, I tried all encodings. Did you try UTF-8 encoding? Besides, if you open your file with an external application, e.g. OpenOffice or TextWrangler, what happens? Vincent

Re: NSString looses Umlaute

Yes, you are right, but it does not make a difference, I tried all encodings. This is a DBF file. From the DBF file format description the header is binary and the rest is ASCII. I found an older post from someone with French special chars that went lost: http://stackoverflow.com/questions/49134

Re: NSString looses Umlaute

On 21 Dec 2011, at 4:45 pm, Alexander Reichstadt wrote: > NSString *theContent = [[NSString alloc] initWithData:theData > encoding:NSASCIIStringEncoding]; >theContent = [[theContent componentsSeparatedByString:@"\r"] > objectAtIndex:1]; >theContent = [theContent > stringB