Текст и повседневные инструменты · Текстовый инструментарий
CR, LF и CRLF: откуда берутся окончания строк и почему вставленный текст разрывается
· Фон
окончания строк очистка текста экспорт данных
Объясняет происхождение возврата каретки и перевода строки в телетайпе, почему операционные системы выбрали разные соглашения и как этот выбор отображается в виде двойных пустых строк и случайных символов во вставленном тексте.
Экспорт с пустой строкой после каждой строки — почему в файл из другой системы вставляется вдвое больше строк
Вы вставляете экспорт из трех строк и видите пустую строку после каждой записи. Соблазнительно сразу же обвинить Windows CRLF, но текстовая область, соответствующая стандартам, обычно представляет разрывы строк в нормализованной форме. Двойные строки чаще всего означают, что более раннее преобразование рассматривало возврат каретки и перевод строки как два независимых разделителя или вставляло дополнительную новую строку между записями.
Сохраняйте оригинал до тех пор, пока не узнаете, на каком этапе он был изменен. Сравните исходный код в редакторе, который может отображать управляющие символы, а затем сравните количество вставленных строк. ToolAcre намеренно принимает CRLF, LF и одиночный CR как одну границу каждый, поэтому нетронутый файл с тремя записями должен создавать три строки, а не шесть просто потому, что он пришел из Windows.
Дополнительная пустая строка является симптомом, а не доказательством того, что ее вызвал только CRLF.
Названия описывают физические действия на печатающих терминалах. Возврат каретки перемещает каретку в начало текущей строки, а перевод строки перемещает бумагу на следующую строку. Это были отдельные элементы управления, поскольку любое движение можно было запросить независимо. ASCII сохранил их как управляющие символы CR в десятичном 13 и LF в десятичном 10.
Современные экраны больше не перемещают бумагу, однако байтовые значения сохранились в файлах, протоколах и программных интерфейсах. История объясняет, почему CR и LF не являются взаимозаменяемыми знаками препинания и почему CRLF представляет собой двухсимвольную последовательность. Это не означает, что каждое современное приложение обрабатывает их отдельно; синтаксические анализаторы обычно распознают пару как одно логическое окончание строки.
Три соглашения — LF в Unix и современной macOS, CRLF в Windows, CR в классической Mac OS, и почему каждое из них кажется разумным
Unix и Unix-подобные системы обычно используют LF для окончания строки, и современная macOS следует этому соглашению. Текстовые файлы Windows обычно используют CRLF. Классическая Mac OS использовала только CR, но Mac OS X приняла основу Unix и LF. Этот выбор остается видимым, когда инструменты обмениваются открытым текстом, не соглашаясь на нормализацию.
Никакая условность не делает сами слова разными. Проблемы возникают на границе, читатель которой ожидает только одного представления или наивно разбивается на каждый управляющий символ. Надежный анализатор строк проверяет CRLF как пару перед проверкой одиночного CR или LF. ToolAcre делает именно это с упорядоченным шаблоном ` | | `, затем объединяет преобразованный вывод с LF.
Что происходит в текстовом поле браузера — как обычно нормализуются разрывы строк при вставке и где все еще появляются случайные символы
HTML определяет специальную обработку разрывов строк в текстовых элементах управления. В значении текстовой области браузеры нормализуют CRLF и одиночный CR до LF в открытом значении, в то время как отправка формы может применять правила данных формы для разрывов строк. Следовательно, вставка, которая выглядит правильно в коробке, все равно может быть сериализована другим слоем или скопирована в программное обеспечение с другим соглашением.
Случайный CR все еще может появиться, когда текст обходит обычную текстовую область, когда отображаются экранированные байты, такие как литеральные символы `\r`, или когда анализатор разбивается только на LF и оставляет CR прикрепленным к каждому полю. Браузер — это один из этапов пути, а не универсальный сервис восстановления файлов, производителей буфера обмена, API и потребителей командной строки.
Браузеры нормализуют разрывы строк текстовой области, но форматы буфера обмена и последующих форматов по-прежнему различаются.
Пустые строки и конечные возвраты каретки требуют разных диагнозов. Удалить пустые строки удаляет строки, содержимое которых является пустым или пробельным, после того как ToolAcre распознал все три стиля окончания строк. Trim Lines удаляет начальные и конечные пробелы из каждой строки. Поскольку разделитель ToolAcre использует реальный разделитель CR, обрезка обычно не требуется просто для стирания этого разделителя.
Используйте обрезку только тогда, когда остаются пробелы, табуляции или неиспользуемые символы, и проверяйте значимые отступы перед их изменением. Если текст содержит видимый `^M`, определите, отображает ли средство просмотра фактический CR или эти два печатных символа. Полная замена может повредить предполагаемый контент, тогда как проверка подсчетов до и после дает проверяемый результат.
Удалить пустые строки исправляет пустые строки; обрезка обычно не требуется после того, как ToolAcre правильно разделяет CR
Для воспроизводимого примера начните с трех имен, поврежденное промежуточное представление которых содержит пустую строку между каждым именем: `Ada`, пусто, `Grace`, пусто, `Linus`. Счетчик слов и символов сообщает пять строк. Это намеренное удвоение входных данных; настоящая последовательность CRLF сама по себе будет распознана как одна граница и не будет создавать пустые строки в ToolAcre.
Выберите «Удалить пустые строки», и результат станет тремя строками, соединенными с помощью LF. Теперь счетчик должен сообщить три. Если импортированные значения также содержат дополнения, запустите «Линии обрезки» отдельно и просмотрите результат. Разделение этих операций показывает, какие дефекты исправлены в каждом действии, а не приписывает каждую очистку неопределенному преобразованию текста Windows.
Рабочий пример: очистите намеренно удвоенный экспорт и проверьте количество строк.
Очистка конца строки не устраняет жесткую переносимость, когда одно логическое предложение было намеренно нарушено на ширине столбца. Удаление каждой новой строки из этого материала также приведет к объединению реальных абзацев и элементов списка. Решите, представляет ли граница запись, абзац или визуальный перенос, прежде чем применять операцию линии ко всему блоку.
Он также не диагностирует кодировку символов. Метка порядка байтов UTF-8, ромбы замены, моджибаке и ошибки декодирования касаются того, как байты становятся символами, а не того, разделяет ли CR или LF эти символы на строки. Сохраните исходный файл и определите его кодировку с помощью соответствующего инструмента, работающего с файлами, прежде чем обрабатывать нечетные видимые символы как окончания строк.
Вывод: окончания строк — это история, которую вы можете увидеть; линейные инструменты и счетчик Text Toolkit позволяют устранить симптомы за считанные секунды.
CR, LF и CRLF — это исторические элементы управления с современными последствиями совместимости. Самая безопасная ментальная модель — это граница одной логической линии с несколькими физическими представлениями. Подсчитайте записи, проверьте исходное соглашение и определите этап, на котором были добавлены пустые строки или сохранены управляющие символы, прежде чем что-либо удалять.
Для вставленного материала откройте Text Toolkit по адресу `/tools/text/`, запишите начальное количество строк, примените «Удалить пустые строки» только тогда, когда пустые строки действительно нежелательны, и используйте «Обрезать линии» только для окружающих пробелов. После этого еще раз проверьте записи подсчета и проб. Эта короткая проверка превращает невидимую проблему форматирования в контролируемое обратимое преобразование текста.