(这个问题已经在NSTextView
进行了一些进一步的研究后被重写了)
更新:您可以下载一个显示问题的基本项目:
http://w3style.co.uk/~d11wtq/DocumentApp.tar.gz
(对您保存的文件执行grep -c "\r" file.txt
以获取\r
出现的行数...重复\n
)。
我已经意识到NSDocument
创建的所有文件都有\r
是行结尾,而不是标准\n
,即使我的文档子类返回的NSData
不包含\r
,它只包含\n
。有没有办法配置它?
我认为Macs最近使用了UNIX行结尾,所以AppKit仍在使用过时的Mac结尾似乎很奇怪。 Weirder是NSDocument
要求NSData
,然后通过改变行结尾而不客气地破坏NSData
。
在生成\r
之后,切换到NSData
正在发生,因此NSDocument
本身正在对字节进行一些替换:
const char *bytes = [data bytes];
int i, len;
for (i = 0, len = [data length]; i < len; ++i) {
NSLog(@"byte %d = %02x", i, bytes[i]);
}
输出(注意0a是\n
的十六进制值):
> 2010-12-17 12:45:59.076
> MojiBaker[74929:a0f] byte 0 = 66
> 2010-12-17 12:45:59.076
> MojiBaker[74929:a0f] byte 1 = 6f
> 2010-12-17 12:45:59.076
> MojiBaker[74929:a0f] byte 2 = 6f
> 2010-12-17 12:45:59.077
> MojiBaker[74929:a0f] byte 3 = 0a
> 2010-12-17 12:45:59.077
> MojiBaker[74929:a0f] byte 4 = 62
> 2010-12-17 12:45:59.077
> MojiBaker[74929:a0f] byte 5 = 61
> 2010-12-17 12:45:59.077
> MojiBaker[74929:a0f] byte 6 = 72
> 2010-12-17 12:45:59.077
> MojiBaker[74929:a0f] byte 7 = 0a
如果NSDocument
要求NSData
,那么它应该尊重它而不是修改它。
以下是方法中的完整代码:我的文档中的-dataOfType:error:
方法:
-(NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError {
NSString *string = [textView string];
// DEBUG CODE...
NSArray *unixLines = [string componentsSeparatedByString:@"\n"];
NSArray *windowsLines = [string componentsSeparatedByString:@"\r\n"];
NSArray *macLines = [string componentsSeparatedByString:@"\r"];
NSLog(@"TextView has %d LF, %d CRLF, %d CR", [unixLines count] - 1, [windowsLines count] - 1, [macLines count] - 1);
NSData *data = [NSData dataWithBytes:[string cStringUsingEncoding:NSUTF8StringEncoding]
length:[string lengthOfBytesUsingEncoding:NSUTF8StringEncoding]];
const char *bytes = [data bytes];
int i, len;
for (i = 0, len = [data length]; i < len; ++i) {
NSLog(@"byte %d = %02x", i, bytes[i]);
}
if (data != nil) {
[textView breakUndoCoalescing];
}
return data;
}
答案 0 :(得分:1)
NSDocument不关心线路终端;它是一个半抽象类,设计为子类。它本身并没有对文件格式施加任何限制。
这是NSDocument子类的特定实现 - 一个恰好读写纯文本的子类 - 它将关注行终止字符。