下面给出一个小示例，在运行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源代码中跟踪转换发生的位置。。。并更新此答案。）