UTF-8 String

wer112

Top Contributor
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:

Java:
 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

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

Dann musst du diese vorher manuell bereinigen.
 

wer112

Top Contributor

Oneixee5

Top Contributor
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

Top Contributor
Wie ist denn der Spaltentyp in der DB und welche DB verwendest du?
Java:
-- 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

Super-Moderator
Mitarbeiter
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

Top Contributor
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?
PHP:
$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

Super-Moderator
Mitarbeiter
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

Top Contributor
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

Super-Moderator
Mitarbeiter
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

Top Contributor
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

Top Contributor
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

Top Contributor
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:
<?php

echo $_POST['test'];
?>

Ergebniss Response: XXÃÃXX

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

LimDul

Top Contributor
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
 

KonradN

Super-Moderator
Mitarbeiter
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

Top Contributor
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

Top Contributor
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

Super-Moderator
Mitarbeiter
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!
 

wer112

Top Contributor
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
 

Jw456

Top Contributor
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

Top Contributor
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

Super-Moderator
Mitarbeiter
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.
 

KonradN

Super-Moderator
Mitarbeiter
Evtl. kann man auch einfach den ganzen Request in PHP in eine Datei schreiben:

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

Bekanntes Mitglied
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

Super-Moderator
Mitarbeiter
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

Top Contributor
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:
<?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

Super-Moderator
Mitarbeiter
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.
 

KonradN

Super-Moderator
Mitarbeiter
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

Bekanntes Mitglied
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

Top Contributor
POSt

in PHP ist ein Header gesetzt;

Das ist der Header:

PHP:
<?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

Super-Moderator
Mitarbeiter
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

Top Contributor
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:

PHP:
$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

Bekanntes Mitglied
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

Top Contributor
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.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
W Base64 konvertierter URI String Android & Cross-Platform Mobile Apps 32
W String Array Pfad in Int setzen Android & Cross-Platform Mobile Apps 54
W Volley String Response gibt falchen if aus Android & Cross-Platform Mobile Apps 35
H Anfänger String types not allowed (at 'textColor' with value 'black' Android & Cross-Platform Mobile Apps 13
W Firestore String in Apps Laden Android & Cross-Platform Mobile Apps 10
T Android R.string.test+i Problem Android & Cross-Platform Mobile Apps 2
A Mit Java neues item in ein string-array einer Strings.xml schreiben Android & Cross-Platform Mobile Apps 4
C Zugriff auf die Position eines String- bzw Spinner-Arrays Android & Cross-Platform Mobile Apps 1
J Android String in andere Java-Dateien überführen Android & Cross-Platform Mobile Apps 1
J R.string.(variable) geht das Android & Cross-Platform Mobile Apps 3
R Android incomingNumber bein Eingehenden Anruf immer leerer String Android & Cross-Platform Mobile Apps 4
S SPLIT funktion bei STRING funktioniert nicht! Android & Cross-Platform Mobile Apps 4
G String an einen php Script senden Android & Cross-Platform Mobile Apps 8
J Plötzlich "java.lang.String cannot be converted to JSONObject" Android & Cross-Platform Mobile Apps 9
T int to string ... Android & Cross-Platform Mobile Apps 8
A String[] für Lisadapter Android & Cross-Platform Mobile Apps 4
M jsonobject cannot be cast to java.lang.string Android & Cross-Platform Mobile Apps 4
N Android Hilfe string to float geht nicht... Android & Cross-Platform Mobile Apps 4
J Einen String bewegen wie? Android & Cross-Platform Mobile Apps 3
R String wie WAV Datei nutzen Android & Cross-Platform Mobile Apps 4
C 2 kleine Probleme (Datei lesen, String durchsuchen) Android & Cross-Platform Mobile Apps 16
L String dem Display anpassen Android & Cross-Platform Mobile Apps 12
G Text parsen String to Double Android & Cross-Platform Mobile Apps 2
S ein String nach vorgegebenen Zeichen teilen Android & Cross-Platform Mobile Apps 3
N Zeichen im String löschen? Android & Cross-Platform Mobile Apps 18
M MIDlet + Datum in String Android & Cross-Platform Mobile Apps 5

Ähnliche Java Themen


Oben