javascript array umkopieren und teilweise umbenennen

[der henry]

Hallo,

ich bekomme ein Array aus meiner der Datenbank.

data = [{ 
	"datetime" : "2026-05-06 00:30:00",
	"daten1" : "123",
	"daten2" : "34,56",
	....
    "daten5" : "15.8.2005"
}];

Die möchte ich in ein Chartprogramm übertragen.

Das Chart benötigt pro Kurve:

dataCurve1 = [{ 
	"x" : "2026-05-06 00:30:00",
	"y" : "123",
}];

dataCurve2 = [{ 
	"x" : "2026-05-06 00:30:00",
	"y" : "34,56",
}];

Wie kann ich dies am einfachsten umkopieren/umbenennen ... es können schon ein paar tausend Messpunkte von der Datenbank kommen.

Mein Gedanke war, "data" von der Datenbank jeweils pro Kurve kopieren, nicht benötigte Schlüssel löschen und dann jweils die Schlüssel umbenennen.

Den Input von der Datenbank möchte ich "Standard" belassen.

Hat jemand eine bessere Idee?

Vielen Dank !!

[Rolf B]

Hallo henry,

Vorsicht beim „Kopieren“, JavaScript ist nicht PHP.

dataCurve1 = data;
// mit dataCurve1 rummachen
dataCurve2 = data;
// dataCurve2 enthält x,y Paare!

Abgesehen davon ist das Umbenennen von Objekteigenschaften auch nur durch Umkopieren möglich.

Daher:

• erzeuge 5 leere Arrays dataCurve1 bis dataCurve5
• laufe in einer Schleife durch data
• füge an Hand des aktuellen data Eintrags je einen Punkt an die Kurvenrrays an (z.B. per push-Methode)

Oder, wenn Du es lieber funktional hast, rufe 5 mal data.map() auf und übergib jeweils einen Callback, der aus datetime und einen der daten-Werte einen x,y Punkt macht.

Rolf

[Rolf B]

Hallo Henry,

mit der Array-Methode map könnte das so aussehen.

Für ein Chartprogramm ist es sicherlich eine gute Idee, korrekte Datentypen zu erhalten. Wenn dein Chartprogramm das selbst tun kann, dann kannst Du die Typumwandlung in deinem Script auch wegfallen lassen.

WENN Du es selbst tun musst, steckst Du tief im „de-DE vs en-us“ und „UTC vs CET“ Sumpf. Aber erstmal das Codebeispiel:

const data = [
  { datetime: "2026-05-06 00:30:00",
    daten1: "123", daten2: "34,56", daten5: "15.8.2005" },
  { datetime: "2026-05-06 00:40:00",
    daten1: "125", daten2: "17,56", daten5: "17.8.2005" },
  { datetime: "2026-05-06 00:50:00",
    daten1: "121", daten2: "24,96", daten5: "19.8.2005" },
];

const dataCurve1 = data.map(
        entry => ({ x: entry.datetime,
                    y: parseInt(entry.daten1) })
      );
const dataCurve2 = data.map(
        entry => ({ x: entry.datetime,
                    y: parseFloat(entry.daten2.replace(",", ".")) })
      );
const dataCurve5 = data.map(
        entry => ({ x: entry.datetime, 
                    y: parseGermanDate(entry.daten5) })
      );

function parseGermanDate(dateString) {
  const parts = dateString.split(".");

// Wähle aus, was für Dein Szenario richtig ist (Erklärung folgt)
  return new Date(parseInt(parts[2]),
                  parseInt(parts[1])-1,
                  parseInt(parts[0]));
// ODER
  return Date.UTC(parseInt(parts[2]),
                  parseInt(parts[1])-1,
                  parseInt(parts[0]));
// ODER
  return new Temporal.PlainDate(
      parseInt(parts[2]),
      parseInt(parts[1]),
      parseInt(parts[0])
    );
}

Für daten2 muss das Dezimalkomma in einen Dezimalpunkt umgewandelt werden. Einen Intl-Numberparser gibt es meines Wissens nicht. Ein replace-Aufruf ist die Minimallösung und setzt voraus, dass es sich um eine ansonsten korrekt aufgebaute Zahl handelt.

