Node.js 中文亂碼解決
Node.js 支援中文不太好(實際上是Javascript支援),見《Node.js開發指南》。
要想Node.js正常顯示中文,需要兩點:
1、js檔案儲存為unicode格式。js檔案是否為unicode格式,一個簡單的方法是使用記事本來判斷。使用記事本開啟JS檔案,點選單另存為,看編碼格式是否為"UTF-8"。若不是,可使用UltraEdit工具進行轉換,使用記事本也可以轉換。
2、在js檔案中增加編碼說明meta資料,讓瀏覽器知道使用什麼編碼來解釋網頁。
兩個條件缺一不可。
一個Node.js中使用中文的例子如下,該app.js需儲存為utf-8格式,同時在文中增加meta編碼資料說明:
《Node.js開發指南》節選:
Node.js 不支援完整的Unicode,很多字元無法用string 表示。公平地說這不是Node.js 的缺陷,而是JavaScript 標準的問題。目前JavaScript 支援的字符集還是雙位元組的UCS2,即用兩個位元組來表示一個Unicode 字元,這樣能表示的字元數量是65536。顯然,僅僅是漢字就不止這個數目,很多生僻漢字,以及一些較為罕見語言的文字都無法表示。這其實是一個歷史遺留問題,像2000 年問題(俗稱千年蟲)一樣,都起源於當時人們的主觀判斷。最早的Unicode 設計者認為65536個字元足以囊括全世界所有的文字了,因此那個時候盲目相容Unicode 的系統或平臺(如Windows、Java 和JavaScript)在後來都遇到了問題。
Unicode 隨後意識到2個位元組是不夠的,因此推出了UCS4,即用4 個位元組來表示一個Unicode 字元。很多原先用定長編碼的UCS2 的系統都升級為了變長編碼的UTF-16,因為只有它向下相容UCS2。UTF-16 對UCS2 以內的字元采用定長的雙位元組編碼,而對它以外的部分使用多位元組的變長編碼。這種方式的好處是在絕大多數情況下它都是定長的編碼,有利於提高運算效率,而且相容了UCS2,但缺點是它本質還是變長編碼,程式中處理多少有些不便。
許多號稱支援UTF-16 的平臺仍然只支援它的子集UCS2,而不支援它的變長編碼部分。相比之下,UTF-8 完全是變長編碼,有利於傳輸,而UTF-32 或UCS4 則是4 位元組的定長編碼,有利於計算。
當下的JavaScript 內部支援的仍是定長的UCS2 而不是變長的UTF-16,因此對於處理UCS4 的字元它無能為力。所有的JavaScript 引擎都被迫保留了這個缺陷,包括V8 在內,因此你無法使用Node.js 處理罕見的字元。想用Node.js 實現一個多語言的字典工具?還是算了吧,除非你放棄使用string 資料型別,把所有的字元當作二進位制的Buffer 資料來處理。
要想Node.js正常顯示中文,需要兩點:
1、js檔案儲存為unicode格式。js檔案是否為unicode格式,一個簡單的方法是使用記事本來判斷。使用記事本開啟JS檔案,點選單另存為,看編碼格式是否為"UTF-8"。若不是,可使用UltraEdit工具進行轉換,使用記事本也可以轉換。
2、在js檔案中增加編碼說明meta資料,讓瀏覽器知道使用什麼編碼來解釋網頁。
兩個條件缺一不可。
一個Node.js中使用中文的例子如下,該app.js需儲存為utf-8格式,同時在文中增加meta編碼資料說明:
- <meta charset="utf-8"/>
- //app.js
- var http = require('http');
- http.createServer(function(req, res) {
- res.writeHead(200, {'Content-Type': 'text/html'});
- res.write('<head><meta charset="utf-8"/></head>');
- res.write('<h1>Node.js</h1>');
- res.write('<b>親愛的,你慢慢飛,小心前面帶刺的玫瑰...</b>');
- res.end('<p>Hello World</p>');
- }).listen(3000);
- console.log("HTTP server is listening at port 3000.");
《Node.js開發指南》節選:
Node.js 不支援完整的Unicode,很多字元無法用string 表示。公平地說這不是Node.js 的缺陷,而是JavaScript 標準的問題。目前JavaScript 支援的字符集還是雙位元組的UCS2,即用兩個位元組來表示一個Unicode 字元,這樣能表示的字元數量是65536。顯然,僅僅是漢字就不止這個數目,很多生僻漢字,以及一些較為罕見語言的文字都無法表示。這其實是一個歷史遺留問題,像2000 年問題(俗稱千年蟲)一樣,都起源於當時人們的主觀判斷。最早的Unicode 設計者認為65536個字元足以囊括全世界所有的文字了,因此那個時候盲目相容Unicode 的系統或平臺(如Windows、Java 和JavaScript)在後來都遇到了問題。
Unicode 隨後意識到2個位元組是不夠的,因此推出了UCS4,即用4 個位元組來表示一個Unicode 字元。很多原先用定長編碼的UCS2 的系統都升級為了變長編碼的UTF-16,因為只有它向下相容UCS2。UTF-16 對UCS2 以內的字元采用定長的雙位元組編碼,而對它以外的部分使用多位元組的變長編碼。這種方式的好處是在絕大多數情況下它都是定長的編碼,有利於提高運算效率,而且相容了UCS2,但缺點是它本質還是變長編碼,程式中處理多少有些不便。
許多號稱支援UTF-16 的平臺仍然只支援它的子集UCS2,而不支援它的變長編碼部分。相比之下,UTF-8 完全是變長編碼,有利於傳輸,而UTF-32 或UCS4 則是4 位元組的定長編碼,有利於計算。
當下的JavaScript 內部支援的仍是定長的UCS2 而不是變長的UTF-16,因此對於處理UCS4 的字元它無能為力。所有的JavaScript 引擎都被迫保留了這個缺陷,包括V8 在內,因此你無法使用Node.js 處理罕見的字元。想用Node.js 實現一個多語言的字典工具?還是算了吧,除非你放棄使用string 資料型別,把所有的字元當作二進位制的Buffer 資料來處理。
相關文章
- RHEL中文亂碼解決
- HttpClient 解決中文亂碼HTTPclient
- request/response解決中文亂碼
- eclipse中文亂碼解決Eclipse
- myeclipse解決中文亂碼Eclipse
- 解決Linux中文亂碼Linux
- ROS中解決中文亂碼ROS
- 解決中文亂碼問題
- MySql中文亂碼問題解決MySql
- Jmeter 解決中文亂碼問題JMeter
- 解決 SecureCRT 和 SecureFX 中文亂碼Securecrt
- Java 解決中文亂碼問題Java
- RDSSQLSERVER解決中文亂碼問題SQLServer
- Windows下Clion中文亂碼解決Windows
- 徹底解決Oracle中文亂碼Oracle
- 解決MySQL中文亂碼問題MySql
- 解決SecureCRT中文顯示亂碼Securecrt
- QT中文顯示亂碼解決QT
- cat中文正常vim中文亂碼怎麼解決?
- Spring MVC 中文編碼亂碼解決SpringMVC
- C# 解決httplistener querystring 中文亂碼、返回json中文格式亂碼C#HTTPJSON
- Dbvisualizer9.0.6 解決中文亂碼
- 解決plsql中中文亂碼問題SQL
- Springmvc中文亂碼解決辦法SpringMVC
- centos 中文亂碼解決辦法2CentOS
- 中文字元亂碼的解決字元
- mysql 插入中文亂碼解決方案 轉MySql
- 解決Tomcat視窗中文亂碼Tomcat
- springmvc 解決中文亂碼問題SpringMVC
- js解決url中文亂碼問題JS
- matplotlib 圖示 中文亂碼, 與 wordcloud 詞雲圖 中文亂碼 解決方法Cloud
- centos7 vim中文亂碼解決方法CentOS
- navicat for mysql顯示中文亂碼解決方案MySql
- toad 中文顯示亂碼解決方法
- java中解決request中文亂碼問題Java
- SpringMvc解決Restful中文亂碼問題SpringMVCREST
- css中文字型亂碼解決方案CSS
- python 中文亂碼問題解決方案Python