Question

当一个HTTP请求刚刚通过NSURLConnection对象（connectionDidFinishLoading）完成时，我调用了一个非常简单的回调函数。此代码只是将从远程文件读取的原始7位编码数据转换为NSString。

- (void)connectionDidFinishLoading:(NSURLConnection *)connection{
NSString *string = [[NSString alloc] initWithData:mReceivedData encoding:NSASCIIStringEncoding];

NSLog(@"string = %@", string);
}

问题是字符串是NIL。然后我怀疑由于存在坏字节（> 0x80）导致转换不良，但我读取的所有字节都是纯7位编码的ASCII数据：

(gdb) po mReceivedData

＆LT; 2366696c 65566572 73696f6e 0a310a23 66696c65 54797065 0a626964 4465660a 23657865 72636973 654c6576 656c0a31 0a23636f 6c756d6e 54657874 0a537564 2f4f7565 73742f4e 6f72642f 4573740a 23636f6c 756d6e43 6f6c6f72 0a677265 656e2f72 65642f67 7265656e 2f726564 0a236269 6456616c 7565730a 2a2f3144 2f582f2d 0a3f2f2a 2f2a2f2a 0a2a2f2a 2f2a2f2a 0a2a2f2a 2f2a2f2a 0a236164 76696365 4c696e65 310a5370 6f75746e 696b2028 52c3a970 6f6e6461 6e740a23 61647669 63654c69 6e65320a 617072c3 a8732069 6e746572 76656e74 696f6e0a 2368616e 64436172 64730a4a 2f392f36 2f350a38 2f350a41 2f580a4b 2f372f36 2f332f32 0a237363 6f726547 7269640a 32532f31 300a3343 2f360a31 532f330a 32432f30 0a23616e 73776572 436f6d6d 656e7473 0a32532f 4f75693a 20646520 3820c3a0 20313020 706f696e 74732065 74203420 63617274 657320c3 a020532e 0a33432f 5072696f 726974c3 a920c3a0 206c6120 6d6f7965 6e6e652e 0a31532f 436f6d6d 65206176 6563207a c3a9726f 20706f69 6e74203f 0a32432f 4168206e 6f6e2021 0a236d61 696e436f 6d6d656e 740a4c65 20636f6d 6d6 56e74 61697265 20646520 4d696368 656c2042 65737369 732e0a0a 456e2072 c3a9706f 6e736520 61752063 6f6e7472 652064e2 80996170 70656c2c 20696c20 66617574 20646f6e 6e657220 6c652070 6c65696e 20646520 7361206d 61696e2e 20416e6e 6f6e6365 72203153 206d6f6e 74726572 61697420 64652030 20c3a020 3720706f 696e7473 202872c3 a9706f6e 73652066 6f7263c3 a965292e 0a0a4963 692c2069 6c206661 75742073 61757465 7220c3a0 2032532c 20656e63 68c3a872 65207175 69206e65 2070726f 6d657420 70617320 63696e71 20636172 74657320 65742071 75692064 69742075 c3a96372 6e206a65 75206465 203820c3 a0203130 20706f69 6e747320 482028c3 a0207061 72746972 20646520 31312070 6f696e74 732c2063 e2809965 73742075 6e206375 652d6269 64206f75 20756e20 73617574 20c3a020 6c61206d 616e6368 65207175 69207365 72612063 686f6973 69292e＆GT;

这些原始数据与远程文件中包含的字节完全相同，因此没有污染字节。

我也尝试过使用UTF-8转换，但这仍然是同样的问题。

我有另一种做法，就是从那些原始数据构建一个C字符串，并用NSStringWithCString构建一个NSString ......但我认为这非常难看，我真的很想使用Cocoa API为此目的而设计。我没有理由不能将Cocoa力量用于这样一项基本任务。

我完全错过了什么吗？

非常感谢，弗朗兹

Answer 1

尽管你坚持

此处显示的所有7位字节的值均为＆lt; 0x80的

快速浏览显示字节0x99 0xa8 0xa9 0xc3 0xa0 0xe2等等。所以这是无效的ascii编码为8位字节。

如果它确实是7位值（不是每个都以8位字节编码）那么字符串不会启动

<强> #FILE

正如你的建议，但是

<强> YJ -

我不认为这是你所期待的。

因此，您的文件似乎不是ascii或不是ascii传输。无论哪种方式，你的问题在它到达Cocoa之前就开始了。

Answer 2

有时，gdb不是你的朋友。

po字符串不起作用并说：

（gdb）po string 无法访问变量“string” 无法打印NIL对象的描述。

但如果我用

打印它

NSLog（@“string =％@”，string）;

然后它被正确打印并且字符串包含重音字符...实际上，当使用NSUTF8StringEncoding参数时文件被正确解码：

NSString *string = [[NSString alloc] initWithData:mReceivedData encoding:NSUTF8StringEncoding];

NSLog(@"string = %@", string);

很难相信gdb可以提供有关字符串的错误信息。我对这个解释只有一半的满意。我想了解为什么gdb提供有关字符串的信息。

编辑：我最后将“运行”操作设置为调试而不是按产品发布 - ＆gt;管理方案和调试信息由gdb正确显示。

使用NSString initWithData构建字符串的iOS / Cocoa / Data解释让我发疯

2 个答案: