Кінець рядка в текстовому файлі — це не просто «перехід на новий рядок», а конкретна послідовність байтів, і різні операційні системи історично обрали різні послідовності. Ця розбіжність і досі спричиняє реальні проблеми.
Звідки взялась розбіжність
Unix і macOS використовують один символ — LF (line feed, \n). Windows успадкувала від старих телетайпів пару символів — CRLF (carriage return + line feed, \r\n): один символ повертає каретку на початок рядка, другий переміщує на рядок нижче — буквальна імітація друкарської машинки.
Чому це досі має значення
- Git. Якщо файл із CRLF потрапляє в репозиторій, де інші файли з LF, git може показати «змінений увесь файл», хоча змінився лише один рядок — бо технічно змінились закінчення всіх рядків.
- Shebang-скрипти. Скрипт для Unix-shell із закінченнями CRLF може не запуститись, бо інтерпретатор бачить зайвий символ
\rу першому рядку. - Порівняння рядків у коді. Рядок, зчитаний з CRLF-файлу, може не збігатися при порівнянні з очікуваним LF-рядком, навіть якщо видимий текст однаковий.
Як це вирішують
Git має налаштування (core.autocrlf), яке автоматично конвертує закінчення рядків при checkout/commit. Редактори коду зазвичай дозволяють вибрати й уніфікувати стиль закінчення рядків для всього проєкту через конфіг (наприклад, .editorconfig).
Навіщо потрібна ручна конвертація
- Виправити файл, який потрапив у репозиторій із неправильним стилем закінчень рядків.
- Підготувати скрипт для Unix-середовища, який редагували у Windows-редакторі.
- Продіагностувати, чому текстове порівняння двох на вигляд однакових файлів показує відмінність.
Змішані закінчення в одному файлі
Файл, відредагований у кількох редакторах чи на різних ОС, може містити і CRLF, і LF одночасно — частина рядків з одним стилем, частина з іншим. Це найкапризніший випадок: конвертація «в LF» на перший погляд нічого не змінює для рядків, які вже мали LF, але важливо застосувати перетворення до всього файлу, а не лише до видимо «підозрілих» рядків, інакше проблема залишиться прихованою.