Hinweis: diese Antwort zwischen dem OP entwickelt und Rob W. es hier in der Hoffnung platzieren, die Diese Frage könnte für andere nützlich sein, ohne die oben erwähnte Kommentarkette zu durchforsten.
Es gibt zwei Probleme. Erstens, a userscript header does not parse if a UTF8 BOM is present (Chromium bug 102667).
Zweitens, wenn in einem Userscript @include versus @match verwendet wird, meldet Chrome fälschlicherweise, dass das Skript "Zugriff auf Ihre Daten auf allen Websites", aber das stimmt nicht wirklich. Das Skript wird nur auf den Websites ausgeführt, die durch die Include-Anweisung (en) angegeben werden.
Betrachten wir (oder machen) diese drei Skripte:
UTF-Test, nicht UTF.user.js (mit ANSI-Codierung speichern):
// ==UserScript==
// @name Not UTF source file
// @match http://www.yahoo.com/*
// ==/UserScript==
if (location.hostname != 'www.yahoo.com')
alert ("This script should not run on "+location.hostname+"!");
UTF-Test , ist UTF.user.js (speichern mit UTF-8-Codierung, einschließlich der Stückliste):
// ==UserScript==
// @name Is UTF source file
// @match http://www.yahoo.com/*
// ==/UserScript==
if (location.hostname != 'www.yahoo.com')
alert ("This script should not run on "+location.hostname+"!");
einschließen, nicht match.user.js (mit ANSI-Codierung speichern):
// ==UserScript==
// @name Use include, not match
// @include http://www.yahoo.com/*
// ==/UserScript==
if (location.hostname != 'www.yahoo.com')
alert ("This script should not run on "+location.hostname+"!");
Beachten Sie, dass alle drei Skripte den gleichen Code sind. Nur die @name und/oder das Dateiformat und/oder @include gegenüber @match sind unterschiedlich.
Der ANSI-Skript, mit Spiel (UTF-Test, nicht UTF.user.js) meldet diese Berechtigungen:
Dieses Skript arbeitet und Berichte korrekt und wie erwartet.
Das UTF-8-Skript mit Übereinstimmung (UTF-Test, ist UTF.user.js) meldet diese Berechtigungen:
Die Berechtigungen falsch gemeldet werden, im Widerspruch zur @match Aussage (n). Beachten Sie auch, dass der Dateiname URL-codiert anstelle der @name-Direktive angezeigt wird. Dies sind beide Hinweise, dass etwas nicht stimmt.
Schlimmer, dieses Skript wird auf allen Websites funktionieren. Das heißt, Sie werden die alert() auf allen Nicht-Yahoo-Seiten sehen. Dies ist eindeutig a bug.
Der ANSI-Skript, mit umfasst (einschließen, nicht match.user.js) meldet diese Berechtigungen:
Zwar ist dies ein irreführender Bericht ist, wird das Skript arbeitet tatsächlich richtig. Das heißt, es wird nur für Yahoo Seiten ausgelöst.
Dies ist teilweise darauf zurückzuführen, wie Chrome Benutzerreferenzen automatisch in Erweiterungen konvertiert. @match Aussagen werden direkt in die manifest.jsonmatches Eigenschaft übersetzt, während @include Aussagen in include_globs Werte gemacht werden. Siehe Match patterns and globs. Die Berechtigungen melden Schlüssel aus dem Array matches.
Versuchen Sie eine zip/crx-Datei oder eine '.user.js'-Datei zu installieren? –
Ich habe Userscript gesagt, also ist es .user.js – Leadri
Chrome konvertiert Benutzer-Scripts in native Chrome-Erweiterungen mit einem Übereinstimmungsmuster, das "" entspricht, und beschränkt dann die Seiten über "include_globs" '. Mach dir keine Sorgen über die Warnung, es verhält sich so, wie du es erwartest. Wenn Sie eine weniger beängstigende Warnung erhalten möchten, müssen Sie eine Chrome-Erweiterung aus Ihrem Benutzerskript erstellen und den Teil "content_scripts" der Datei "manifest.json" bearbeiten. Siehe [diese Antwort] (http://stackoverflow.com/questions/11772308/keep-same-id-when-converting-from-userscript-in-chrome/11773654#11773654) für die Schritte zum Generieren einer Chrome-Erweiterung von a Benutzerskript –