MozTW 討論區
https://forum.moztw.org/

[問題]字元編碼不正常
https://forum.moztw.org/viewtopic.php?f=10&t=6454
1 頁 (共 2 頁)

發表人:  s921c003 [ 2005-02-11, 12:50 ]
文章主題 :  [問題]字元編碼不正常

這篇放在上面的板...沒人理

希望有人可以幫我

有時候我瀏覽網頁時 無論是什麼網頁

只要有日文的地方  就會有幾個字顯示成韓文

甚至還有全部都變成韓文的

絕對不會是因為對方打的是韓文 因為我打的日文偏偏就有一兩個顯示成韓文

我試過所有的編碼方式都不行(也包括自動編碼)

請問為什麼會這樣呢?

發表人:  路人乙 [ 2005-02-11, 14:34 ]
文章主題 : 

請問您用的輸入法是:

一、微軟日文新輸入法
二、微軟國際日文輸入法
三、Unicode 櫻花輸入法
四、Unicode 日和輸入法
五、Big5ext 櫻花輸入法
六、Big5ext 日和輸入法
七、智慧半角輸入法

哪一種?

發表人:  josesun [ 2005-02-11, 15:19 ]
文章主題 : 

maybe 你可以抓個圖? :?

發表人:  s921c003 [ 2005-02-11, 16:49 ]
文章主題 : 

路人乙 寫:
請問您用的輸入法是:

一、微軟日文新輸入法
二、微軟國際日文輸入法
三、Unicode 櫻花輸入法
四、Unicode 日和輸入法
五、Big5ext 櫻花輸入法
六、Big5ext 日和輸入法
七、智慧半角輸入法

哪一種?

我不知道我用的日文輸入法是哪一種
有兩種日文的
不過有櫻花的我可以確定
另一種則是我去Unicode補完計畫下載的2.4 AlphaBeta版

發表人:  s921c003 [ 2005-02-11, 16:54 ]
文章主題 : 

josesun 寫:
maybe 你可以抓個圖? :?

請看圖中上方"OhHunter"旁是否有兩個韓文?

作者說他是打"覇気"

可是我看卻變成韓文

我看是韓文的地方還有一些地方

不過變成古物了 一時之間找不到

附加檔案:
檔案註釋: 應觀眾要求XD
ehh.JPG [173.46 KiB]
被下載 3461 次

發表人:  路人乙 [ 2005-02-11, 19:41 ]
文章主題 : 

呃~~~Firefox 不支援 Unicode 補完計畫與 Big5 日文...抱歉囉...
請找找看有沒有 3rd-party 的版本...

發表人:  Alica [ 2005-02-11, 21:38 ]
文章主題 : 

路人乙 寫:
呃~~~Firefox 不支援 Unicode 補完計畫與 Big5 日文...抱歉囉...
請找找看有沒有 3rd-party 的版本...

看來是Unicode補完計畫新增的日文漢字啊……那就沒救了,的確是看不到這樣。可以的話應該請jtw或其他願意幫忙編譯Firefox的大大們弄一份有支援Unicode補完計畫的版本;可以不用常常改版,至少方便有需要的使用者。

發表人:  josesun [ 2005-02-11, 23:15 ]
文章主題 : 

Alica 寫:
看來是Unicode補完計畫新增的日文漢字啊……那就沒救了,的確是看不到這樣。可以的話應該請jtw或其他願意幫忙編譯Firefox的大大們弄一份有支援Unicode補完計畫的版本;可以不用常常改版,至少方便有需要的使用者。

