Kan ik opmerkingen in een JSON-bestand gebruiken? Zo ja, hoe?
Antwoord 1, autoriteit 100%
Nee.
De JSON bestaat alleen uit gegevens, en als u een opmerking opneemt, zijn het ook gegevens.
Je zou een aangewezen data-element kunnen hebben met de naam "_comment" (of zoiets) dat moet worden genegeerd door apps die de JSON-gegevens gebruiken.
U zou waarschijnlijk beter de opmerking hebben in de processen die de JSON genereren/ontvangen, omdat ze verondersteld worden van tevoren te weten wat de JSON-gegevens zullen zijn, of in ieder geval de structuur ervan.
Maar als je besluit om:
{
"_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"
}
}
}
}
}
Antwoord 2, autoriteit 32%
Nee, opmerkingen in de vorm //… of /*…*/ zijn niet toegestaan in JSON. Dit antwoord is gebaseerd op:
- https://www.json.org
- RFC 4627:
Het mediatypeapplication/jsonvoor JavaScript Object Notation (JSON) - RFC 8259 The JavaScript Object Notation (JSON) Data Interchange Format (vervangt RFC’s 4627, 7158 , 7159)
Antwoord 3, autoriteit 14%
Voeg eventueel opmerkingen toe; verwijder ze met een minifier voordat ze worden geparseerd of verzonden.
Ik heb zojuist JSON.minify() uitgebracht, wat eruit komt opmerkingen en witruimte van een JSON-blok en maakt het een geldige JSON die kan worden geparseerd. Je zou het dus als volgt kunnen gebruiken:
JSON.parse(JSON.minify(my_str));
Toen ik het uitbracht, kreeg ik een enorme reactie van mensen die het zelfs niet eens waren met het idee ervan, dus besloot ik een uitgebreide blogpost te schrijven over waarom opmerkingen zijn logisch in JSON. Het bevat deze opmerkelijke opmerking van de maker van JSON:
Stel dat u JSON gebruikt om configuratiebestanden te bewaren, die u wilt annoteren. Ga je gang en voeg alle opmerkingen in die je leuk vindt. Leid het vervolgens door JSMin voordat u het aan uw JSON-parser geeft. – Douglas Crockford, 2012
Hopelijk is dit nuttig voor degenen die het niet eens zijn met waarom JSON.minify() nuttig zou kunnen zijn.
Antwoord 4, autoriteit 8%
Reacties zijn met opzet uit JSON verwijderd.
Ik heb opmerkingen uit JSON verwijderd omdat ik zag dat mensen ze gebruikten om richtlijnen voor parsering vast te houden, een praktijk die de interoperabiliteit zou hebben vernietigd. Ik weet dat het gebrek aan reacties sommige mensen verdrietig maakt, maar dat zou niet moeten.
Stel dat u JSON gebruikt om configuratiebestanden te bewaren, die u wilt annoteren. Ga je gang en voeg alle opmerkingen in die je leuk vindt. Leid het vervolgens door JSMin voordat je het aan je JSON-parser geeft.
Bron: Openbare verklaring van Douglas Crockford op Google+
Antwoord 5, autoriteit 5%
JSON ondersteunt geen opmerkingen. Het was ook nooit bedoeld om te worden gebruikt voor configuratiebestanden waar commentaar nodig zou zijn.
Hjson is een configuratiebestandsindeling voor mensen. Ontspannen syntaxis, minder fouten, meer opmerkingen.
Zie hjson.github.io voor JavaScript, Java, Python, PHP, Rust, Go, Ruby, C++- en C#-bibliotheken.
Antwoord 6, autoriteit 4%
DISCLAIMER: UW GARANTIE IS NIETIG
Zoals is opgemerkt, maakt deze hack gebruik van de implementatie van de specificatie. Niet alle JSON-parsers zullen dit soort JSON begrijpen. Vooral streaming-parsers zullen stikken.
Het is een interessante curiositeit, maar je zou het echt nergens voor moeten gebruiken. Hieronder staat het originele antwoord.
Ik heb een kleine hack gevonden waarmee je opmerkingen in een JSON-bestand kunt plaatsen die het parseren niet beïnvloeden, of de gegevens die worden weergegeven op enigerlei wijze wijzigen.
Het lijkt erop dat wanneer u een object letterlijk verklaart, u twee waarden kunt specificeren met dezelfde sleutel, en de laatste heeft voorrang. Geloof het of niet, het blijkt dat JSON-parsers op dezelfde manier werken. We kunnen dit dus gebruiken om opmerkingen in de bron-JSON te maken die niet aanwezig zullen zijn in een geparseerde objectrepresentatie.
({a: 1, a: 2});
// => Object {a: 2}
Object.keys(JSON.parse('{"a": 1, "a": 2}')).length;
// => 1
Als we deze techniek toepassen, kan uw JSON-bestand met commentaar er als volgt uitzien:
{
"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]
}
De bovenstaande code is geldige JSON. Als je het analyseert, krijg je een object als dit:
{
"api_host": "hodorhodor.com",
"retry_interval": 10,
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favorite_numbers": [19,13,53]
}
Wat betekent dat er geen spoor van de opmerkingen is en dat ze geen rare bijwerkingen hebben.
Veel plezier met hacken!
Antwoord 7, autoriteit 2%
Overweeg om YAML te gebruiken. Het is bijna een superset van JSON (vrijwel alle geldige JSON is geldige YAML) en het staat opmerkingen toe.
Antwoord 8, autoriteit 2%
Dat kan niet. Dat is tenminste mijn ervaring na een snelle blik op json.org.
JSON heeft zijn syntaxis gevisualiseerd op die pagina. Er is geen opmerking over opmerkingen.
Antwoord 9, autoriteit 2%
Opmerkingen zijn geen officiële standaard, hoewel sommige parsers opmerkingen in C++-stijl ondersteunen. Een die ik gebruik is JsonCpp. In de voorbeelden is er deze:
// 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 valideert dit niet. Reacties zijn dus een parser-specifieke extensie en niet standaard.
Een andere parser is JSON5.
Een alternatief voor JSON TOML.
Een ander alternatief is jsonc.
De nieuwste versie van nlohmann/json heeft optionele ondersteuning voor het negeren van opmerkingen over ontleden.
Antwoord 10
Je moet in plaats daarvan een JSON-schema schrijven. JSON-schema is momenteel een voorgestelde internetconceptspecificatie. Naast documentatie kan het schema ook worden gebruikt voor het valideren van uw JSON-gegevens.
Voorbeeld:
{
"description":"A person",
"type":"object",
"properties":
{
"name":
{
"type":"string"
},
"age":
{
"type":"integer",
"maximum":125
}
}
}
U kunt documentatie verstrekken door het schemakenmerk description te gebruiken.
Antwoord 11
Als u Jackson als uw JSON-parser gebruikt, kunt u dit als volgt inschakelen om opmerkingen toe te staan:
ObjectMapper mapper = new ObjectMapper().configure(Feature.ALLOW_COMMENTS, true);
Dan kun je opmerkingen als deze hebben:
{
key: "value" // Comment
}
En je kunt ook opmerkingen hebben die beginnen met # door het volgende in te stellen:
mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);
Maar in het algemeen (zoals eerder beantwoord) staat de specificatie geen opmerkingen toe.
Antwoord 12
Dit is wat ik heb gevonden in de Google Firebase-documentatie waarmee u opmerkingen in JSON kunt plaatsen:
{
"//": "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"
}
Antwoord 13
NEE. JSON ondersteunde opmerkingen, maar deze werden misbruikt en verwijderd uit de standaard.
Van de maker van JSON:
Ik heb opmerkingen uit JSON verwijderd omdat ik zag dat mensen ze gebruikten om richtlijnen voor parsering vast te houden, een praktijk die de interoperabiliteit zou hebben vernietigd. Ik weet dat het gebrek aan commentaar sommige mensen verdrietig maakt, maar dat zou niet moeten. – Douglas Crockford, 2012
De officiële JSON-site is op JSON.org. JSON is door ECMA International gedefinieerd als een standaard. Er is altijd een verzoekschriftprocedure om normen te laten herzien. Het is om verschillende redenen onwaarschijnlijk dat annotaties aan de JSON-standaard worden toegevoegd.
JSON by design is een eenvoudig reverse-engineered (door mensen ontleed) alternatief voor XML. Het is zelfs zo vereenvoudigd dat annotaties niet nodig zijn. Het is niet eens een opmaaktaal. Het doel is stabiliteit en interoperabiliteit.
Iedereen die de “heeft-een”-relatie van objectoriëntatie begrijpt, kan elke JSON-structuur begrijpen – dat is het hele punt. Het is gewoon een gerichte acyclische grafiek (DAG) met knooppunttags (sleutel/waarde-paren), wat een bijna universele gegevensstructuur is.
Deze enige vereiste annotatie kan “//Dit zijn DAG-tags” zijn. De sleutelnamen kunnen zo informatief zijn als nodig is, waardoor willekeurige semantische ariteit mogelijk is.
Elk platform kan JSON ontleden met slechts een paar regels code. XML vereist complexe OO-bibliotheken die op veel platforms niet levensvatbaar zijn.
Annotaties zouden JSON alleen maar minder interoperabel maken. Er is gewoon niets anders toe te voegen, tenzij je echt een opmaaktaal (XML) nodig hebt, en het niet uitmaakt of je persistente gegevens gemakkelijk kunnen worden geparseerd.
MAAR zoals de maker van JSON ook opmerkte, is er altijd JS-pijplijnondersteuning geweest voor opmerkingen:
Ga je gang en voeg alle opmerkingen in die je leuk vindt.
Leid het vervolgens door JSMin voordat u het aan uw JSON-parser geeft. – Douglas Crockford, 2012
Antwoord 14
Als uw tekstbestand, dat een JSON-tekenreeks is, door een programma wordt gelezen, hoe moeilijk zou het dan zijn om opmerkingen in C- of C++-stijl te verwijderen voordat u het gebruikt?
Antwoord: het zou een oneliner zijn. Als u dat doet, kunnen JSON-bestanden worden gebruikt als configuratiebestanden.
Antwoord 15
Als u de Newtonsoft.Json-bibliotheek met ASP.NET gebruikt om te lezen/deserialiseren, kunt u opmerkingen in de JSON-inhoud gebruiken:
//"naam": "string"
//"id": int
of
/* Dit is een
commentaar voorbeeld */
PS: Enkelregelige opmerkingen worden alleen ondersteund met 6+ versies van Newtonsoft Json.
Aanvullende opmerking voor mensen die niet out-of-the-box kunnen denken: ik gebruik het JSON-formaat voor basisinstellingen in een ASP.NET-webtoepassing die ik heb gemaakt. Ik lees het bestand, converteer het naar het instellingenobject met de Newtonsoft-bibliotheek en gebruik het indien nodig.
Ik schrijf liever opmerkingen over elke individuele instelling in het JSON-bestand zelf, en de integriteit van het JSON-formaat interesseert me niet zo lang als de bibliotheek die ik gebruik er in orde mee is.
Ik denk dat dit een ‘gemakkelijker te gebruiken/begrijpen’ manier is dan een apart ‘settings.README’-bestand te maken en de instellingen daarin uit te leggen.
Als je een probleem hebt met dit soort gebruik; sorry, de geest is uit de lamp. Mensen zouden andere manieren vinden om het JSON-formaat te gebruiken, en je kunt er niets aan doen.
Antwoord 16
Het idee achter JSON is om eenvoudige gegevensuitwisseling tussen applicaties mogelijk te maken. Deze zijn meestal webgebaseerd en de taal is JavaScript.
Het staat niet echt opmerkingen als zodanig toe, maar het doorgeven van een opmerking als een van de naam/waarde-paren in de gegevens zou zeker werken, hoewel die gegevens uiteraard moeten worden genegeerd of specifiek door de parseercode moeten worden behandeld .
Dat gezegd hebbende, het is niet de bedoeling dat het JSON-bestand commentaar in de traditionele zin zou bevatten. Het zouden alleen de gegevens moeten zijn.
Bekijk de JSON-website voor meer informatie.
Antwoord 17
JSON ondersteunt native opmerkingen niet, maar je kunt je eigen decoder maken of op zijn minst een preprocessor om opmerkingen te verwijderen, dat is prima (zolang je opmerkingen gewoon negeert en ze niet gebruikt om te bepalen hoe je toepassing moet verwerken de JSON-gegevens).
JSON heeft geen opmerkingen. Een JSON-encoder MAG GEEN opmerkingen uitvoeren.
Een JSON-decoder KAN opmerkingen accepteren en negeren.Opmerkingen mogen nooit worden gebruikt om iets zinnigs over te brengen. Dat is
waar JSON voor is.
Zie: Douglas Crockford, auteur van JSON-specificatie.
Antwoord 18
Ik kom dit net tegen voor configuratiebestanden. Ik wil geen XML (uitgebreid, grafisch, lelijk, moeilijk leesbaar), of “ini”-formaat (geen hiërarchie, geen echte standaard, enz.) of Java “Eigenschappen”-formaat ( zoals .ini).
JSON kan alles wat ze kunnen, maar het is veel minder uitgebreid en beter leesbaar voor mensen – en parsers zijn gemakkelijk en alomtegenwoordig in veel talen. Het is gewoon een gegevensboom. Maar out-of-band opmerkingen zijn vaak een noodzaak om “standaard” configuraties en dergelijke te documenteren. Configuraties mogen nooit “volledige documenten” zijn, maar bomen van opgeslagen gegevens die indien nodig door mensen kunnen worden gelezen.
Ik denk dat je "#": "comment" zou kunnen gebruiken voor “geldige” JSON.
Antwoord 19
Het hangt af van uw JSON-bibliotheek. Json.NET ondersteunt opmerkingen in JavaScript-stijl, /* commment */ .
Bekijk een andere Stack Overflow-vraag.
Antwoord 20
JSON heeft veel zin voor configuratiebestanden en ander lokaal gebruik, omdat het alomtegenwoordig is en omdat het veel eenvoudiger is dan XML.
Als mensen sterke redenen hebben om geen opmerkingen te hebben in JSON bij het communiceren van gegevens (al dan niet geldig), dan kan JSON mogelijk in tweeën worden gesplitst:
- JSON-COM: JSON op de draad, of regels die van toepassing zijn bij het communiceren van JSON-gegevens.
- JSON-DOC: JSON-document of JSON in bestanden of lokaal. Regels die een geldig JSON-document definiëren.
JSON-DOC staat opmerkingen toe en er kunnen andere kleine verschillen zijn, zoals het omgaan met witruimte. Parsers kunnen gemakkelijk van de ene specificatie naar de andere converteren.
Met betrekking tot de opmerking gemaakt door Douglas Crockford over deze kwestie (verwezen door @Artur Czajka)
Stel dat u JSON gebruikt om configuratiebestanden te bewaren, die u wilt annoteren. Ga je gang en voeg alle opmerkingen in die je leuk vindt. Leid het vervolgens door JSMin voordat je het aan je JSON-parser geeft.
We hebben het over een algemeen probleem met het configuratiebestand (cross-taal/platform), en hij antwoordt met een specifiek JS-hulpprogramma!
Natuurlijk kan een JSON-specifieke minify in elke taal worden geïmplementeerd,
maar standaardiseer dit zodat het alomtegenwoordig wordt op alle parsers in alle talen en platforms, zodat mensen stoppen hun tijd te verspillen aan het ontbreken van de functie omdat ze er goede gebruiksscenario’s voor hebben, het probleem opzoeken in online forums en mensen laten vertellen dat het een slecht idee is of suggereren dat het gemakkelijk is om het verwijderen van opmerkingen uit tekstbestanden te implementeren.
Het andere probleem is interoperabiliteit. Stel dat u een bibliotheek of API heeft of een ander subsysteem waaraan configuratie- of gegevensbestanden zijn gekoppeld. En dit subsysteem is
vanuit verschillende talen te benaderen. Ga je dan mensen vertellen: tussen haakjes
vergeet niet de opmerkingen uit de JSON-bestanden te verwijderen voordat u ze doorgeeft aan de parser!
Antwoord 21
Als je JSON5 gebruikt, kun je opmerkingen toevoegen.
JSON5 is een voorgestelde uitbreiding van JSON die tot doel heeft het voor mensen gemakkelijker te maken om met de hand te schrijven en te onderhouden. Het doet dit door enkele minimale syntaxisfuncties rechtstreeks vanuit ECMAScript 5 toe te voegen.
Antwoord 22
Met de Dojo Toolkit JavaScript-toolkit (ten minste vanaf versie 1.4), kunt u opmerkingen opnemen in uw JSON. De opmerkingen kunnen van het formaat /*…*/ zijn. Dojo Toolkit verbruikt de JSON via de dojo.xhrGet() aanroep.
Andere JavaScript-toolkits werken mogelijk op dezelfde manier.
Dit kan handig zijn bij het experimenteren met alternatieve gegevensstructuren (of zelfs gegevenslijsten) voordat u een laatste optie kiest.
Antwoord 23
JSON is geen ingelijst protocol. Het is een taalvrij formaat. Het formaat van een opmerking is dus niet gedefinieerd voor JSON.
Zoals veel mensen hebben gesuggereerd, zijn er enkele trucjes, bijvoorbeeld dubbele sleutels of een specifieke sleutel _comment die u kunt gebruiken. Het is aan jou.
Antwoord 24
Je mag opmerkingen hebben in JSONP, maar niet in pure JSON. Ik heb net een uur geprobeerd om mijn programma te laten werken met dit voorbeeld van Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?
Als u de link volgt, ziet u
?(/* AAPL historical OHLC data from the Google Finance API */
[
/* May 2006 */
[1147651200000,67.79],
[1147737600000,64.98],
...
[1368057600000,456.77],
[1368144000000,452.97]
]);
Aangezien ik een soortgelijk bestand in mijn lokale map had, waren er geen problemen met de Same-origin policy, dus besloot ik pure JSON te gebruiken… en natuurlijk faalde $.getJSON stil vanwege de opmerkingen.
Uiteindelijk heb ik zojuist een handmatig HTTP-verzoek naar het bovenstaande adres gestuurd en realiseerde ik me dat het inhoudstype text/javascript was, aangezien JSONP puur JavaScript retourneert. In dit geval zijn opmerkingen toegestaan. Maar mijn applicatie retourneerde content-type application/json, dus ik moest de opmerkingen verwijderen.
Antwoord 25
Disclaimer: dit is dom
Er is een manier om opmerkingen toe te voegen en binnen de specificatie te blijven (geen extra parser nodig). Het zal echter niet resulteren in voor mensen leesbare opmerkingen zonder enige vorm van ontleden.
Je zou het volgende kunnen misbruiken:
Onbeduidende witruimte is toegestaan voor of na een token.
Witruimte is een willekeurige reeks van een of meer van de volgende code
punten: tekentabel (U+0009), regelinvoer (U+000A), regel
return (U+000D) en spatie (U+0020).
Op een hacky manier kun je dit misbruiken om een opmerking toe te voegen. Bijvoorbeeld: begin en eindig je reactie met een tab. Codeer de opmerking in base3 en gebruik de andere witruimtetekens om ze weer te geven. Bijvoorbeeld.
010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202
(hello base three in ASCII) Maar in plaats van 0, gebruik spatie, voor 1 gebruik regelinvoer en voor 2 gebruik regelterugloop.
Hierdoor krijg je alleen maar veel onleesbare witruimte (tenzij je een IDE-plug-in maakt om deze on-the-fly te coderen/decoderen).
Ik heb dit om voor de hand liggende redenen niet eens geprobeerd, en jij ook niet.
Antwoord 26
Ja, de nieuwe standaard, JSON5 staat opmerkingen in C++-stijl toe , tussen vele andere extensies:
// A single line comment.
/* A multi-
line comment. */
Het JSON5 Data Interchange Format (JSON5) is een superset van JSON die tot doel heeft enkele van de beperkingen van JSON te verminderen. Het is volledig achterwaarts compatibel en het gebruik ervan is waarschijnlijk beter dan het schrijven van de aangepaste niet-standaard parser, het inschakelen van niet-standaard functies voor de bestaande of het gebruiken van verschillende hacks zoals stringvelden voor commentaar. Of, als de gebruikte parser dit ondersteunt, ga er gewoon mee akkoord we gebruiken JSON 5-subset, dat wil zeggen JSON- en C++-stijlopmerkingen. Het is veel beter dan we passen de JSON-standaard aan naar eigen inzicht.
Er is al een npm-pakket, Python-pakket, Java-pakket en C-bibliotheek beschikbaar. Het is achterwaarts compatibel. Ik zie geen reden om bij de "officiële" JSON-beperkingen.
Ik denk dat het verwijderen van opmerkingen uit JSON dezelfde redenen heeft als het verwijderen van de overbelasting van de operator in Java: het kan op de verkeerde manier worden gebruikt, maar een aantal duidelijk legitieme use-cases werden over het hoofd gezien. Voor overbelasting door operators zijn dit matrixalgebra en complexe getallen. Voor JSON-opmerkingen zijn het configuratiebestanden en andere documenten die kunnen worden geschreven, bewerkt of gelezen door mensen en niet alleen door parser.
Antwoord 27
Dit is een ‘kun je’-vraag. En hier is een “ja” antwoord.
Nee, u moet geen dubbele objectleden gebruiken om zijkanaalgegevens in een JSON-codering te proppen. (Zie “De namen binnen een object MOETEN uniek zijn” in de RFC).
En ja, u kunt opmerkingen invoegen rond de JSON, die u zou kunnen ontleden.
Maar als u een manier wilt om willekeurige zijkanaalgegevens in te voegen en te extraheren naar een geldige JSON, dan is hier een antwoord. We profiteren van de niet-unieke weergave van gegevens in een JSON-codering. Dit is toegestaan* in sectie twee van de RFC onder “witruimte is toegestaan voor of na een van de zes structurele tekens”.
*In de RFC staat alleen “witruimte is toegestaan voor of na een van de zes structurele tekens”, waarbij strings, cijfers, “false”, “true” en “niet expliciet worden genoemd. nul”. Deze omissie wordt genegeerd in ALLE implementaties.
Kanoniseer eerst uw JSON door deze te verkleinen:
$jsonMin = json_encode(json_decode($json));
Encodeer uw commentaar vervolgens in binair:
$hex = unpack('H*', $comment);
$commentBinary = base_convert($hex[1], 16, 2);
Steg vervolgens uw binaire bestand:
$steg = str_replace('0', ' ', $commentBinary);
$steg = str_replace('1', "\t", $steg);
Hier is je output:
$jsonWithComment = $steg . $jsonMin;
Antwoord 28
In mijn geval moet ik opmerkingen gebruiken voor foutopsporingsdoeleinden net voor de uitvoer van de JSON. Dus plaatste ik de foutopsporingsinformatie in de HTTP-header om te voorkomen dat de client wordt verbroken:
header("My-Json-Comment: Yes, I know it's a workaround ;-) ");
Antwoord 29
JSON staat op zich geen opmerkingen toe. De redenering is volkomen dwaas, omdat je JSON zelf kunt gebruiken om opmerkingen te maken, waardoor de redenering volledig wordt ondervangen, en de parser-gegevensruimte zonder enige goede reden laadt voor exact hetzelfde resultaat en mogelijke problemen, zoals ze zijn: een JSON-bestand met opmerkingen.
Als je commentaar probeert te geven (bijvoorbeeld met
//of/*…*/of#), dan sommige parsers zullen mislukken omdat dit strikt genomen niet is
binnen de JSON-specificatie. Dus je moet dat nooit doen.
Hier bijvoorbeeld, waar mijn beeldmanipulatiesysteem beeldnotaties heeft opgeslagen en enkele basisformaten heeft (commentaar) informatie met betrekking tot hen (onderaan):
{
"Notations": [
{
"anchorX": 333,
"anchorY": 265,
"areaMode": "Ellipse",
"extentX": 356,
"extentY": 294,
"opacity": 0.5,
"text": "Elliptical area on top",
"textX": 333,
"textY": 265,
"title": "Notation 1"
},
{
"anchorX": 87,
"anchorY": 385,
"areaMode": "Rectangle",
"extentX": 109,
"extentY": 412,
"opacity": 0.5,
"text": "Rect area\non bottom",
"textX": 98,
"textY": 385,
"title": "Notation 2"
},
{
"anchorX": 69,
"anchorY": 104,
"areaMode": "Polygon",
"extentX": 102,
"extentY": 136,
"opacity": 0.5,
"pointList": [
{
"i": 0,
"x": 83,
"y": 104
},
{
"i": 1,
"x": 69,
"y": 136
},
{
"i": 2,
"x": 102,
"y": 132
},
{
"i": 3,
"x": 83,
"y": 104
}
],
"text": "Simple polygon",
"textX": 85,
"textY": 104,
"title": "Notation 3"
}
],
"imageXW": 512,
"imageYW": 512,
"imageName": "lena_std.ato",
"tinyDocs": {
"c01": "JSON image notation data:",
"c02": "-------------------------",
"c03": "",
"c04": "This data contains image notations and related area",
"c05": "selection information that provides a means for an",
"c06": "image gallery to display notations with elliptical,",
"c07": "rectangular, polygonal or freehand area indications",
"c08": "over an image displayed to a gallery visitor.",
"c09": "",
"c10": "X and Y positions are all in image space. The image",
"c11": "resolution is given as imageXW and imageYW, which",
"c12": "you use to scale the notation areas to their proper",
"c13": "locations and sizes for your display of the image,",
"c14": "regardless of scale.",
"c15": "",
"c16": "For Ellipses, anchor is the center of the ellipse,",
"c17": "and the extents are the X and Y radii respectively.",
"c18": "",
"c19": "For Rectangles, the anchor is the top left and the",
"c20": "extents are the bottom right.",
"c21": "",
"c22": "For Freehand and Polygon area modes, the pointList",
"c23": "contains a series of numbered XY points. If the area",
"c24": "is closed, the last point will be the same as the",
"c25": "first, so all you have to be concerned with is drawing",
"c26": "lines between the points in the list. Anchor and extent",
"c27": "are set to the top left and bottom right of the indicated",
"c28": "region, and can be used as a simplistic rectangular",
"c29": "detect for the mouse hover position over these types",
"c30": "of areas.",
"c31": "",
"c32": "The textx and texty positions provide basic positioning",
"c33": "information to help you locate the text information",
"c34": "in a reasonable location associated with the area",
"c35": "indication.",
"c36": "",
"c37": "Opacity is a value between 0 and 1, where .5 represents",
"c38": "a 50% opaque backdrop and 1.0 represents a fully opaque",
"c39": "backdrop. Recommendation is that regions be drawn",
"c40": "only if the user hovers the pointer over the image,",
"c41": "and that the text associated with the regions be drawn",
"c42": "only if the user hovers the pointer over the indicated",
"c43": "region."
}
}
Antwoord 30
We gebruiken strip-json-comments voor ons project. Het ondersteunt zoiets als:
/*
* Description
*/
{
// rainbows
"unicorn": /* ? */ "cake"
}
Gewoon npm install --save strip-json-comments om het als volgt te installeren en te gebruiken:
var strip_json_comments = require('strip-json-comments')
var json = '{/*rainbows*/"unicorn":"cake"}';
JSON.parse(strip_json_comments(json));
//=> {unicorn: 'cake'}