semaphor: ICQ & Multimessenger -Wirrwarr

Hallo allerseits!

Ihr kennt wahrscheinlich alle den Instant-Messenger ICQ.
Es gibt ja nun genügend ICQ-Clients bzw. Multi-Messenger,
die nicht von AOL stammen, wie
Trillian, Miranda, SIM, Licq, Pidgin, Kopete, Adium, usw.

In den letzten Monaten stelle ich zunehmend fest, daß diese
Messenger untereinander immer mehr Kompatibilitätsprobleme
haben, vermutlich zumeist wegen des Zeichensatzes.
Dabei sind die Fehler jedoch sehr unterschiedlich.
Es ist noch recht harmlos, wenn bloß die Umlaute falsch
dargestellt werden, doch es gibt auch Fälle, wo der
andere ICQ-Client/Multi-Messenger die ankommende Nachricht
überhaupt nicht verarbeitet und garnichts anzeigt!

Als ich gestern über Gaim, ähm, "Pidgin" von meiner Linux-Kiste
aus mit jemanden, der Pidgin auf seinem Windows-Rechner laufen
hat, sprach, setzte es dann doch bei mir aus:
Seine Nachrichten kamen sauber bei mir an,
aber meine Nachrichten wurden bei ihm etwa so angezeigt:
_________________

<font size=3>Hallo!</font>
_________________
(ja, tatsächlich mit dem grottigen <font>-Tag)

wobei keiner von uns irgendwas am Zeichensatz oder Protokoll
verändert hatte. Das waren beides 2 frische Installationen.

Also das kann's doch nicht sein.
Ich würde gern dem Protokoll- und Kodierungs-Wirrwarr ein Ende
setzen, allerdings, bevor jetzt jemand mit anderen
Instant-Messenger-Netzwerken ankommt: Ich habe 130 Leute auf
meiner ICQ-Liste und werde die wohl kaum alle zu irgendeinem
anderen supertollen System bekehren können.

Darum mal eine (erste?) konkrete Frage:
Ist zumindest bekannt, welcher Zeichensatz von ICQ
tatsächlich unterstützt wird?
Ich jongliere zur Zeit je nach Gegenstelle per Try & Error mit
UTF-8, CP 1252, CP 1250, ISO 8859-1 und ISO 8859-15 herum.
Zum Glück unterstützen SIM und Licq zumindest teilweise
individuelle Zeichensatz-Zuweisungen *schwitz*

Und ja, ich weiß auch, daß der oben angeführte Beispielsfehler
ganz bestimmt kein Zeichensatz-Problem ist.
Da liegt mit Sicherheit noch mehr im argen.
Aber irgendwo muß man ja mal anfangen...

Einen schönen Gruß aus dem sonnigen Bochum!

