TCL-script (Eggdrop)存在特殊字符问题

Question

我已经在一个新的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îçõé.

(另请参阅之前提出的一个问题，但没有得到解决：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]"
}
}

Answer 1

您看到的丑陋的混乱是UTF-8，解释为ISO 8859-1。它表明在某个地方存在对字符含义的误解，这可能是由于通信通道上的线路交叉或应用了额外的一轮编码造成的。因为涉及到相当多的移动部分(IRC客户端、IRC服务器、eggdrop、您的脚本、Google translate)，所以有必要告诉您整个调试过程。

Tcl和Google可以正确地相互通信(我已经仔细检查了代码)，所以我们可以排除这种可能性。因此，问题出在您的IRC客户机、IRC服务器和eggdrop之间；如果它们不能就“网络上”字节的解释达成一致，那么就会出现乱码。

您可以通过使用encoding convertto (和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脚本无法解决这个问题。

Answer 2

值得注意的是，如果数据的创建者以“编码a”对其进行编码，而在“编码b”中读取它，那么当您查看文本时，文本已经被破坏了。您不能简单地告诉Tcl将其编码为另一种编码，然后期望它能够工作。

假设它是这样的：

• 发送器rar's a file
• 接收器获取文件并使用压缩公式对其进行解码(并得到垃圾信息)
• 告诉代码将文件重新编码为lz7
• 您现在有了lz7 lz7垃圾编码<

>F29>

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