Frage

Kann ich Kommentare in einer JSON -Datei verwenden? Wenn das so ist, wie?

War es hilfreich?

Lösung

Nein.

Der JSON sollte alle Daten sein, und wenn Sie einen Kommentar angeben, sind es auch Daten.

Sie könnten ein bestimmtes Datenelement nennen lassen "_comment" (oder so), das von Apps ignoriert wird, die die JSON -Daten verwenden.

Sie wären wahrscheinlich besser, wenn Sie den Kommentar in den Prozessen haben, die den JSON generieren/empfangen, da er wissen soll, was die JSON -Daten im Voraus oder zumindest die Struktur davon haben.

Aber wenn Sie sich entschlossen haben:

{
   "_comment": "comment text goes here...",
   "glossary": {
      "title": "example glossary",
      "GlossDiv": {
         "title": "S",
         "GlossList": {
            "GlossEntry": {
               "ID": "SGML",
               "SortAs": "SGML",
               "GlossTerm": "Standard Generalized Markup Language",
               "Acronym": "SGML",
               "Abbrev": "ISO 8879:1986",
               "GlossDef": {
                  "para": "A meta-markup language, used to create markup languages such as DocBook.",
                  "GlossSeeAlso": ["GML", "XML"]
               },
               "GlossSee": "markup"
            }
         }
      }
   }
}

Andere Tipps

Nein, Kommentare der Form //… oder /*…*/ sind in JSON nicht erlaubt. Diese Antwort basiert auf:

  • http://www.json.org
  • RFC 4627: Das application/json Medientyp für JavaScript -Objektnotation (JSON)
  • RFC 7159 Das JavaScript -Objektnotation (JSON) -Datenwechselformat - Obsoletes: 4627, 7158

Kommentare angeben, wenn Sie möchten; Streichen Sie sie mit einem Minifikator aus, bevor Sie analysieren oder übertragen werden.

Ich habe gerade veröffentlicht Json.Minify () Das streift Kommentare und Whitespace aus einem JSON -Block aus und macht es gültig, dass JSON analysiert werden kann. Sie können es also verwenden wie:

JSON.parse(JSON.minify(my_str));

Als ich es veröffentlichte, bekam ich eine große Gegenreaktion von Menschen, die selbst der Idee davon nicht einverstanden sind, also habe ich beschlossen, einen umfassenden Blog -Beitrag darüber zu schreiben, warum Kommentare machen in JSON Sinn. Es enthält diesen bemerkenswerten Kommentar vom Schöpfer von JSON:

Nehmen wir an, Sie verwenden JSON, um Konfigurationsdateien aufzubewahren, die Sie mit Anmerkungen versehen möchten. Gehen Sie voran und setzen Sie alle Kommentare ein, die Sie mögen. Dann leiten Sie es durch JSmin, bevor Sie es Ihrem JSON -Parser übergeben. - - Douglas Crockford, 2012

Hoffentlich ist das für diejenigen hilfreich, die nicht einverstanden sind, warum Json.Minify () könnte nützlich sein.

Die Kommentare wurden von JSON von Design entfernt.

Ich habe Kommentare von JSON entfernt, weil ich gesehen habe, wie Leute sie benutzten, um Parsen -Richtlinien zu halten, eine Praxis, die die Interoperabilität zerstört hätte. Ich weiß, dass das Fehlen von Kommentaren einige Leute traurig macht, aber es sollte nicht.

Nehmen wir an, Sie verwenden JSON, um Konfigurationsdateien aufzubewahren, die Sie mit Anmerkungen versehen möchten. Gehen Sie voran und setzen Sie alle Kommentare ein, die Sie mögen. Dann leiten Sie es durch JSmin, bevor Sie es Ihrem JSON -Parser übergeben.

Quelle: Öffentliche Erklärung von Douglas Crockford auf G+

Haftungsausschluss: Ihre Garantie ist nichtig

Wie hervorgehoben, nutzt dieser Hack die Implementierung der Spezifikation. Nicht alle JSON -Parser werden diese Art von JSON verstehen. Insbesondere Parser werden ersticken.

Es ist eine interessante Neugier, aber Sie sollte es wirklich für nichts verwenden. Unten ist die ursprüngliche Antwort.


