UTF-8 String

[wer112]

Ich habe schon lange das Problem, dass Sonderzeichen in der DB falsch dargestellt wird. auch anders rum ist das Problem.
Dachte es liegt am PHP, was am Ende am Java liegt.

Ich muss jeden String in UTF-8 ändern, aber weiß nicht wie.

Früher bekam ich das in die DB: ©

Jetzt hatte ich aus SOF diesen Code getestet:

 public static String convertStringToUTF8(String s) {
        String out = null;
        try {
            out = new String(s.getBytes("UTF-8"), "ISO-8859-1");
        } catch (java.io.UnsupportedEncodingException e) {
            return null;
        }
        return out;
    }

Dabei kam das raus: é

Wie kann ich es in utf 8 ändern und es abspeichern?

Bzw. wie zurück ins Java Format?

 

[Marinek]

Das liegt wahrscheinlich daran, dass die falschen Zeichen schon in der Datenbank stehen.

Dann musst du diese vorher manuell bereinigen.

 

[wer112]

Das liegt wahrscheinlich daran, dass die falschen Zeichen schon in der Datenbank stehen.

Nein wenn man das Richtig stellt, kommt es falsch in der App an.

Dann musst du diese vorher manuell bereinigen.

Richtig, der String muss vorher in utf 8 geändert werden, damit dieser normal in die DB kommt.
Zurück ist ein anderes Thema.

 

[Oneixee5]

Wie ist denn der Spaltentyp in der DB und welche DB verwendest du?
Wenn ich eine Webseite habe, welche auch UTF8 verwendet und der Spaltentyp auch UTF8 aufnehmen kann, dann muss ich nichts konvertieren. Wir verwenden dabei noch Sorbisch, Arabisch und hatten auch schon Japanisch als Eingaben. Allerdings sollte man Strings nie in Bytes umwandeln.

 

[wer112]

Wie ist denn der Spaltentyp in der DB und welche DB verwendest du?

-- phpMyAdmin SQL Dump
-- version 5.2.0
-- https://www.phpmyadmin.net/
--
-- Host: localhost
-- Erstellungszeit: 03. Dez 2023 um 17:40
-- Server-Version: 10.6.12-MariaDB-0ubuntu0.22.04.1-log
-- PHP-Version: 7.4.33

SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
START TRANSACTION;
SET time_zone = "+00:00";

--
-- Datenbank: ``
--

-- --------------------------------------------------------

--
-- Tabellenstruktur für Tabelle ``
--

CREATE TABLE `` (
  `kundennummer` varchar(255) CHARACTER SET utf8mb3 COLLATE utf8mb3_unicode_ci NOT NULL,
  `vorname` varchar(255) CHARACTER SET utf8mb3 COLLATE utf8mb3_unicode_ci NOT NULL,
  `nachname` varchar(255) CHARACTER SET utf8mb3 COLLATE utf8mb3_unicode_ci NOT NULL,
  `geburtstag` varchar(255) CHARACTER SET utf8mb3 COLLATE utf8mb3_unicode_ci NOT NULL,
  `geburtsort` varchar(255) CHARACTER SET utf8mb3 COLLATE utf8mb3_unicode_ci NOT NULL,
  `person_type` varchar(255) CHARACTER SET utf8mb3 COLLATE utf8mb3_unicode_ci NOT NULL,
  `registrationsdatum` timestamp NOT NULL DEFAULT current_timestamp() ON UPDATE current_timestamp(),
  `zip_passwort` varchar(255) CHARACTER SET utf8mb3 COLLATE utf8mb3_unicode_ci NOT NULL,
  `bearbeiter` varchar(255) CHARACTER SET utf8mb3 COLLATE utf8mb3_unicode_ci NOT NULL,
  `bearbeitet_am` text CHARACTER SET utf8mb3 COLLATE utf8mb3_unicode_ci NOT NULL,
  `personalien_geprueft` int(10) NOT NULL,
  `angaben_stimmen` int(10) NOT NULL,
  `freigegeben` int(10) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_german2_ci;

--
-- Indizes der exportierten Tabellen
--

--
-- Indizes für die Tabelle ``
--
ALTER TABLE ``
  ADD PRIMARY KEY (`kundennummer`);
COMMIT;

Wenn ich eine Webseite habe, welche auch UTF8 verwendet und der Spaltentyp auch UTF8 aufnehmen kann, dann muss ich nichts konvertieren. Wir verwenden dabei noch Sorbisch, Arabisch und hatten auch schon Japanisch als Eingaben. Allerdings sollte man Strings nie in Bytes umwandeln.

PHP hat laut VSC UTF-8, und die Datenbank hat selber UTF-8. Leider kommt ese falsch in der DB an. Wenn ich es in der Datenbank korregiere, kommt es falsch in Java an. Android versteht nur HTML Sonderzeichen, wie: ä

Deswegen muss der String auch in utf-8 konventiert werden.

 

[KonradN]

Also generell kannst Du Strings nicht wirklich umwandeln. Strings sind intern in UTF-16 codiert. Wenn Du dann die Strings irgendwo ausgibst, dann wird das automatisch in dem richtigen Format übergeben. Sprich: bei Ausgaben wird, so nichts anderes angegeben, das default Encoding verwendet.

Bei der Datenbank hast Du aber natürlich keine normale Ausgabe. Du übergibst den String an den JDBC Treiber und der kümmert sich dann.

Daher ist jetzt erst einmal zu prüfen:
a) Sind die Zeichen in Java noch ok?
b) Wie übergibst Du diese genau an PHP?
c) Wie wertest Du diese in PHP aus?
d) Wie schreibt PHP dies dann in die Datenbank?

