CRLF lwn. LF pada Windows: Tukar, konfigurasi dan elakkan masalah projek

Jika anda bekerja dalam Windows dan projek ganti dengan orang dari Linux atau macOS, lambat laun anda akan menghadapi pertempuran abadi CRLF lwn LF. Kadangkala ia kelihatan seperti sihir hitam: anda mengedit fail, jangan ubah apa-apa "kelihatan", dan Git menandakan separuh fail sebagai diubah suai. Jangan risau, ia bukan sihir; ia adalah penghujung baris bermain menentang kamu.

Untuk menyelamatkan diri anda daripada sakit kepala, memahami perkara di bawah dan cara menyesuaikan diri Git, editor anda dan alatan anda supaya setiap fail tiba "bersih" ke repositori, tanpa perubahan hantu atau ralat aneh dalam CI/CD atau skrip. Dalam panduan ini saya memberitahu anda, secara terperinci dan tepat, bagaimana untuk menukar, mengkonfigurasi dan normalkan CRLF dan LF pada Windows tanpa kehilangan el tiempo.

Apakah LF dan CRLF dan mengapa ia penting?

Penghujung baris ialah aksara kawalan yang mengehadkan setiap baris dalam fail teks: LF (\n, ASCII 10) y CRLF (\r\n, ASCII 13+10). Pada sistem seperti Unix (Linux, macOS) ia digunakan LF, manakala Windows menggunakan CRLF diwarisi daripada pencetak dan mesin taip: pemulangan pengangkutan pertama (CR), kemudian suapan talian (LF).

Pilihannya bukan estetik: perubahan dari satu format ke format lain boleh menyebabkan perbezaan buatan, skrip yang gagal dengan "perintah tidak ditemui," saluran paip yang ranap apabila menjalankan fail yang disimpan dengan CRLF pada Linux, atau editor yang memaparkan segala-galanya pada satu baris. Ya, anda membuka .sh dengan CRLF dalam Bash dan anda boleh mendapat ketakutan yang baik.

Untuk menyelesaikan masalah, Unicode mengenali lebih banyak pemisah (NEL U+0085, LS U+2028, PS U+2029, VT U+000B, FF U+000C), tetapi dalam pembangunan setiap hari, pertarungan sebenar ialah CRLF lwn LF. Namun, mengetahui bahawa ia wujud membantu apabila anda menjumpai teks daripadanya kerangka utama atau fail pelik yang tidak ditafsir dengan baik oleh editor lama.

Satu lagi rasa ingin tahu teknikal yang berguna: lompatan boleh dianggap sebagai pemisah (antara garisan) atau sebagai terminator (menandakan akhir). Kehalusan itu menerangkan sebab anda kadangkala melihat baris terakhir "tiada-putus" atau baris kosong tambahan apabila anda menggabungkan alatan. Jika anda perlu belajar bagaimana untuk cari dan gantikan patah perenggan, berhati-hati, kerana sesetengah penganalisis mengharapkan satu perkara atau yang lain.

Perbezaan mengikut sistem dan masalah biasa

Dalam Windows, perkara biasa ialah CRLF; pada Linux dan macOS, LF. Pertembungan ini serta-merta dapat dilihat pada pasukan campuran: seseorang mengedit fail dengan sistem mereka, menyimpannya dan perbezaannya dipenuhi dengan perubahan yang sebenarnya hanya penghujung barisPada peringkat praktikal, ia merumitkan pemeriksaan anda dan mencemarkan sejarah anda.

Terdapat juga kesan sampingan: a skrip dengan CRLF berjalan dalam persekitaran Unix boleh gagal dengan ralat samar, atau dalam CI tugasan terputus kerana shell salah tafsir pulangan. Sebaliknya, membuka fail dengan hanya LF dalam editor lama pada Windows boleh ratakannya menjadi satu garisan.

Berhati-hati dengan alat penyepaduan berterusan seperti Jenkins atau GitHub Actions: jika binaan berjalan pada Linux tetapi anda memuat naik fail dengan penghujung baris yang tidak konsisten, anda boleh memecahkan saluran paip Walaupun "semuanya berfungsi pada mesin saya." Lebih daripada seorang telah kehilangan jam kerana ini.

Berita baiknya ialah terdapat resipi yang jelas: tetapkan konvensyen dan lakukannya. alatan menggunakannya sahaja. Itu berlaku melalui Git dan editor anda. Dan jika kerosakan sudah dilakukan, oleh menormalkan semula repo itu.