Ich habe einen kleinen Hack gefunden, der es Ihnen ermöglicht, Kommentare in eine JSON -Datei zu platzieren, die sich nicht auf die Parsen auswirkt, oder die Daten in irgendeiner Weise ändern.

Es scheint, dass Sie beim Deklarieren eines Objektliterales zwei Werte mit demselben Schlüssel angeben können und der letzte Vorrang hat. Ob Sie es glauben oder nicht, es stellt sich heraus, dass JSON -Parser genauso arbeiten. Wir können dies daher verwenden, um Kommentare in der Quell -JSON zu erstellen, die nicht in einer analysierten Objektdarstellung vorhanden sind.

({a: 1, a: 2});
// => Object {a: 2}
Object.keys(JSON.parse('{"a": 1, "a": 2}')).length; 
// => 1

Wenn wir diese Technik anwenden, sieht Ihre kommentierte JSON -Datei möglicherweise so aus:

{
  "api_host" : "The hostname of your API server. You may also specify the port.",
  "api_host" : "hodorhodor.com",

  "retry_interval" : "The interval in seconds between retrying failed API calls",
  "retry_interval" : 10,

  "auth_token" : "The authentication token. It is available in your developer dashboard under 'Settings'",
  "auth_token" : "5ad0eb93697215bc0d48a7b69aa6fb8b",

  "favorite_numbers": "An array containing my all-time favorite numbers",
  "favorite_numbers": [19, 13, 53]
}

Der obige Code ist Gültiges JSON. Wenn Sie es analysieren, erhalten Sie ein Objekt wie folgt:

{
    "api_host": "hodorhodor.com",
    "retry_interval": 10,
    "auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
    "favorite_numbers": [19,13,53]
}

Das heißt, es gibt keine Spur der Kommentare, und sie werden keine seltsamen Nebenwirkungen haben.

Frohe Hacking!

JSON unterstützt keine Kommentare. Es war auch nie beabsichtigt, für Konfigurationsdateien verwendet zu werden, bei denen Kommentare erforderlich wären.

HJSON ist ein Konfigurationsdateiformat für Menschen. Entspannte Syntax, weniger Fehler, mehr Kommentare.

Hjson intro

Sehen hjson.org Für JavaScript, Java, Python, PHP, Rost, Go, Ruby und C# Bibliotheken.

Erwägen Sie, YAML zu verwenden. Es ist fast ein Superset von JSON (praktisch alle gültigen JSON ist gültig YAML) und ermöglicht Kommentare.

Du kannst nicht. Zumindest ist das meine Erfahrung aus einem kurzen Blick auf json.org.

JSON hat seine Syntax auf dieser Seite visualisiert. Es gibt keine Notiz zu Kommentaren.

Sie sollten a schreiben JSON -Schema stattdessen. JSON Schema ist derzeit eine vorgeschlagene Internetentwurfsspezifikation. Neben der Dokumentation kann das Schema auch zur Validierung Ihrer JSON -Daten verwendet werden.

Beispiel:

{
    "description":"A person",
    "type":"object",
    "properties":
        {
            "name":
                {
                    "type":"string"
                },
            "age":
                {
                    "type":"integer",
                    "maximum":125
                }
        }
}

Sie können Dokumentation mithilfe der verwenden Bezeichnung Schema -Attribut.

Wenn Sie verwenden Jackson Als Ihr JSON -Parser ermöglichen Sie dies so, dass Sie Kommentare ermöglichen:

ObjectMapper mapper = new ObjectMapper().configure(Feature.ALLOW_COMMENTS, true);

Dann können Sie solche Kommentare haben:

{
  key: "value" // Comment
}

Und Sie können auch Kommentare mit beginnen, beginnend mit # indem man es einstellt:

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);

Im Allgemeinen (wie zuvor beantwortet) erlaubt die Spezifikation keine Kommentare.

Kommentare sind kein offizieller Standard. Obwohl einige Parser Kommentare im C-Stil unterstützen. Eine, die ich benutze, ist JSONCPP. In den Beispielen gibt es dieses:

// Configuration options
{
    // Default encoding for text
    "encoding" : "UTF-8",

    // Plug-ins loaded at start-up
    "plug-ins" : [
        "python",
        "c++",
        "ruby"
        ],

    // Tab indent size
    "indent" : { "length" : 3, "use_space": true }
}

