如何在.NET中確定文件是UCS-2還是UTF-16

我有可以在UTF-16中正常加載.NET的平面文件，即使它們在技術上是UCS2-LE（w/o BOM），而且我明白這是因爲UCS-2是UTF-16替代的較老的標準。如何在.NET中確定文件是UCS-2還是UTF-16

但是，我感興趣的是能夠確定文件是否實際上是UCS-2。我知道這意味着我會猜測。我嘗試過使用chardet的.NET端口，IMultilang2 interop，以及Novell的一些開源代碼，因爲它試圖通過UTF-16來確定UCS-2，我還沒有取得任何成功。我還沒有找到任何技術可以確定UCS-2LE沒有BOM和無效/過長的UTF-8之間的差異。

我應該檢查他們字節的字節，並試圖確定它是變量還是固定長度編碼？也許看看缺少的代碼點？問題是這些文本文件沒有特殊的代碼點，它們只有bog標準的西方字符集。但TextPad將它們保存爲不帶BOM的UCS2-LE，並且它使我們的軟件中的下游文件操作變得複雜，並希望它們完全符合UTF-16（只是強制加載文件，但不能滿足軟件要求）。

來源

2012-05-24 Daniel Crenna

這可能有所幫助：[https://lists.ubuntu.com/archives/bazaar/2007q2/025942.html]（https://lists.ubuntu.com/archives/bazaar/2007q2/025942.html）引用：*在解釋過去用法中「UCS-2」的含義時，最好認爲它不是數據格式，而是表示實現不解釋任何補充字符。特別地，爲了數據交換的目的，UCS-2和UTF-16是相同的格式。兩者都是16位，並且具有完全相同的代碼單元表示。* –

這就是問題;我可以使用現有的啓發式方法檢測UTF-16，但這些實現無法找出UCS-2LE沒有BOM文件。我想對待它們，但我最終不得不使用後備編碼，因爲我找不到一種方法來確定差異。 –

本維基百科文章部分，http://en.wikipedia.org/wiki/UTF-16, 談論基本多語言平面，BMP。 BMP中的所有代碼點對於UTF-16和UCS-2都是相同的。如果TextPad只是編碼BMP，那麼您可以將文檔視爲UTF-16或UCS-2。

這是編碼之外的代碼點編碼，出現問題。 UCS-2無法表示BMP以外的代碼點。http://en.wikipedia.org/wiki/Universal_Character_Set 這將導致人們假設，如果代碼點在BMP之外，那麼它可以用UTF-16處理。如果創建該文件的程序不正確地執行UCS-2並且在BMP之外使用代碼點以輔助原因，則這可能會有問題。

大多數讀取UTF的庫和程序都允許您指定在每個字符的基礎上發生編碼錯誤時引發的操作（引發異常，用佔位符替換，簡單忽略）。如果一個不正確的UCS-2文件以UTF-16格式運行，它會引發錯誤。瞭解該文件的作者在BMP之外嘗試做什麼將是正確處理它們的唯一方法。

來源

2012-06-05 00:21:01

這一切都是絕對正確的，但是當沒有BOM時，我無法像chardet的.NET端口，IMultiLang2等工具那樣猜測任何UCS-2LE文件的UTF-16。 TextPad正好存儲BMP，這是正確的，但我無法讓我的軟件以一種防彈的方式來解決這個問題。但是，這基本上是答案，在這種情況下，我可以通過該文件運行並確定代碼點是否在BMP中。我不喜歡的部分是我無法找到一種啓發式方法，可以在沒有物料清單時自行猜測。 –

如何在.NET中確定文件是UCS-2還是UTF-16

回答

相關問題