От XML до JSON: решения, которые должен принять каждый

Двусмысленность, которой не может избежать ни один преобразователь

Рассмотрим `<items><item>x</item></items>`. Должен ли `item` быть строкой или списком? XML ничего не говорит, и разница имеет значение в тот момент, когда вы пишете для него код: потребитель, ожидающий разрыва всегда массива при одноэлементном ответе, и потребитель, ожидающий, что объект сломается, когда прибудет второй элемент. Зрелые преобразователи позволяют принудительно создавать массивы для известных элементов списка, а не молча гадать, потому что предположение оказывается верным достаточно часто, чтобы достичь рабочей версии.

Атрибутам необходимо соглашение об именах

JSON не имеет атрибутов, поэтому атрибут должен стать либо родственным ключом, либо вложенным объектом. Широко используемое соглашение добавляет к именам атрибутов префиксы `@` — `<image src="a.png"/>` становится `{"@src": "a.png"}` — тогда как текст элемента помещается в зарезервированный ключ, например `#text`, когда элемент имеет и атрибуты, и содержимое. Какое бы соглашение ни использовал преобразователь, его следует применять последовательно, поскольку полупреобразованный XML хуже, чем непреобразованный XML.

                <rss version="2.0"><channel><title>Feed</title></channel></rss>
→ {
  "rss": {
    "@version": "2.0",
    "channel": { "title": "Feed" }
  }
}
              

Пространства имен

Документы в пространстве имен — службы SOAP, карты сайта, форматы Office — определяют имена элементов как `ns:element`. JSON не имеет эквивалента, поэтому преобразователь либо удаляет префикс, либо сохраняет его как часть ключа, либо переупорядочивает документ вокруг URI пространства имен. Удаление его является обычным явлением, а иногда и катастрофическим, когда два пространства имен используют одно и то же локальное имя. Если в вашем документе используются пространства имен, проверьте выходные данные на предмет коллизий, прежде чем доверять им, и предпочитайте сохранять префикс в ключе.

Где на самом деле используется это преобразование

• RSS и Atom-каналы — чтение каналов в JavaScript после конвертации становится намного проще.
• SOAP и устаревшие API — превращение ответа во что-то, что может использовать современный клиент.
• Карты сайта и файлы конфигурации — проверка структуры без редактора, понимающего схемы.
• Миграция данных — перемещение записей из системы эпохи XML в систему, основанную на JSON.

Верность в обе стороны — это миф. Преобразование XML в JSON и обратно редко возвращает исходный документ побайтно, поскольку порядок объявления, пробелы, комментарии и CDATA не сохраняются. Преобразуйте, когда вам нужно использовать данные в другом месте, а не в качестве стратегии резервного копирования.

Сначала проверьте, затем преобразуйте

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