Может ли быть ключ JSON составным?

Ключи в JSON: Простые строки и концепция "составного" ключа

Нет, в чистом стандарте JSON ключ объекта не может быть составным в том смысле, как это понимается в некоторых других структурах данных (например, составные ключи в базах данных). Согласно официальной спецификации (ECMA-404, RFC 8259), ключом в объекте JSON всегда должна быть строка (string), заключенная в двойные кавычки. Эта строка — атомарное, неделимое значение.

Однако на практике существует несколько распространенных техник для эмуляции или представления составной информации в роли ключа, что и приводит к вопросу. Давайте разберем это подробно.

Почему ключ — всегда строка: Синтаксис JSON

Синтаксис объекта JSON строго определен:

{
  "простой_ключ": "значение",
  "anotherKey": 123
}

Попытка использовать что-либо кроме строки (число, объект, массив) напрямую в качестве ключа приведет к невалидному JSON:

{
  42: "числовой ключ",          // НЕВАЛИДНО (без кавычек)
  ["часть1", "часть2"]: "value" // НЕВАЛИДНО
}

Валидный вариант — только если число или иное значение представлено как строка: "42".

Способы эмуляции "составного" ключа

На практике, когда требуется ассоциировать значение с несколькими параметрами (например, с координатами x=10, y=20 или с парой имя+фамилия), используют следующие подходы:

1. Конкатенация с разделителем

Самый частый и практичный способ. Составные части "склеиваются" в одну строку с помощью четко выбранного разделителя, который не встречается в самих данных.

{
  "user:1001": "Иванов Иван",
  "coord:10_20": "Точка A",
  "product-RU-MOSCOW": 1250
}

Недостаток: Необходимо экранировать или запрещать использование символа-разделителя в данных, а также парсить строку при чтении.

2. Вложенные объекты

Это наиболее структурированный и "родной" для JSON подход. Вместо составного ключа создается иерархия объектов.

{
  "users": {
    "1001": "Иванов Иван"
  },
  "coordinates": {
    "10": {
      "20": "Точка A"
    }
  },
  "productAvailability": {
    "RU": {
      "MOSCOW": 1250
    }
  }
}

Для доступа к значению используется цепочка ключей: productAvailability.RU.MOSCOW. Это чисто, читаемо и не требует парсинга строк.

3. Использование массива в качестве значения (а не ключа)

Часто задача, требующая составного ключа, решается иначе: составные части становятся полями объекта-значения, а уникальный ID — ключом. Или наоборот, ключом является ID, а составные данные лежат в массиве.

{
  "points": {
    "id1": {"x": 10, "y": 20, "name": "Точка A"},
    "id2": {"x": 15, "y": 25, "name": "Точка B"}
  }
}

Или с массивом в качестве ключа (но не ключа объекта!):

{
  "index": [
    [["Москва", "Россия"], "data_id_1"],
    [["Лондон", "Великобритания"], "data_id_2"]
  ]
}

Здесь ключом к внешнему объекту является строка "index", а внутри значения-массива лежат пары "составной идентификатор - значение".

Важное замечание: JSON vs JavaScript Object Literal

Путаница часто возникает из-за различий между текстовым форматом JSON и литералами объектов в JavaScript. В JavaScript (ES6+) существуют вычисляемые свойства объекта (computed properties), где ключом может быть результат выражения:

// Это JavaScript, а НЕ JSON
const keyPart1 = 'user';
const keyPart2 = 'Id';
const obj = {
  [keyPart1 + keyPart2 + '_1001']: 'John Doe', // Ключ: "userId_1001"
  [Symbol('composite')]: 'secret' // Использование Symbol
};

Обратите внимание: даже здесь итоговый ключ — это строка "userId_1001". Символ (Symbol) — это отдельный тип, но он не будет сериализован в JSON при использовании JSON.stringify().

Вывод для QA Engineer

Понимание этого нюанса критически важно при тестировании API:

1. Валидация: Тесты должны проверять, что API возвращает/принимает валидный JSON. Любая попытка передать не-строку в качестве ключа (без кавычек) должна приводить к понятной ошибке 400 Bad Request или подобной.
2. Тест-дизайн: При составлении тестовых данных, имитирующих составной ключ, нужно использовать правильные стратегии (конкатенацию или вложенность).
3. Документация: Следует проверять документацию API: если заявлена поддержка "составных" ключей, необходимо уточнить, какой именно формат (строковый с разделителем) ожидается.
4. Парсинг и граничные значения: Если используется ключ с разделителем (например, city:country), необходимо тестировать случаи, когда в самих данных встречается этот разделитель. Это классический источник уязвимостей или ошибок парсинга.

Итог: Прямого составного ключа в JSON нет, но потребность в нем прекрасно покрывается либо строковой конкатенацией, либо — что более правильно — проектированием вложенной структуры данных. Задача QA — понимать эти форматы и уметь тестировать системы, которые их используют.