1

我在一个新的 Debian 服务器上安装了 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îçõé.

(另请参阅之前提出的问题,该问题未得到解决:Eggdrop 上的 TCL 编码问题

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]"
}
}
4

2 回答 2

3

你看到的那个丑陋的烂摊子是 UTF-8 解释为 ISO 8859-1。这表明在某个地方对字符的含义存在误解,并且可能是由于在通信通道越过电线应用了额外的一轮编码造成的。因为涉及到相当多的活动部分(IRC 客户端、IRC 服务器、eggdrop、你的脚本、谷歌翻译),所以有必要通过调试来告诉你。

Tcl 和 Google 可以正确地相互通信(我已经仔细检查了代码),因此我们可以消除这种可能性。因此,问题出在您的 IRC 客户端、IRC 服务器和 Eggdrop 之间;如果他们不同意“在线”字节的解释是什么,你就会被弄乱。

encoding convertto您可以通过使用(and )在脚本中添加(或删除)修改,encoding convertfrom但有必要明确在做什么以便正确处理。在内存中,Tcl 将字符串表示为抽象的 Unicode 字符序列;它们在内存中“写下”的方式与您无关(事实上,在运行时间方面几乎总是高效的复杂方式不时变化)。如果普遍同意 IRC 服务器的通道将通过 UTF-8,那么您的要求是:

  • 确保 eggdrop 脚本将 UTF8 编码的字符写入通道。
  • 确保您的客户端从通道中读取 UTF8 编码的字符。

关于第一点,我不记得 Eggdrop 是否为您自动处理编码。如果是这样,您只需在绑定的最后阶段执行此操作:

putserv "PRIVMSG $chan :$translated"

如果没有,请执行以下操作:

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

实验。使用正确的。

在第二点(客户端)上,探索其设置并正确处理。请注意,如果客户端在无法正确显示所有 Unicode 字符的情况下运行(在终端中运行的常见问题),则可能会出现其他问题。您的Eggdrop脚本无法解决此问题。

于 2011-05-20T08:25:52.110 回答
0

可能值得注意的是,如果数据的创建者将其编码为“编码 a”并以“编码 b”的形式读取,那么在您查看文本时文本已经损坏。您不能只告诉 Tcl 以另一种编码对其进行编码并期望它能够工作。

考虑一下:

  • 发件人 rar 文件
  • 接收器获取文件并使用 zip 公式对其进行解码(并取回垃圾)
  • 你告诉代码将文件重新编码为 lz7
  • 你现在有 lz7 编码的垃圾

由于原始解码与编码不匹配,因此您遇到了问题。这不是一个完美的类比,但它可能会有所帮助。

于 2011-05-20T01:44:27.840 回答