下面给出一个小示例,在运行java 1.8的windows 10计算机上将字符串复制到剪贴板:
String copyMe = "abc\ndef\nghi\n";
Clipboard clipboard = Toolkit.getDefaultToolkit().getSystemClipboard();
clipboard.setContents(new StringSelection(copyMe), null);
看起来是这样的:
这个 \n
这是一个包含ascii码的换行符 0xA
在某个点上似乎转换为\r\n(其中\r是包含ascii码的回车符) 0xD
).
因此,在复制到notepad++时查看结果:
如果我使用像free clipboard viewer这样的工具,我会看到类似的结果:
我不知道问题出在哪里。
我能用这个复制字符串吗 \n
在没有任何干预的情况下从上面上传到剪贴板?
更新1
正在调试java的内部。。。 WClipboard
似乎找到了反编译的.class文件的第41行: byte[] var6 = WDataTransferer.getInstance().translateTransferable(var1, var5, var4);
其中var6包含:
因此,在这一点上,它看起来像 \r\n
准备就绪。
1条答案
按热度按时间q9rjltbz1#
我认为这里没有错。您正在将文本复制到windows剪贴板。windows使用
CR
+LF
作为其行分隔符序列。对我来说,当文本被复制到剪贴板时,它会获得windows风格的行分隔符,这并不奇怪。现在,你问这是在哪里发生的。
我认为这发生在java方面,尽管我的证据是间接的。考虑以下针对atom文本编辑器的bug报告。
-- https://github.com/atom/atom/issues/8365
注意,当atom使用unix样式的行终止符将文本复制到windows剪贴板时,行终止符不会被转换。这意味着(对我来说)转换不会发生在windows端(如果是的话,那么atom就不会有问题了。)所以如果不是在windows端发生的,那么对于您的示例来说,它一定是在java端发生的。
但是这个bug报告告诉我们的另一件事是,大多数人认为在将文本复制到剪贴板时,转换为窗口行终止符是一种自然而可取的行为。
有鉴于此,我认为是你的期望是不正确的,而不是默认的行为。
(我将查看是否可以在openjdk源代码中跟踪转换发生的位置。。。并更新此答案。)