Tekst
CRLF ↔ LF Converter
Konwertuj znaki końca wiersza między Windows (CRLF), Unix/macOS (LF) i klasycznym Mac (CR), z wykrywaniem mieszanych zakończeń.
Przeglądarka sama normalizuje wklejony w pole tekst do LF, więc wykrycie oryginalnych CRLF/CR nie jest tu możliwe — aby przeanalizować lub przekonwertować plik z rzeczywistymi CRLF/CR, użyj przesyłania pliku powyżej.
Windows, Unix/macOS, and the old classic Mac historically use different characters to mark the end of a line — CRLF, LF, and CR respectively. Mixing these styles in one file often causes odd artifacts in diffs or editors. This tool converts line endings to one style and detects mixed ones.
How to use it
- Paste text and the tool automatically detects the current line-ending style, including a mixed one.
- Pick a target format (CRLF, LF, or CR) and the conversion happens instantly.
- If several styles are found in the same file, that's flagged with a separate warning.
Common uses
- Fixing a file where git diff shows every line as changed because of differing line endings, even though the content itself didn't actually change.
- Converting a text file to the format a specific system or script expects (a Unix script, for instance, expects LF).
- Debugging why a file opened in a Windows editor shows the entire text on one line (a sign of plain LF with no CR).
Things to keep in mind
Git can automate this conversion itself through core.autocrlf or .gitattributes — often more convenient than converting files in a repository by hand.
Mixed line endings in one file aren't always visible at a glance, but they can break parsers or scripts that expect one specific style.
Artykuł o tym narzędziu: CRLF kontra LF: dlaczego znaki końca linii wciąż mają znaczenie
Najczęstsze pytania
Dlaczego znaki końca linii różnią się w zależności od systemu?
Windows używa CRLF (\r\n), Unix i macOS używają tylko LF (\n), a klasyczny Mac używał tylko CR (\r) — te różne historyczne konwencje powodują niespójności, gdy plik przemieszcza się między systemami.
Dlaczego muszę przesłać plik zamiast wkleić tekst?
Przeglądarka automatycznie normalizuje każdy tekst wklejony do pola do LF, więc rzeczywiste oryginalne znaki CRLF lub CR stają się niewykrywalne po wklejeniu — tylko bezpośrednie przesłanie pliku zachowuje prawdziwe końce linii do analizy lub konwersji.
Kiedy taki problem naprawdę ma znaczenie?
Ma to największe znaczenie w przypadku git (zaszumione diffy spowodowane końcami linii), skryptów powłoki, które zawodzą przez pozostałe CRLF, oraz plików wymienianych między systemami Windows i Unix/macOS; przesłany plik jest przetwarzany wyłącznie lokalnie w przeglądarce, nigdy nie jest wysyłany na serwer.
Co zrobić, jeśli w pliku wymieszane są CRLF i LF?
Plik edytowany w kilku edytorach lub na różnych systemach operacyjnych może zawierać oba style jednocześnie. Konwersję trzeba zastosować do całego pliku, a nie tylko do widocznie „podejrzanych" linii — inaczej część problematycznych końców pozostanie niezauważona.
Czy można zautomatyzować konwersję za pomocą git?
Tak, ustawienie core.autocrlf w git automatycznie konwertuje końce linii przy checkout i commit, a .gitattributes pozwala jawnie określić styl końców linii dla konkretnych typów plików w repozytorium.