RFC 4180¶

RFC 4180 — это запрос комментариев (Request for Comments), опубликованный в октябре 2005 года, который формализует распространённый текстовый формат файлов CSV (Comma-Separated Values, значения, разделённые запятыми). Документ, подготовленный группой разработчиков во главе с Yakov Shafranovich, устанавливает единый стандарт для представления табличных данных в виде простого текста, где каждая строка соответствует одной записи, а поля внутри строки разделяются запятыми. RFC 4180 не является обязательным стандартом, но широко используется как де-факто спецификация для обмена данными между различными приложениями, базами данных и электронными таблицами.

¶История и предпосылки создания

До появления RFC 4180 формат CSV существовал в виде неформального соглашения, восходящего к ранним дням компьютерной обработки данных. Разные программы (например, Microsoft Excel, базы данных dBase, различные скрипты на языках программирования) реализовывали экспорт и импорт CSV по-своему. Это приводило к несовместимости: одни программы использовали запятую, другие — точку с запятой, по-разному обрабатывали кавычки и символы новой строки внутри полей.

Потребность в едином стандарте стала особенно острой с ростом популярности веб-приложений и обмена данными через интернет. В 2004 году в рамках рабочей группы IETF (Internet Engineering Task Force) началась работа над документом, который бы зафиксировал наиболее распространённую практику. Результатом стал RFC 4180, который был опубликован как информационный (Informational) документ, а не как стандарт (Standards Track), что подчёркивает его описательный, а не предписывающий характер.

¶Основные положения спецификации

RFC 4180 определяет структуру CSV-файла через набор чётких правил, касающихся формата строк, полей и обработки специальных символов.

¶Определение записи и поля

• Каждая запись (строка) располагается на отдельной строке текста.
• Записи разделяются символами перевода строки (CRLF — Carriage Return + Line Feed, \r\n).
• Каждая запись содержит одно или несколько полей, разделённых запятыми (,).
• Последнее поле в записи не должно заканчиваться запятой.

¶Обработка кавычек

Для включения в поле символов, имеющих специальное значение (запятая, кавычка, перевод строки), используется механизм экранирования с помощью двойных кавычек ("):

• Если поле содержит запятую, перевод строки или двойную кавычку, оно должно быть заключено в двойные кавычки.
• Если внутри поля, заключённого в кавычки, необходимо использовать саму двойную кавычку, она дублируется (две кавычки подряд "").
• Пробелы вне кавычек считаются частью поля (не игнорируются).

¶Заголовки

• Первая запись в файле может быть строкой заголовков (header line). Она содержит названия столбцов и форматируется по тем же правилам, что и обычные записи.
• Спецификация не требует обязательного наличия заголовков, но рекомендует их использовать для улучшения читаемости и совместимости.

¶Структура файла

• Файл должен содержать одну или несколько записей.
• Каждая запись должна содержать одинаковое количество полей (хотя это явно не оговаривается, это подразумевается логикой табличных данных).
• Файл может заканчиваться или не заканчиваться пустой строкой.

¶Примеры формата

Следующие примеры иллюстрируют правила RFC 4180.

Простой файл (три записи, два поля): `` Имя,Возраст Иван,30 Мария,25 ``

Файл с полем, содержащим запятую (город, штат): `` Имя,Адрес Иван,"Москва, Россия" Мария,"Санкт-Петербург, Россия" ``

Файл с полем, содержащим кавычку (цитата): `` Цитата,Автор "Он сказал: ""Привет""",Иван ``

¶Применение и значение

RFC 4180 стал основой для реализации импорта и экспорта данных в тысячах программных продуктов. Его ключевое преимущество — простота и универсальность.

¶Области использования

• Электронные таблицы: Microsoft Excel, Google Sheets, LibreOffice Calc поддерживают экспорт/импорт в формате CSV, часто следуя RFC 4180, хотя и с региональными вариациями (например, использование точки с запятой в локалях, где запятая является десятичным разделителем).
• Базы данных: Системы управления базами данных (MySQL, PostgreSQL, SQLite) предоставляют команды для импорта и экспорта данных в CSV.
• Веб-приложения и API: Многие API возвращают данные в формате CSV для пакетной загрузки (например, финансовые данные, логи, списки товаров).
• Научные вычисления и анализ данных: Языки программирования (Python с модулем csv, R, Julia) имеют встроенную поддержку чтения и записи CSV в соответствии с RFC 4180.
• Машинное обучение: CSV является стандартным форматом для хранения наборов данных (датасетов), например, на платформе Kaggle.

¶Критика и ограничения

Несмотря на широкое распространение, RFC 4180 имеет ряд недостатков:

• Отсутствие поддержки типов данных: Все поля являются текстовыми. Числа, даты и булевы значения не кодируются явно, что приводит к необходимости их парсинга на стороне приложения.
• Проблемы с кодировками: Спецификация не определяет кодировку символов. На практике чаще всего используется UTF-8, но в старых системах может применяться Windows-1251 или ISO 8859-1, что вызывает проблемы с отображением.
• Региональные вариации: Во многих европейских странах десятичным разделителем является запятая, а не точка. Это приводит к конфликту с разделителем полей в CSV. В результате программы часто используют точку с запятой (;) в качестве разделителя, что нарушает RFC 4180.
• Неоднозначность с переводом строки: RFC 4180 требует CRLF (\r\n), но многие системы (особенно Unix-подобные) используют только LF (\n). Некоторые парсеры корректно обрабатывают оба варианта, другие — нет.
• Отсутствие поддержки многострочных полей: Хотя спецификация разрешает перевод строки внутри поля в кавычках, многие упрощённые парсеры этого не поддерживают.

¶Альтернативы и родственные форматы

Несмотря на популярность CSV, существуют и другие форматы для табличных данных:

• TSV (Tab-Separated Values): Использует табуляцию вместо запятой. Реже вызывает проблемы с десятичными разделителями, но неудобен для визуального просмотра.
• DSV (Delimiter-Separated Values): Обобщение, где разделителем может быть любой символ.
• JSON (JavaScript Object Notation): Структурированный формат, поддерживающий вложенность и типы данных. Часто используется в API, но менее компактен для больших таблиц.
• Parquet и Arrow: Двоичные форматы, оптимизированные для хранения и обработки больших объёмов данных в аналитических системах. Они обеспечивают сжатие, поддержку сложных типов и быстрый доступ, но не являются текстовыми.

¶Интересные факты

• RFC 4180 — один из самых коротких и простых для понимания документов IETF. Его полный текст занимает всего несколько страниц.
• Несмотря на свою простоту, он является одним из самых цитируемых RFC в области обработки данных.
• Спецификация была написана в ответ на реальную проблему несовместимости, и её принятие значительно упростило жизнь разработчикам и аналитикам.

¶Источники

• RFC 4180 — Common Format and MIME Type for Comma-Separated Values (CSV) Files. Y. Shafranovich. October 2005.
• IETF (Internet Engineering Task Force). Официальный репозиторий RFC.
• Документация модуля csv языка Python (стандартная библиотека).
• Microsoft. Формат CSV (Comma Separated Values). Справочная документация.
• W3C. Model for Tabular Data and Metadata on the Web.