JsonLint bestätigt dies nicht. Kommentare sind also eine parserspezifische Erweiterung und nicht Standard.

Ein anderer Parser ist JSON5.

Eine Alternative zu JSON Toml.

Eine weitere Alternative ist JSONC.

Hier ist, was ich in der gefunden habe Google Firebase -Dokumentation Dadurch können Sie Kommentare in JSON eingeben:

{
  "//": "Some browsers will use this to enable push notifications.",
  "//": "It is the same for all projects, this is not your project's sender ID",
  "gcm_sender_id": "1234567890"
}

Wenn Ihre Textdatei, die eine JSON -Zeichenfolge ist, von einem Programm gelesen wird, wie schwierig wäre es, entweder C- oder C ++ - Style -Kommentare auszuziehen, bevor sie sie verwenden?

Antworten: Es wäre ein One -Liner. Wenn Sie dies tun, können JSON -Dateien als Konfigurationsdateien verwendet werden.

Wenn Sie die Newtonsoft.json -Bibliothek mit ASP.NET zum Lesen/Deserialisieren verwenden, können Sie Kommentare im JSON -Inhalt verwenden:

// "Name": "String"

// "id": int

oder

/* Das ist ein

Kommentar Beispiel */

PS: Einzelzeilen-Kommentare werden nur mit mehr als 6 Versionen von Newtonsoft JSON unterstützt.

Zusätzliche Anmerkung für Personen, die nicht über die Box denken können: Ich verwende das JSON -Format für grundlegende Einstellungen in einer von mir erstellten ASP.NET -Webanwendung. Ich habe die Datei gelesen, sie in das Einstellungsobjekt mit der Newtonsoft -Bibliothek konvertiert und bei Bedarf verwendet.

Ich schreibe lieber Kommentare zu jeder einzelnen Einstellung in der JSON -Datei selbst, und ich kümmere mich wirklich nicht um die Integrität des JSON -Formats, solange die Bibliothek, die ich verwende, damit einverstanden ist.

Ich denke, dies ist eine "einfachere Verwendung/Verständnis" als das Erstellen einer separaten Datei "Einstellungen.Readme" und die Erläuterung der darin enthaltenen Einstellungen.

Wenn Sie ein Problem mit dieser Art von Nutzung haben; Entschuldigung, der Genie ist aus der Lampe. Die Leute würden andere Verwendungen für das JSON -Format finden, und Sie können nichts dagegen tun.

Die Idee hinter JSON ist es, einen einfachen Datenaustausch zwischen Anwendungen bereitzustellen. Diese sind in der Regel webbasiert und die Sprache ist JavaScript.

Es ermöglicht jedoch nicht wirklich Kommentare als solches, wenn ein Kommentar als eines der Namen/Wert -Paare in den Daten abgegeben wird, würde sicherlich funktionieren, obwohl diese Daten offensichtlich durch den Parsencode ignoriert oder speziell behandelt werden müssen.

Alles in allem ist es nicht die Absicht, dass die JSON -Datei im traditionellen Sinne Kommentare enthalten sollte. Es sollte nur die Daten sein.

Schauen Sie sich das an die JSON -Website Weitere Details.

Ich habe dies nur für Konfigurationsdateien begegnet. Ich möchte nicht benutzen Xml (wörtlich, grafisch, hässlich, schwer zu lesen) oder "Ini" -Format (keine Hierarchie, kein realer Standard usw.) oder Java -Eigenschaften "Eigenschaften" -Format (wie .ini).

JSON kann alles tun, was sie können, aber es ist viel weniger ausführlich und mehr menschlicher lesbar - und Parser sind in vielen Sprachen einfach und allgegenwärtig. Es ist nur ein Datenbaum. Out-of-Band-Kommentare sind jedoch häufig eine Notwendigkeit, "Standard" -Konfigurationen und dergleichen zu dokumentieren. Konfigurationen dürfen niemals "vollständige Dokumente" sein, sondern Bäume gespeicherter Daten, die bei Bedarf menschlich lesbar sein können.

Ich denke, man könnte gebrauchen "#": "comment", für "gültig" JSON.

JSON unterstützt keine Kommentare nativ, aber Sie können Ihren eigenen Decoder oder zumindest vorbereitet machen, um Kommentare auszuziehen. ).

