爲什麼讀取UTF-16LE文件不會轉換爲「\ r \ n」變成了「\ n」在Windows

如果我在讀用下面的代碼然後每個「\ r \ n」個文件將在存儲器被轉換成「\ n」個ASCII文件：如果我在UTF-16LE（視窗1200）讀

open CUR_FILE, "<", $asciiFile;

用以下代碼文件，當我嘗試用換行符正則表達式行時，這種不一致性會導致問題。

open CUR_FILE, "<:encoding(UTF-16LE)", $utf16leFile;

然後「\ r \ n」將保持不變。

更新：
對於UTF-16LE文件的每一行：

line =~ /(.*)$/

那麼字符串匹配$ 1將包括一個爲「\ r」結尾......

它看起來像一個bug。據我記得，Perl應該保證'\ n'適用於內部編碼的東西的換行匹配。絕對適用於Windows上的其他編碼。 – 2010-04-13 03:31:00

您正在使用哪個版本的Perl？如果它不是5.10.1（或5.12.RCn），那麼你能切換到更新的版本嗎？ – 2010-04-13 04:35:41

我使用的是5.10.0，但升級到5.10.1後，問題依然存在（Windows 64bit） – 2010-04-13 05:13:58

你使用的是什麼版本的Perl？ UTF-16和CRLF處理在5.8.9（Unicode changes in 5.8.9）之前沒有正確混合。我不確定關於5.10.0，但它在5.10.1和5.8.9中工作。打開文件時可能需要使用。

2010-04-13 04:42:57 cjm

「<：encoding（UTF-16LE）：crlf」的錨點，即使使用5.10.1版本，也不起作用 – 2010-04-13 05:14:36

@cjm在5.10版本的測試中出現中斷。 1（雖然承認我不在窗戶上，我只是用'PERLIO = crlf'來僞裝它:) – hobbs 2010-04-13 05:19:32

'「<：encoding（UTF-16LE）：crlf」'絕對適合我（在Linux上）與5.8.9和5.10.1。我在Windows上只有5.8.8，並且不起作用。 – cjm 2010-04-13 05:44:22

那就是windows爲你執行這個魔術......如果你指定了UTF，這相當於以二進制模式打開文件vs文本。

較新版本的Perl具有\ R這是一個通用換行符（即，將匹配\ r \ n和\ n）以及\ v，它將匹配垂直空白的所有OS和Unicode概念（即，\ r \ n \ r \ n不間斷空格等）

您是否正則表達式邏輯允許使用\ R而不是\ n？

2010-04-13 03:54:30 dawg

我只是使用$作爲行尾 – 2010-04-13 05:29:58

回答