Die Übergänge sind also wichtig. Und da hast Du dann entweder eine Schnittstelle, die einen String nimmt (dann hast Du da auf Deiner Code-Seite erst einmal keine Codierung zu beachten!) oder Du hast dann Klassen, die die Ausgabe machen (also z.B. Writer und so). Da kannst Du dann ein Encoding vorgeben.

Eine Methode wie String convertStringToUTF8(String s) ist aus meiner Sicht Quatsch, denn Du bekommst einen korrekten String und baust dann irgendwas dubioses! Sieh String wirklich als eine Zeichenkette an! Die Zeichenkette ist immer die Zeichenkette. Da hast Du dann ein Ä oder Ü oder so. Das ist dann wirklich das Zeichen. Die Codierung sind dann immer Byte Arrays. Je nach Codierung kommt da dann was anderes an Bytes bei raus.

 

[wer112]

Also generell kannst Du Strings nicht wirklich umwandeln. Strings sind intern in UTF-16 codiert. Wenn Du dann die Strings irgendwo ausgibst, dann wird das automatisch in dem richtigen Format übergeben. Sprich: bei Ausgaben wird, so nichts anderes angegeben, das default Encoding verwendet.

Also übergibt java richtig an PHP?

Bei der Datenbank hast Du aber natürlich keine normale Ausgabe. Du übergibst den String an den JDBC Treiber und der kümmert sich dann.

Daher ist jetzt erst einmal zu prüfen:
a) Sind die Zeichen in Java noch ok?

Das weiß ich nicht, da Java nur HTML Code versteht bisher.

b) Wie übergibst Du diese genau an PHP?

Volly per getParam Methode

c) Wie wertest Du diese in PHP aus?

Ich übertrage es einfach

d) Wie schreibt PHP dies dann in die Datenbank?

$warteStat = $con->prepare("INSERT INTO entwickler_registrations_warteschleife (kundennummer, vorname, nachname, geburtstag, geburtsort, person_type, zip_passwort) VALUES (:kn, :vn, :nn, :gt, :geo, :pt, :pw)");
                        $warteStat->execute(array(":kn" => "E" . $kundennummer, ":vn" => $vorname, ":nn" => $name, ":gt" => $geburtstag, ":geo" => $geburtsort, ":pt" => "privat", ":pw" => $passwort));

Die Übergänge sind also wichtig. Und da hast Du dann entweder eine Schnittstelle, die einen String nimmt (dann hast Du da auf Deiner Code-Seite erst einmal keine Codierung zu beachten!) oder Du hast dann Klassen, die die Ausgabe machen (also z.B. Writer und so). Da kannst Du dann ein Encoding vorgeben.

Ist Volly eine Schnittstelle oder ein Writer?

