TCL腳本（Eggdrop）有特殊字符問題

我在新的Debian服務器上安裝了Eggdrop，但它在處理特殊字符時仍然存在問題。TCL腳本（Eggdrop）有特殊字符問題

Eggdrop正在運行utf-8。我甚至在腳本中手動實施了TCL編碼爲utf-8。我已經嘗試用http://eggwiki.org/Utf-8的指令重新編寫Eggdrop。

22:00 <@me> !tr fr I have prepared lots of cookies for the entire family. 
22:00 <@bot> J'ai prÃÂ©parÃÂ© beaucoup de biscuits pour toute la famille. 
22:00 <@me> !tr ar The special characters are processed. 
22:00 <@bot> ÃÂªÃÂªÃE ÃEÃÂ¹ÃÂ§ÃDÃÂ¬ÃÂ© ÃÂ§ÃDÃÂ£ÃÂÃÂ±ÃA ÃÂ§ÃDÃÂ®ÃÂ§ÃÂµÃÂ©.

（參閱前一個問題問，那沒有得到解決：Issues with TCL encoding on Eggdrop）

namespace eval gTranslator { 

# Factor this out into a helper 
proc getJson url { 
    set tok [http::geturl $url] 
    set res [json::json2dict [http::data $tok]] 
    http::cleanup $tok 
    return $res 
} 
# How to decode _decimal_ entities; WARNING: high magic factor within! 
proc decodeEntities str { 
    set str [string map {\[ {\[} \] {\]} \$ {\$} \\ \\\\} $str] 
    subst [regsub -all {&#(\d+);} $str {[format %c \1]}] 
} 

bind pub - !tr gTranslator::translate 
proc translate { nick uhost handle chan text } { 
    package require http 
    package require json 
    set lngto [string tolower [lindex [split $text] 0]] 
    set text [http::formatQuery q [join [lrange [split $text] 1 end]]] 
    set dturl "http://ajax.googleapis.com/ajax/services/language/detect?v=1.0&q=$text" 

    set lng [dict get [getJson $dturl] responseData language] 

    if { $lng == $lngto } { 
    putserv "PRIVMSG $chan :\002Error\002 translating $lng to $lngto." 
    return 0 
    } 
    set trurl "http://ajax.googleapis.com/ajax/services/language/translate?v=1.0&langpair=$lng%7c$lngto&$text" 
    putlog $trurl 

    set res [getJson $trurl] 

    putlog $res 
    #putserv "PRIVMSG $chan :Language detected: $lng" 

    set translated [decodeEntities [dict get $res responseData translatedText]] 

    putserv "PRIVMSG $chan :[encoding convertto utf-8 $translated]" 
} 
}

來源

2011-05-19 Dennis

你有什麼問題？你的問題沒有問題。 – 2011-05-19 20:52:36

你看到的醜陋混亂是UTF-8解釋爲ISO 8859-1。它表示某處存在對什麼字符意思的曲解，並且可能由或通過通信信道獲得電線，或通過應用額外的一輪編碼而引起。由於涉及到很多移動部件（IRC客戶端，IRC服務器，蛋白滴，腳本，谷歌翻譯），因此有必要通過調試來與您討論。

Tcl和谷歌彼此正確通信（我仔細檢查了代碼），所以我們可以消除這種可能性。因此問題在於您的IRC客戶端，IRC服務器和eggdrop之間;如果他們不同意「線上」字節的解釋是什麼，那麼你會得到改變。

您可以添加（或刪除）通過使用encoding convertto（和encoding convertfrom）在腳本重整，但它是必要向是明確你爲了得到它的權利在做什麼。在內存中，Tcl將字符串表示爲抽象Unicode字符的序列;他們在記憶中被「記錄下來」的方式並不是您的業務（事實上，這種複雜的方式在運行時間上幾乎總是非常高效）。如果有一個普遍的IRC服務器頻道將通過UTF8，您的要求則是：

確保蛋花湯腳本將UTF8編碼字符的通道。
確保您的客戶端從通道讀取UTF8編碼的字符。

處理第一點，我不記得是否eggdrop自動處理您的編碼。如果確實如此，你只是這樣做在你的綁定的最後階段：

putserv "PRIVMSG $chan :$translated"

如果沒有，你這樣做：

putserv "PRIVMSG $chan :[encoding convertto utf-8 $translated]"

實驗。使用正確的。

在第二點（客戶端）上，探索其設置並將其正確設置。請注意，如果客戶端運行時無法正確顯示所有Unicode字符（如果在終端中運行常見問題），則可能會出現其他問題。有什麼都沒有您的eggdrop腳本可以做到這一點。

來源

2011-05-20 08:25:52

我覺得很愚蠢，第一個工作！現在UTF-8已經完美無缺了！我不確定我是否重新編譯了http://eggwiki.org/Utf-8說明。你是我的英雄！ – Dennis 2011-05-20 22:01:35

這可能是值得指出的是，如果數據的創建者將其編碼在「編碼」並在「編碼b」中讀取，那麼當您查看文本時，文本已經被打破。你不能僅僅告訴Tcl用另一種編碼對它進行編碼，並期望它能夠工作。

考慮它是這樣的：

發送RAR的文件
接收器獲取文件和使用Zip公式對其進行解碼（並得到垃圾回來）
你告訴代碼重新編碼文件作爲LZ7
你現在有LZ7編碼的垃圾

由於原來的解碼不匹配的編碼，你有一個問題。這不是一個完美的比喻，但它可能有幫助。

來源

2011-05-20 01:44:27 RHSeeger

TCL腳本（Eggdrop）有特殊字符問題

回答

相關問題