TCL-скрипт (Eggdrop) имеет проблемы со спецсимволами - PullRequest
Новая
       18

TCL-скрипт (Eggdrop) имеет проблемы со спецсимволами

1 голос
/ 20 мая 2011

Я установил Eggdrop на новый сервер Debian, но у него по-прежнему возникают проблемы с обработкой специальных символов.

Eggdrop работает utf-8.Я даже вручную ввел кодирование TCL в utf-8 в сценарии.И я попытался перекомпилировать Eggdrop с инструкциями от http://eggwiki.org/Utf-8. 

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îçõé.

(также см. Предыдущий вопрос, который не был решен: Проблемы с кодировкой TCL на 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]"
}
}

Ответы [ 2 ]

2 голосов
/ 20 мая 2011

Этот ужасный беспорядок, который вы видите, является UTF-8, интерпретируемым как ISO 8859-1.Это указывает на то, что где-то существует неправильное толкование того, что означают символы, и может быть вызвано или пересечением проводов по каналу связи, или в результате применения дополнительного цикла кодирования.Поскольку задействовано довольно много движущихся частей (IRC-клиент, IRC-сервер, eggdrop, ваш скрипт, Google переводчик), необходимо провести отладку.

Tcl и Google правильно общаются друг с другом (ямы дважды проверили код), чтобы мы могли исключить эту возможность.Следовательно, проблема заключается в том, что между вашим IRC-клиентом, IRC-сервером и eggdrop;если они не согласны с интерпретацией байтов «по проводам», вы получаете искажение.

Вы можете добавить (или удалить) искажение в сценарии с помощью encoding convertto (иencoding convertfrom) но необходимо , чтобы быть ясным , что вы делаете, чтобы понять это правильно.В памяти Tcl представляет строки как последовательности абстрактных символов Юникода;способ, которым они «записываются» в память, не является вашим делом (и на самом деле время от времени изменяется сложным образом, который почти всегда очень эффективен с точки зрения времени выполнения).Если существует общее соглашение о том, что канал IRC-сервера будет проходить через UTF-8, вам необходимо:

  • Убедитесь, что скрипт eggdrop записывает символы канала в кодировке UTF8.
  • Убедитесь, что ваш клиент читает символы в кодировке UTF8 из канала.

Имея дело с первым пунктом, я не могу вспомнить, обрабатывает ли eggdrop кодирование автоматически для вас или нет.Если это так, вы просто делаете это на заключительной стадии привязки: 

putserv "PRIVMSG $chan :$translated"

Если это не так, вы делаете это: 

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

Эксперимент.Используйте правильный.

Во втором пункте (клиент), изучите его настройки и сделайте все правильно.Помните, что могут возникнуть дополнительные проблемы, если клиент работает в ситуации, когда он не может правильно отображать все символы Unicode (обычная проблема, если он работает в терминале).* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *} * * * * * * * * * * * * * * * * * * * * * * * * *.

0 голосов
/ 20 мая 2011

Возможно, стоит отметить, что, если создатель данных кодирует их в «кодировке a» и читает их в «кодировке b», то текст уже разбит к тому времени, когда вы на него смотрите.Вы не можете просто сказать Tcl кодировать его в другой кодировке и ожидать, что он будет работать.

Считайте, что это что-то вроде:

  • sender rar a file
  • receiveerполучает файл и декодирует его, используя формулу zip (и возвращает мусор)
  • вы говорите коду, чтобы перекодировать файл как lz7
  • у вас теперь есть закодированный lz7 мусор

Поскольку исходное декодирование не соответствует кодировке, возникла проблема.Это не идеальная аналогия, но она может помочь.

...