推 kocw:拖曳後顯示"此檔案不是正確的unicode文字檔" 01/15 18:28
→ CHCOOBOO:我有點忘了 它只支援某一種UTF格式 01/15 18:29
→ tokeep:試了一下.應該是Unicode-LE 01/15 21:06
→ Wcw5504:在設定→轉碼程式那裡把big5日文假名支援取消就可以了吧 01/17 04:08
→ Wcw5504:以前轉utf-16le的時候 也是這樣解決的 01/17 04:08
→ CHCOOBOO:什麼! 原來是這樣造成BUG的!? 01/17 21:04
→ y3k:UTF-8的問題在於他出來的檔案會比較大 因為中文字會是二到四個 01/17 22:00
→ y3k:位元組不等的長度 如果要求檔案不要太大而沒有日文字符還是可 01/17 22:02
→ y3k:以用BIG5的 01/17 22:02
→ mybaby520:UTF-8中文3bytes 以目前的硬碟容量和網路上下行速度儲存 01/17 23:48
→ mybaby520:編碼還是選好一點的較優 01/17 23:49
推 newclicker:UTF-8的優點是可以向下相容ASCII,Unicode則否 01/18 02:41
推 newclicker:精確的說UTF-8向上可表示Unicode字元,向下可相容ASCII 01/18 02:44
→ newclicker:但是UTF-16(Unicode-LE、BE)則無法向下相容ASCII 01/18 02:50
→ newclicker:相較於編碼效率,佔用空間,UTF-8的向下相容性是他的優勢 01/18 02:53
推 newclicker:而且是很大的優勢... 01/18 02:55
→ Wcw5504:不過現在沒支援UTF-16的大概也沒幾款了... 01/19 23:25
推 newclicker:牽涉編碼的不只有文字編輯轉檔軟體,還有檔案系統以及 01/29 17:14
→ newclicker:網路傳輸等等,這時候相容性就非常重要了,像是上ptt的 01/29 17:16
→ newclicker:telnet連線依然還是靠ASCII編碼,其他Server頂多支援到 01/29 17:18
推 newclicker:能以UTF-8編碼和用戶端的Client軟體溝通就算很了不起了 01/29 17:21
推 newclicker:碰到UTF-16相關編碼往往下場就是死給你看,這點回顧FTP 01/29 17:50
→ newclicker:伺服器,Client的進化史就能明瞭當中相容問題的斑斑血淚 01/29 17:52