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

发布于 2024-12-06 06:41:36 字数 2541 浏览 0 评论 0原文

当 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

<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 6d656e74 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 c3a96372 69742075 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>

这些原始数据与远程文件中包含的字节完全相同,因此不存在污染字节。

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

我还有另一种方法,那就是从这些原始数据构建一个 C 字符串,并使用 NSStringWithCString 之类的东西构建一个 NSString...但我认为这非常丑陋,我真的很想使用为此设计的 Cocoa API一个目的。我没有理由不能使用 Cocoa power 来完成这样的基本任务。

我完全错过了什么吗?

非常感谢, 弗朗茨

I have a very simple callback called when a HTTP request has just been completed through a NSURLConnection object (connectionDidFinishLoading). This code just turns raw 7-bit encoded data read from a remote file into a NSString.

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

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

The issue is that string is NIL. I then suspected a bad conversion due to the presence of bad bytes (>0x80) but all my bytes read are pure 7-bit encoded ASCII data:

(gdb) po mReceivedData

<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 6d656e74 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 c3a96372 69742075 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>

Those raw data are exactly the same as bytes contained into the remote file, so there are no polluting bytes.

I also tried to play with UTF-8 conversion but this is still the same issue.

I have another way of doing which would be to build a C string from those raw data and to build a NSString with something like NSStringWithCString... but I consider this is very ugly and I really would like to use the Cocoa API designed for such a purpose. There is no reason why I should not be able to use Cocoa power for such a basic task.

Do I totally miss something ?

Many thanks,
Franz

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

澉约 2024-12-13 06:41:36

尽管你坚持认为

此处显示的所有 7 位字节的值都

0x80

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

如果它确实是 7 位值(不是每个都以 8 位字节编码),那么该字符串不会

按照您的建议以#file

开头,而是

Yj-

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

所以看来您的文件不是 ascii 或没有作为 ascii 传输。不管怎样,你的问题在到达 Cocoa 之前就开始了。

Despite your insistance that

All 7-bit bytes shown here have values < 0x80

a quick glance shows bytes 0x99 0xa8 0xa9 0xc3 0xa0 0xe2 and more. So this isn't valid ascii encoded as 8bit bytes.

If it really is 7bit values (not each encoded in an 8bit byte) then the string doesn't start

#file

as you suggest, but

Yj-

Which i don't think is what you are expecting.

So it seems that your file isn't ascii or isn't being transmitted as ascii. Either way your problems start before it gets to Cocoa.

趴在窗边数星星i 2024-12-13 06:41:36

有时,gdb 不是你的朋友。

po 字符串不起作用并显示:

(gdb) po 字符串
无法访问变量“字符串”
无法打印 NIL 对象的描述。

但是如果我用

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

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

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

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

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

编辑:我最终将“运行”操作设置为调试而不是按产品发布 - >管理方案,gdb 可以正确显示调试信息。

Sometimes, gdb is not your friend.

po string does not work and says:

(gdb) po string
Unable to access variable "string"
Can't print the description of a NIL object.

But if I print it with

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

then it is properly printed and string contains the accented characters... and in fact the file is properly decoded when using the NSUTF8StringEncoding parameter:

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

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

Hard to believe that gdb can provide erronous information about string. I am only half satisfied of this explanation. I would like to understand why gdb provides such an information about string.

EDIT: I finally set the "Run" action to debug instead of release by Product -> Manage schemes and the debug information is properly displayed by gdb.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文