Eine Methode wie String convertStringToUTF8(String s) ist aus meiner Sicht Quatsch, denn Du bekommst einen korrekten String und baust dann irgendwas dubioses! Sieh String wirklich als eine Zeichenkette an! Die Zeichenkette ist immer die Zeichenkette. Da hast Du dann ein Ä oder Ü oder so. Das ist dann wirklich das Zeichen. Die Codierung sind dann immer Byte Arrays. Je nach Codierung kommt da dann was anderes an Bytes bei raus.

 

[KonradN]

Volly per getParam Methode

Ach je - ich erinnere mich noch an die vergangenen Threads rund um diese Topics.

Hier ist es wichtig, dass Du Dich mit den Requests im Detail beschäftigst. Du musst schauen, was Du wie codiert weiter sendest.

Aber das wurde in der Vergangenheit schon mehrfach gesagt und Du bist dem nie im Detail nachgegangen. Statt dessen hattest Du Schnipse aus dem Netz kopiert und irgendwie angepasst.

Mir graut es schon jetzt, aber zur Not könntest Du den Request aufblähen und den String codiert übertragen. Also etwas wie: UTF-8 Bytes holen und diese Base64 codiert übertragen. Das kannst Du dann auf PHP Seite rückgängig machen. Aber das ist kein Workaround - das ist ein Kündigungsgrund (aus meiner Sicht). Wenn man etwas macht oder nutzt, dann muss man es verstehen. Wenn man das nicht macht, dann kann das Produkt nicht stabil funktionieren.

 

[wer112]

Mir graut es schon jetzt, aber zur Not könntest Du den Request aufblähen und den String codiert übertragen. Also etwas wie: UTF-8 Bytes holen und diese Base64 codiert übertragen.

Bevor ich die param sende möchte ich das konvenieren. Also soll ich es von utf16 in Base64 konventieren und dann in PHP wieder in UTF 8 konventieren?

Das kannst Du dann auf PHP Seite rückgängig machen. Aber das ist kein Workaround - das ist ein Kündigungsgrund (aus meiner Sicht).

warum wäre das ein Kündigungsgrund?

Wenn man etwas macht oder nutzt, dann muss man es verstehen. Wenn man das nicht macht, dann kann das Produkt nicht stabil funktionieren.

Hauptsache die Beta funktioniert, damit Entwickler sehen, was ich ca. haben möchte

 

[KonradN]

warum wäre das ein Kündigungsgrund?

Wenn man etwas entwickelt, dann muss man verstehen, was man da macht. Das, was hier getrieben wird, ist ein frickeln. Irgendwann scheint es dann zu gehen aber wirklich 100% verstanden, was da abgeht, hat niemand. Und die Chance ist groß, dass dann irgendwas nicht geht. So wie Du jetzt das Problem mit den Sonderzeichen festgestellt hast.

Wobei es evtl. einfacher sein könnte, es "html encoded" zu senden. In HTML werden viele Zeichen als &...; dargestellt. Also z.B. ü für das ü.

Das wäre evtl. auch eine Idee. Aber die Einschränkung muss dir bewusst sein: Du hast da kein sauberes Encoding. Wenn dir da ein Chinese mit chinesischen Zeichen kommt oder so, dann hast Du vermutlich ein Problem.

Daher kann die Lösung nur sein, dass man die Requests sauber absetzt und dann ein entsprechend saubern Transfer von Strings hat. Dazu gibt es ja UTF.

Wie so ein Encoding aussehen könnte findet sich z.B. hier:
Java Escape HTML - Encode Special Characters (howtodoinjava.com)

 

[wer112]

Wenn man etwas entwickelt, dann muss man verstehen, was man da macht. Das, was hier getrieben wird, ist ein frickeln. Irgendwann scheint es dann zu gehen aber wirklich 100% verstanden, was da abgeht, hat niemand. Und die Chance ist groß, dass dann irgendwas nicht geht. So wie Du jetzt das Problem mit den Sonderzeichen festgestellt hast.

Ich versuche das ja zu verstehen, soweit mir das möglich ist. Das Problem mit den Sonderzeichen habe ich schon länger, dachte es liegt am PHP.

Wobei es evtl. einfacher sein könnte, es "html encoded" zu senden. In HTML werden viele Zeichen als &...; dargestellt. Also z.B. ü für das ü.

Das wäre evtl. auch eine Idee. Aber die Einschränkung muss dir bewusst sein: Du hast da kein sauberes Encoding. Wenn dir da ein Chinese mit chinesischen Zeichen kommt oder so, dann hast Du vermutlich ein Problem.

