2012-08-16 51 views
1

從Java規範SE 7版如何用Unicode編寫程序?

3.1節統一

程序使用Unicode字符集編寫的。

§3.2詞彙翻譯

原始Unicode字符流被翻譯成的 令牌的序列,使用以下三個詞彙翻譯步驟......

我很困惑,因爲我寫我的源代碼與我的本地字符編碼(WINDOWS-1252),以及規範menti (?)全部從原始Unicode字符流開始,然後執行詞法翻譯(包括Unicode轉換轉換)。

他們提到的Unicode轉義可用於包括使用 只有ASCII字符的Unicode字符;如果執行先前的轉換,我認爲它們指的是Unicode字符集的子集中的ASCII字符,這很有意義。

有從以前寫的源文件的Unicode編碼之前的轉換?

一些相關的信息,但我認爲這是比較厚道的運行文本處理,而不是在編譯過程:

Converting Non-Unicode Text

+1

假設您的編譯器將能夠將您的源代碼文件*轉換爲內部的unicode表示。對於語言規範的目的而言,實際的物理文件的格式應該不重要。 – 2012-08-16 20:34:08

+1

CP-1252是一種**編碼**,並且該規範討論了**字符集**。所有由CP-1252支持的字符都確實包含在Unicode字符集中。 – 2012-08-16 20:37:03

回答

4

基本上什麼規格的意思是,你只能使用Unicode字符在你的源文件中。它沒有定義如何將這些字符實際編碼爲字節,這取決於您和您正在使用的平臺。

編譯器內基本上什麼情況是,源文件被從磁盤讀出的字節流,這些字節被再轉換爲Unicode字符Java的內部表示。它轉換的源文件,以Unicode字符的原始字節的方式是基於傳遞給javac-encoding選項。如果沒有設置-encoding選項,它將使用您的平臺的默認編碼。

現在還需要注意的是,在編譯器將源代碼字節轉換爲字符後,它會執行另一步將字符文字(例如\u00a5123)轉換爲適當的單個Unicode字符。這實際上是您在問題中引用的第3.2節中引用的三個步驟中的第一個。這樣就可以使用純ASCII字符來代表源代碼中的任何Unicode字符。

+0

這是否意味着你可以從字面上寫下你所有的源代碼:\ u00a5123? – 2012-08-16 21:22:16

+1

@RobertMarkBram我不知道有關Java,但C和C++允許使用Unicode逃逸以及但從被用於字符的基本來源字符串和字符以外設置禁止他們。我猜測Java有相同的限制,所以你不能用這種方式編寫你的代碼。 – bames53 2012-08-16 21:26:56

+2

@RobertMarkBram的Hello World程序使用轉義序列:http://ideone.com/EqD25 – nEAnnam 2012-08-16 21:41:29

2

'Unicode'不是一種編碼,它只是一個字符和相關數字(或'碼點')的列表,但與傳統字符集不同,這些數字不是Unicode字符的磁盤表示形式。要對Unicode字符進行編碼或解碼,您需要一個單獨的編碼,該編碼將字節序列映射到Unicode編號,從而映射到Unicode字符。

一些編碼,像UTF-8,設計編碼所有可能的Unicode代碼點。其他人,如Windows CP 1252,只能代表Unicode字符的一小部分。但是任何有效的Windows CP 1252數據仍然可以解碼爲有效的Unicode代碼點序列。

所以,是的,存在從磁盤表示到虛擬Unicode字符流的轉換。

+0

呀,怎麼統一進行處理(字符集或編碼),導致混亂,但看,我已經發布的鏈接(官方文檔),他們說:* Unicode是支持世界主要語言的16位字符編碼*所以我不知道如何引用它,謝謝你的建議 – nEAnnam 2012-08-16 21:17:46

+2

該文檔是不正確的。即使我們不會挑剔Unicode作爲編碼的參考,那麼他們仍然錯誤地說它是'16位'。事實上,Unicode代碼點在以二進制表示時可能需要多達21位。 Unicode聯合會承諾不會爲了保持與UTF-16兼容使用較大的值,但在此之前的Unicode也可以使用值高達兼容性31位用UTF-32和UTF-8(6字節的版本)。如果不希望與這些編碼保持兼容,那麼就沒有限制 – bames53 2012-08-16 21:28:39