Für daten5 wird es richtig spannend. Date-Objekte, die aus Jahr, Monat und Tag erstellt werden, haben als Uhrzeit 0:00:00 lokaler Zeit. Das kann zu Abweichungen führen, wenn das Chartprogramm die UTC-Werte für das Datum abfragt. new Date(2026, 4, 6) liefert Dir den 6. Mai 2026 mit Zeitzonenoffset -120, d.h. wenn Du auf dieses Objekt getUTCDate() anwendest, bekommst Du eine 5 (weil die Zeit 2026-05-05T22:00:00 UTC ist). Wenn dein Chartprogramm so arbeitet, musst Du das Datum mit Date.UTC(year, month-1, day) erzeugen.

Wenn dein Chartprogramm und den Browser die Temporal-Klassen unterstützen, solltest Du das Problem umgehen und statt mit Date mit Temporal.PlainDate arbeiten. In dem Fall musst Du auch nicht 1 vom Monat abziehen.

Rolf

[der henry]

Hallo Rolf,

vielen Dank für die schnelle Rückmeldung.

Ich stecke noch fest ...

graphData => Daten aus der Datenbank

Ich möchte pro Messwert (Kurve) der aus der Datenbank kommt, ein eigenes Array anlegen. Dazu lese ich alle Schlüssel aus dem ersten Datensatz aus (Es sind ja alle gleich)

let dataCurve = [];
let z = 0;

for (const [key, value] of Object.entries(graphData[0])) 
	{
		if ( key === 'datetime') { continue; }
		dataCurve[z] = graphData.map( entry => ({ 
											x: entry.datetime,
											y: parseInt(entry.key) 
										   })
								);
		z++;
	}