Ngomong-ngomong, editor moden seperti VS Code menunjukkan jenis lompatan dalam bar status dan membolehkan anda menukarnya dengan cepat; ia adalah penyelamat apabila anda melihat fail "potongan silang" dan mahu menyusun perkara dengan cepat, atau apabila anda perlukan elakkan pemecahan halaman dan pemformatan yang tidak dijangka apabila menampal teks ke dalam dokumen.

Git dan penghujung baris: core.autocrlf dan .gitattributes

Git boleh menukar pengakhiran baris secara automatik untuk memastikan sejarah anda bersih dan mengelakkan sebarang kejutan yang tidak menyenangkan. Kuncinya ialah pilihan teras.autocrlf, yang anda mesti fahami dengan baik sebelum menyentuhnya, dan ketahui bahawa konfigurasi boleh berada pada tahap global o tempatan daripada repositori (peraturan tempatan).

Semak tetapan global anda dengan -global dan ingat bahawa repo mungkin mempunyai nilai berbeza yang berlaku. Untuk melihat semuanya secara global, gunakan git config –list –globalJika anda melihat tingkah laku pelik dalam repo, semak nilai setempat dan utamakannya mengikut apa yang anda perlukan.

Mod Core.autocrlf dalam istilah praktikal (Windows vs Unix): benar menukar kepada CRLF semasa pembayaran dan kembali kepada LF apabila komited; input hanya tukar kepada LF pada komit (hebat pada Linux/macOS); palsu tidak menyentuh apa-apa (dan selalunya penyelesaian pantas jika terdapat pasukan campuran). Dalam Windows, perkara yang paling masuk akal untuk dilakukan ialah benar jika anda tidak mahu kejutan.

Komandos berguna untuk melaraskan dan membersihkan keadaan repo anda tanpa mengacaukannya terlalu banyak: jika anda mahu repositori menggunakan nilai global, menghapuskan kunci tempatan; jika anda lebih suka memaksa nilai dalam repo itu, tetapkannya tanpa -globalUntuk membetulkan fail yang sudah bercampur, normalkan semula dan lakukan perubahan pengakhiran baris bersama-sama.

git config --list --global
# Ver el valor global efectivo

git config --unset core.autocrlf
# Quitar el valor local y heredar el global

git config core.autocrlf true
# Fijar el valor solo en el repo actual (Windows)

git add --renormalize .
# Recorrerá el repo y homogeneizará line endings según la config

git commit -m 'Homogeneizados los cambios de línea'
# Sube un solo commit de normalización

Tetapi ada sesuatu yang lebih baik: a .gitattributes dalam akar yang bergerak dengan kod. Dengan peraturan * teks=auto anda memberitahu Git untuk mengesan fail teks dan mengendalikan pemisah baris dengan sewajarnya (LF dalam repo; CRLF dalam salinan kerja Windows jika berkenaan). Dan anda boleh memperhalusi dengan sambungan, contohnya, memaksa Git untuk mengendalikan baris baharu dengan sewajarnya. .sln Visual Studio untuk kekal sebagai CRLF sentiasa.

* text=auto
# Homogeneiza automáticamente (LF en el repo)

*.sln text eol=crlf
# Asegura CRLF en soluciones de Visual Studio

Apabila anda memperkenalkan .gitattributes ke dalam repo yang sedia ada, jangan lupa untuk git add –renormalize . dan mengumpulkan komitmen. Dengan cara ini, anda mengelakkan setiap penyumbang menjana "komit mega pembersihan" mereka sendiri. Ia adalah salah satu tugas yang anda lakukan sekali dan ia menghilangkan masalah anda selama bertahun-tahun.

Konfigurasikan editor: Kod VS, EditorConfig dan Visual Studio

Editor anda juga banyak melukis. Dalam Kod VS Anda boleh menetapkan pemisah baris dari bar status atau dengan pilihan files.eolJika projek anda menggunakan LF, pilih dan itu sahaja; editor akan menyimpannya dengan cara itu tanpa anda perlu pergi fail demi fail. Ia pantas dan menyelamatkan anda daripada perbezaan yang bising.

Jika semua orang dalam pasukan menggunakan editor yang berbeza, sertakan EditorConfig (.editorconfig) pada akarnya ialah anugerah: ia mentakrifkan peraturan seperti pengakhiran baris, pengekodan dan ruang/tab secara konsisten. Kebanyakan editor moden menghormatinya, dan ia berintegrasi secara fenomenal dengan Git dan CI.