Deswegen will ich am liebsten mit UTF-8 arbeiten. Und dann per Param dies zu übertragen.

Daher kann die Lösung nur sein, dass man die Requests sauber absetzt und dann ein entsprechend saubern Transfer von Strings hat. Dazu gibt es ja UTF.

Da muss ich wissen wie ich das mache. Das Posten der Strings, brauche ich ja kein Volly Request. Nur für das Empfangen, das ist aber ein anderes Problem.

Erstmal möchte ich es, das es ordentlich in die DB eingetragen wird.

Wie so ein Encoding aussehen könnte findet sich z.B. hier:
Java Escape HTML - Encode Special Characters (howtodoinjava.com)

 

[LimDul]

Dann wäre der erste Schritt mal zu debuggen:

• Was wird gesendet von Java
• Was wird empfangen von PHP

Um dann zu schauen, ob es korrekt ankommt.
Am besten mit einfachen Test-Requests die z.B. nur "XXXÄÄXXX" enthalten.

 

[wer112]

Dann wäre der erste Schritt mal zu debuggen:

• Was wird gesendet von Java
• Was wird empfangen von PHP

Um dann zu schauen, ob es korrekt ankommt.
Am besten mit einfachen Test-Requests die z.B. nur "XXXÄÄXXX" enthalten.

PHP Teil:

<?php

echo $_POST['test'];
?>

Ergebniss Response: XXÃÃXX

Param: param.put("test", "XXÄÜXX");

 

[Marinek]

Problem gefunden Hast du noch weitere Fragen?

 

[wer112]

Problem gefunden Hast du noch weitere Fragen?

Das Problem ist ja bekannt, deswegen möchte ich ees so konventieren, dass im PHP richtig ankommt, deswegen diesen Thread.

 

[LimDul]

Ich meine den request zu loggen, nicht den Aufruf von außen. Sprich Protokollierung des Framework hochdrehen bis der request protokolliert wird, was wirklich gesendet wird

 

[Marinek]

Welche Header setzt du denn?

 

[mihe7]

kundennummer varchar(255) CHARACTER SET utf8mb3 COLLATE utf8mb3_unicode_ci NOT NULL,

Übrigens

The utf8mb3 character set is deprecated and you should expect it to be removed in a future MySQL release. Please use utf8mb4 instead.

 

[LimDul]

z.B.: https://stackoverflow.com/questions/47593303/volley-library-multipartrequest-and-utf-8-support

 

[Jw456]

PHP Teil:

<?php

echo $_POST['test'];
?>

Ergebniss Response: XXÃÃXX

Param: param.put("test", "XXÄÜXX");

Mit echo schickst du es ja wierder mit html zurück. Du solltest schon auf dem Server selber direkt schauen was da ankommt.

 

[wer112]

Mit echo schickst du es ja wierder mit html zurück. Du solltest schon auf dem Server selber direkt schauen was da ankommt.

In der DB kommt © an , wenn ich é sende. oder was meinst du?

 

[wer112]

Welche Header setzt du denn?

bei volly keinen. habe in php utf 8 als header gesetzt.

 

[wer112]

Übrigens

also soll ich alles auf mb4 setzten und nicht auf mb3?

 

[wer112]

z.B.: https://stackoverflow.com/questions/47593303/volley-library-multipartrequest-and-utf-8-support

die zeile: dataOutputStream.writeBytes("Content-Type: text/plain; charset=UTF-8" + lineEnd);
habe ich hinzugefügt, kommt in der db é raus

 

[KonradN]

Also das ist jetzt alles ein Stochern im Nebel. Du musst genau prüfen, was da als Request versendet wird. Dann kann man den ganzen Request analysieren und auch prüfen, ob da das Richtige im Request steckt.

Es bringt nichts, nur hinten bei PHP zu schauen, was da ggf. raus kommt. Du musst Schritt für Schritt prüfen, was Du da genau machst und ob nach jedem Schritt das Ergebnis stimmt.

Eine Idee wäre noch, was dataOutputStream für ein Encoding nutzt. Aber bei Android ist das default Encoding UTF-8 daher sollte es eigentlich passen.

Aber was für einen Request sendest Du da? Ist das evtl. Bestandteil von Deinem multi part Request? Dann ist da ggf. der Content Type gezielt für den entsprechenden Part zu setzen oder so ...

 

