我發現Firefox在繁體中文Windows XP or 2000都會有相同問題，就是建立一個日文目錄(裡面有檔案也讀取不到)或者建立一個日文檔案，然後去讀取就會發生錯誤，變成找不到檔案！
這個問題在WinRAR與ACDSee也有相同問題，反而在7-Zip與Ashampoo Photo Commander 4沒有這個問題。
哪個高手能說明到底是怎麼樣？到底Windows轉碼機制是為何？小弟想要了解，麻煩大家幫個忙。

這是bug 162361
簡單地說，為了相容Windows 95/98/ME，目前的Firefox不能使用Windows內建的機制處理Unicode檔名（因為Win9x不支援）。如果要修正這個問題，要不就是放棄Win9x的支援，要不就是對Win9x特別處理轉碼的問題。

[quote="chungyu"]我發現Firefox在繁體中文Windows XP or 2000都會有相同問題，就是建立一個日文目錄(裡面有檔案也讀取不到)或者建立一個日文檔案，然後去讀取就會發生錯誤，變成找不到檔案！
這個問題在WinRAR與ACDSee也有相同問題，反而在7-Zip與Ashampoo Photo Commander 4沒有這個問題。
哪個高手能說明到底是怎麼樣？到底Windows轉碼機制是為何？小弟想要了解，麻煩大家幫個忙。 :wink:[/quote]

我覺得真的是耶
不過至少現在有個問題改進了
以前開日文網頁在TAB還是TITLE上出現的日文字都會變成??????
1.07(吧?)以後的就都正常了

WinRAR和ACDSee就用Applocal開吧
如果ACDSee會因此發生錯誤，請使用舊版或經典版的即可

_________________
被恐嚇嘍…真恐怖…暫時不放簽名檔了

簡單講就是，因為 m$ 版的 big5 沒有日文假名，所以 unicode 日文假名對應過來會變成「?」或「_」。但系統內實際上並沒有「?」或「_」的檔案，所以就讀取失敗。

目前唯一不用改使用者習慣的解決方法是裝 unicode 補完計畫。其它方法都會或多或少的改變使用者的軟體使用習慣。


其實就我開發 unicode 補完計畫 98 版的經驗來看，用上 unicode layer 在 98 下，不能用的一樣是不能用，因為 unicode layer 一樣要去用系統的碼表作轉換，遇到碼表沒有對應的字一樣會死。xp 下全系統只有一個表在管轉換，98 下有 3 個 －－ 字型一個、顯示一個、檔案系統一個 －－ 即使 unicode layer 能轉，但由於 98 下顯示跟檔案系統是不同一張表，所以在掛了 unicode layer 的 98 下，不能動的一樣會不能動。

總之，扯到檔案系統的話，沒有方法可以兩全，單向對應只會死的更慘。

_________________
想讓 Internet Explorer 當掉嗎?

「方法一」 - 被 google 檔掉的樣子，開不起來

「方法二」

其實說到這個我一直很好奇
到底如果我輸入或剪貼（不管從哪，如ＢＢＳ或ＷＥＢ）
日文到
譬如MSN視窗，或者用來取檔名
這時候他是BIG5還是JIS日文呢

＊影響到其他人是否看得到我對話的日文
　或我燒錄檔案中的日文檔名

_________________
被恐嚇嘍…真恐怖…暫時不放簽名檔了

看您的目的地是什麼編碼，他就會變成什麼。

msn 是 unicode 程式，所以貼到 msn 會變成 unicode。
長檔名是 unicode 儲存，所以貼到長檔名會是 unicode。
bbs 是 big5 環境，所以貼到 bbs 會變 big5。
網站部份比較複雜一點，基本上一樣是看對方是什麼編碼，如果對方是 s-jis，那貼上就會變 s-jis，如果對方是 big5，那貼上就會變 big5，如果對方是 utf-8，那貼上就會變 utf-8。但是網站有 unicode 參照碼這種東西，如果那個 unicode 字 big5 沒有對應的話，網站就會用 unicode 碼硬上。這時如果看原始碼就會看到一堆數字天書。

我是不想再跟人吵什麼看不看得到的問題了，如果您的生命永遠不會碰到 bbs 也不會使用純文字，那麼的確，不要用 unicode 補完計畫對您而言是對的。如果您真的有想要瞭解，請自己下功夫作功課。

_________________
想讓 Internet Explorer 當掉嗎?

「方法一」 - 被 google 檔掉的樣子，開不起來

「方法二」

沒有和你吵的意思
我也離戰的生活很遠了
就這樣
還是謝謝你回答了我的疑惑

_________________
被恐嚇嘍…真恐怖…暫時不放簽名檔了

我想，Windows的所有版本(至少到目前為止)都還無法用多國語言的檔名吧？！因為Windows所有版本的檔案名稱都是用Big5編碼的。
不過在這一方面，Linux的作法就好很多，十分的方便。

_________________
- Wayne

這是錯誤認知哦，windows nt 的完整 unicode 程式都可以正確處理多國語言檔名。

