nodejs npm package.json Chinesisch document

Einführung

Dieses Dokument enthält alle notwendigen Konfigurationen in package.json. Es muss ein echter JSON sein, kein JS-Objekt.

Ein Großteil des in diesem Dokument beschriebenen Verhaltens wird durch npm-config(7) beeinflusst.

Standardwert

npm legt einige Standardwerte basierend auf dem Paketinhalt fest.

Code kopieren Der Code lautet wie folgt:

"scripts": {"start": "node server .js" }
Wenn sich im Stammverzeichnis des Pakets eine server.js-Datei befindet, setzt npm den Startbefehl standardmäßig auf node server.js.

"scripts":{"preinstall": "node-waf clean || true; node-waf configure build"🎜> Wenn sich im Stammverzeichnis des Pakets eine Wscript-Datei befindet, kompiliert npm den Vorinstallationsbefehl standardmäßig mit node-waf.

"scripts":{"preinstall": "node-gyp rebuild"🎜> Wenn sich im Stammverzeichnis des Pakets eine binding.gyp-Datei befindet, kompiliert npm den Vorinstallationsbefehl standardmäßig mit node-gyp.

„Mitwirkende“: [...]

Wenn sich im Stammverzeichnis des Pakets eine AUTHORS-Datei befindet, verarbeitet npm diese standardmäßig zeilenweise im Format Name

Name

Die wichtigsten Felder in package.json sind die Felder „Name“ und „Version“. Sie sind alle erforderlich und können ohne sie nicht installiert werden. Der aus Name und Version zusammengesetzte Bezeichner wird als eindeutig angenommen. Wenn Sie das Paket ändern, ändert sich auch die Version.

Name ist der Name dieser Sache. Hinweis:

1. Geben Sie weder node noch js in den Namen ein. Da Sie package.json geschrieben haben, wird davon ausgegangen, dass es sich um js handelt, Sie können jedoch eine Engine mithilfe des Felds „engine“ angeben (siehe unten).

2. Dieser Name wird als Teil der URL, des Befehlszeilenparameters oder des Ordnernamens verwendet. Nicht URL-sichere Zeichen sind nicht zulässig.

3. Dieser Name kann als Parameter an require() übergeben werden, daher sollte er kurz, aber auch klar in der Bedeutung sein.
4. Bevor Sie sich in Ihren Namen verlieben, sollten Sie in der npm-Registrierung nachsehen, ob der Name bereits verwendet wird. http://registry.npmjs.org/

Version

Die wichtigsten Felder in package.json sind die Namens- und Versionsfelder. Sie sind alle erforderlich und können ohne sie nicht installiert werden. Der aus Name und Version zusammengesetzte Bezeichner wird als eindeutig angenommen. Wenn Sie das Paket ändern, ändert sich auch die Version.

Version muss durch Node-Semver analysierbar sein, was in npm-Abhängigkeiten enthalten ist. (Wenn Sie es selbst verwenden möchten, können Sie npm install semver ausführen)

Für verfügbare „Zahlen“ oder „Bereiche“ siehe Abschnitt (7).

Beschreibung

Setzen Sie Einleitung und Zeichenfolge ein. Für Verlierer ist es praktisch, in der NPM-Suche zu suchen.

Schlüsselwörter

Schlüsselwörter, Arrays, Strings. Für Verlierer ist es auch praktisch, in der NPM-Suche zu suchen.

Homepage

Die URL der offiziellen Website des Projekts.

Hinweis: Dies ist nicht dasselbe wie „URL“. Wenn Sie ein „URL“-Feld eingeben, geht die Registrierung davon aus, dass es sich um einen Sprung zu der Adresse handelt, die Sie an anderer Stelle veröffentlicht haben, und fordert Sie dann auf, sich zu verirren.

Ja, fick mich, kein Scherz.

Fehler

Die URL und/oder E-Mail-Adresse des Einreichungsproblems Ihres Projekts. Dies ist hilfreich für Diaosi, die Probleme haben.

Es sieht so aus:

Code kopieren Der Code lautet wie folgt:

{ "url" : "http://github.com/owner/project/issues"

, „email“ : „project@hostname.com“

}

Sie können ein oder zwei angeben. Wenn Sie nur eine URL angeben möchten, ist kein Objekt erforderlich, sondern nur eine Zeichenfolge.

Wenn die URL angegeben wird, wird sie vom Befehl npm bugs verwendet.

Lizenz

Sie sollten eine Lizenz angeben, damit die Leute die Rechte und Einschränkungen der Nutzung kennen.

Am einfachsten ist es, wenn Sie eine allgemeine Lizenz wie BSD oder MIT verwenden, Sie müssen nur einen Lizenznamen angeben, etwa so:

Code kopieren Der Code lautet wie folgt:

{ "license" : "BSD" }

Wenn Sie komplexere Lizenzbedingungen haben oder weitere Details angeben möchten, können Sie dies tun: 

Code kopieren Der Code lautet wie folgt:

„Lizenzen“: [

{ "type" : "MyLicense"
, „url“: „http://github.com/owner/project/path/to/license“
}
]

Es empfiehlt sich auch, eine Lizenzdatei im Stammverzeichnis bereitzustellen.

Personenfelder: Autor, Mitwirkende

Der Autor ist eine Person. Mitwirkende sind eine Reihe von Menschen. Person ist ein Objekt mit einem Namensfeld, optionalen URL- und E-Mail-Feldern, etwa so:

Code kopieren Der Code lautet wie folgt:

{ „name“ : „Barney Rubble“

, „E-Mail“: „b@rubble.com“

, „url“: „http://barnyrubble.tumblr.com/“

}

Oder Sie können alles in einen String packen und npm analysiert es für Sie:

Code kopieren Der Code lautet wie folgt:

„Barney Rubble (http://barnyrubble.tumblr.com/)

E-Mail und URL sind in beiden Formen optional.

Sie können in Ihren npm-Benutzerinformationen auch ein Feld für Betreuer der obersten Ebene festlegen.

Dateien

Dateien ist ein Array, das die Dateien im Projekt enthält. Wenn ein Ordner benannt wird, werden auch die darin enthaltenen Dateien einbezogen. (sofern nicht durch andere Bedingungen ignoriert)

Sie können auch eine .npmignore-Datei bereitstellen, damit Dateien auch dann erhalten bleiben, wenn sie im Dateifeld enthalten sind. Tatsächlich ist es genau wie .gitignore.

Haupt

Das Hauptfeld ist eine Modul-ID, die auf das Hauptprojekt Ihres Programms verweist. Das heißt, wenn der Name Ihres Pakets foo lautet und der Benutzer es installiert und dann require("foo"), dann wird das Exportobjekt Ihres Hauptmoduls zurückgegeben.

Dies sollte eine Modul-ID relativ zum Stammverzeichnis sein.

Für die meisten Module macht es absolut Sinn und nichts anderes.

Mülleimer

Viele Pakete verfügen über eine oder mehrere ausführbare Dateien, die im PATH abgelegt werden sollen. Mit npm muss sich Mama keine Sorgen mehr machen (tatsächlich ist es diese Funktion, die npm ausführbar macht).

Um diese Funktion zu nutzen, geben Sie dem bin-Feld in package.json eine Zuordnung vom Befehlsnamen zum Dateispeicherort. Während der Initialisierung verknüpft npm es mit prefix/bin (globale Initialisierung) oder ./node_modules/.bin/ (lokale Initialisierung).

Zum Beispiel hat npm:

Code kopieren Der Code lautet wie folgt:

{ "bin" : { "npm" : "./cli.js" } }

Wenn Sie also npm initialisieren, wird ein symbolischer Link zum cli.js-Skript in /usr/local/bin/npm erstellt.

Wenn Sie nur eine ausführbare Datei mit demselben Namen wie der Paketname haben. Dann können Sie einfach eine Zeichenfolge verwenden, z. B.:

Code kopieren Der Code lautet wie folgt:

{ "name": "mein-programm"

, „Version“: „1.2.5“

, „bin“: „./path/to/program“ }

Das Ergebnis ist das gleiche wie dieses:

Code kopieren Der Code lautet wie folgt:

{ "name": "mein-programm"

, „Version“: „1.2.5“

, "bin" : { "my-program" : "./path/to/program" } 🎜>

Mann

Geben Sie eine einzelne Datei oder ein Array von Dateien zur Verwendung durch das Man-Programm an.

Wenn nur eine einzelne Datei bereitgestellt wird, ist sie das Ergebnis von man nach der Initialisierung, unabhängig vom tatsächlichen Dateinamen, wie zum Beispiel:

Code kopieren Der Code lautet wie folgt:

{ "name" : "foo"

, „Version“: „1.2.3“

, „description“: „Ein verpackter Foo-Fooer zum Fooing von Foos“

, „main“ : „foo.js“

, „man“ : „./man/doc.1“

}

Auf diese Weise kann man foo die Datei ./man/doc.1 verwenden.

Wenn der Dateiname nicht mit dem Paketnamen beginnt, wird ihm Folgendes vorangestellt:

Code kopieren Der Code lautet wie folgt:

{ "name" : "foo"
, „Version“: „1.2.3“
, „description“: „Ein verpackter Foo-Fooer zum Fooing von Foos“
, „main“ : „foo.js“
, „man“ : [ „./man/foo.1“, „./man/bar.1“ ]
}

Es werden Dateien für man foo und man foo-bar erstellt.

Die Man-Datei muss mit einer Zahl enden und dann optional mit einem .gz-Suffix komprimiert werden. Die Nummer bestimmt, in welchem Man-Abschnitt die Datei installiert wird.

Code kopieren Der Code lautet wie folgt:

{ "name" : "foo"

, „Version“: „1.2.3“

, „description“: „Ein verpackter Foo-Fooer zum Fooing von Foos“

, „main“ : „foo.js“

, „man“ : [ „./man/foo.1“, „./man/foo.2“ ]

}

wird für man foo und man 2 foo erstellt.

Verzeichnisse

Die CommonJS Packages-Spezifikation beschreibt mehrere Möglichkeiten, wie Sie Directorieshash verwenden können, um die Struktur des Pakets anzugeben. Wenn Sie sich die package.json von npm ansehen, werden Sie feststellen, dass es Verzeichnisse mit den Bezeichnungen doc, lib und man gibt.

Diese Informationen können in Zukunft verwendet werden.

directories.lib

Sagen Sie den Verlierern, wo sich Ihr Bibliotheksordner befindet. Die Verwendung des lib-Ordners ist im Moment nichts Besonderes, es handelt sich jedoch um wichtige Metainformationen.

directories.bin

Wenn Sie ein „bin“-Verzeichnis angeben, werden alle Dateien in diesem Ordner als „bin“-Feld verwendet.

Wenn Sie das Feld „bin“ angegeben haben, hat dies keine Auswirkung.

directories.man

Ein Ordner voller Manpages. Erstellen Sie sorgfältig ein „Mann“-Feld.
Ein Ordner voller Manpages von Sugar zum Generieren eines „man“-Arrays von
durch den Ordner gehen.

directories.doc

Legen Sie die Markdown-Datei hier ab. Irgendwann werden diese vielleicht eines Tages schön gezeigt.
Fügen Sie hier Markdown-Dateien ein, diese werden schließlich gut angezeigt,
vielleicht, irgendwann.

directories.example

Fügen Sie hier Ihr Beispielskript ein. Eines Tages könnte es auf clevere Weise auftauchen.

Repository

Geben Sie an, wo Ihr Code gespeichert werden soll. Dies ist hilfreich für diejenigen, die einen Beitrag leisten möchten. Wenn sich das Git-Repository auf Github befindet, kann der Befehl npm docs Sie finden.

Machen Sie Folgendes:

Code kopieren Der Code lautet wie folgt:

"Repository" :

{ "type" : "git"

, „url“: „http://github.com/isaacs/npm.git“

}

"Repository" :

{ "type" : "svn"

, „url“: „http://v8.googlecode.com/svn/trunk/“

}

Die URL sollte eine öffentliche (auch schreibgeschützte) URL sein, die direkt von einem unveränderten Versionskontrollprogramm verarbeitet werden kann. Es sollte keine HTML-Projektseite sein. Weil es für Computer sichtbar ist.

Skripte

„scripts“ ist ein Hash-Objekt, das aus Skriptbefehlen besteht, die während verschiedener Lebenszyklen des Pakets ausgeführt werden. Der Schlüssel ist das Lebenszyklusereignis und der Wert ist der auszuführende Befehl.

Siehe npm-scripts(7)

config

Der „config“-Hash kann verwendet werden, um versionenübergreifende Parameter zu konfigurieren, die in Paketskripten verwendet werden. Im Beispiel, wenn ein Paket die folgende Konfiguration hat:

Code kopieren Der Code lautet wie folgt:

{ "name" : "foo"

, "config" : { "port" : "8080" } }

Dann gibt es einen „Start“-Befehl, der auf die Umgebungsvariable npm_package_config_port verweist, und Benutzer können ihn über npm config set foo:port 8001 überschreiben.

Siehe npm-config(7) und npm-scripts(7).

Abhängigkeiten

Eine Abhängigkeit ist ein Hash, der einen Versionsbereich für eine Reihe von Paketnamen angibt. Der Versionsbereich ist eine durch ein oder mehrere Leerzeichen getrennte Zeichenfolge. Abhängigkeiten können auch Tarballs oder Git-URLs verwenden.

Bitte fügen Sie keine Test- oder Übergangsabhängigkeiten in den Abhängigkeitshash ein. Siehe devDependencies unten.

Weitere Informationen finden Sie in Abschnitt (7).

1.Version muss vollständig mit Version übereinstimmen
2.>version muss größer sein als version
3.>=Version Wie oben
4. 5.<=Version Wie oben
6.~Version ist ungefähr gleich, siehe Semver(7)
7.1.2.x 1.2.0, 1.2.1 usw., jedoch ohne 1.3.0
8.http://... Siehe „Von URL abhängig“ unten
9.* Alle
10."" Leer, dasselbe wie *
11.version1 - version2 ist dasselbe wie >=version1 <=version2.
12.range1 ||. range2 Wählen Sie eine der beiden.
13.git... Siehe unten „Abhängig von der Git-URL“
14.user/repo Siehe „GitHub-URLs“ unten
15. Folgendes ist beispielsweise zulässig:

Code kopieren Der Code lautet wie folgt:

{ "Abhängigkeiten" :

{ "foo" : "1.0.0 - 2.9999.9999"

, "bar" : ">=1.0.2 <2.1.2"

, „baz“ : „>1.0.2 <=2.3.4“

, „boo“ : „2.0.1“

, "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0"

, „asd“: „http://asdf.com/asdf.tar.gz“

, „til“ : „~1.2“

, „elf“ : „~1.2.3“

, „two“ : „2.x“

, „thr“ : „3.3.x“

}

}

Abhängigkeits-URL

Sie können eine Tarball-URL angeben, die heruntergeladen und initialisiert wird, wenn das Paket initialisiert wird.

Abhängig von der Git-URL

Git-URLs können in den folgenden Formen vorliegen:

Code kopieren Der Code lautet wie folgt:

git://github.com/user/project.git#commit-ish

git ssh://user@hostname:project.git#commit-ish

git ssh://user@hostname/project.git#commit-ish

git http://user@hostname/project/blah.git#commit-ish

git https://user@hostname/project/blah.git#commit-ish

commit-ish ist ein beliebiges Tag, SHA oder Branch, das von Git ausgecheckt werden kann. Der Standardwert ist Master.

GitHub-URLs

Nach Version 1.1.65 können Sie einfach „user/foo-project“ verwenden, um auf GitHub-URLs zu verweisen, wie zum Beispiel:

Code kopieren Der Code lautet wie folgt:

{

„name“: „foo“,

„Version“: „0.0.0“,

„Abhängigkeiten“: {

„express“: „visionmedia/express“

}

}

devDependencies

Wenn jemand Ihr Modul herunterladen und in seinem Programm verwenden möchte, möchte oder muss er möglicherweise nicht das von Ihnen verwendete externe Test- oder Dokumentations-Framework herunterladen und erstellen.

In diesem Fall ist es besser, diese abhängigen Projekte im devDependencies-Hash aufzulisten.

Diese Dinge werden initialisiert, wenn npm link oder npm install im Stammverzeichnis ausgeführt wird, und können wie andere npm-Konfigurationsparameter verwaltet werden. Weitere Informationen finden Sie unter npm-config(7).

Für nicht plattformspezifische Build-Schritte, wie das Kompilieren von CoffeeScript oder anderen Sprachen zu Javascript, verwenden Sie ein Prepublish-Skript, um es zu implementieren und in devDependency zu platzieren.

Zum Beispiel:

Code kopieren Der Code lautet wie folgt:

{ "name": "ethopia-waza",

„Beschreibung“: „eine herrlich fruchtige Kaffeesorte“,

„Version“: „1.2.3“,

„devDependencies“: {

„coffee-script“: „~1.6.3“

},

„Skripte“: {

„prepublish“: „coffee -o lib/ -c src/waza.coffee“

},

„main“: „lib/waza.js“

}

Das Vorveröffentlichungsskript wird vor der Veröffentlichung ausgeführt, sodass Benutzer es nicht selbst kompilieren müssen, bevor sie es verwenden können. Und im Entwicklungsmodus (z. B. beim lokalen Ausführen von npm install) wird dieses Skript zum besseren Testen ausgeführt.

peerDependencies

In einigen Szenarien, beispielsweise wenn „require“ auf einem Host nicht erforderlich ist, möchten Sie den Kompatibilitätsschlüssel Ihres Pakets mit einem Host-Tool oder einer Host-Bibliothek anzeigen. Dies wird im Allgemeinen verwendet, um auf Plugins zu verweisen. Insbesondere stellt Ihr Modul möglicherweise eine bestimmte Schnittstelle bereit, die vom Hostdokument erwartet und angegeben wird.

Zum Beispiel:

Code kopieren Der Code lautet wie folgt:

{

„Name“: „Tee-Latte“,

„Version“: „1.3.5“

„peerDependencies“: {

„Tee“: „2.x“

}

}

Dadurch wird sichergestellt, dass Ihr Paket nur mit der 2.x-Version von Tea initialisiert werden kann. npm install tea-latte kann die folgenden Abhängigkeiten erzeugen

Code kopieren Der Code lautet wie folgt:

â“œâ“?â“? tea-latte@1.3.5

â““â“?â“? tea@2.2.0

Der Versuch, ein anderes Plugin mit widersprüchlichen Abhängigkeiten zu initialisieren, führt zu einem Fehler. Stellen Sie daher sicher, dass die Anforderungen Ihres Plugins so wenig wie möglich eingeschränkt sind, ohne es an eine bestimmte Version zu binden.

Angenommen, dieser Host hält sich an die Semver-Spezifikation, führt eine bloße Änderung der Hauptversion dieses Pakets dazu, dass Ihr Plugin kaputt geht. Wenn Sie also jede 1.x-Version in einem Paket verwendet haben, verwenden Sie „^1.0“ oder „1.x“, um sie darzustellen. Wenn Sie sich auf die Funktionseinführung 1.5.2 verlassen, verwenden Sie „>= 1.5.2 < 2“.

gebündelte Abhängigkeiten

Eine Reihe von Paketnamen, die bei der Veröffentlichung enthalten sein werden.

Sie können es auch als „bundleDependencies“ buchstabieren (d fehlt).

optionale Abhängigkeiten

Wenn eine Abhängigkeit verfügbar ist, Sie aber möchten, dass npm die Initialisierung fortsetzt, auch wenn die Installation fehlschlägt, können Sie sie in den Hash optionalDependencies einfügen. Dies ist eine Zuordnung von Paketnamen zu Versionen oder URLs, genau wie ein Abhängigkeits-Hash. Es läuft einfach schief.

Der Umgang mit fehlenden Abhängigkeiten liegt ebenfalls in der Verantwortung Ihres Programms. Zum Beispiel so:

Code kopieren Der Code lautet wie folgt:

versuche es mit {

var foo = require('foo')

var fooVersion = require('foo/package.json').version

} fangen (äh) {

foo = null

}

if ( notGoodFooVersion(fooVersion) ) {

foo = null

}

// .. dann später in Ihrem Programm ..

if (foo) {

foo.doFooThings()

}

optionalDependencies überschreibt Elemente mit demselben Namen in Abhängigkeiten, daher ist es normalerweise besser, als sie nur an einem Ort zu platzieren.

Motoren

Sie können die Version des Arbeitsknotens angeben:

Code kopieren Der Code lautet wie folgt:

{ "engines" : { "node" : ">=0.10.3 <0.12" } }

Und wenn Sie wie bei Abhängigkeiten keine Version angeben oder „*“ als Version angeben, funktionieren alle Versionen des Knotens.

Wenn Sie ein „Engines“-Feld angeben, erfordert npm, dass sich dort ein Knoten befindet. Wenn „Engines“ weggelassen wird, geht npm davon aus, dass es auf dem Knoten funktioniert.

Sie können auch das Feld „Engines“ verwenden, um anzugeben, welche npm-Version Ihr Programm besser initialisieren kann, wie zum Beispiel:

Code kopieren Der Code lautet wie folgt:

{ "engines" : { "npm" : "~1.0.20" } }

Denken Sie daran, dass dieses Feld nur ein empfohlener Wert ist, es sei denn, der Benutzer setzt das Flag „engine-strict“.

engineStrict

Wenn Sie sicher sind, dass Ihr Modul nicht auf einem anderen Knoten oder NPM als der von Ihnen angegebenen Version ausgeführt wird, können Sie „engineStrict“: true in der Datei package.json festlegen. Es überschreibt die Engine-strikte Einstellung des Benutzers.

Tun Sie dies nicht, es sei denn, Sie sind sich sehr, sehr sicher. Wenn der Hash Ihrer Engine zu restriktiv ist, können Sie leicht in Schwierigkeiten geraten. Überlegen Sie sich diese Wahl sorgfältig. Wenn es missbraucht wird, wird es in zukünftigen NPM-Versionen entfernt.

Betriebssystem

Sie können festlegen, auf welchen Betriebssystemen Ihr Modul laufen soll:

Code kopieren Der Code lautet wie folgt:

"os" : [ "darwin", "linux" ]

Sie können anstelle einer Whitelist auch eine Blacklist verwenden. Fügen Sie einfach „!“ vor dem Namen hinzu:

Code kopieren Der Code lautet wie folgt:

"os" : [ "!win32" ]

Das Betriebssystem verwendet zur Erkennung „process.platform“.

Obwohl es keinen guten Grund dafür gibt, unterstützt es sowohl die Blacklist als auch die Whitelist.

CPU

Wenn Ihr Code nur auf einer bestimmten CPU-Architektur ausgeführt werden kann, können Sie eine angeben:

Code kopieren Der Code lautet wie folgt:

„cpu“: [ „x64“, „ia32“ ]

Genau wie bei der OS-Option können Sie auch eine Architektur hacken:

Code kopieren Der Code lautet wie folgt:

"cpu" : [ "!arm", "!mips" ]

L'architecture du processeur est détectée à l'aide de process.arch.

préférerGlobal

Si le package est principalement un programme en ligne de commande qui doit être installé globalement, définissez ceci sur true pour fournir un avertissement aux personnes qui l'installent uniquement localement.

Cela n'empêchera pas réellement les utilisateurs d'installer localement, mais cela aidera à éviter les malentendus si cela ne fonctionne pas comme prévu.

privé

Si vous définissez "privé" : vrai, npm ne le publiera pas.

C'est un moyen d'éviter la libération accidentelle de bibliothèques privées. Si vous souhaitez vous assurer qu'un package donné est publié uniquement dans un registre spécifique (tel qu'un registre interne), remplacez le paramètre de configuration au moment de la publication du registre par une description publiConfighash.

publishConfig

Il s'agit d'une collection de configurations utilisée au moment de la publication. Ceci est utile lorsque vous souhaitez configurer une balise ou un registre, afin de vous assurer qu'un package donné ne porte pas la balise « dernier » ou n'est pas publié par défaut dans le registre public mondial.

N'importe quelle configuration peut être remplacée, mais bien sûr, seuls "tag" et "registry" peuvent être pertinents à des fins de publication.

Voir npm-config(7) pour une liste des éléments qui peuvent être remplacés.

Verwandte Etiketten：

nodejs npm package.json

Quelle：php.cn

Vorheriger Artikel：Deaktivieren Sie JavaScript nicht vollständig, sondern teilweise in den page_javascript-Tipps Nächster Artikel：So deaktivieren Sie das Popup-Fenster „Javascript Alert“ und deaktivieren die Popup-Warnung box_javascript skills

Erklärung dieser Website

Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn

Neueste Artikel des Autors