Почему данные GTFS содержат «невидимые» разрывы строк?

Question

Итак, я искал способ импортировать данные GTFS в SQLdb для моего приложения. Я нашел решение на GitHub.

Но это написано с использованием python. Я не думаю, что могу использовать это прямо в моем приложении Windows. Пожалуйста, поправьте меня, если я ошибаюсь.

Но у меня нет проблем с пониманием логики решения и создания собственного «парсера».

Итак, я открыл файл данных GTFS «calendar date.txt» в «Блокноте» и нашел его содержимое запутанным. Это было так:

service_id,date,exception_type1,20151012,11,20151111,12,20150822,12,20150829,12.....

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

service_id,date,exception_type 
1,20151012,1 
1,20151111,1 
2,20150822,1 
2,20150829,1 
2 

Теперь ясно имеет смысл !! (Есть пробелы между синтаксическими разборами).

Но я не понимаю. Является ли блокнот неправильным? Как я могу видеть данные «правильно», затем, чтобы написать собственный парсер?

Answer 1

Прежде всего скопировать связанные GTFS (маршруты, shaps и т.д.) и чем паста в онлайновом текстовом редакторе (например: http://www.editpad.org/)

И чем скопировать из этого онлайна текстового редактора и снова вставить в свой оригинал. текст.

Answer 2

Скорее всего, ваши данные GTFS записываются с концевыми символами UNIX (только для перевода строки), в отличие от символов MS-DOS/Windows (возврат каретки, за которым следует линия перевода строки). Это permitted by the GTFS spec, в котором говорится:

Каждая строка должна заканчиваться символом линии CRLF или LF.

Большинство прикладных программ, доступных для Windows, включая Блокнот, распознает только символы конца строки Windows и открытие файла, созданного в UNIX, покажет все содержимое как одну строку, как вы заметили. Однако такие инструменты, как Notepad ++, предназначенные для разработчиков, а также большинство библиотек программирования (например, предназначенные для разбора файлов CSV), обычно достаточно умны, чтобы распознавать оба формата и обрабатывать их соответствующим образом.

Википедия имеет более подробную информацию о end-of-line representations across operating systems, если вам это интересно.

Наконец, я упомянул, что я недавно отправил в Github my own GTFS-to-SQLite loading tool, который написан на C и использует libcsv для разбора данных GTFS. Если вы разрабатываете язык на более низком уровне, чем Python, вы можете найти его полезным в качестве примера.