Null, пустая строка и отсутствующее поле

Поле может отсутствовать, присутствовать с null или содержать пустую строку. В JSON это три различимых состояния. Отсутствие нередко означает «источник не передавал это свойство», null — «значение неизвестно или явно очищено», пустая строка — «текст известен и имеет нулевую длину». Конкретный смысл определяет договорённость, но сам формат позволяет сохранить различие.

При частичном обновлении объекта эта разница особенно важна. Отсутствующее поле может означать оставить старое значение, а null — очистить его. Если клиент автоматически заменит оба случая пустой строкой, сервер потеряет возможность понять намерение. Поэтому правила обновления стоит описывать отдельно от правил хранения полного снимка.

В JSON Schema required отвечает за наличие свойства. Указание свойства в properties само по себе не делает его обязательным. Разрешение null задаётся типом, например объединением string и null. Проверка длины строки не заменяет проверку наличия, а запрет null не гарантирует непустой текст. Это независимые ограничения, которые полезно тестировать отдельно.

SQL NULL имеет собственную семантику. Сравнение через = NULL не выбирает строки с неизвестным значением; нужен IS NULL. Агрегаты могут пропускать NULL, поэтому COUNT(*) и COUNT(column) отвечают на разные вопросы. При экспорте таблицы обязательно решите, как эти состояния будут представлены в целевом формате и можно ли выполнить обратный импорт.

CSV хранит поля как текст и не задаёт общего значения null. Пустое поле, quoted пустое поле и строка NULL могут трактоваться получателями по-разному. Некоторые загрузчики различают кавычки, другие отдают только строковое значение. Поэтому одного образца таблицы недостаточно: нужен документированный маркер и правило экранирования самого маркера в обычном тексте.

TOML не имеет встроенного null. Пропуск ключа может быть приемлемым представлением необязательного значения, но тогда теряется различие между явной очисткой и отсутствием сообщения. Иногда лучше добавить отдельный флаг состояния или использовать другой формат. Выбор следует из модели данных, а не из желания сохранить одинаковые ключи во всех файлах.

Перед передачей таблицы полезно спросить не только о принимаемом расширении, но и о настройках импорта. Табличный редактор способен автоматически заменить пустые ячейки, распознать текстовый маркер как обычное слово или превратить идентификатор в число. Получатель должен подтвердить конкретный способ чтения образца. Сохраните маленький набор пограничных значений вместе с описанием ожидаемых состояний после импорта. Если разные программы дают разные результаты, это аргумент в пользу более явного контракта или другого формата. Важное различие лучше выразить отдельным полем состояния, чем надеяться на оформление ячейки. Цвет, комментарий редактора и визуальная пустота не являются переносимыми значениями CSV и обычно исчезают при сохранении текстового представления.

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

Не используйте конструкцию «значение или пустая строка» для универсальной подстановки. Во многих языках она заменит также ноль и false. Проверяйте именно отсутствие или именно null. В Python для словаря можно сначала проверить принадлежность ключа, затем отдельно сравнить значение с None. Так код непосредственно выражает предусмотренную модель.

В журнале импорта храните количество отсутствующих, пустых и отклонённых значений по важным колонкам. Резкое изменение этих чисел помогает обнаружить смену поведения источника. Если принимается решение объединить состояния, запишите его как потерю информации и задайте версию правила. Не называйте такое преобразование чистым форматированием: оно меняет смысл и может повлиять на последующие обновления.