Hallo Programmier-Freunde,

ich habe wieder mal ein Problem-chen:

Ich habe ein kleines Messaging-Programm (PHP, Web-Formular) am laufen.

Funktion: -> Webformular -> Empfänger aus Liste auswählen - Nachricht in Formular eintippen und per POST an ein PHP-Skript auf einem Webserver senden!
Der Text wird samt Umlauten sauber in der Datenbank hinterlegt und beim Empfänger angezeigt.

Nun habe ich mich an einen nativen Windows-Client gemacht, der auf die gleichen Daten zugreift. Es ist einfach komfortabler und vom Funktionsumfang ist mehr möglich!

Die 'alten Daten' werden richtig dargestellt. Habe ich aber über die Anwendung Umlaute in der Nachricht, stehen ich in der Datenbank UTF-8 kodierte Einträge. Die sind a) größer und b) in der Browser-Version sieht es schlimm aus.

Ich konnte in der Delphi Anwendung die Ausgabe mit

eine perfekte Ausgabe erreichen, aber das hilft mir nicht bei den Web-Version.

Hier mein Beispiel für eine nachricht an TestUser2:

Ich nutze also die NetHTTPRequest-Komponente (und will da auch nicht von weg). Ich bin mir sicher, ich habe schon sämtliche Kombinationen (sogar nil) für TEncoding ausprobiert, aber das Ding ist Stur!

Hat jemand mal einen konstruktiven Tip für mich? Google verweist - wenn dann auf Indy-Problemfälle.
Viele Grüße

Moderiert von Narses: Delphi-Tags hinzugefügt

Hi,

hast du einmal probiert deine Strings vor den einfügen in die Stringliste mit utf8encode in UTF-8 Strings zu wandeln und diese zu schicken? Wenn ich die Dokumentation von TNetHTTPRequest.Post richtig verstehe musst du dann kein Encoding mehr angeben und die Informationen sollten richtig ankommen. Sollte dein PHP-Script nicht mit UTF-8 zurecht kommen, würde ich eher diesem den Umgang damit beibringen als auf Unicode zu verzichten, den eigentlich macht das den Umgang mit Sonderzeichen und Umlauten erheblich einfacher. Ansonsten musst du wahrscheinlich das Encoding deines Servers Angeben und nicht das deines Clients, das könnte dann solange funktionieren, bis es sich mal auf dem Server ändert.

Zusammengefasst also mein Tipp: Gehe nicht weg von UTF-8 sondern mache einen Schritt drauf zu. Ich möchte nicht mehr mit nicht Unicode Strings arbeiten müssen und UTF-8 ist hier eine schön platzsparende Codierung des ganzen.

Gruß

Hallo doublecross,

vielen Dank für Deine schnelle Reaktion.

Da ich mich schon eine ganze Weile mit diesem Problem befasse, hab ich schnell nochmal

'äöüÄÖÜß'

los geschickt.

Mit phpMyAdmin sehe ich folgendes in der Datenbank:


utf8encode() ergibt äöüÄÖÜß


utf8decode() -so als Verzweiflungstat- ergibt Schrott = ������� (war natürlich utfdecode)


Da ich vor der Ausgabe in meinem Programm ein utf8decode() drin habe, sieht das natürlich wieder schick aus.
Ja, das PHP-Skript zu ändern ist schon ein Erfolg garantierender Ansatz. Meine Intuition bei der ganzen Sache ist jedoch, 1. die Komponente zu verstehen und nutzen zu können - sooo toll ist die Hilfe dazu ja nun auch nicht - und 2. ist es eine hervorragende Möglichkeit Datenbankanwendungen zu verteilen, ohne irgendwelche DB-Treiber. Der Webserver quasi als Vermittler zwischen DB und Client! Nix lokale Treiber-Konfiguration, nix Versionskonflikte. Da ist es aus meiner Sicht kontraproduktiv, die DB-Felder auf Unicode aufzublähen.

Ich habe auch schon den REST-Debugger in Benutzung. Der hilft ungemein! Aber der benimmt sich wie meine Anwendung. Nur dass man schneller alle möglichen Einstellungen durchtesten kann.

Ich fänds schon schicker, wenn ich die Daten auch in phpMyAdmin lesen könnte - wie bisher

Viele Grüße

Probier mal statt 'äöüÄÖÜß' '%E4%F6%FC%C4%D6%DC%DF' zu schicken.

Indy hat dafür eine Function, um das umzuwandeln (TIdURI.URLEncode)

Da kommt das gleiche raus, wie wenn ich utf8encode() vorher benutze also �������

Ich mache erstmal ne Pause, vllt. hab ich den falschen Betrachtungswinkel.

Und wenn du utf8decode() weglässt?

- Nachträglich durch die Entwickler-Ecke gelöscht -

Das eigentliche Problem ist für mich, dass ich die UTF-Konvertierung beim Senden an den Webserver nicht weg bekomme.
Die 'alten' Datensätze sind in der Webansicht und in meinem Programm korrekt dargestellt.Natürlich ohne UTF8decode().
UTF8decode() brauche ich nur, um die neuen Datensätze aus meinem Programm korrekt anzuzeigen.
Ich wäre gerne jede konvertierung los. Aber alle möglichen Parameter für die TNetHTTPRequest-Komponente scheinen dafür nicht ausgelegt.
Wie gesagt, TEncoding lässt sich auf nil setzen.. Bleibt bei utf-8.