JSON hat keine Kommentare. Ein JSON -Encoder darf keine Kommentare ausgeben. Ein JSON -Decoder kann Kommentare akzeptieren und ignorieren.

Kommentare sollten niemals verwendet werden, um etwas Sinnvolles zu übertragen. Dafür ist JSON da.

Vgl.: Douglas Crockford, Autor von JSON Spec.

Es hängt von Ihrer JSON -Bibliothek ab. Json.net Unterstützt Kommentare im JavaScript-Stil, /* commment */.

Sehen Ein weiterer Stapelüberlauffrage.

JSON ist viel Sinn für Konfigurationsdateien und andere lokale Verwendung, weil es allgegenwärtig ist und weil es viel einfacher ist als XML.

Wenn Menschen starke Gründe gegen Kommentare in JSON haben, wenn sie Daten kommunizieren (ob gültig oder nicht), kann JSON möglicherweise in zwei aufgeteilt werden:

  • JSON-COM: JSON auf dem Kabel oder Regeln, die bei der Kommunikation von JSON-Daten gelten.
  • JSON-DOC: JSON-Dokument oder JSON in Dateien oder lokal. Regeln, die ein gültiges JSON -Dokument definieren.

JSON-DOC ermöglicht Kommentare, und andere kleinere Unterschiede könnten vorhanden sein, z. B. die Behandlung von Whitespace. Parser können leicht von einer Spezifikation in die andere konvertieren.

In Bezug auf die Anmerkung Hergestellt von Douglas Crockford zu diesen Themen (verwiesen von @artur czajka)

Nehmen wir an, Sie verwenden JSON, um Konfigurationsdateien aufzubewahren, die Sie mit Anmerkungen versehen möchten. Gehen Sie voran und setzen Sie alle Kommentare ein, die Sie mögen. Dann leiten Sie es durch JSmin, bevor Sie es Ihrem JSON -Parser übergeben.

Wir sprechen über ein generisches Problem mit Konfigurationsdatei (Cross Language/Plattform) und antwortet mit einem JS -spezifischen Dienstprogramm!

Sicher, ein JSON-spezifisches Minify kann in jeder Sprache implementiert werden, aber standardisieren Sie dies so, dass es in allen Sprachen und Plattformen über Parsers hinweg allgegenwärtig wird, damit die Leute aufhören, ihre Zeit zu verschwenden, weil sie gute Anwendungsmittel für sie haben, und das Problem in der Ausgabe ansehen. Online -Foren, und die Leute dazu bringen, ihnen zu sagen, dass es eine schlechte Idee ist oder vorschlägt, dass es einfach ist, Striping -Kommentare aus Textdateien zu implementieren.

Das andere Problem ist die Interoperabilität. Angenommen, Sie haben eine Bibliothek oder eine API oder eine Art Subsystem, das einige Konfigurations- oder Datendateien zugeordnet ist. Und auf dieses Subsystem ist aus verschiedenen Sprachen zugänglich zu werden. Dann erzählen Sie den Leuten: Vergessen Sie übrigens nicht, die Kommentare der JSON -Dateien auszuziehen, bevor Sie sie an den Parser weitergeben!

Mit dem DOJO Toolkit JavaScript Toolkit (mindestens von Version 1.4) können Sie Kommentare in Ihr JSON aufnehmen. Die Kommentare können von sein /* */ Format. Das Dojo -Toolkit konsumiert den JSON über die dojo.xhrGet() Anruf.

Andere JavaScript -Toolkits können ähnlich funktionieren.

Dies kann hilfreich sein, wenn Sie mit alternativen Datenstrukturen (oder sogar Datenlisten) experimentieren, bevor Sie eine endgültige Option auswählen.

Wenn du benutzt JSON5 Sie können Kommentare einfügen.


JSON5 ist eine vorgeschlagene Erweiterung von JSON Das zielt darauf ab, es dem Menschen leichter zu machen, von Hand zu schreiben und zu warten. Dies geschieht durch Hinzufügen einiger minimaler Syntaxfunktionen direkt aus ECMascript 5.

JSON ist kein gerahmtes Protokoll. Es ist ein Sprachfreies Format. Das Format eines Kommentars ist also nicht für JSON definiert.