Bagi mereka yang menggunakan Visual Studio, terdapat panel khusus untuk disimpan dengan pengekodan dan pemisah baris tertentu (Pilihan Simpan Lanjutan). Anda boleh mengakses aliran Fail > Simpan Sebagai > Simpan lungsur > Simpan dengan pengekodan, dan juga tempat Pilihan simpan lanjutan terus dalam menu Fail untuk akses pantas.

1. Buka Alatan > Sesuaikan.
2. Dalam tab Komandospilih Bar menu dan pilih arkib.
3. akhbar Tambah perintah, kategori arkib, dan menambah Pilihan simpan lanjutan.
4. Letakkan semula dengan Muat naik/Muat turun dan tutupnya. Anda telah menyediakannya.

Dengan Visual Studio, anda juga mungkin menemui fail yang mempunyai pemisah lain (NEL, LS, PS). IDE cuba normalkan mereka Apabila ia mengesan ketidakkonsistenan, ia akan meminta arahan daripada anda. Mengekalkan .gitattributes dan menyimpan pilihan yang ditetapkan dengan betul menghalang projek anda daripada dipenuhi dengan "kes eksotik."

Di luar CRLF dan LF: NEL, LS, PS dan syarikat

Unicode menganggap titik kod tambahan tertentu sebagai pengakhiran baris: NEL (U+0085), LS (U+2028) y PS (U+2029), sebagai tambahan kepada VT (U+000B) y FF (U+000C). Ia tidak biasa dalam projek apl/web, tetapi ia muncul dalam Kerangka utama IBM (EBCDIC) dan dalam beberapa dokumen yang diproses dengan alat yang lebih lama atau khusus.

Untuk keserasian, Unicode mereplikasi kawalan ASCII lama dengan nilai angka yang sama (CR dan LF) dan menambah yang baharu untuk penukaran tanpa kehilangan antara pengekodan (cth., pemetaan EBCDIC NL kepada Unicode NEL). Jika anda mendapat fail "pelik", editor moden biasanya akan menunjukkan atau meminta menormalkan.

Dalam versi Windows Notepad yang lebih lama ia tidak sekata LF Ia menunjukkan dengan baik; sokongan hari ini jauh lebih baik, tetapi NEL masih bermasalah dalam sesetengah persekitaran. Oleh itu, untuk repo dan CI, simpan semuanya LF dalam repo dan meninggalkan Git/editor CRLF salinan kerja pada Windows adalah langkah yang menang.

Bahasa pengaturcaraan dan pemisah baris (\r, \n, dan perangkap)

Dalam rentetan teks, banyak bahasa membenarkan urutan melarikan diri: \n = LF, \r = CR. Dengan ini, anda mengarang CRLF sebagai \r\n apabila perlu, atau masukkan LF "bersih" dengan \n. Tetapi berhati-hati, kerana tidak semua runtime berkelakuan sama.

Kes yang perlu diingat: dalam Java, sebagai tambahan kepada \r dan \n, anda ada %n (pemformat) dan System.lineSeparator() untuk mendapatkan pemecahan talian sistem dengan cara mudah alih; dalam C#, Environment.NewLine melakukan perkara yang sama; dalam PHP terdapat PHP_EOL; dalam Python, os.linesep. Jika anda ingin mencetak mengikut platform, gunakan pemalar tersebut dan bukannya berkahwin dengan CRLF.

Penjagaan khas dengan C dan C ++: Dalam mod teks, jujukan \n boleh dipetakan kepada pemisah baris sistem (pada Windows, CRLF), dan jika anda mencetak \r\n anda mungkin akhirnya menjana CRCRLFDalam mod binari, perkara itu literal. Kehalusan ini menarik perhatian ramai orang apabila menyusun pada Windows dan menguji pada Linux.

En JavaScript/TypeScript, \n biasanya mencukupi untuk kebanyakan kegunaan, tetapi jika anda memproses input daripada pengguna Windows, anda akan melihat \r\n dan anda perlu menormalkan apabila memutuskan talian. Juga, apabila anda menjana HTML susun atur akhir dikawal oleh tag (hlm., br, p, h2…), bukan aksara \r atau \n.

// C#
var s1 = "Primera\nSegunda";            // LF explícito
var s2 = "Primera" + Environment.NewLine + "Segunda"; // Salto del sistema

// Java
String a = "Uno\r\nDos";                 // CRLF explícito
String b = "Uno" + System.lineSeparator() + "Dos";    // Portátil