Semaphor

  1. Tach,

    Ich würde gern dem Protokoll- und Kodierungs-Wirrwarr ein Ende
    setzen, allerdings, bevor jetzt jemand mit anderen
    Instant-Messenger-Netzwerken ankommt: Ich habe 130 Leute auf
    meiner ICQ-Liste und werde die wohl kaum alle zu irgendeinem
    anderen supertollen System bekehren können.

    Ich weiß, das willst du jetzt nicht hören, aber vielliecht ist es ja doch eine Alternative für dich: Nimm Jabber. Da gibt es auch Server, die Connects zu ICQ aufbauen können. Das heißt du kannst eine sanfte Migration machen und musst deine Kontakte nicht umstellen. Außerdem profitierst du auf Dauer von den Vorteilen des XMP Protokolls.

    Ciao
    Phil

    1. Heißa, Philipp,

      Ich weiß, das willst du jetzt nicht hören, aber vielliecht ist es ja doch eine Alternative für dich: Nimm Jabber. Da gibt es auch Server, die Connects zu ICQ aufbauen können. Das heißt du kannst eine sanfte Migration machen und musst deine Kontakte nicht umstellen. Außerdem profitierst du auf Dauer von den Vorteilen des XMP Protokolls.

      BTW: Kennst du einen stabilen Jabber-Server und einen stabilen ICQ-Transport? Im Moment bin ich bei jabber.org und benutze für ICQ icq.jaim.at, aber beide, besonders der ICQ-Transport, sind dermaßen unstabil, dass man das als inakzeptabel bezeichnen könnte. Gute Erfahrungen habe ich mit allen Transports von draugr.de gemacht (nur den IRC-Transport habe ich noch nicht zum Laufen gebracht), leider lässt der Betreiber keine neuen ICQ-Registrierungen mehr zu, da er die Stabilität des Servers bewahren will. Einen eigenen Jabber-Server will ich mir irgendwann mal selbst installieren, hat ja auch was, eine Jabber-ID auf der eigenen Domain. Aber auf einen ICQ-Transport, den ich selbst pflegen muss, habe ich wirklich keine Lust. Kann mir jemand einen Server empfehlen, dessen ICQ-Transport stabil läuft? (amessage habe ich schon probiert, das läuft bei mir meistens überhaupt nicht.)

      Gautera!
      Grüße aus Biberach Riss,
      Candid Dauth

      --
      <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
      <html><head>
      <title>404 Not Found</title>
      </head><body>
      <h1>Not Found</h1>
      <p>The requested URL /selfforum/remote-signature.php was not found on this server.</p>
      <hr>
      <address>Apache Server at files.cdauth.de Port 80</address>
      </body></html>
      1. Heißa, Philipp,

        Hossa, Candid,

        BTW: Kennst du einen stabilen Jabber-Server und einen stabilen ICQ-Transport?

        Sorry, nein. Habe früher den von jabber.ccc.de genutzt. Mittlerweile brauche ich aber keinen ICQ Transport mehr.

        Einen eigenen Jabber-Server will ich mir irgendwann mal selbst installieren, hat ja auch was, eine Jabber-ID auf der eigenen Domain.

        Ich habe das auch bald vor mir. Werde das in der Firma einsetzen und wahrscheinlich openfire verwenden (da wird kein ICQ Transport benötigt). Trau mich nur noch nicht den Rechner den ich dafür ausgewählt habe upzudaten (Debian 3.1 auf 4.0). Der andere Dienst der drauf läuft ist nicht gerade unwichtig. :-)

        Ciao
        Phil

        1. Ich habe Jabber früher schon mal getestet, bzw. wollte es testen, aber wurde
          schnell durch ein paar Serverprobleme entmutigt.

          Außerdem würde ich rein intuitiv sagen, daß ich durch die Umleitung über
          Jabber zu ICQ doch garnichts gewinne. Wenn ich das Jabber-System richtig
          verstanden habe, fungiert es beim ICQ-Transport doch bloß als Relais-Station.
          Ergo wird dann der Jabber-Server mit dem Zeichensatz-Müll zugeschüttet und
          leitet mir dann entweder den Krams so weiter, wie er dort ankommt, oder aber
          er versucht ihn in ein einheitliches Format umzusetzen, wobei wiederum
          fraglich ist, wie gut das der Jabber-Software gelingt.

          Bei einer direkten Verbindung kann ich wenigstens noch das Endergebnis
          mehr oder minder gut beeinflussen. Aber wenn ich die Zügel aus der Hand gebe...nunja.
          Im übrigen nimmt die Fehleranfälligkeit eines Systems proportional zu seiner
          Komplexität zu. Füge ich also der Kette noch nen weiteren Server hinzu,
          dürften sich damit vermutlich bloß noch weitere Probleme ergeben. :-/

          1. Heißa, semaphor,

            Außerdem würde ich rein intuitiv sagen, daß ich durch die Umleitung über
            Jabber zu ICQ doch garnichts gewinne. Wenn ich das Jabber-System richtig
            verstanden habe, fungiert es beim ICQ-Transport doch bloß als Relais-Station.
            Ergo wird dann der Jabber-Server mit dem Zeichensatz-Müll zugeschüttet und
            leitet mir dann entweder den Krams so weiter, wie er dort ankommt, oder aber
            er versucht ihn in ein einheitliches Format umzusetzen, wobei wiederum
            fraglich ist, wie gut das der Jabber-Software gelingt.

            Ich hatte bisher, was Zeichensätze angeht, keine Probleme mit den Jabber-Transports. Mit Kopete gab es früher manchmal Probleme, wenn man mit bestimmten Leuten gechattet hat, es hieß dann immer, die Nachricht könne aufgrund von Kodierungsfehlern nicht angezeigt werden, obwohl sie das im passiven KDE-Benachrichtigungsfenster wurde. Es half da, für den einzelnen Kontakt in den Einstellungen den Zeichensatz zu ändern, sodass es gepasst hat (normalerweise auf Windows-1252 oder Ähnliches). Mittlerweile haben sich diese Probleme aber gelegt, in den neueren Versionen ist der Fehler so gut wie nie aufgetreten (außer, wenn mir jemand ganz exotische ASCII-Steuerzeichen geschickt hat). In Gaim hatte ich dagegen ständig Probleme, aus Umlauten wurden irgendwelche chinesischen Zeichen, weil es wohl probiert hat, diese als UTF-8 zu interpretieren.

            Gautera!
            Grüße aus Biberach Riss,
            Candid Dauth

            --
            <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
            <html><head>
            <title>404 Not Found</title>
            </head><body>
            <h1>Not Found</h1>
            <p>The requested URL /selfforum/remote-signature.php was not found on this server.</p>
            <hr>
            <address>Apache Server at files.cdauth.de Port 80</address>
            </body></html>