您的軟件是否處理來自其他系統的換行符？換行符
Linux/BSD linefeed ^J 10 x0A
Windows/IBM return linefeed ^M^J 13 10 x0D x0A
old Macs return ^M 13 x0D
others?
由於瘋狂的原因，我將在我的文本文件中使用Linux版本的換行符。但是，當我將文本文件轉換爲Windows時，某些程序不能很好地與我的文本中的換行符配合使用。你會如何處理這個問題？
正如他們所說，要嚴格要求自己寫的東西，要自由自在地閱讀。
您的應用程序應該能夠正常讀取兩行結尾。如果您想使用換行符，並且可能會使Windows用戶感到不安，那就很好。
但保存記事本中，我玩大多數程序似乎很樂意與這兩種方法。
（我使用Cygwin在Windows上，這只是讓一切有趣的）呼籲crlf.py和lfcr.py
我懷疑你會發現，最先進的Windows程序（用記事本的顯着的例外）處理換行符僅文件就好了。但是，使用Windows程序生成的文件仍然傾向於有crlf結尾。
大部分時間裏，該行尾會自動在運行時庫特定於平臺的方式處理。例如，打開文件fopen(..., "r")的C程序將在任何平臺上以一致的方式（僅換行）看到這些行，而不管實際行結束。
不知道你是什麼意思時，你說的「交易」有，但基本上你可以這樣說：
string convertLineBreaks(String line, String lineBreakYouWant) {
replace all ^M^J or ^M or ^J in line with lineBreakYouWant
return line
}
編輯：我重新閱讀你的問題，你的意思後，懷疑你如何處理其他人無法處理錯誤（針對目標系統）換行符的程序。
我建議：1）使用一個程序，它可以處理或2）運行通過發現任何類型的換行符的腳本文件，然後將它們轉換成任何類型是適合您的系統。
Python標準版配備了兩個命令行腳本（在工具/腳本），可以轉換在Windows和Unix/Linux行結束之間。
在.NET中，新線通過Environment.NewLine表示，所以框架的設計是這樣一種方式，以採取任何系統的新線是（僅或LF僅CR + LF或CR），以在運行時使用。當然這在Mono中最終是有用的。
據我所知，它是有行分隔符的問題只有記事本。幾乎所有世界上的其他軟件都可以接受這三種分離器中的任何一種，也可能有其他的分離器。不幸的是，記事本現在是大多數計算機用戶的首選度假勝地的編輯。我認爲讓這種情況繼續下去對微軟來說是非常不負責任的。我從來沒有玩過Vista，但我相信問題仍然存在，就像它在XP中一樣。任何機構都知道下一個版本？
正如其他人所說，有很多的（很簡單）轉換器周圍，在有需要時。需要注意的是，如果你做ASCII模式，FTP傳輸，它會自動進行轉換......
事實上，記事本是具有與LF結束的問題最proeminent程序...
最討厭我看到的是帶有混合行結尾的文本文件，基本上由編輯Unix上的Windows文件的人員完成，或者實用程序添加內容而不檢查正確的格式。
爲了快樂，只需按照標準的建議。
http://unicode.org/standard/reports/tr13/tr13-5.html
，並提供選項，在特殊情況下像老的MacOS。或者如果您可以可靠地檢測它們，則自動處理該案例。
我推薦使用Unix風格格式化文本。忘記Windows用戶。因爲沒有Windows用戶對文檔或數據使用純文本。如果你傳遞純文本，他們會很不高興。他們總是期望Word或Excel文檔。即使他們使用純文本文件，他們將得到的唯一問題只是奇怪地顯示文本。
但是Unix用戶會體驗到他們所有的工具都會不正確的工作。特別是對於Unix，嚴格遵循標準。
PS。 哦，如果你的Windows用戶是一個開發人員，只需在Unix中用文本格式化，並告訴他們這是來自Unix的文件。
您的功能有問題。使用它來運行字符串以檢測換行符會爲每個Windows換行符檢測兩個。如果你通過它分割線，你會得到空行。 – 2008-09-26 05:04:46
修正了它。它仍然是僞代碼，但其想法是，它貪婪地消耗潛在的換行符，並在這種情況下「修復」它們。這個'修復'真的取決於你想要做什麼。 – SCdF 2008-09-26 05:18:10