// Python
s = 'Linea1' + os.linesep + 'Linea2'

// JavaScript
const t = 'L1\nL2'; // Normaliza entrada si viene con \r\n

Jika anda menjana trafik rangkaian, ingat bahawa protokol seperti HTTP, SMTP, FTP atau IRC adalah lengkap: tajuk dan banyak baris kawalan disertakan CRLF Ya atau ya. Tiada "ciptaan": laraskan output kepada RFC atau anda akan menemui pelayan yang menolak permintaan.

Cara mengesan dan menukar penghujung baris dengan pasti

Tiada "BOM" yang memberitahu anda jenis pemisah baris dalam fail: anda perlu lihat pada baitDalam amalan, alat mengira CR (0x0D) dan LF (0x0A) dan melihat coraknya: jika ia kelihatan berpasangan, ia biasanya CRLF; jika hanya 0x0A muncul, ia adalah LF; jika terdapat pencampuran yang tidak konsisten, anda mempunyai a hodgepodge itu harus diperbaiki.

Sesetengah editor mengesan ini dan memberitahu anda; Kod VS memaparkannya dalam bar status; Visual Studio mungkin menawarkan untuk menormalkannya. Dalam Git, langkah selamat adalah untuk menentukan .gitattributes dan, jika sesuai, normalkan semula untuk menjajarkan keseluruhan pokok dengan dasar. Repositori anda (dan semakan anda) akan berterima kasih kerananya.

Bagaimana jika anda bekerja dengan "format eksotik"? Editor seperti Notepad++ dan VS Code mengendalikan CRLF dan LF dengan baik, dan biasanya mengenal pasti LS/PS. Untuk kes NEL dan EBCDIC, kadangkala anda perlu melalui a penukaran sebelumnya pengekodan sebagai tambahan kepada pemisah baris.

Strategi kemenangan dalam kebanyakan projek adalah mudah: simpan dalam repo dengan LF, membolehkan penukaran automatik dalam Windows dan menyekat pengecualian sekali-sekala dengan eol=crlf untuk fail yang memerlukannya (cth., .sln). Selebihnya adalah ketakutan yang boleh dielakkan.

Repo dengan pemisah baris bercampur: cara membetulkan kekacauan

Ia sangat tipikal: bahagian kod datang daripada Linux (LF) dan yang lain telah diubah suai pada Windows (CRLF). Hasilnya ialah pokok dengan garis bercampur, perbezaan tidak boleh dibaca dan orang tertanya-tanya mengapa skrip mereka tidak akan bermula hari ini. meletakkan pesanan.

pelan cepat dan selamat:

1. Tambah .gitattributes dengan * teks=auto dan peraturan khusus jika perlu (mis., *.sln teks eol=crlf).
2. Lari git add –renormalize . untuk meminta Git melintasi repo dan menyesuaikan pemisah baris mengikut peraturan.
3. Buat a komitmen tunggal dengan mesej yang jelas (cth., "Perubahan talian homogen").
4. Beritahu pasukan dan tanya tarik sebelum meneruskan untuk meminimumkan konflik.

Jika anda mempunyai skrip sensitif (sh, py, dll.) pastikan ia disimpan dengan LF dan shebang tidak cacat. Anda boleh memaksanya dengan corak dalam .gitattributes atau menyemaknya dalam editor anda sebelum melakukan.

Untuk Visual Studio, jika ia mengesan lompatan yang tidak konsisten, ia akan mencadangkan untuk menormalkan. Terima, semak perbezaan, dan iringi dengan komitmen penormalan semula sebelumnya supaya semuanya bulat.

Mulai saat itu, dengan .gitattributes dan core.autocrlf disediakan dengan betul, mereka sudah selesai patch "kali ini ia melalui CRLF". Dan jika seseorang membuka projek pada Linux atau macOS, semuanya akan kekal sama kerana fail dalam repo disimpan dengan LF.

artikel berkaitan:

Format Microsoft Office: Apakah Itu dan Masa untuk Menggunakan Setiap Satu

Ishak

Penulis yang bersemangat tentang dunia bait dan teknologi secara umum. Saya suka berkongsi pengetahuan saya melalui penulisan, dan itulah yang akan saya lakukan dalam blog ini, menunjukkan kepada anda semua perkara yang paling menarik tentang alat, perisian, perkakasan, trend teknologi dan banyak lagi. Matlamat saya adalah untuk membantu anda mengemudi dunia digital dengan cara yang mudah dan menghiburkan.