PHP Unsichtbare Zeichen: %E2%80%8E

[EuroCent]

Hallo zusammen,

seit Stunden habe Ich an einem Skript einen Fehler gesucht.
Es ging dabei um ein Datumsformat: 2020-07-06

Inhaltlich hat er es mir korrekt angezeigt.
Sobald die Abfrage dann via SQL an die DB ging, hieß es dann seitens DB: "conversion failed when converting date and/or time from character string".

Ich suchte seit Heute früh 6 Uhr nach dem Problem, warum er den Eintrag nicht speichern will.
Hatte Ich die Abfrage 1:1 nach geschrieben in die DB direkt, kam es zu keinem Fehler.

Also überprüfte Ich weiterhin mein Skript, um die Ursache heraus zu finden.
Selbst als Ich das Datumsformat manuell in die Variable gepackt hatte, gab es den selbigen Fehler.

<?php
    //Dies hole Ich aus meinem Formular
    $date = $_REQUEST['dateformat'];
?>
   
<?php
    //Manuelle Schreibweise
    $date = "2020-07-06";
?>

Beide geben mit den oben-genannten Fehler der DB zurück.

Nach langem hin und her, suchen und machen... kam Ich mal auf die Glorreiche Idee und wande "rawurlencode" an.
Sie da: aus 2020-07-06 wurde: "%E2%80%8E2020-07%E2%80%8E-%E2%80%8E06%E2%80%8E"

Die Daten werden via JS an Ajax zum Skript geliefert.

Meine Frage:
Welche Ursache kann dies denn haben, dass er mir diesen Kryptischen Text zurückliefert.
Ich verwende in dem Skript kein UTF8-Decode oder Encode.

Lediglich "header("Content-Type: text/html; charset=utf-8");" => Hatte ich weg gelassen, der Fehler war der selbe!

Gibt es dafür irgendeine Erklärung wie sowas passieren kann?

 

[EuroCent]

Hast du mal da was von versucht ?
https://stackoverflow.com/questions/553463/jquery-ajax-character-encoding

Ja das hab Ich schon genutzt.
Das ergebnis bleibt daher das selbe.

Ich arbeite absolut ohne javascript,ajax,jQuery usw.
aber Du hast noch immernicht den DB auszug, und deinen Weg zum speichern in eine DB gepostet.

Nichts für ungut, aber der Eintrag in die DB ist nicht das Problem.
Sondern vorweg die Codierung.

Daher ist es nicht notwendig dir einen Auszug zu schicken.

Wie gesagt das Feld in der DB ist als datetime deklariert.

<?php
$sql = "INSERT INTO [dbo].[tabelle] ([catalog_date]) VALUES(?)";
$params = array($_REQUEST['catalogexpiredFrom']);
$stmt = sqlsrv_prepare($msconnect, $sql, $params);
sqlsrv_execute($stmt);
sqlsrv_free_stmt($stmt);
?>

 

[ComFreek]

Ich vermute, dass der Browser dieses Zeichen einfügt. Überprüfe doch mal, ob nach Veränderung der Eingabe (manuell mittels Tastatur) der Wert des Eingabefeldes das left-to-right-mark enthält. Etwa via hexEncode(document.getElementById('catalogexpiredFrom').value), wobei du dir hexEncode irgendwo aus dem Internet ziehen müsstest, z. B. von Javascript: Unicode string to hex.

Was spricht dagegen ein <input>-Feld vom type="date" zu benutzen? Ich würde stark vermuten, dass da der Browser so etwas nicht einfügen würde.

Nebenbei: wenn dein <input>-Feld type="text" hat, machen dann die Attribute "min" und "max" überhaupt noch Sinn -- geschweige denn sind erlaubt?

 

[EuroCent]

Ich vermute, dass der Browser dieses Zeichen einfügt. Überprüfe doch mal, ob nach Veränderung der Eingabe (manuell mittels Tastatur) der Wert des Eingabefeldes das left-to-right-mark enthält. Etwa via hexEncode(document.getElementById('catalogexpiredFrom').value), wobei du dir hexEncode irgendwo aus dem Internet ziehen müsstest, z. B. von Javascript: Unicode string to hex.

Das werde Ich mir morgen anschauen
Sieht zumindestens sehr viel versprechend aus.

Vielen Dank

Was spricht dagegen ein <input>-Feld vom type="date" zu benutzen? Ich würde stark vermuten, dass da der Browser so etwas nicht einfügen würde.

Leider verwenden wir noch den IE11 und der nimmt zwar das date-Attribute aber baut es als en-GB das Datum um (2020-06-07).
Das irritiert aber viele, da der Chrome welcher Alternative unterstützt wird, macht.

Sobald der neue Edge draußen ist, wird dieser für das Unternehmen entsprechend Verwendet.
Dann ist die alternative zu Chrome dann auch hinfällig

Daher hab Ich es aktuell in text umgestellt damit es nicht zu Problemen führt.

Nebenbei: wenn dein <input>-Feld type="text" hat, machen dann die Attribute "min" und "max" überhaupt noch Sinn -- geschweige denn sind erlaubt?

Macht natürlich null Sinn, an der Stelle hab Ich es nur versäumt, es entsprechend zu entfernen.
Das wird natürlich noch entfernt.

 

[ComFreek]

Ich verstehe! Wenn es tatsächlich der Browser ist, würde ich das clientseitig mit String.prototype.trim() aus dem inputField.value entfernen. Ich würde sowieso empfehlen, clientseitig sowie serverseitig das eingegebene Datum zu validieren.

 

[EuroCent]

Ich verstehe! Wenn es tatsächlich der Browser ist, würde ich das clientseitig mit String.prototype.trim() aus dem inputField.value entfernen. Ich würde sowieso empfehlen, clientseitig sowie serverseitig das eingegebene Datum zu validieren.

Naja ist halt die Frage ob er diese Zeichen ebenfalls entfernt.

Ich werde es dennoch versuchen
Bin zwar nicht sicher, aber glaube dass Ich dies bereits gemacht hatte.
Aber egal... auf ein neues

 

[ComFreek]

Oh, tatsächlich werden die mit trim() oder Regex \s nicht gematched und entfernt:

"\u200e".trim().length // result: 1
"\u200e".replace(/^\s*/g, "").length // result: 1

Dann müsstest du U200E (oder gleich eine umgebende Range*) explizit im Regex vermerken.

* zum Beispiel ist der Right-to-Left-Mark mit U200F direkt daneben.

 

[EuroCent]

Oh, tatsächlich werden die mit trim() oder Regex \s nicht gematched und entfernt:

"\u200e".trim().length // result: 1
"\u200e".replace(/^\s*/g, "").length // result: 1

Dann müsstest du U200E (oder gleich eine umgebende Range*) explizit im Regex vermerken.

* zum Beispiel ist der Right-to-Left-Mark mit U200F direkt daneben.

Okay dann ist meine Lösung schon bereits eingebunden gewesen.
Denn mit regex habe Ich es bereits php seitig gelöst.