Längenberechnung verzählt sich

[neniuideo]

Ist vermutlich im anderen Bug Report untergegangen (da hatte ich es mal nebenbei erwähnt).

https://github.com/Ph1b/websms-connector-developergarden/blob/master/DevGardenConnector/src/main/java/de/ph1b/dgard/DevCon.java#L157
und auch der dynamische Längeberechner (der die verbleibenden Zeichen beim Tippen in webSMS anzeigt) funktionieren nicht bei Sonderzeichen (die per Escape Sequenz zwei Zeichen beanspruchen).

Versuche mal 129 "€" zu senden ;)

Ist in der Praxis nicht so relevant. Aber wenn ich den Bug schon finde will ich den auch melden ;)

Edit: OK, das Problem liegt bei der webSMS API. Die berücksichtigt Escape Sequenzen wohl nicht.
Aber ich denke an verlinkter Codestelle sollte folgendes mit true für use7bitOnly verwendet werden.

    calculateLength(final String messageBody,
                    final boolean use7bitOnly) {

Wenn die API dann zukünftig angepasst wird dann wird sich das Problem von alleine erledigen.

cu

[PaulWoitaschek]

Hast du ne Idee, was man da machen kann? Die Websmsinternen Dinge die ich benutze, also:
c.setLimitLength(129);
und der kleine "Hack":
c.setSMSLengthCalculator(new BasicSMSLengthCalculator(new int[]{129}));
Holen sich die Nachrichtenlänge ja direkt aus dem Textfeld von WebSMS. Da kann ich ja nicht drauf zugreifen. Mach ich mir seit ein Paar Tagen so nebenbei drüber Gedanken, hab ich nicht überlesen. Genau das mit den 129 € hab ich als erstes ausprobiert :-P Was mir einfallen würde ist, die Zeichen alle auszuwerten und dann bei >129 ne Exception zu werfen, aber das ist den Aufwand ja nicht Wert, die Exception bekommst du dann ja beim Senden vom Dgarden (auch wenn die das kaputt formatiert und mit 160 Zeichen auch im Sandbox bei der Meldung implementiert haben).

[neniuideo]

Hm, wenn ich so darüber nachdenke... Der Connector macht ja alles richtig. Er scheint ja korrekt zu signalisieren das er nur 7-bit kann und das er max. 129 Zeichen (genauer 129 7-bit Einheiten) kann.

Das webSMS erlaubt zu lange Nachrichten abzusenden ist ein Bug in webSMS. Unter mySMS funktioniert es jedenfalls so, da ist es unmöglich zu lange Nachrichten abzusenden (mySMS zählt selber (korrekt) und deaktiviert den Connector bei zu viel Zeichen (und auch bei non 7-bit Zeichen)).

Und das der dynamische Längenberchner falsch zählt ist ein Bug in der webSMS API. Bei mySMS ist das kein Problem weil das dort eh nicht benutzt wird.

Also ich würde die beiden Bugs melden, den Check in Zeile 157 rausnehmen (der sollte eh niemals greifen können) und irgendwo im Readme unter known problems auf diese Problematik hinweisen (Damit die Leute wissen das u.u. Zeichen abgeschnitten werden (bei 130-160 Sendet er ja ohne Fehlermeldung und schneidet still ab, oder verwechsle ich das jetzt mit dem innosend Connector?) und das Bug Repots hier überflüssig sind).

Diese Problematik betrifft ja auch alle Connectoren, da kommt mir ein Workarount in diesem Connector irgendwie falsch vor.

BTW: Wenn man erstmal anfängt Fehler zu suchen... ;) Unicode Zeichen werden kommentarlos durch Leerzeichen ersetzt. Die Telekom API scheint hier zu ersetzen. Bei meinen Experiment mit non DE 7-bit Zeichen haben sie auch automatisch durch ähnlich aussehende zeichen im 7-bit DE Zeichensatz ersetzt.

cu

[felixb]

Ihr dürft gern die API oder WebSMS anpassen, wenn es da einen Bug gibt.
Insgesamt ist das aber kein einfaches Thema, weil jeder Provider die Zeichen unterscheidlich zählt. Einige zählen UTF-8 chars. Andere 7bit ASCII. Das Escaping ist auch jedes mal anders.
Das ganze in der API für alle möglichen Varianten richtig zu machen halte ich für unmöglich.