[LimDul]

Simples Google bringt z.B.: https://stackoverflow.com/questions...request-of-my-multipart-volley-request-in-log

Alternativ Proxy dazwischen schalten
Oder im Apache (oder wo auch immer PHP läuft) entsprechend logs aktivieren.

Wichtig ist, dass man anstelle rumzuprobieren mal exakt loggt was an Bytes über die Leitung geht. Und nicht was vorne ins Framework reingesteckt wird oder was hinten in der Anwendung rauskommt. Das A und O bei solchen Problemen ist wirklich den Datenfluss genau zu verfolgen.

 

[Jw456]

out = new String(s.getBytes("UTF-8"), "ISO-8859-1");

Überlege finde heraus ob Java wirklich den „ISO-8859-1“ ZeichenSatz benutzt.
Es wurde hier auch schon gesagt was Java benutzt.
Also von wo nach was du Notfalls Konvertieren musst.

 

[mrBrown]

die zeile: dataOutputStream.writeBytes("Content-Type: text/plain; charset=UTF-8" + lineEnd);
habe ich hinzugefügt, kommt in der db é raus

Ist dataOutputStream ein DataOutputStream?

Der ist generell für sowas eher nicht geeignet, sondern nur sinnvoll zum Austausch zwischen Java-Apps, und writeBytes schreibt hier kein UTF-8!

 

[mihe7]

also soll ich alles auf mb4 setzten und nicht auf mb3?

Bei Gelegenheit, ja. Hat aber nichts mit Deinem Problem zu tun.

 

[wer112]

Also das ist jetzt alles ein Stochern im Nebel. Du musst genau prüfen, was da als Request versendet wird. Dann kann man den ganzen Request analysieren und auch prüfen, ob da das Richtige im Request steckt.

wie mache ich das? edittext per log ausgeben?

Es bringt nichts, nur hinten bei PHP zu schauen, was da ggf. raus kommt. Du musst Schritt für Schritt prüfen, was Du da genau machst und ob nach jedem Schritt das Ergebnis stimmt.

Eine Idee wäre noch, was dataOutputStream für ein Encoding nutzt. Aber bei Android ist das default Encoding UTF-8 daher sollte es eigentlich passen.

Aber was für einen Request sendest Du da? Ist das evtl. Bestandteil von Deinem multi part Request? Dann ist da ggf. der Content Type gezielt für den entsprechenden Part zu setzen oder so ...

multipart war für den zip. benutze normales stringrequest

 

[wer112]

Überlege finde heraus ob Java wirklich den „ISO-8859-1“ ZeichenSatz benutzt.
Es wurde hier auch schon gesagt was Java benutzt.
Also von wo nach was du Notfalls Konvertieren musst.

gesagt wurde utf16, aber da kommt mit der SOF methode noch mehr müll raus

 

[Jw456]

gesagt wurde utf16, aber da kommt mit der SOF methode noch mehr müll raus

Das war als Tipp und Denkanstoß gemeint nicht als Lösung.

 

[Jw456]

multipart war für den zip. benutze normales stringrequest

Dann zeige das doch mal.
Was nutzt du da Get oder Post?
Hast du da auch den Contenttyp gesetzt damit php das auch weiß.

Denn android benutzt intern eigentlich utf8 denn Linux nutzt Standart utf8.

Das java utf16 benutzt solte kein Thema sein hat dir Konrad ja schon erklärt.

 

[Jw456]

multipart war für den zip. benutze normales stringrequest

Dann zeige das doch mal.
Was nutzt du da Get oder Post?
Hast du da auch den Contenttyp gesetzt damit php das auch weiß.

Denn android benutzt intern eigentlich utf8 denn Linux nutzt Standart utf8.

Das java utf16 benutzsolte kein Thema sein hat dir Konrad ja schon erklärt.

Auf welchen Zeichensatz ist den deine DB eingestellt?

 

[KonradN]

Die interne Speicherung eines Strings spielt absolut keine Rolle! Das können die Entwickler des JDKs so machen, wie sie wollten. Das hat mit Deiner Thematik absolut nichts zu tun.

