對於一個“純JS實現GB2312轉碼”的看法

來源:互聯網
上載者:User

完整貼在 http://community.csdn.net/Expert/TopicView3.asp?id=4563329

此處把我的論點集中一下:

編碼問題不應該這樣解決。樓主的出發點是好的,但是解決問題的思路有問題,這個東西充其量就是一個在某些特定條件下的patch。

我說的“思路問題”,是指樓主有沒有想過,encoding實際上是一種底層的(相對你開發的application本身來說)設施。

你用到encoding僅僅是在通訊中,如流的io。對於b/s來說,基本上就是browser和server的通訊,極少數應用可能涉及本地檔案系統的讀寫(但是這樣的話通常會使用ActiveX或者XPCOM,就更不必用js來做轉碼了)。本質上,好的設計必然需要把這一部分細節封裝起來。

事實上,encoding的處理,在正常環境下,這應該是由瀏覽器和伺服器完成的任務。而且這些都有技術規範或約定。例如伺服器發送content-type頭中指定encoding。

正確的思路應該是學會怎樣正確的利用瀏覽器和伺服器的設施,而不是自己去造輪子。你的輪子運行在系統體系的錯誤的層次,而且轉動也不流暢(效能問題)。只有在極少數的情況下(如某些瀏覽器的bug,或者你沒有辦法去修改伺服器的錯誤設定),你的代碼可以作為一種臨時性的patch。

關於encoding問題,已經確立的最佳實務就是,儘可能全部使用utf-8編碼(如html,xml,js,css...)。基本上現代瀏覽器都能識別帶有BOM的utf-8。

這個東西如果作為framework的一部分來說,還是有一點意思的。framework和一般的app開發有些不同,提供這樣的功能也不錯。不過我是建議在文檔中寫清楚,對於大多數情況,不應推薦使用該功能。不能因為framework有一種patch的能力,就慣壞了所有用framework的程式員,讓他們失去了學習“正確方式”的機會。

例如,“因為很多web伺服器在處理請求,反編碼的時候都是採用gb2312的方式。”
這個例子裡面,關鍵在於這些web伺服器端的程式(asp,jsp,etc.)最好不要用gb2312的方式解碼,我在csdn和很多地方的討論java中文問題的地方都反覆表達了這個觀點。特別是GET方式的(參數編碼在url裡面的),應該始終以utf-8來解碼,這是大量規範(http相關的rfc, w3c html規範等等)已經規定了的。以XmlHttpRequest來說,由於它只能請求本domain的網頁,可以認為做js開發的人,應該有能力影響 server端的人,所以基本上不存在server無法控制的問題。如果是虛擬機器主機使用者發現虛擬空間的設定有問題(例如始終以錯誤的編碼發送 content-type),可以要求webmaster做設定,如果它的服務商不願意或者不會的話,那就是服務水準或者態度的問題,如果是我的話,我就會換一家。

開發難道不是根據具體的環境和情況來討論的嗎?對於可以得到更高許可權的Intranet或本地應用,IE下可以用ActiveX,Moz可以用 XPCOM,都可以調用效能更高的編碼模組。對於一般WebApp,應該始終遵循各種規範,例如提交URL參數應該始終使用UTF-8,這才是正途。我們有太多程式員老是用各種hack,而不是仔細看看到底這個工作應該在整個體系的哪一部分完成。

單純作一個js下的gb2312codec,它是完成了一定的功能,我認為作為framework的一個備用工具還是不錯的,但是採用其來作為通用的跨瀏覽器解決方案顯然是不妥的,就好像在城市的公路上騎馬出行,沒錯,可以到達目的地,但是能作為城市的通用交通工具嗎?

同樣是字元處理,做一個完整的漢字和拼音索引,對於高互動的webapp開發來說,如果能增加這方面的庫,其意義比gb2312codec要大得多!

網頁當然可以gb2312 編碼。但是參數提交應該使用utf-8,兩者並不矛盾。

我們不能完全歸咎於客觀原因,我們有沒有自己爭取過用正確的方式處理問題呢?其實並不一定需要轉碼。

雖然XMLHttpRequest在讀取text檔案時,並不會自動調整編碼,但是如果你讀取的是一個帶有encoding聲明的xml檔案,無論IE或者 Moz都會正確的處理編碼。所以根本沒有必要大動幹戈的使用所謂純JS的轉碼。到現在為止,我還沒有看到一個實際的web應用例子能說用純JS轉碼是合理的方案。

最後補充一點,解決encoding問題的最好方法是伺服器發送正確的Content-Type。這是多份規範所規定的,即伺服器發送的Content- Type對決定User-Agent應採取的character encoding具有最高的優先順序。而IE、Moz、Opera都是基本遵循這個規範的(無論是網頁還是XMLHttpRequest)。

如果情況確實需要處理多種編碼,那麼最佳實務是:只要開發人員有機會影響到server配置,就不要放棄使用這一最簡單直接高效的方式來解決問題!例如,即使你是virtual host使用者,而你的服務商既蠢又態度蠻橫,使得你無法去改正錯誤的全域配置,但是你還可能有機會使用.htaccess的方式在局部作修正(事實上由於你的服務商很蠢,所以他做出錯誤配置的機率反而小,並且其伺服器保持預設設定即允許使用.htaccess的機會是很大地)。

對於最常用的Apache 2而言,AddCharset指令甚至可以做的更好。使用該指令可以為特定尾碼名的檔案自動選擇字元集編碼。而且,令人高興的是,在絕大多數安裝版本的預設配置下,abc.gb.html就會發送gb2312作為編碼,一切就都ok了。你所要做的只是規範一下檔案命名。注意:Apache的預設配置使用 Content-Negotiation,你甚至只要訪問abc就會自動為中文使用者選擇abc.gb.html的內容發送過去。
對於各種Java web container(servlet/jsp),只要你的container不是太老掉牙,你都可使用filter來處理encoding,Java具有一切你處理encoding所要的能力,唯一問題是你會不會使用。

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.