Wie kann ich dem parseInt(entry ... eine Variable mitgeben ... denn ich weiß nicht wie die Namen der Messwerte sind, die von der database kommen, deshalb key?

Ein y: parseInt(entry.key) geht natürlich nicht, aber wie 😉

[Rolf B]

Hallo der henry,

bitte beachte auch die übrige Diskussion im Thread, da sind einige wichtige Details drin.

Zu deinem Ansatz:

Man kann es mit entries machen, aber ich würde ein Array aller Keys mit

const dataKeys = Object.getOwnPropertyNames(graphData[0])
                       .filter(n => n !== "datetime");

erzeugen (Umbruch vor .filter nach Belieben, ich hab's für die Forenlesbarkeit gemacht).

Das kannst Du dann einfach mit foreach durchlaufen und brauchst keine Abfrage mehr in der Schleife.

Um im Objekt entry auf die Eigenschaft zuzugreifen, deren Name in der Variablen key steht, verwendest Du die Schreibweise mit eckigen Klammern, die auch bei Arrays genutzt wird: entry[key].

Solange nur stumpf die Eigenschaftswerte kopierst, lässt sich das alles zu einem "Einzeiler" verdichten^[1], den ich aber lieber auf 9 Zeilen verteile 😉:

const dataCurves = 
   Object.getOwnPropertyNames(graphData[0])
   .filter(key => key !== "datetime")
   .map(
      key => graphData.map(
                        entry => ({ x: entry.datetime,
                                    y: entry[key] 
                                  })
                      )
   );

ABER

Wenn Du nicht weißt, welche Werte in graphData sind, hast Du ein Problem. Du hast unterschiedliche Datentypen, die Du ggf. aufbereiten musst. Du musst eine Legende und eine Y-Achsenbeschriftung erstellen. Die Frage ist auch, welchen Sinn es hat, Datumswerte (daten5) auf der Y-Achse eines Diagramms darzustellen, dessen X-Achse ein Timestamp ist.

D.h. aus meiner Sicht kannst Du gar nicht stumpf über die Keys der Datenpunkte latschen, da muss mehr Intelligenz hinein.

Rolf

---

1. Die Sprachen C und APL erlauben einzeilige Programme beliebiger Komplexität. JavaScript hat den Ehrgeiz, es ihnen gleich zu tun. ↩︎

[Felix Riesterer]

Lieber Rolf,

new Date(2026, 4, 6) liefert Dir den 6. Mai 2026 mit Zeitzonenoffset -120, d.h. wenn Du auf dieses Objekt getUTCDate() anwendest, bekommst Du eine 5 (weil die Zeit 2026-05-05T22:00:00 UTC ist).

das sollte irrelevant werden, wenn der Datetime-String der Datenbank verwendet wird:

const zeitpunkt = new Date("2026-05-06 00:30:00");

Es ist richtig, dass der Browser das mit der Zeitzone des Systems versieht und da heimlich ein T einbaut, sodass der String-Wert des Date-Objektes dann 2026-05-06T00:30:00 lautet, was im Vergleich zu UTC wegen der Sommerzeit bei uns einen Zweistundenvorsprung bedeutet. Aber für die Darstellung im Diagramm sollte das egal sein.

Liebe Grüße

Felix Riesterer

[Rolf B]

Hallo Felix,

es geht nicht um den datetime-Key, der ist fein im ISO-Format, sondern um daten5. Das ist im d.m.y-Format, und muss konvertiert werden, wenn das irgendwie gechartet werden soll. Denke ich jedenfalls…

Rolf

[Gunnar Bittersmann]

@@Rolf B

es geht nicht um den datetime-Key, der ist fein im ISO-Format

Das glaube ich nicht. Wäre mir neu, dass das ISO-Format ein Leerzeichen anstatt eines T zwischen Datum und Uhrzeit zuließe.

🖖 Live long and prosper

[Rolf B]

Hallo Gunnar,

na gut, es ist aber nahe genug dran, dass new Date() damit klarkommt.

Witzigerweise gibt selbst die ISO ein Beispiel ohne T. Den Standard selbst muss man für 181 Fränkli kaufen, da hab ich keine Lust drauf.

Rolf

[Felix Riesterer]

Lieber Henry,

data = [{ 
	"datetime" : "2026-05-06 00:30:00",
	"daten1" : "123",
	"daten2" : "34,56",
	....
    "daten5" : "15.8.2005"
}];

was ist das für eine Datenbank, die Dir Dezimalzahlen mit einem Komma anstelle eines Punktes ausgibt? Das müffelt verdächtig nach Microsoft, sowas wie Access. Und diesen Müll gibst Du ungefiltert an den Browser weiter? Das ist eine dämliche Idee. Was auch immer der Grund ist, warum Deine Datenbank die Daten in diesem vermurksten Format speichert, es ist kein Grund, dem Browser die Daten in einem so Web-fremden Format zu liefern!

Vermutlich sind Deine Schlüssel wie daten1, daten2 etc. für das Forum so umbenannt worden, sonst würde ich auch da anmeckern, dass bessere sprechende Bezeichner verwendet werden müssen.

Wenn der Browser diese Daten mit JavaScript verarbeiten soll, dann wäre es ja Unsinn, wenn die nicht bereits passend aufbereitet an ihn gehen. Ein Umkopieren sollte nicht in JavaScript, sondern bereits serverseitig erfolgen. Denn wo genau möchtest Du Anpassungen vornehmen müssen, wenn Deine Software mit einem Update die Daten einmal umstrukturiert, weil die neue Version das für sich so löst? Richtige Antwort: An der Quelle, also im serverseitigen Script, welches die Daten aus der Datenbank holt und für den Browser mundgerecht aufbereitet.

Außerdem verletzt Du sonst die Idee hinter der Trennung von Zuständigkeiten (separation of concerns), weil sich der Browser auf gar keinen Fall darum scheren sollte, welche Software ihre Daten wie in irgendeiner Datenbank speichert. Das sollte das serverseitige Script verwalten, welches die Daten an den Browser versendet. Ab da gilt nur noch der Web-Kontext, für den HTML/JS als Grundlage dient und wie Inhalte auf einer Internetseite abgebildet werden sollen. Von der ursprünglichen Software mit ihrer Datenbank darf da nix mehr übrig sein!

Die möchte ich in ein Chartprogramm übertragen.

Dann verlinke bitte gefälligst, welches Chart-Script Du verwendest, damit man Dir auch kompetent raten kann, wie Du die Daten serverseitig aufbereitest. Du bist doch nun lange genug hier, um zu wissen, dass fehlende Informationen in einem Frageposting die Qualität der Antworten nach unten drückt!

Den Input von der Datenbank möchte ich "Standard" belassen.

Und keine Erklärung, warum. Nein, das solltest Du auf gar keinen Fall so lassen, sondern von vornherein in ein JavaScript-kompatibles Format umwandeln, um dieses an den Browser zu senden!

Liebe Grüße

Felix Riesterer

[Rolf B]

Hallo Felix,

separation of concerns

Ja, da hast Du wohl recht, ich hätte mich auf eine clientseitige Konvertierung gar nicht einlassen dürfen.

Rolf

[Gunnar Bittersmann]

@@der henry

ich bekomme ein Array aus meiner der Datenbank.

data = [{ 
	"datetime" : "2026-05-06 00:30:00",
	"daten1" : "123",
	"daten2" : "34,56",
	....
    "daten5" : "15.8.2005"
}];

Warum hast du da irgendwelche Strings als Daten anstatt genormter Datentypen?

Statt 2026-05-06 00:30:00 sollte es 2026-05-06T00:30:00 sein (mind the gap!, wenn es eine Angabe in irgendeiner lokalen Zeitzone ist. Die Zeitzone sollte besser angegeben sein: 2026-05-06T00:30:00+02:00

Statt 34,56 – wenn es sich um eine Dezimalzahl handelt, nicht um zwei Zahlen (Koordinaten?) 34 und 56 – 34.56.

Die Schreibweise 15.8.2005 ist auch falsch. Richtig ist Tag und Monat zweistellig mit führender Null: 15.08.2005.

🖖 Live long and prosper

[Rolf B]

Hallo Gunnar Bittersmann,

das sieht zumindest partiell nach JSON aus und JSON kennt keine anderen Typen als Number und String. Date() ist es egal, ob da ein T steht oder nicht.

Aber ja, ein RFC 9557-konformer String mit dem T zwischen Datum und Zeit wäre grundsätzlich besser. Wenn die DB den nicht liefert, sollte man es serverseitig, wie Felix empfahl, hinbiegen.

Was ich übersehen hatte: Die datetime-Eigenschaft sollte einen Zonenoffset mitbekommen oder gleich als UTC geschickt werden, andernfalls gibt's einmal pro Herbst Rätselraten, ob es jetzt 02:30 Uhr Sommer- oder Winterzeit ist. Mein Solarwechselrichterhersteller macht so einen Scheiß, und für meine Trackingdatenbank muss ich prüfen, ob die CSV-Datei von jetzt auf gleich eine Stunde rückwärts springt, um das verarbeiten zu können. Im Frühjahr ist's wurscht…

Warum daten2 mit Komma kommt, ist tatsächlich merkwürdig. Wurde da ein numerischer Wert im deutschen Locale als String in der Datenbank abgelegt, anstatt ihn für die Speicherung in einen geeigneten Datentyp zu überführen?

'15.8.2005' als falsch zu bezeichnen halte ich für übertrieben. Es ist nicht DIN-konform, nehme ich an, aber FALSCH wäre sowas wie "10-8-2005", was man mit einem M-D-Y Format verwechseln kann.

Oder anders gesagt: Diese DB ist mutmaßlich ein Sanierungsfall, um nicht ständig unsauberen Daten hinterher programmieren zu müssen.

Rolf

[Gunnar Bittersmann]

@@Rolf B

'15.8.2005' als falsch zu bezeichnen halte ich für übertrieben.

Ich nicht. Wenn das so als String in der Datenbank steht, ist das wohl der falsche Datentyp. Und wenn ein Datum mit richtigem Datentyp in der Datenbank steht, solle man '15.08.2005' herausbekommen.

aber FALSCH wäre sowas wie "10-8-2005", was man mit einem M-D-Y Format verwechseln kann.

AFAIK verwenden die Amis für ihr Datum(un)format immer / als Trennzeichen.

Und die Verwechsungsgefahr besteht unabhängig vom Trennzeichen; ob nun . oder - oder /.

🖖 Live long and prosper

[Rolf B]

Hallo Gunnar Bittersmann,

Wenn das so als String in der Datenbank steht, ist das wohl der falsche Datentyp.

Winde Dich nicht davon. Du hast die Schreibweise als falsch bezeichnet, nicht den Datentyp 😉. Und mit mm-dd-yyyy habe ich mich geirrt, ja. Ein mm-dd-yyyy verwendet wohl niemand auf dieser Welt (zumindest ist die Liste der Datumsformat in der en-Wikipedia dieser Meinung). Aber wenn schon Schrott, dann auch richtig…

Dass das so nicht als String in die DB gehört, darüber sind wir uns einig.

Rolf

[der henry]

Hallo,

vielen Dank für euer Feedback.

Die Datenbank wird von verschiedenen Programmen/Herstellern, nicht nur von mir, gefüllt. Da man sich damals auf "jeder Messwert wird als String gespeichert" festgelegt hat, wird es immer so bleiben. Da in der Datenbank auch Messwerte in Hex und teilweise mit ASCII Zeichen gespeichert werden, ist String nicht so schlecht. Ausserdem werde ich dies nie ändern können.

Für mich (chart) werden nur gleitkomma und integer angezeigt.

Diverse Messwerte werden automatisch in bestimmten Zeitrastern gespeichert. Hierzu wird automatisch ein "datetime" mit jedem Messpunkt durch die Datenbank erzeugt ... so entsteht das "2026-05-06 00:30:00"

Wenn ich nun diese Archivdaten lese und per json zum Frontend sende, kommt das "datetime" so wie ich es gezeigt habe. Sicher kann ich jeweils ein "T" auf der Serverseite einfügen.

Die Daten sollen dann mittels "chart.js" grafisch angezeit werden. Bei chart.js bin ich kompletter Anfänger ...

 "daten5" : "15.8.2005"

War ein Fehler von mir, dies (Datum) gibt es in Zusammenhang mit chart.js nicht

So meine Herren, das ist meine aktuell Ausgangssituation.

Ich muss mich auch an gewisse Vorgaben halten und kann diese vllt. optimieren, aber sicher nicht von Grund auf verändern.

[Rolf B]

Hallo Henry,

Ich muss mich auch an gewisse Vorgaben halten und kann diese vllt. optimieren, aber sicher nicht von Grund auf verändern.

Das ist eine Eingangsvoraussetzung, die Du uns vielleicht mal irgendwann erzählt hast, aber nicht in diesem Thread und daher geriet das in Vergessenheit.

Wenn man sich nicht im Vorfeld auf bestimmte Datentypen festlegen konnte oder wollte, war „alles als String“ vermutlich die einzig sinnvolle Lösung. Dass Fließkommazahlen mit Dezimalkomma geschrieben werden, dürfte dann hystorisch gewachsen sein. Geschieht das zumindest konsistent? Oder hast Du ein fröhliches Durcheinander aus 47.11 und 8,15?

Das Format ohne T ist typisch für ein MYSQL Datetime, richtig. Du solltest das T aber trotzdem im PHP hinzufügen. Für den Date() Konstruktor ist es egal, aber mit T ist es eher normgerecht. Und falls Du mal irgendwann auf Temporal.PlainDateTime statt Date umsteigst, brauchst Du es eh.

Die Normierung auf Dezimalpunkt solltest Du definitiv auch am Server machen. Wenn Du definitiv und ausschließlich Integer- und Float-Werte vorfindest, dann kann reicht ein einfaches Ersetzen von "," durch ".".

Wie man mit chart.js spielt, weiß ich auch nicht.

Aber...

Für mich (chart) werden nur gleitkomma und integer angezeigt.

Heißt das, dass serverseitig bereits alles ausgefiltert wird, was weder float noch int ist? Oder heißt das, dass Du irgendwie herausfinden musst, welche Messwerte für Dich relevant sind, damit Du nicht versehentlich Hex-Strings an chart.js durchreichst? Good luck… - könnte es sinnvoll sein, wenn Du eine Liste von Messwertnamen vorhältst, die für Dich relevant sind und alle anderen gleich schon am Server ausfilterst? Je nachdem, wie die Datenbank ausieht (jeder Messpunkt eine Zeile) könnte man das schon im SQL tun…

Rolf

[MudGuard]

Hi,

Die Normierung auf Dezimalpunkt solltest Du definitiv auch am Server machen. Wenn Du definitiv und ausschließlich Integer- und Float-Werte vorfindest, dann kann reicht ein einfaches Ersetzen von "," durch ".".

sofern die Werte klein genug sind. Sonst könnte da 1.234,56 daherkommen …

cu,
Andreas a/k/a MudGuard

[der henry]

Hallo,

Gleitkommazahlen werden durchgehend mit Komma geschrieben, das ist Fakt.

Nur die "neueren Werte" können/werden mit Chart.js grafisch dargestellt und diese sind Integer aber überwiegend Gleitkommazahlen.

Das ein Hexwert oder ähnliches gelesen wird kann nicht passieren, und ich lasse ich schon bei der Auswahl nicht zu.

Die Normierung auf Dezimalpunkt solltest Du definitiv auch am Server machen. Wenn Du definitiv und ausschließlich Integer- und Float-Werte vorfindest, dann kann reicht ein einfaches Ersetzen von "," durch ". sofern die Werte klein genug sind. Sonst könnte da 1.234,56 daherkommen …

Ja, auf jedenfall auch größere Zahlen.

[Rolf B]

Hallo Henry und Mudguard,

ein Tausenderpunkt muss explizit hineinformatiert werden, ein Dezimalkomma ist - bei Float - nicht optional. Hast Du Tausenderpunkte (oder andere Lesbarkeitshilfen) drin?

Rolf

[der Henry]

… Nein, in der Database sind keine tausender-Trennzeichen und ich mache sicher keine hinein 😀

[Felix Riesterer]

Lieber Henry,

dann erstelle doch einmal einen kleinen Auszug aus einem echten Datensatz, wenn es die Geheimhaltung der Daten nicht verbietet! Dann kann man Dir raten, wie Du am besten die Daten für den Browser aufbereitest. Im JSON-Format hat es nämlich einen Sinn, dass man um die Zahlen keine Anführungszeichen macht, weil JSON die auch so als Literale versteht.

Liebe Grüße

Felix Riesterer

[Gunnar Bittersmann]

@@Felix Riesterer

Im JSON-Format hat es nämlich einen Sinn, dass man um die Zahlen keine Anführungszeichen macht, weil JSON die auch so als Literale versteht.

Aber Vorsicht!

{ "value": 47.11 } ist valides JSON;

{ "value": 47,11 } ist es nicht.

🖖 Live long and prosper

[Rolf B]

Hallo Gunnar,

weswegen Henry die Daten ja schon am Server sinnvoll aufbereiten sollte.

Rolf

[Felix Riesterer]

Lieber Gunnar,

{ "value": 47.11 } ist valides JSON;

{ "value": 47,11 } ist es nicht.

richtig. Die nach dem Komma folgende Zahl 11 würde als Schlüssel-Wert-Paar erwartet und kann das nicht erfüllen, weil es kein Paar (mit trennendem Doppelpunkt) ist. JSON wird in einem solchen Fall nicht fehlertolerant behandelt und deshalb auch nicht beispielsweise zu dem hier interpretiert:

{ "value": 47, 11: "" }

Liebe Grüße

Felix Riesterer

[Rolf B]

Hallo Felix,

was mir dazu gerade noch einfällt: dieses Szenario kann nur entstehen, wenn man den JSON String selbst baut.

Geht man von einem Objekt oder assoziativen Array aus und serialisiert es mit json_encode(), ist der Fehler unmöglich. Einen Wert vom Typ Number mit Dezimalkomma gibt es in PHP nicht. Man erhält deswegen entweder "47,11" oder 47.11, die Mischform 47,11 ist ausgeschlossen.

Rolf

[Felix Riesterer]

Lieber Rolf,

Geht man von einem Objekt oder assoziativen Array aus und serialisiert es mit json_encode(), ist der Fehler unmöglich. Einen Wert vom Typ Number mit Dezimalkomma gibt es in PHP nicht. Man erhält deswegen entweder "47,11" oder 47.11, die Mischform 47,11 ist ausgeschlossen.

wenn man aus 47,11 per str_replace() ein 47.11 macht, ist das kein Wert vom Typ Number, sondern noch immer ein String. Da wird auch json_encode() den Zahlenwert als String in seinen Anführungszeichen schreiben. Will man da „sauberes“ JSON erhalten, muss man das Ergebnis von str_replace() explizit in diesen Datentyp umwandeln. Entweder verwendet man dazu das Type-Casting $n = (float) str_replace(',', '.', $value);, oder eine passende Funktion wie floatval().

Liebe Grüße

Felix Riesterer

[Gunnar Bittersmann]

@@Felix Riesterer

{ "value": 47.11 } ist valides JSON;

{ "value": 47,11 } ist es nicht.

richtig. Die nach dem Komma folgende Zahl 11 würde als Schlüssel-Wert-Paar erwartet und kann das nicht erfüllen, weil es kein Paar (mit trennendem Doppelpunkt) ist.

Nicht nur das. Der Schlüssel muss ein String sein. Also nichts mit

{ "value": 47, 11: "" }

---

Dass JSON nicht fehlertolerant ist, ist mitunter nervig. Insbesondere, dass man kein Komma nach dem letzten Schlüssel-Wert-Paar bzw. dem letzen Item in einer Liste setzen darf.

In JSON 2 soll das möglich sein. Aber wird JSON 2 jemals möglich sein?

🖖 Live long and prosper