为什么 NSLog 有时会为 ucode 字符打印八进制? [英] Why does NSLog sometimes print out octal for ucode characters?

问题描述

我在普通 iPad 单视图应用的 viewDidLoad 函数中运行以下代码:

I'm running the following code in the viewDidLoad function of a vanilla iPad single view app:

/*
 *  Print the string.  A lot.
 */
for (int i = 0; i < 300; i++) {
    NSLog(@"%d\n", i);
    NSLog(@"⊢ ⊣ ⊥ ⊻ ⊼ ⊂ ⊃ ⊑ ⊒ \n");
}

输出如下:

2013-02-04 20:17:49.718 testplay[59585:c07] 228
2013-02-04 20:17:49.718 testplay[59585:c07] ⊢ ⊣ ⊥ ⊻ ⊼ ⊂ ⊃ ⊑ ⊒ 
2013-02-04 20:17:49.719 testplay[59585:c07] 229
2013-02-04 20:17:49.719 testplay[59585:c07] ⊢ ⊣ ⊥ ⊻ ⊼ ⊂ ⊃ ⊑ ⊒ 
2013-02-04 20:17:49.719 testplay[59585:c07] 230
2013-02-04 20:17:49.720 testplay[59585:c07] ⊢ ⊣ ⊥ ⊻ ⊼ ⊂ ⊃ ⊑ ⊒ 
2013-02-04 20:17:49.720 testplay[59585:c07] 231
2013-02-04 20:17:49.720 testplay[59585:c07] ⊢ ⊣ ⊥ ⊻ ⊼ ⊂ ⊃ \342\212\221 ⊒ 
2013-02-04 20:17:49.723 testplay[59585:c07] 232
2013-02-04 20:17:49.724 testplay[59585:c07] ⊢ ⊣ ⊥ ⊻ ⊼ ⊂ ⊃ ⊑ ⊒ 

八进制几乎总是发生在同一个字符上，每次运行大约随机出现 3 次打嗝.

The octal happens almost always on the same character and the hiccup occurs randomly about 3 times per run.

虽然它在 NSLog() 中相对无害，但它意味着 unicode 字符可能在某种程度上被不规则地处理.如果有这种行为的历史记录或我可以查看的某些资源，那就太好了.

While it's relatively harmless in NSLog(), it implies that unicode characters may be dealt with irregularly at some level. If there's a history to this behavior or some resource I could be looking at that would be great.

[附录:删除了我如何遇到这个问题的参考.了解 NSLog 为什么以及如何读取 unicode 字符是我的希望.]

[addendum: Removed reference to how I came across this problem. Understanding why and how NSLog gets a corrupted read of a unicode character is my hope here.]

推荐答案

简短版本:

我认为如果 NSLog() 输出的 UTF-8 序列恰好落在缓冲区的边界上，就会发生这种情况Xcode 用于调试进程的标准错误的伪终端.

I think this happens if a UTF-8 sequence of an NSLog() output happens to fall on the boundary of the buffer of the pseudo-terminal that Xcode uses for standard error of the debugged process.

如果我的假设是正确的，这只是 Xcode 调试器输出的问题，并不意味着应用程序中存在任何 Unicode 问题.

If my assumption is correct, this is only a problem of the Xcode debugger output and does not imply any Unicode problems in the application.

长版:

如果您在模拟器中运行您的应用程序，lsof -p <pid_of_simulated_app> 显示标准错误(文件描述符 2)被重定向到一个伪终端:

If you run your app in the simulator, lsof -p <pid_of_simulated_app> shows that the standard error (file descriptor 2) is redirected to a pseudo-terminal:

# lsof -p 3251
...
testplay 3251 martin    2w     CHR               16,2     0t131     905 /dev/ttys002
...

并且 lsof -p 显示 Xcode 具有相同的伪终端打开:

And lsof -p <pid_of_Xcode> shows that Xcode has the same pseudo-terminal open:

# lsof -p 3202
...
Xcode   3202 martin   51u     CHR               16,2       0t0     905 /dev/ttys002
...

NSLog() 写入标准错误.使用系统调用跟踪器dtruss"可以看到Xcode 从伪终端读取日志消息.对于单个日志消息

NSLog() writes to standard error. With the system call tracer "dtruss" one can see that Xcode reads the log message from the pseudo-terminal. For a single log message

NSLog(@"⊢ ⊣ ⊥ ⊻ ⊼ ⊂ ⊃ ⊑ ⊒ \n");

看起来像这样:

# dtruss -n Xcode -t read_nocancel
 3202/0xe101:  read_nocancel(0x31, "2013-02-05 08:57:44.744 testplay[3251:11303] \342\212\242 \342\212\243 ... \342\212\222 \n\0", 0x8000)       = 82 0

但是对于很多 NSLog() 语句快速地相互跟随，有时会发生以下情况:

But for many NSLog() statements following each other rapidly, sometimes the following happens:

# dtruss -n Xcode -t read_nocancel
...
 3202/0xd828:  read_nocancel(0x33, "2013-02-05 08:39:51.156 ...", 0x8000) = 1024 0
 3202/0xd87b:  read_nocancel(0x33, "\212\273 \342\212\274 ...", 0x8000) = 24 0

可以看到，Xcode已经从伪终端读取了1024个字节，接下来读取以不完整的 UTF-8 序列开头.在这种情况下，Xcode没有看到"第一次读取的最后一个字节和第二次读取的前两个字节是相同的 UTF-8 序列.我假设 Xcode 将所有 3 个字节视为无效的 UTF-8 序列并将它们打印为八进制数.

As you can see, Xcode has read 1024 bytes from the pseudo-terminal, and the next read starts with an incomplete UTF-8 sequence. In this case, Xcode "does not see" that the last byte of the first read and the first two bytes of the second read are parts of the same UTF-8 sequence. I assume that Xcode treats all 3 bytes as invalid UTF-8 sequences and prints them as octal numbers.

这篇关于为什么 NSLog 有时会为 ucode 字符打印八进制?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！