1

新しいDebianサーバーにEggdropをインストールしましたが、特殊文字の処理で問題が発生し続けます。

Eggdropはutf-8を実行しています。スクリプトでutf-8にTCLエンコーディングを手動で適用しました。そして、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

あなたが見ているその醜い混乱は、ISO8859-1として解釈されるUTF-8です。これは、文字の意味がどこかで誤解されていることを示しています。これは、通信チャネルを介してワイヤが交差するか、追加のエンコードが適用されていることが原因である可能性があります。かなり多くの可動部分（IRCクライアント、IRCサーバー、eggdrop、スクリプト、Google翻訳）が関係しているため、デバッグについて説明する必要があります。

TclとGoogleは互いに正しく通信しているので（コードを再確認しました）、その可能性を排除できます。したがって、問題はIRCクライアント、IRCサーバー、およびeggdropの間にあります。「ネットワーク上の」バイトの解釈が何であるかについて彼らが同意しない場合、あなたは混乱します。

encoding convertto（およびencoding convertfrom）を使用してスクリプトにマングリングを追加（または削除）できますが、正しく行うには、何をしているかを明確にする必要があります。メモリ内では、Tclは文字列を抽象的なUnicode文字のシーケンスとして表します。それらがメモリに「書き留められる」方法はあなたのビジネスではありません（実際、実行時の点でほとんど常に非常に効率的である複雑な方法で時々変化します）。IRCサーバーのチャネルがUTF-8を通過するという一般的な合意がある場合、要件は次のとおりです。

  • egdropスクリプトがUTF8でエンコードされた文字をチャネルに書き込むことを確認してください。
  • クライアントがチャネルからUTF8でエンコードされた文字を読み取ることを確認してください。

最初のポイントを扱うと、eggdropが自動的にエンコーディングを処理するかどうかは思い出せません。もしそうなら、あなたはあなたのバインディングの最終段階でこれをするだけです：

putserv "PRIVMSG $chan :$translated"

そうでない場合は、次のようにします。

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

実験。正しいものを使用してください。

2番目のポイント（クライアント）で、その設定を調べて正しく設定します。すべてのUnicode文字を正しく表示できない状況でクライアントを実行している場合は、追加の問題が発生する可能性があることに注意してください（端末で実行している場合の一般的な問題）。それを修正するためにeggdropスクリプトでできることは何もありません。

于 2011-05-20T08:25:52.110 に答える
0

データの作成者がデータを「encodinga」でエンコードし、「encoding b」で読み取った場合、テキストは見ている時点ですでに壊れていることに注意してください。Tclに別のエンコーディングでエンコードして機能することを期待するように指示することはできません。

次のようなものと考えてください。

  • 送信者rarのファイル
  • 受信者はファイルを取得し、zip式を使用してデコードします（そしてガベージを取り戻します）
  • ファイルをlz7として再エンコードするようにコードに指示します
  • これで、lz7でエンコードされたガベージができました

元のデコードがエンコーディングと一致しなかったため、問題が発生します。これは完全な例えではありませんが、役立つ場合があります。

于 2011-05-20T01:44:27.840 に答える