Telefon Treff im Wap?

Zitat

Original geschrieben von Steffen
Soweit ich das von hier aus erkennen kann scheint mir der Inhalt, der dann gesendet wird, garnicht utf-8 kodiert zu sein.
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?

Sobald eine Seite angezeigt wird und die eine bestimmte Encodierung sendet, kann ich beim MDA nicht mehr umstellen, sondern es wird die Encodierung gewählt, die gesendet wird, nur bei Seiten, die keine explizite Encodierung senden, kann umgestellt werden. Bei TT steht die Encodierung dann auf "Unicode".

[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

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.

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

[small]Gepostet via WAP (im Moment genutzt: SonyEricssonP800/R102 Profile/MIDP-1.0 Configuration/CLDC-1.0)[/small]

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

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.

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]

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.

[small]Gepostet via WAP (im Moment genutzt: Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; 240x320) UP.Link/1.1)[/small]

Carsten hat hier anscheinend auch wieder umgestellt, denn mit dem MDA funktionieren die Umlaute wieder: öäüßÖÄܤ

[small]Gepostet via WAP (portalmmm/1.0 m21i-10(c10))[/small]

hallo,nur ein kleiner Test.

So,habe die Suche bemüht und selber probiert.Zum Teufel,wie komme ich auf die Letzte Seite zum Antworten ? Nicht per [quote] sondern ganz normal."Page Jump" funzt nicht,bleibt einfach stehen.Habe ich da was übersehen,oder funzt es nicht so richtig mit den alternativen APN's über das imode -Mitsubishi ?

ciao

C.