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編碼資料說明：
[javascript] view plain copy <meta charset="utf-8"/>
[javascript] view plain copy //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 資料來處理。