Wie viele Menschen vorgeschlagen haben, gibt es einige Tricks, zum Beispiel doppelte Schlüssel oder einen bestimmten Schlüssel _comment das können Sie verwenden. Es liegt an dir.

Du kann Kommentare in JSONP, aber nicht in reinem JSON. Ich habe gerade eine Stunde damit verbracht, mein Programm mit diesem Beispiel von Highcharts zum Laufen zu bringen: http://www.highcharts.com/samples/data/jsonp.php?filename=AAPL-C.JSON&callback=?

Wenn Sie dem Link folgen, werden Sie sehen

?(/* AAPL historical OHLC data from the Google Finance API */
[
/* May 2006 */
[1147651200000,67.79],
[1147737600000,64.98],
...
[1368057600000,456.77],
[1368144000000,452.97]
]);

Da ich eine ähnliche Datei in meinem lokalen Ordner hatte, gab es keine Probleme mit dem Gleichorientierte Politik, Also habe ich mich entschlossen, Pure JSON zu verwenden ... und natürlich, $.getJSON scheiterte stillschweigend wegen der Kommentare.

Schließlich habe ich gerade eine manuelle HTTP-Anfrage an die obige Adresse gesendet und festgestellt, dass der Inhaltstyp war text/javascript Da JSONP pure JavaScript zurückgibt. In diesem Fall Kommentare sind erlaubt. Aber meine Anwendung hat Content-Typ zurückgegeben application/json, Also musste ich die Kommentare entfernen.

JSON unterstützte früher Kommentare, aber sie wurden missbraucht und vom Standard entfernt.

Vom Schöpfer von JSON:

Ich habe Kommentare von JSON entfernt, weil ich gesehen habe, wie Leute sie benutzten, um Parsen -Richtlinien zu halten, eine Praxis, die die Interoperabilität zerstört hätte. Ich weiß, dass das Fehlen von Kommentaren einige Leute traurig macht, aber es sollte nicht. - - Douglas Crockford, 2012

Die offizielle JSON -Website ist um Json.org. JSON ist definiert als a Standard von ECMA International. Es gibt immer einen Petitionsprozess, um Standards überarbeitet zu haben. Es ist unwahrscheinlich, dass dem JSON -Standard aus mehreren Gründen Anmerkungen hinzugefügt werden.

JSON By Design ist eine leicht umgekehrte Alternative zu XML. Es ist auch so vereinfacht, dass Anmerkungen unnötig sind. Es ist nicht einmal eine Markup -Sprache. Das Ziel ist Stabilität und interoperablilty.

Jeder, der die "Has -A" -Bewegung der Objektorientierung versteht, kann jede JSON -Struktur verstehen - das ist der ganze Punkt. Es handelt sich nur um einen gerichteten acyclischen Graphen (DAG) mit Knoten -Tags (Schlüssel-/Wertpaare), das eine nahezu universelle Datenstruktur ist.

Diese einzige Annotation ist möglicherweise "// das sind DAG -Tags". Die Schlüsselnamen können so informativ wie erforderlich sein, was eine willkürliche semantische Arität ermöglicht.

Jede Plattform kann JSON mit nur wenigen Codezeilen analysieren. XML benötigt komplexe OO -Bibliotheken, die auf vielen Plattformen nicht tragfähig sind.

Anmerkungen würden JSON nur dazu bringen, weniger interoperabel zu machen. Es gibt einfach nichts anderes hinzuzufügen, es sei denn, Sie brauchen wirklich eine Markup -Sprache (XML), und es ist sich egal, ob Ihre anhaltenden Daten leicht analysiert werden.

Das ist ein "Können Sie" Frage. Und hier ist ein "Jawohl" Antworten.

Nein, Sie sollten keine doppelten Objektmitglieder verwenden, um Seitenkanaldaten in eine JSON -Codierung zu füllen. (Siehe "Die Namen in einem Objekt sollten eindeutig sein" im RFC).

Und ja, du könntest Kommentare einfügen um der JSON, was du ausrichten könntest.

Wenn Sie jedoch eine Möglichkeit haben möchten, beliebige Seitenkanaldaten in einen gültigen JSON einzufügen und zu extrahieren, ist hier eine Antwort. Wir nutzen die nicht eindeutige Darstellung von Daten in einer JSON-Codierung. Das ist erlaubt* In Abschnitt zwei der RFC unter "Whitespace ist vor oder nach einer der sechs strukturellen Zeichen zulässig".

