→ descent:有沒可能是 utf8/big5 中文的問題 08/06 11:43
check 環境語系問題 應該不是 這問題追起來應該相當多文章
※ 編輯: erspicu (60.248.56.181), 08/06/2014 11:50:37
→ uranusjr:如果直接給 Big 5 編碼過後的 char sequence 呢? 08/06 12:19
真的很奇妙 大概發現原因
http://ideone.com/OuBhdX
char test_char2[]= "中文字測試" ;
網站經過處理變亂碼 但原始是這樣
經過測試這code儲存為ASII編碼
然後在不同的環境用不同的編譯器去跑
印出來的數值會不太相同
WIN7 CODEBLOCKS GCC跑出來是
char test!
98 , 97 , 120 , 101
-92 , -92 , -92 , -27
x86 linux上是
char test!
98 , 97 , 101 , 114
-92 , -92 , -27 , -90
arm linux上是
98 , 97 ,120 , 101
164 , 164 ,164 , 229
※ 編輯: erspicu (60.248.56.181), 08/06/2014 17:38:55
→ uranusjr:Windows 7 和 ARM Linux 其實是一樣的, 只是 char 定義為 08/06 17:59
→ uranusjr:signed 或 unsigned 的差異; 怎麼看都還是編碼問題啊 08/06 17:59
http://blog.cdleary.com/2012/11/arm-chars-are-unsigned-by-default/
這應該就是問題原因了 比較奇怪的是同是X86 列印英文
一組是98 , 97 , 120 , 101 一組是98 , 97 , 101 , 114
※ 編輯: erspicu (60.248.56.181), 08/06/2014 18:15:47
推 purpose:就 sign extension 超過 0x7F 的被一直補 1 出來就變負數 08/06 18:14
→ purpose:然後 linux 會把你的中文用 UTF-8 存,Win 用 Big5 存 08/06 18:15
→ purpose:至於 linux 的 98 97 "101" 應該是你打字錯誤 08/06 18:16
X86 LINUX sample 有打錯 array index變成 0,1,3,4 .....
所以的確只是signed和unsigned的問題 沒錯
這麼說來按照PTT sources的寫法 要編譯正確運作
在arm上就要多下一點編譯器參數了
※ 編輯: erspicu (60.248.56.181), 08/06/2014 18:20:58
→ uranusjr:這個故事告訴我們請不要對 non-ASCII input 用 char... 08/06 18:23
→ uranusjr:不知道如果提 patch 改成 signed char 他們會不會收 08/06 18:24
※ 編輯: erspicu (60.248.56.181), 08/06/2014 18:25:11
→ erspicu:借轉 08/06 21:40
※ erspicu:轉錄至看板 PttCurrent 08/06 21:40