Инструменты разработчика · Сравнение текста
Почему Windows и Unix не согласны с окончаниями строк: история CR, LF и CRLF
· Фон
разница текста окончания строк история программного обеспечения
Прослеживает окончания строк от пишущих машинок и телетайпов до современных операционных систем и объясняет, почему два соглашения до сих пор сосуществуют в каждом кроссплатформенном проекте.
Один невидимый персонаж, десятилетия трений — начинается с постоянного кроссплатформенного раздражения.
Окончание строк невидимо в обычных редакторах, но может иметь значение для файлов и протоколов. Однако в ToolAcre CR, LF и CRLF нормализуются перед сравнением строк. Пара, отличающаяся только этими разделителями, дает одинаковый массив строк и идентичный результат.
Такое поведение решает практический вопрос для этого маршрута, ограничивая при этом то, что он может диагностировать. Сравнение не может определить, какие байты новой строки содержатся в исходных файлах после того, как текст достигает своих редакторов. Для сохранения или проверки протокола требуется инструмент, учитывающий байты.
Возврат каретки и перевод строки на пишущей машинке - объясняет два физических действия, которые первоначально описали персонажи.
Термины «возврат каретки» и «перевод строки» имеют физическое и историческое значение, но в репозитории нет источника пишущей машинки. Повторение по памяти истории механического происхождения нарушило бы договор о доказательствах, даже если бы эта история казалась знакомой.
Таким образом, в данной статье CR рассматривается как « ` code unit and LF as ` ` только там, где реализация их использует. Историческое объяснение должно быть добавлено позже из первичных стандартов или архивов, а не заимствовано из схемы, которая явно не является источником.
Значения пишущей машинки - это исторические утверждения, требующие внешних источников.
Аналогично, исходные файлы не документируют соглашения телетайпа или ранние решения операционной системы. Они показывают только выбор совместимости в текущем JavaScript: заменить каждый CRLF или одиночный CR на LF перед разделением.
Это преобразование принимает вставленный текст, созданный в соответствии с несколькими соглашениями, без заполнения вывода изменениями, имеющими только окончание. Это решение по реализации, видимое в одном регулярном выражении и закрепленное тестами для всех трех форм.
Происхождение телетайпа и операционной системы не является доказательством за пределами хранилища.
Обычно Unix ассоциируется с LF, Windows с CRLF и более старые системы с одиночным CR, но текущий репозиторий не может служить историческим доказательством этих заимствований. Заявление о безопасности является работоспособным: все три входа становятся НЧ внутри `splitLines`.
Терминал LF не создает последнюю пустую строку, а пустые строки в середине остаются. Это различие означает, что логическое содержимое сохраняется, даже если различия в физических разделителях стираются. Сравнение ориентировано на строки, а не на сохранение байтов.
Код доказывает, что три соглашения нормализуются; это не доказывает, почему системы приняли их
Некоторые сетевые протоколы и протоколы сообщений указывают точные терминаторы линий, но их требования должны исходить из их спецификаций. Нормализация ToolAcre делает его непригодным для доказательства соответствия такому формату провода, поскольку исходное свидетельство разделителя намеренно удалено.
Используйте шестнадцатеричное средство просмотра или средство проверки протокола перед анализом, когда точные последовательности CRLF имеют значение. Чистый результат сравнения текста может подтвердить совпадение логических строк и одновременно скрыть дефект транспортного уровня. Оба наблюдения могут быть верными, поскольку инструменты отвечают на разные вопросы.
Требования протокола требуют собственных спецификаций и здесь опущены.
Сравните `альфа beta`, `alpha beta` and `alpha бета` парами. Каждый создает две строки, альфа и бета, без каких-либо добавлений или удалений. Игнорировать пробелы не приводит к такому равенству; нормализация уже произошла во время расщепления.
Добавьте конечные пробелы в одну бета-строку, и обычный режим теперь сообщит о разнице. Включите «Игнорировать пробелы», и они могут исчезнуть. Последовательность отделяет обработку новой строки от обработки пробелов в ключах строк и предотвращает зачисление неправильной опции.
Рабочий пример: все три завершающие формы сравниваются как равные перед параметрами пробелов.
Этот маршрут не настраивает редакторы, не перезаписывает файлы, не устанавливает атрибуты Git и не выполняет массовое преобразование окончаний. Он также не отображает исходный разделитель в строках результатов. Вставленные строки поступают в конвейер сравнения, а не в утилиту переноса новой строки.
Историческая причинно-следственная связь и стандарты протокола опущены в ожидании источников. Это ограничение оставляет меньшую, но точную статью: что делают три соглашения в этой реализации, какие пустые строки остаются и почему равенство здесь не устанавливает идентичность байтов.
Вывод: знайте, какое соглашение содержит ваш текст — обобщает историю и то, как сравнение текста ToolAcre помогает подтвердить, заключается ли разница только в окончаниях строк.
Узнайте, какие доказательства пережили инструмент. После нормализации ToolAcre может сравнивать содержимое логических строк через общие разделители. Он не может сказать вам, какое соглашение использовал источник или требует ли нижестоящий потребитель одну точную последовательность байтов.
Используйте разницу браузера для проверки человеком и проверку на уровне байтов для проверки репозитория или протокола. Инструмент надежен, когда его преобразования явны; рецензенты по-прежнему несут ответственность за выбор того, который сохраняет свойство, которое им необходимо проверить.