Beiträge von Steffen

Auf Homezone-Nummer!?

Zitat

Original geschrieben von Tom Paris TK
Soweit ich weiß geht nur zur MAilbox und selbst die muß von der Kundenetreuung gesetzt und gelöscht werden.

Ein Bekannter konnte seine Umleitung zur Mailbox nicht selbst löschen, er muste es telefonisch machen lassen.

Ja, das war früher mal so, wenn eine Konfiguration überhaupt möglich war. Mit diesen Schikanen zur Förderung der kostenpflichtigen Mailbox haben sich vor allem D2 und E+ ervor getan. (Wobei die E+ Variante bei geeigneter Konfig afaik auch mit einem zugegebenermaßen exotisch anmutenden Vorteil aufwarten kann: kostenlose bedingte Umleitungsvariante bei Auslandsaufenthalt - ohne Gewähr, weil nie getestet) Zumindest netzintern ist die Konfigruation der Rufumleitung bei CallYa bunt heute kein Problem mehr.

Aber BTT, @Hightower200e:
Leite doch auf die Homezone-Nummer um (wenn das von deiner CallYa aus mögl. ist.), evtl. kannst Du mit der CallYa in einen Tarif mit günstigeren Preisen ins Festnetz wechseln. (Die ja dann nach chrischs Posting auch für die Umleitung gelten sollten - ich selbst hab' mich damit noch nicht befasst) Auch wenn dann mancher Anruf über Anrufmanager auf der Mailbox landet wirst Du ja per SMS informiert, und kein Anruf geht verloren, und es handelt sich bei dir ja wohl eher um eine Übergangslösung, bis alle deine neue Nr. haben, oder?

Grüße,
Steffen.

P.S. Unter der missverständlichen Begriffsschöpfung Rufnummernweiterleitung verstehe ich eher die Portierung einer Rufnummer, als die Weiterleitung eines Rufs.

Deklarierte und tatsächliche Zeichenkodierung stimmen weiterhin nicht überein.

Zitat

Original geschrieben von Sencer
Hallo Steffen,

vielen Dank für den Tipp. Wir hatten selber auf unseren Seiten viele Problemberichte von Nokia-Usern. Nach diversen Validatoren, Doctypes und schrauben an der Encodierung, hatte ich die Sache schon Ruhen lassen.

Mit deinem Tipp die Encodierung im Header zu übermitteln funktiert es nun bei allen Usern bei uns. Danke.

Sencer
Danke für die Blumen. Falls die Frage hier in A&K(&L) gestattet ist, und da „Eure“ Erfahrungen vielleicht auch für TT nicht uninteressant sein könnten, muss ich doch mal ganz naiv fragen: „Von welchen Seiten sprichst Du?“

P.S. welche WAP-Validatoren hast Du verwendet? (Validatoren überprüfen zwar den gesendeten Inhalt, afaik aber leider nicht immer, ob dieser auch zum gesendeten http response header passt!)

BTT:
Mit der Rücksetzung der xml-Deklaration sind die gröbsten Probleme ja wieder beseitigt. :top: Der ursprüngliche Fehler ist leider nach wie vor noch nicht beseitigt: die gemeldeten, bzw. tatsächlichen Zeichenkodierungen von http response header (meldet garkeine Zeichenkodierung), xml-Deklaration (behauptet iso-8859-15) und Inhalt (ist nicht iso-8859-15 kodiert) stimmen nicht überein. Das macht sich zum Glück nur bei wenigen WAP-Clients (die die Zeichenkodierung im http response header erwarten, und ansonsten bei wenige Sonderzeichen bemerkbar, bei denen die tatsächliche Kodierung (vermutlich iso-8859-1) von iso-8859-15 abweicht.

  Liebe Grüße,
  Steffen.

Spezifizierte und tatsächliche Zeichenkodierung stimmen nicht überein!

So, jetzt habe ich mir sowohl Quelltext als auch den http response header der WAP-TT-Seiten nochmal etwas näher angeschaut. Fazit:
[list=1]
[*]Die tatsächliche Kodierung des Textes ist iso-8859-1, und nicht utf-8, oder iso-8859-15.
[*]Die xml-Deklaration spezifiziert die Zeichenkodierung uft-8.
[*]Der http response header spezifiziert garkeine Zeichenkodierung.
[/list=1]
D.h. die spezifizierte Zeichenkodierung sitmmt definitiv nicht mit der tatsächlich verwendeten überein! (Wie bereits vermutet.) Beide Deklarationen ([2] und [3]) sollten natürlich die tatsächliche Kodierung ([1]) spezifizieren.

Abhilfe:
Solange der Text weiterhin in iso-8859-1 übertragen wird ist eine Änderung der Spezifikation sowohl in der xml-Deklaration, als auch im http response header in iso-8859-1 angebracht!

Für die Festlegung des http response headers ist in php der Befehl header voergesehen:

header("Content-Type: text/vnd.wap.wml; charset=iso-8859-1");

Für den Fall, dass die Variante mit dem php-Befehl nicht ohne weiteres anwendbar sein sollte habe ich mal noch nach 'ner anderen Lösung gesucht. Da TT offensichtlich auf einem Apache-Server gehostet ist, liegt eine Anpassung der .htaccess-Datei auf der Hand. Und in der Tat hat auch diese Variante funktioniert, mit der Eintragung:

addtype "text/vnd.wap.wml; charset=iso-8859-1" wml

Wenn es irgendwann möglich ist, den Text tatsächlich in utf-8 Kodierung zu senden, dann können wir immer noch auf utf-8 umstellen, bis dahin sollte das, was der Server sendet aber wenigstens schonmal konsistent sein.

  Grüße,
  Steffen.

[Nachtrag] Die Variante mit der .htaccess-Datei muss natürlich auf die tatsächliche Dateiendung angepasst werden, hier also wohl „addtype "text/vnd.wap.wml; charset=iso-8859-1" php“. Das funktioniert natürlich nur, wenn die wml-generierenden php-Dateien in einem anderen Verzeichnis liegen als die html-generierenden php-Dateien, und wenn der header nicht wieder überschrieben wird.[/Nachtrag]

Zitat

Original geschrieben von Merlin
[...]Interessanterweise hat der MDA vor der Codeumsteelung durch Carsten die Umlaute korrekt dargestellt und nur das P800 machte Probleme. Jetzt werden von beiden Geraeten die Umlaute nicht korrekt wiedergegeben

Wenn die WAP-TT Seiten nicht in der angegebenen Kodierung übertragen werden, dann ist es natürlich naheliegend, dass die Sonderzeichen nicht richtig angezeigt werden. (Der Client behandelt die gesendeten Zeichen als utf-8, der Text ist aber garnicht utf-8 kodiert - dass die falsch kodierten Zeichen nicht dazu führen, dass der ganze Text unleserlich wird, ist der überlegten Konzeption von utf-8 (alle zusätzlichen Bytes in von Multibytezeichen jeweils größer 127) zu verdanken.) Solange der Inhalt noch nicht utf-8 kodiert wird, sollte Carsten vielleicht die im Header angegebene Kodierung nochmal zurücksetzen.

Grüße,
Steffen.

Test war nicht signifikant - der Thread-Übersichtlichkeit wegen gelöscht. €

Zitat

Original geschrieben von Weizen
[small]Gepostet via WAP (Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Opera 7.23 [de])[/small]

Beim 6600 bringt das Umstellen der Standardcodierung keinen Vorteil... ich bin grad über Opera unter Windows auf der WAP-Seite, da werden die Umlaute auch nicht angezeigt. Im Quelltext stehen sie als ä, ö, ü etc. (also nicht ä etc.) und sind zumindest unter Windows lesbar.

EDIT: ä in ä geändert, damits auch als ä und nicht als ä angezeigt wird

Ja, das passt auch zu meinen Beobachtungen. Das sieht mir wie gesagt sehr nach iso-8859-1 (iso-Latin-1) oder iso-8859-15 (iso-Latin-9) aus, und nicht nach utf-8. (Irgendwelche Entitäten liefern hier übrigens keinen Hinweis auf die Kodierung, da die hier in Frage kommenden Kodierungen, im US-ASCII-Kern alle übereinstimmen.)

Aber ich kann momentan nur mit dem UP-SDK testen (von dem ich sicher weiß, dass es utf-8 unterstützt), keines meiner Handies kann WAP-TT mit den verschiedenen freien WAP-Gateways darstellen, die ich bisher durchgetestet habe. Aber das ist auch kein Wunder bei Decks von z.B. 2266 bytes, da kommen meine alten Handies nicht mit. Daher bin ich für Eure Hinweise dankbar. Bei der Kontrolle der Quelltext ist allerdings zu beobachten, dass die Quelltextanzeige mancher Browser die spezifizierte Kodierung der Web/WAP- Seite verwendet (z.B. Mozilla) während andere den Text in ASCII oder Latin-1 anzeigen (z.B. IE). Wie das bei Opera umgesetzt ist weiß ich nicht, um auf nummer Sicher zu gehen sollte sich daher nicht auf die Quelltextanzeige des jeweiligen Browers verlassen werden, sondern die WAP-Seite abgespeichert und mit einem Texteditor in iso-8859-1 angesehen werden. Wenn dann ein „ü“ immer noch als ein „ü“ und nicht als „ü“ (oder je nach Texteditor vergleichbar unleserliches) angezeigt wird, dann ist der Inhalt nicht utf-8 kodiert.

  Grüße,
  Steffen.

Nach der Korrektur kann ich WAP-TT jetzt auch abrufen. Und die Seite wird jetzt auch angekündigt als utf-8 kodiert.
Aber:
Soweit ich das von hier aus erkennen kann scheint mir der Inhalt, der dann gesendet wird, garnicht utf-8 kodiert zu sein. (allerdings iso-8859-1 oder iso-8859-15 ist es auch nicht - in welcher Kodierung liegen die Daten eigentlich in der SQL-Datenbank?)

Zitat

Original geschrieben von Merlin
[...] im Pocket-IE kann ich auf UTF-8 umstellen, wie ich will, er bleibt auf "Unicode" und ignoriert "Unicode UTF-8" vollständig ...

Vielleicht hängt das ja mit der vermuteten Inkonsistenz zwischen gemeldeter und tatsächlicher Kodierung zusammen.
Wie werden denn die Sonderzeichen in den verschiedenen Kodierungseinstellungen die Du manuell einstellen kannst (Latin-1, Latin-9 = 8859-15, utf-8) dargestellt?

Zitat

Original geschrieben von Merlin
Ich kann [...] die Beitragsreihenfolge nicht mehr umstellen[...]

Im Quelltext des Optionsmenüs konnte ich jetzt auf die Schnelle keinen Fehler finden. Mir ist allerdings aufgefallen, dass die ganze Card scheinbar in einer einzigen Zeile übertragen wird. Ich weiß nicht, wie zuverlässig die Übertragung überlanger Zeilen im Internet ist, um jedoch zu vermeiden, dass auf dem Weg vom Server irendein Rechner die Zeile an einer ungeeigneten Stelle umbricht würde ich die Card auf mehrere Zeilen aufteilen (in PHP ."/n" an einige '<br />' anhängen), wenn das bei der dynamischen Erzeugung der Card möglich ist. Zwar glaube ich nicht, dass die Zeilenlänge für die obige Beobachtung verantwortlich ist, ich konnte diese Problem auch nicht nachvollziehen, mit der Zeilenkürzung gingen wir aber auf Nummer Sicher.

&nbsp;&nbsp;Grüße,
&nbsp;&nbsp;Steffen.

Zitat

Original geschrieben von arni
[...]
1. Die provider machen in meinen augen keine offenen WAP-Push gateways weil die dann ihre sms services einpacken können. Denn auch per wap-push kann man sms ähnliche nachrichten auf die handy's verschicken und das mangels wissen woher der request kommt, kostenlos.

2. Eine MMS wird dem handy per wap push signalisiert nicht geschickt. Das handy bekommt eine wap-push nachricht mit ein paar info's zur mms und dann eine adresse zu welcher es gehen kann um sich die mms herunterzuladen, ganz normal per WAP-AP nur das es in diesem fall auch für nicht flat nutzer nichts kostet, da der verschicker der mms das schon gezahlt hat.
[...]

Ja, das ist schon klar. Unsere aktuelle Überlegung geht in der Richtung all diese kostspieligen Hürden, die die Netzbetreiber da (aus den bekannten Gründen) aufrichten durch ein Post direkt an eine IP zu signalisieren. Mit 'nem geeigneten Client auf dem Handy ist das natürlich möglich, der beim Einloggen seine aktuelle IP-Adresse an einen Server meldet, der diese nach geeignetem Zeitraum ohne Rückmeldung natürlich wieder deaktivieren muss. Aber gibt es diese Möglichkeit auch zur MMS-Signalisierung. Ich bezweifle's zwar, aber vielleicht wisst Ihr's besser. (Ich kenne mich Mit so Sachen wie WAP, WML und Zeichenkodierungen aus, aber mit Messaging eher weniger, mal von eMail.)

Allgemein wäre diese Lösung wohl schneller als ein regelmäßiges Reload, regelmäßig beim Server melden muß sich der Client natürlich auch bei einer Lösung mit dem &bdquo;Anpingen&ldquo; der IP-Adresse.

Grüße,
Steffen.

Zeichenkodierung: Miniübersicht zum Nachlesen.

Zitat

Original geschrieben von lanturlu
[...]die bei o2 sind, aber keine WAP-Flatrate haben. Solche Leute sind gar nicht so selten, aber vermutlich in diesem Thread nicht so häufig anzutreffen. ;)[...]

BTT:
Das Thema Zeichenkodierung sorgt bekanntlich immer für einige Verwirrung. Zu utf-8 und Co habe ich ja bereits Manches gepostet. Dabei habe ich komplett vergessen, dass ich mir das eigentlich sparen könnte, indem ich auf eine Mini-Übersicht hinweise, die ich zu diesem Thema bereits vor geraumer Zeit ins Netz gestellt habe. Die Seiten habe ich in sehr kleine Einheiten zerlegt, da sie für WAP-Handies vorgesehen ist. Ich hab' sie aber so angelegt, dass auch via Web-Browser d'rauf zugegriffen werden kann.

Wer also in der Mini-Einführung mal nachlesen will findet diese unter steffenbonn.de/test/utf8_1.php (selbe Adresse, ohne „www“, für Web wie WAP).

Grüße,
Steffen.

Abfrage User-Agent (WAP wie Web)

Zitat

Original geschrieben von Teddie_Neubert
[...]nur vom WAP-Handy aus aufrufen !

Für alle, die diese Abfrage durchführen wollen, unabhängig davon, ob der jeweilige Client wml-fähig ist:
http://steffenbonn.de/test/uagent.php

&nbsp;&nbsp;Grüße,
Steffen.

P.S. Test der Darstellung numerischer Entitäten (manche WAP-Clients haben Probleme mit benannten Entitäten - Dieser Test hat nichts mit obigem Posting zu tun):
„deutsche Anführungszeichen“, “englische Anführungszeichen”