推 LPH66: 應該是來源字串已經是 NFD 分解過的字了 49.159.72.196 11/09 13:38
→ LPH66: じ (U+3058) 經過 NFD 會拆開成し (U+3057) 49.159.72.196 11/09 13:39
→ LPH66: 和組合用濁點 U+3099, 會顯示不正常的就是 49.159.72.196 11/09 13:40
→ LPH66: 這個組合用濁點沒有正確處理 49.159.72.196 11/09 13:40
→ LPH66: 後者跟單獨打的濁點 ゛(U+309B) 是不一樣的 49.159.72.196 11/09 13:41
推 LPH66: 至於你寫的程式的問題就要看你是用什麼方式 49.159.72.196 11/09 13:44
→ LPH66: 去讀檔名; 會發生消失的狀況應該不是直接 49.159.72.196 11/09 13:44
→ LPH66: 向系統讀 Unicode 檔名的那種 49.159.72.196 11/09 13:45
→ LPH66: 這會讓系統先幫你轉成地區編碼(big5 等)後 49.159.72.196 11/09 13:46
→ LPH66: 才回傳給你, 但 U+3099 沒有對應碼就吃掉了 49.159.72.196 11/09 13:47
感謝L大回復,我研究一下
※ 編輯: liu2007 (123.192.225.144 臺灣), 11/09/2021 14:18:14
程式的部分我是用QT寫的
讀取檔名其實也沒有什麼特別的操作
純粹就是
QFileInfo target{"F:\檔案A"}
target.fileName();
如此而已
我沒想到在日文上會有拆解的問題
※ 編輯: liu2007 (123.192.225.144 臺灣), 11/09/2021 14:36:58
推 LPH66: 啊, QT 的話那 QString 有支援分解組合 49.159.72.196 11/09 15:03
→ LPH66: 呼叫 normalized 函數並指令 NFC 型式 49.159.72.196 11/09 15:03
→ LPH66: (NormalizationForm_C ←這個參數) 49.159.72.196 11/09 15:03
→ LPH66: 就能幫你組起來了 49.159.72.196 11/09 15:04
→ LPH66: 上三樓 指令→指定 49.159.72.196 11/09 15:05
→ LPH66: 不然一般來說這種分解組合需要有函式庫幫忙 49.159.72.196 11/09 15:07
→ LPH66: 這樣看起來似乎做拆解的可能是 QT 49.159.72.196 11/09 15:08
→ LPH66: 主要因為就我所知 Windows 很少做自動拆組 49.159.72.196 11/09 15:28
→ LPH66: (Windows 也有他自己的一套函數可以做就是) 49.159.72.196 11/09 15:28
→ LPH66: 反而比較常聽到 Apple 很常幫拆 49.159.72.196 11/09 15:28
→ LPH66: 但你這裡的使用情境顯然是 Windows... 49.159.72.196 11/09 15:28
沒錯,就是這個normalized,剛剛也是找到這個解
感謝L大的細心的指點
我想我下載的檔案應該是來自MacOS分享的檔案
然後Win7的系統、chrome、網站、Sublime Text都有做處理
但就是我的程式和win7內建的筆記本以及ptt沒做處理,所以才會產生錯誤吧?
總之非常感謝
本來以為這個問題不會有人回答XDDD
※ 編輯: liu2007 (123.192.225.144 臺灣), 11/09/2021 15:40:56