我覺得做成擴充套件的形式會比較好(不過我不知道可不可行@@")

發表人:  路人乙 [ 2005-02-11, 23:40 ]
文章主題 : 

= = ...
直覺上,做成 Plug-in 的成功率應該比較高...
做成 extension 應該會發生像同文堂那樣的效率問題~

發表人:  訪客 [ 2005-02-12, 10:48 ]
文章主題 : 

路人乙 寫:
= = ...
直覺上,做成 Plug-in 的成功率應該比較高...
做成 extension 應該會發生像同文堂那樣的效率問題~
同文堂有什麼效率問題?

發表人:  路人乙 [ 2005-02-12, 16:47 ]
文章主題 : 

Anonymous 寫:
同文堂有什麼效率問題?


簡單來說就是應用程式執行層級的問題。

◎由於套件架構的關係,同文堂在執行轉換時是按照下面的步驟:

文件進入本文區→待載入完成後擷取本文區文件→轉換字碼→搜尋並替換關聯字詞→重繪本文區

這個程序的問題在於「為什麼一定要等文件載入完成才進行轉換?」,
如果事先就知道使用者「要看正體中文」,
那麼在載入時以 Element by Element 的方式進行替換字碼的工作會不會比較有效率?
(這個假設建立在「載入網頁時,CPU 通常是閑閑沒事幹」的假設上)
但是,囿於套件環境架構的關係,除了以本文區為 spool 之外,
我實在找不到有哪個點可以先切入做這個工作,
如果可行的話,那麼同文堂的「轉換字碼」功能看起來應該會更有效率,
(或許可以將「轉換字碼」與「轉換關聯字詞」兩個選項拆開,
 讓使用者有兩段式的工作效能可選擇)

◎從另一個層次上來說,同文堂的效能問題也就是瀏覽器架構的問題。

套件工作的方式可以這樣表示(忽略介面繪製的部份):

腳本→(Interp. to ByteCode)→Machine Code→Run(Search and Replace)→Render Page

我們可以很明顯看出來:腳本→(Interp. to ByteCode)這一段是腳本引擎的罩門,
要避過這一段有兩個方法:

一、將替換編碼的部份直接以機器碼實作,
  實現的方法有賴於將這個功能劃分到 Core 層級,
  (這是不可能的,因為這個功能只有兩岸三地的人用得到)
  或是將這個功能製作成 plugin(plugin 可以是 dll 形式)。

二、將原來的字碼表直接取代掉,
  也就是類似「Unicode 補完計畫」編譯到 Firefox 中的作法,
  (這也是不可能的,因為 UAO 目前尚非公認的「標準」,
   更不用提內建簡體字碼(GB)→繁體(UTF8)取代程式的這種作法)
  或是直接使用以正體顯示簡體的 Typeface 字型,
  但是這樣子就無法進行「關聯字詞」替換的作業了。

相同的問題也發生 Adblock 身上(怎麼看都是一個「用戶導向」的功能),
大家應該可以很明顯感覺出來:Maxthon 的「廣告獵手」效能遠優於「Adblock」,
不過 Adblock 可以藉由撰寫良好的 Filter 來改善這種情況,
但「同文堂」的「搜尋、比對、取代」工作卻是一項也跑不掉。

最後的結論就是:
如果 NPAPI 允許的話,以 plugin 實作會是最可行方案,
但是因為 platform 的關係,一種平台就要重新編譯一次,
因此失去了跨平台的優勢...

以上(是胡謅,請您看過就忘了 :P

發表人:  josesun [ 2005-02-12, 17:50 ]
文章主題 : 

路人乙 寫:
最後的結論就是:
如果 NPAPI 允許的話,以 plugin 實作會是最可行方案,
但是因為 platform 的關係,一種平台就要重新編譯一次,
因此失去了跨平台的優勢...

以上(是胡謅,請您看過就忘了 :P

我是希望能夠用 Extension ,畢竟它是使用者安裝最方便的作法...但是這樣同文堂要 rendering ,UAO 也要 rendering ...這個... :shock: :shock: :shock:

發表人:  訪客 [ 2005-02-12, 18:13 ]
文章主題 : 

josesun 寫:
路人乙 寫:
最後的結論就是:
如果 NPAPI 允許的話,以 plugin 實作會是最可行方案,
但是因為 platform 的關係,一種平台就要重新編譯一次,
因此失去了跨平台的優勢...

以上(是胡謅,請您看過就忘了 :P

我是希望能夠用 Extension ,畢竟它是使用者安裝最方便的作法...但是這樣同文堂要 rendering ,UAO 也要 rendering ...這個... :shock: :shock: :shock:
Extension其實是個容器(container)而已,既能包XUL+JS+XPCOM,也能包plug-in。說到底Extension什麼都能做(如果世界沒有license問題的話……)

發表人:  路人乙 [ 2005-02-12, 18:24 ]
文章主題 : 

josesun 寫:
我是希望能夠用 Extension ,畢竟它是使用者安裝最方便的作法...但是這樣同文堂要 rendering ,UAO 也要 rendering ...這個... :shock: :shock: :shock:


Render 兩次? >"< ....算了,這個不是我們無知市井小民可以插手的,
我們的任務是「用景仰渴求的眼神默默望著 softcup 與 Jtw」~ :P

Anonymous 寫:
Extension其實是個容器(container)而已,既能包XUL+JS+XPCOM,也能包plug-in。說到底Extension什麼都能做(如果世界沒有license問題的話……)

呃~~~對啊~XPI 啥都能包,但是餡的料不是人人能吃 :roll:

發表人:  s793016 [ 2005-02-14, 12:37 ]
文章主題 : 

嗯啊 .... 我回應一下

日文漢字變成韓文的問題是因為,m$ bundle 的免費 ttf
韓文字型中,有內含造字。而 firefox 是 unicode base
的程式,沒動過手腳的 firefox 在看到那些 big5 造字碼
時會先把它轉成 unicode 造字碼再去抓字型來顯示,而
這時會以 native true type 內的造字為優先抓取,所以
無論您有沒有裝造字檔,那些字都會先從韓文 ttf 中取用
,於是就變成韓文了。

至於另兩位的提議,我也覺得好像出現一線曙光一樣,不管
是 extension 或是 plug-in,原則上只要您們找的到人寫,
我願意提供我手上所有的資料,就這樣。

ps: 其實想想 filter 會比同文堂好一點吧,因為只要對 big5
造字有對應的 unicode 造字區作代換,範圍小多了,搞不
好一整頁只有不到 1/10 的字會換,實際上個人使用同文堂
感覺在類似的情況下,效率也是很快的。

1 頁 (共 2 頁) 所有顯示的時間為 UTC + 8 小時
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/