Es ist intern UTF-16. Das hat diverse Vorteile. Unter anderem die Codepoints sind recht interessant (die man dann als char nutzen kann). Aber wenn man wollte, dann könnte die JVM das speichern wie auch immer. Denn das entscheide3nde ist, dass es am Ende immer datum geht, dass man die Bytes braucht. Das bedeutet, dass am Ende immer ein Aufruf kommt: Gib mir die Bytes für diese oder jene Codierung. Und da wird dann die interne Codierung - egal welche das ist - zu der gewünschten Codierung umgewandelt.

Diese Umwandlung hast Du immer. Wenn Du wolltest, könntest Du die Java Dateien UTF-32 codiert ablegen. Das musst Du dann nur eben auch im Projekt configurieren. Der Java Compiler liest die Datei dann im UTF-32 Format ein und wandelt dann alles in das Format, das intern genutzt wird.

Daher ist das für uns wie bei der Dampfmaschin' in der Feuzangenbowle: Das ist eine große, schwarze Kiste mit zwei Löchern. Durch das eine gehen Zeichenketten in definierten Encodings rein und durch das andere gehen Zeichenketten in definierten Encodings raus. Was da in der Kiste passiert, kann uns egal sein. Wir können da an den Löchern mit den Encodings arbeiten, die wir haben wollen und wir bekommen die Encodings raus, die wir haben wollen.

 

[Jw456]

Volley Debuging vielleicht hilft das hier.

https://copyprogramming.com/howto/detailed-debug-logs-with-volley

 

[KonradN]

Evtl. kann man auch einfach den ganzen Request in PHP in eine Datei schreiben:

PHP dump $_REQUEST to file

I want to dump request variables to a file for debugging. How's this possible?

stackoverflow.com

PHP: $_REQUEST - Manual

www.php.net

Aber ich kenne mich mit PHP nicht aus - ich bin mir nicht sicher, dass dies wirklich den ganzen Request zu 100% enthält aber es ist auf jeden Fall auch einen Versuch wert. Den Code aus der SO Antwort kann man auf jeden Fall mal ausprobieren und uns den Inhalt der Datei zeigen.

 

[Marinek]

Es gibt 100 Möglichkeiten den request zu loggen. Eine habe ich im letzten Thread vorgestellt.

Gibt genug Docker Lösungen, die das machen.

 

[KonradN]

Es gibt 100 Möglichkeiten den request zu loggen. Eine habe ich im letzten Thread vorgestellt.

Gibt genug Docker Lösungen, die das machen.

Das Problem dabei ist, dass die Anwendung auf Android läuft. Da dürften viele Möglichkeiten so nicht funktionieren. Und es ist aus meiner Sicht wichtig, einen Weg aufzuzeigen, den der TE gehen kann mit seinem Wissen. Daher wäre wichtig, low level Schritt für Schritt Anleitungen zu geben.

Ist nicht befriedigend, aber so schätze ich die Lage beim TE ein. Er will und ja nicht ärgern sondern er hat aus meiner Sicht nicht den Wissenstand, um so Hinweise dann umzusetzen.

Das nur am Rand als meine Sicht auf die Dinge.

 

[wer112]

Dann zeige das doch mal.
Was nutzt du da Get oder Post?

POSt

Hast du da auch den Contenttyp gesetzt damit php das auch weiß.

in PHP ist ein Header gesetzt;

Das ist der Header:

<?php
header('Content-type: text/html; charset=utf-8');
mb_internal_encoding('UTF-8');



//ini_set(default_charset, "UTF-8");
?>

Denn android benutzt intern eigentlich utf8 denn Linux nutzt Standart utf8.

Das java utf16 benutzt solte kein Thema sein hat dir Konrad ja schon erklärt.

 

[KonradN]

Aber damit setzt Du den Header für die Antwort, die PHP sendet. Das ist erst einmal egal, denn es geht ja um den Request von Android(Java) -> PHP.

 

[wer112]

Es gibt 100 Möglichkeiten den request zu loggen. Eine habe ich im letzten Thread vorgestellt.

Gibt genug Docker Lösungen, die das machen.

Habe es mit Postmann probiert, habe es nicht hinbekommen.

 

[KonradN]

Probierst Du mal, was ich in #37 gepostet habe? Der Link zu der SO Antwort hat ein paar Zeilen Code, die Du einfach an den Anfang deines PHP Scripts setzen kannst. Die request.log kannst Du dann hier im Forum einmal posten.

 