98 雖然不是 unicode 核心，但「長檔名」本身就是用 unicode 儲存的，故只要系統的 unicode <-> ascii 對照表處理好，那 98 一樣可以直接處理多國語言檔名。

_________________
想讓 Internet Explorer 當掉嗎?

「方法一」 - 被 google 檔掉的樣子，開不起來

「方法二」

應該要說清楚的一點是
Windows 全系列對 unicode 的支援都很差
即使有支援的字碼，也常常找不到字型
Win 95 沒有 unicode 支援，Win 98 只有最基礎的支援
Win 2000/xp 仍然是只有部份支援，Vista 據說也沒改善
另 NTFS 內定是一定以 unicode 儲存檔名，
FAT32 則沒有限定，通常是 Big5
所以 98 上要用 unicode 環境？升級系統吧！
不想升級 Windows? 那 Linux 歡迎你

只針對這點補充：Fat32 下其實情況比較特別，VFAT 的長檔名使用標準 unicode 儲存，短檔名則用 local codepage 碼。那麼系統一般看哪個作用？

如果是 nt 核心的又使用純 unicode 程式，那麼是以本身即為 unicode 的長檔名為準。

如果是 98 的話，那一樣還是以 unicode 的長檔名為準，但這邊有條件，條件是該長檔名內含的所有字都必需要跟現時使用的 codepage 能作雙向對應，否則 98 會不能處理這個檔案。而一旦您的長檔名有符合這個條件，那麼即使他在磁碟上的對應短檔名是用 s-jis 儲存的，98 處理這個檔也不會出錯。

_________________
想讓 Internet Explorer 當掉嗎?

「方法一」 - 被 google 檔掉的樣子，開不起來

「方法二」

但是如果Firefox用MSLU的話....
雖然在Win 9x下依然不能處理非本地的編碼...
不過功能上可說比起現在也沒有損失吧?
(反正這些作業系統本來就不能處理Unicode檔名了)
如此一來用Win 2000/XP的話就可以正確處理這些編碼
事實上算起來還是算有益吧...

只不過看bugzilla那邊的討論好像對於MSLU的.dll檔如果包在安裝程式裡面到底合不合法我看到最後好像有沒有什麼結果^^"
並且這project不小如果要改我看也不是小工程...
大多數人也幾乎不會需要Unicode.....
結論就是Firefox要在Windows下支援Unicode檔名我看還有得等
雖然這也是目前這個優秀的瀏覽器中唯一令我不滿的地方了...

你該不滿的是作業系統，這不是瀏覽器的問題
MSLU 是真的有授權合約的問題，我之前有看過
dll 散佈是有限制的，而 Firefox 是自由軟體
一般軟體能否包一起都不一定，況是不能加諸限制的自由軟體
MSLU 並不是裝了就可以有 unicode 功能
他的用途只是讓專為 unicode 寫的程式可以在 Win 9x 上跑
幫應用程式作轉碼好跟系統溝通，實際上沒提供多少額外功能
程式在 Win 9x 系統上「仍然是被當 ANSI 程式在跑」的，
MSLU 只做相容性處理，並不是可以讓 Win 9x 支援 unicode 功能
這點在 M$ 提供的文件上可以找得到
實際上用了可以支援多少？我沒有實際試驗過
用這個的目的主要是讓開發者可以不用開發兩份程式
就可以把 for xp 的軟體拿到 9x 執行 (MSLU幫忙轉碼)
並不是用來提供 Win 9x 各種 xp 有的 unicode 功能

我文中也有提到即使用了Win 9x還是不能在Win9x中擁有Unicode的功能^^"
不知道你是否誤會我的意思...

我的原意是縱使如此...
用上MSLU的話又不會減少在Win9x上面的使用者的權益(理論上來說應該跟目前的情況一模一樣)
但是WinXP的使用者卻可以多享受到Unicode帶來的助益...

所以要不是MSLU的散佈上的合法性問題...(M$是寫"可散佈"...不過似乎還有一些規定[我沒仔細看])
何樂而不為呢??

不過其實是因為Firefox那邊的人太追求完美了吧?
像eMule也是open source....
它就有用MSLU....
不過他的網頁那邊就有提示Win9x使用者自行下載MSLU...
如果有使用者沒看到網頁....
程式開啟的時候也會自動檢查提示必須下載MSLU....
這樣就不會有合法性的問題...

至於作業系統怎樣我是不想多做評論了...
我自己也有在用Linux....
只是沒有拿它來當作我的桌面環境罷了...

你舉eMule當比較的例子不太恰當，一方面因為eMule沒有跨平台所以問題沒這麼複雜，而且eMule本身的功能就比Firefox簡單(沒有Extension，沒有plug-ins，不必考慮binary compatible)；另一方面Firefox的License(MPL/LGPL/GPL tri-license)也比eMule（GPL）複雜
雖然這個問題會拖這麼久不見得完全是上面這些原因就是了；不過幸好現在有自願者開始修的樣子。