*Der RFC sagt nur "Whitespace ist vor oder nach einer der sechs strukturellen Zeichen zulässig" und erwähnt nicht explizit Strings, Zahlen, "Falsch", "wahr" und "null". Diese Auslassung wird in allen Implementierungen ignoriert.


Kanonisieren Sie Ihren JSON -Erstens, indem Sie ihn minimieren:

$jsonMin = json_encode(json_decode($json));

Dann codieren Sie Ihren Kommentar in Binary:

$hex = unpack('H*', $comment);
$commentBinary = base_convert($hex[1], 16, 2);

Dann steg in Ihrer Binärdatei:

$steg = str_replace('0', ' ', $commentBinary);
$steg = str_replace('1', "\t", $steg);

Hier ist Ihre Ausgabe:

$jsonWithComment = $steg . $jsonMin;

Wir benutzen strip-json-comments für unser Projekt. Es unterstützt so etwas wie:

/*
 * Description 
*/
{
    // rainbows
    "unicorn": /* ❤ */ "cake"
}

Einfach npm install --save strip-json-comments So installieren und verwenden Sie es wie:

var strip_json_comments = require('strip-json-comments')
var json = '{/*rainbows*/"unicorn":"cake"}';
JSON.parse(strip_json_comments(json));
//=> {unicorn: 'cake'}

Um ein JSON -Element in Teile zu schneiden, füge ich "Dummy Comment" -Zeilen hinzu:

{

"#############################" : "Part1",

"data1"             : "value1",
"data2"             : "value2",

"#############################" : "Part2",

"data4"             : "value3",
"data3"             : "value4"

}

Es gibt eine gute Lösung (Hack), die gültig ist. Machen Sie einfach zweimal den gleichen Schlüssel (oder mehr). Zum Beispiel:

{
  "param" : "This is the comment place",
  "param" : "This is value place",
}

JSON wird dies also verstehen als:

{
  "param" : "This is value place",
}

Der Autor von JSON möchte, dass wir Kommentare in das JSON aufnehmen, sie aber vor dem Parsen ausziehen (siehe Verknüpfung bereitgestellt von Michael Burr). Wenn JSON Kommentare haben sollte, warum nicht standardisieren und den JSON -Parser den Job machen lassen? Ich stimme der Logik dort nicht zu, aber leider ist das der Standard. Die Verwendung einer YAML -Lösung, wie von anderen vorgeschlagen, ist gut, erfordert jedoch eine Bibliotheksabhängigkeit.

Wenn Sie Kommentare ausziehen möchten, aber keine Bibliotheksabhängigkeit haben möchten, finden Sie hier eine Zwei-Linie-Lösung, die für C ++-Style-Kommentare funktioniert, aber an andere angepasst werden kann:

var comments = new RegExp("//.*", 'mg');
data = JSON.parse(fs.readFileSync(sample_file, 'utf8').replace(comments, ''));

Beachten Sie, dass diese Lösung nur in Fällen verwendet werden kann, in denen Sie sicher sein können, dass die JSON -Daten den Kommentarinitiator z. B. ('//') nicht enthalten.

Eine andere Möglichkeit, JSON -Parsen, Stripping von Kommentaren und keine zusätzliche Bibliothek zu erreichen, besteht darin, den JSON in einem JavaScript -Dolmetscher zu bewerten. Die Einschränkung mit diesem Ansatz ist natürlich, dass Sie nur ungelente Daten bewerten möchten (kein nicht vertrauenswürdiges Benutzereingabericht). Hier ist ein Beispiel für diesen Ansatz in Node.js - eine weitere Einschränkung, das folgende Beispiel wird die Daten nur einmal lesen und dann zwischengespeichert:

data = require(fs.realpathSync(doctree_fp));

Seufzen. Warum nicht einfach Felder hinzufügen, z. B.

{
    "note1" : "This demonstrates the provision of annotations within a JSON file",
    "field1" : 12,
    "field2" : "some text",

    "note2" : "Add more annotations as necessary"
}

Stellen Sie einfach sicher, dass Ihre "Notex" -Namen nicht mit echten Feldern in Konflikt stehen.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top