Русский

Инструменты разработчика · Конвертеры синтаксиса

Отсутствующий стандарт CSV: что RFC покрывает 4180 и что он оставляет открытым

· Фон

csv JSON форматы данных

CSV полей с запятыми, двойными кавычками и CRLF записей, созданных из JSON строк
Оригинальная векторная иллюстрация ToolAcre

CSV предшествует любой спецификации, а описание RFC является информационным и намеренно узким. В этом посте объясняется, что определяет RFC 4180, о чем он ничего не говорит и почему преобразование CSV всегда требует переговоров.

Чей CSV правильный? — два экспорта одной и той же таблицы, один с точкой с запятой, другой с запятыми, оба называются CSV

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

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

Два варианта разделителя являются параметрами вывода, а не свидетельством того, что эта панель читает какой-либо файл.

Репозиторий не содержит источников ранней истории электронных таблиц или баз данных, поэтому в статье не придумывается хронология. Он начинается с текущего модуля записи и его тестов: записей, полей, разделителей, завершения CRLF и экранирования кавычек.

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

История CSV до RFC 4180 является свидетельством вне репозитория

Поле, содержащее разделитель, двойную кавычку, возврат каретки или перевод строки, заключено в двойные кавычки, и каждая встроенная кавычка удваивается. Ведущие или конечные пробелы также заключаются в кавычки, чтобы предотвратить обычную обрезку электронных таблиц. Записи заканчиваются на CRLF, и файл закрывается.

Такое поведение соответствует правилам стиля RFC 4180, протестированным в репозитории. Статья избегает претензий на универсальное соответствие, поскольку автор также поддерживает альтернативные разделители и добавляет обработку безопасности за пределами узкой грамматики.

Автор использует цитирование в стиле RFC 4180 и CRLF, не заявляя о полном соответствии стандартам.

Ячейки CSV не сохраняют типы JSON. Нулевая и пустая строка становятся пустыми ячейками, а логические значения и числа становятся текстовыми представлениями. Содержимое UTF-8 передается, и для потребителей, которым он нужен, может быть добавлен необязательный префикс BOM.

Интерпретация локали не встроена. Разделитель точка с запятой может сосуществовать с десятичными запятыми, но средство записи не переформатирует числа по языковому стандарту и не кодирует тип даты. Принимающее приложение по-прежнему решает, как интерпретировать каждое поле.

В этом авторе остаются явными границы кодировки, типа и локали.

Реализованные варианты: запятая, точка с запятой и табуляция, а также необязательный BOM. Текст в виде формулы, начинающийся с `=`, `+`, `-`, `@`, табуляции или возврата каретки, по умолчанию имеет префикс апострофа, поэтому электронные таблицы обрабатывают его как текст. Пользователи могут отключить эту защиту и получить предупреждение.

В этом средстве записи нет подсказки `sep=` или режима обратной косой черты. Упоминание о них как о поставляемых опциях было бы неверным. Во встроенных кавычках используется удвоение, как и утверждают тесты.

Наблюдаемые варианты электронных таблиц ограничиваются опциями и средствами защиты, реализованными здесь.

Каждое предположение в этом маршруте начинается с анализируемого JSON: какое значение обеспечивает строки, как вложение выравнивается в пунктирные столбцы и какие ключи становятся заголовками. Никаких предположений о входящем диалекте CSV не делается, поскольку входящий CSV отклоняется.

Это исправление меняет запрошенное направление книги на противоположное. Рабочий процесс от CSV до JSON должен выбирать разделитель, кавычки, заголовок и типы ячеек в другом инструменте. Ошибка ToolAcre объясняет этот отказ, а не тихое предположение.

Предположения о преобразовании применяются к JSON-в-CSV только потому, что вход CSV отклонен.

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

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

Вывод: CSV — это соглашение, а не формат. Вы можете проверить, как панель конвертеров синтаксиса превращает правильно сформированный файл в JSON.

Считайте CSV соглашением, выбор которого должен быть видимым. ToolAcre документирует свой выбор вывода и отклоняет недостаточно указанный реверс. Это надежнее, чем использовать одну кнопку для двух принципиально разных задач.

Проверьте разделитель, кавычки, CRLF, BOM и экранирование формулы в принимающей системе. Если требуется синтаксический анализ ввода, используйте инструмент, который запрашивает вместо переноса соглашений автора в неизвестный файл.

Практическая приемочная проверка открывает сгенерированный файл у предполагаемого потребителя, а также проверяет необработанные байты или текст. Взгляд потребителя выявляет проблемы отображения и импорта; необработанное представление подтверждает разделитель, двойные кавычки, CRLF и необязательный BOM без повторной интерпретации электронной таблицы. Тестируйте строки, подобные формулам, как инертный текст, а отрицательное число — как число. Эти парные проверки проверяют действительный контракт автора, не утверждая, что каждая программа одинаково реализует соглашения CSV.