Как получить скопированный текст из JavaScript - PullRequest
Новая
       15

Как получить скопированный текст из JavaScript

0 голосов
/ 03 ноября 2018

Этот вопрос связан с другим вопросом, который я задал , но я понял, что побочный вопрос в этом вопросе заслуживает своего собственного вопроса.

Используя JavaScript, я хотел бы посмотреть, что пользователи копируют с веб-страницы. Чтение содержимого буфера обмена довольно просто, когда пользователь вставляет : 

document.addEventListener("paste", e => {
  let text = e.clipboardData.getData("text");
  alert("pasting text: " + text);
});

Это правильно создает предупреждение с тем, что только что было вставлено. Однако получить данные из буфера обмена сложнее, когда пользователь копирует .

Метод 1 (не работает) 

document.addEventListener("copy", e => {
  let text = e.clipboardData.getData("text");
  alert("copying text: " + text);
});

Это предупреждает о «копировании данных», но без текста после него. Это потому, что метод getData возвращает "" (пустая строка). Насколько я понимаю, для сайтов будет считаться слишком большой проблемой безопасности читать ваш буфер обмена, когда вы делаете что-то кроме вставки.

Способ 2 (работает, но с всплывающим окном) 

document.addEventListener("copy", () => {
  navigator.clipboard.readText().then(text => alert("copied text: " + text));
});

Это работает, но перед предупреждением создает всплывающее окно с запросом разрешения для сайта на чтение буфера обмена. Я бы предпочел не иметь этого всплывающего окна.

Метод 3 (кажется, работает, но не кажется правильным) 

document.addEventListener("copy", () => {
  let text = window.getSelection().toString();
  alert("copying text: " + text);
});

Это похоже на то, что я хочу. Кажется странным, что это будет разрешено, но метод 1 - нет.

У меня есть пара вопросов:

  1. Почему метод 1 не разрешен, если метод 3 разрешен? Похоже, что метод 1 может предоставить ту же информацию, что и метод 3, и он будет более удобным и безопасным.
  2. Есть ли случаи, когда метод 3 давал бы результаты, отличные от метода 2 (с точки зрения переменной text, а не поведения всплывающего окна)?
  3. Существуют ли другие недостатки использования метода 3, которые я не рассматриваю?

На данный момент меня интересуют эти ответы только в контексте Google Chrome или Chromium, а не в других браузерах. Будем благодарны за ответы на любые из этих вопросов.

1 Ответ

0 голосов
/ 03 ноября 2018

tl; dr используйте метод 3, если вы действительно считаете, что не честность с пользователем в отношении того, что вы делаете, оправдана - это хороший обходной путь, хотя многие могут посчитать это подвигом.

Глядя на спецификацию W3 (https://www.w3.org/TR/clipboard-apis/#Cases)), мы можем понять, почему эти события (и все еще развивающийся API) существуют в первую очередь. В частности, copy для вас изменить то, что было скопировано в случае, если ваша цель не является тем, что пользователь на самом деле хотел бы получить в своем буфере обмена, в то время как paste существует, чтобы позволить вам обрабатывать передачу этих данных в ваше приложение.

Зная это, мы можем прийти к некоторым выводам:

  • Метод 1 : Спецификация не дает подробных сведений о безопасности буфера обмена, за исключением того, что предполагается, что реализации должны работать для защиты пользователей. Поэтому я не удивлен, что скопированные данные скрыты от вас; Это кажется разумным решением исполнителей. Более того, если посмотреть на алгоритмы, изложенные в спецификации, вполне возможно, что это еще не данные в буфере обмена, так как цель этого события - дать вам возможность установить, что должен в конечном итоге их.
  • Метод 2 : Это, кажется, гораздо больше замысла авторов. Если приложение собирается получить доступ к буферу обмена, оно должно действительно получить разрешение от пользователя. Тем более, что буфер обмена может содержать данные за пределами вашей страницы.
  • Метод 3 : Это эксплойт, но трудно увидеть случаи, когда он не работает. С точки зрения разработчика трудно блокировать, так как им придется проверять функции делегата события для вызовов; по сравнению с просто «не сделать данные легкодоступными». Это также, возможно, безопасно достаточно , так как единственная информация, к которой вы можете получить доступ, это информация, которая уже в вашем собственном документе .
...