[Marinek]

Ist nicht befriedigend, aber so schätze ich die Lage beim TE ein. Er will und ja nicht ärgern sondern er hat aus meiner Sicht nicht den Wissenstand, um so Hinweise dann umzusetzen.

Also ich denke da muss man mehr erwarten. Auch die Antworten kommen sehr stochastisch rüber. Unklar, welcher Entwicklungsstand da ist.

Ebenfalls wird an jeder Stelle nur geraten seitens TO. Hier benötigt es zunächst einer systemskizze. Dann ist klar, dass ich mit HTTP spreche. Also verlasse ich die android Welt. Und hier kann ich mir ein Echo Proxy setzen oder wireshark oder oder oder. Und da kann ich die Sachen debuggen.

Das muss und hier stimme ich mit dir überein schrittweise erfolgen.

Mangels wissen um die Implementierung kann man nur allgemeine Hilfestellung geben.

 

[Jw456]

POSt

in PHP ist ein Header gesetzt;

Das ist der Header:

<?php
header('Content-type: text/html; charset=utf-8');
mb_internal_encoding('UTF-8');



//ini_set(default_charset, "UTF-8");
?>

Php
war nicht das was ich wollte.
Ich würde auch sagen mache erstmal das was in #37 gesagt wurde.

Wo kommen denn die Daten her die du sendest. Werden die von dir vor dem Senden in irgendeiner Form verändert?

Schaue dir auch die Grundlagen zum Http Protokoll an.

Wie gesagt post #37

 

[mrBrown]

Noch mal die Frage: Wie schreibst du die Daten?

Das eine kleine Code-Stückchen hier benutzt (zumindest dem Namen nach) DataOutputStream#writeBytes, und genau das ist kein UTF-8.

 

[wer112]

Probierst Du mal, was ich in #37 gepostet habe? Der Link zu der SO Antwort hat ein paar Zeilen Code, die Du einfach an den Anfang deines PHP Scripts setzen kannst. Die request.log kannst Du dann hier im Forum einmal posten.

In diesem Request Log in PHP kommt es also richtig an, dann liegt es nicht an Java, sondern die Stelle zur db. wenn man in der db es richtig abspeichert kommt es verkrüppelt in Java an.

Benutze das zum schreiben:

$warteStat = $con->prepare("INSERT INTO entwickler_registrations_warteschleife (kundennummer, vorname, nachname, geburtstag, geburtsort, person_type, zip_passwort) VALUES (:kn, :vn, :nn, :gt, :geo, :pt, :pw)");
                        $warteStat->execute(array(":kn" => "E" . $kundennummer, ":vn" => $vorname, ":nn" => $name, ":gt" => $geburtstag, ":geo" => $geburtsort, ":pt" => "privat", ":pw" => $passwort));

Kann mir jemand helfen, dass es richtig in die db ankommt und wieder zurück?

 

[Marinek]

Also ich bin raus.

Noch weniger code und Kontext kann man nicht liefern.

Kommt garantiert nicht richtig an. Und die Anzeige in html rendert der Browser korrekt.

Wir wissen nicht wie es in der dB ausschaut. Wie du es daraus liest. Wie du es übermittelst.

Das ist ein ewiges stochern im Nebel.

Ich bin raus.

 

[Jw456]

Noch mal die Frage: Wie schreibst du die Daten?

Das eine kleine Code-Stückchen hier benutzt (zumindest dem Namen nach) DataOutputStream#writeBytes, und genau das ist kein UTF-8.

Er benutzt die Lib Volley. Und keinen eignen Stream. Sagte er auch mal zwischen durch.

 

[Jw456]

Bist du dir sicher das du hiermit richtig bist?
kundennummer varchar(255) CHARACTER SET utf8mb3 COLLATE utf8mb3_unicode_ci NOT NULL,

Ich würde mal testen wie es die db ohne Angabe von character set und collate es Abspeichert. Also mal die default Einstellung der db nutzen.

Lasse dir ausgeben was in der Variablen vor dem abspeichern steht. Und dann schaue was gespeichert ist. Schaue das direkt auf dem server nach ohne es in die app zu senden.
Denn hier macht die db genau die von dir geforderte Konvertierung.

Desshalb musst du wissen in wechen utf es php bekommt.
Das war auch der sinn der hinter post #37 steht.