Das mit dem TStringstream hatte ich auch gefunden. Könnte ich mal probieren... aber da soll man sich ja auch für ein encoding entscheiden.

Ich werde wohl erstmal sämtliche Daten auf dem Server ent-UTF-en. Kann den Bedarf ja am UserAgent feststellen.

Ich danke Euch trotzdem schonmal für Eure Mühen und Tips.

Falls ich doch irgendwas finde, schreibe ich es hier rein. Ich finde die Koponente an sich richtig gut. Hab leider keine Quelltexte von dem Teil, da könnte man ja auch was draus lernen.

Viele Grüße

F.elix

Hallo,

f.elix hat folgendes geschrieben :

Hallo doublecross, vielen Dank für Deine schnelle Reaktion. Da ich mich schon eine ganze Weile mit diesem Problem befasse, hab ich schnell nochmal 'äöüÄÖÜß' los geschickt. Mit phpMyAdmin sehe ich folgendes in der Datenbank: utf8encode() ergibt äöüÄÖÜß

hmmm, könnte das vielleicht an dem hier beschriebenen häufigen Konfigurationsproblem vom MySQL liegen? Wird in dieser vielleicht gar kein UTF-8 gespeichert sondern UTF-8 simulierendes latin-1 (oder gar Windows-1252)?

Auf jeden Fall sieht das was du da bekommst wie eine ASCII Interpretation von UTF-8 Texten aus.

Was bekommst du denn in die Datenbank wenn du weder Manuell noch per Parameter selbst ein Encoding erzwingen willst?

PS: Wenn ich im Notepad++ modus UTF-8 Ohne BOM den Text "äöüÄÖÜß" eingebe und dann auf ANSI umschalte erhalte ich exakt den Text "äöüÄÖÜß" also das war du im Datenbanktool zu sehen bekommst. Da scheint mir irgendwo einmal zu viel konvertiert zu werden. Vielleicht solltest du deinen Text nicht nach UTF-8 Konvertieren sondern auf deine Server Codepage.

Hallo doublecross,

Du hast es schon richtig ermittelt: Es wird vor dem Übertragen einfach mal nach UTF-8 konvertiert.

Das macht die NetHTTPRequest-Komponente (gegen meinen Willen)!

Meine Anfangsfrage sollte eigentlich darauf hinaus laufen, dass mit irgendwer verrät, wie ich diese Konvertierung per Parameter abschalten kann.
Ich kann unter sämtlichen Codepages auswählen, aber ich habe nichts finden können, wie ich das Encoding unterdrücke. Wird der TEncoding-Parameter auf nil gesetzt, wird utf-8 codiert - wahrscheinlich als default.
Man kann der Komponente ja auch Header-Parameter mitgeben. Die haben aber auch nichts gebracht oder ich habe genau die eine funktionierende Kombination aus 'content-type' und encoding ausgelassen.

Ich finde es aber toll, dass es immer noch Menschen gibt, die ein Problem lösen wollen, anstatt nur einen Workaround zu basteln.

Das soll mal ein Danke mit Rundumschlag sein!

Gute Nacht erstmal!

Hallo noch einmal,

ich muss zugeben, dass meine Delphi Erfahrungen sich überwiegend auf ältere Delphi Versionen beziehen. Auf Versionen in denen der Standard String noch kein Unicode bot. Das hat sich mittlerweile ja geändert, und vielleicht liegt hier das Problem. Wenn deine Verwendete Delphi Version Unicode als Standard verwendet, dann ist 'äöüÄÖÜß' ansich ja schon ein Unicode String. Vielleicht kann die Komponente den nicht sauber auf nicht Unicode Codepages decoden (wäre doof insbesondere da sie den Parameter anbieten, aber wer weiß). Daher macht es vieelleicht Sinn, wenn du es vorher, also bevor du den String in die Stringlist steckst, einmal manuell versuchst.

Nur eine Idee .

Hey,

ich bin mir nicht sicher ob es sinnvoll ist die UTF8 Codierung abzuschalten da diese eine HTTP kompatible Übertragung sicherstellt.
Aber probier doch einfach mal aus Encoding auf TEncoding.ASCII zustellen.

Hallo Sinspin,

TEncoding.ASCII schaltet die UTF8-Codierung bei mir leider nicht ab.

Da ich vorankommen will, habe ich es jetzt serverseitig gelöst:

Lösung gefunden - Problem aber nicht gelöst!

Ich danke nochmals allen Opfern meiner Anfrage

Gruß F.elix

Moderiert von Narses: PHP-Tags hinzugefügt

Hi,

ich habe gerde noch einmal in die Dokumentation von TNetHTTPRequest.Post geguckt und ich glaube wir haben den TEncoding-Parameter völlig falsch verstanden.

Mittlerweile interpretiere ich das so, dass ein Post immer in UTF-8 Erfolgt, wenn ich in der Stringlist aber Strings habe die eben nicht UTF-8 Codiert sind, dann kann ich das Encoding dieser Strings angeben damit TNetHTTPRequest sie von diesem encoding in UTF-8 wandeln kann. Der Parameter beschreibt also nicht das Ausgangsformat, sondern das Eingangsformat. Dann macht es auch wieder Sinn, dass man den Parmeter weglassen kann wenn die Stringlist schon UTF-8 Strings enthält.

Somit war es unter der Vorgabe bei dieser Komponente zu bleiben wahrscheinlich die einzige Möglichkeit das Problem Serverseitig zu lösen.