Da liegst du falsch. Wäre schlimm wenn PHP dann etwas aus einen String löscht. Und in seinen Hexdump #11 sehe ich keine solchen Zeichen. Möchte fast wetten, jetzt "funzt" es wie von Zauberhand auch ohne (string).
Ankündigung
Einklappen
Keine Ankündigung bisher.
csv auslesen - datum aufbereiten
Einklappen
Neue Werbung 2019
Einklappen
X
-
Zitat von jspit Beitrag anzeigenDa liegst du falsch. Wäre schlimm wenn PHP dann etwas aus einen String löscht. Und in seinen Hexdump #11 sehe ich keine solchen Zeichen.
$foo ="5 Äpfel";
echo (int)$foo; //5
wieso dann auch nicht $bar = "test ..irgendeinSteuerungszeichen"; echo (string)$bar;//alles binäre wird rausgeschnittenapt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]
Kommentar
-
Zitat von BlackScorp Beitrag anzeigenNaja ich vermute dass php dann alle komischen UTF8 steuerungszeichen rauslöscht wenn es nach String konvertiert der TE hat doc geschrieben dass es jetzt "funzt"
Kommentar
-
Zitat von hellbringer Beitrag anzeigen
Aus Sicht von PHP ist ein String nur ein Byte-Array. Für PHP gibt es keine UTF-8 oder Steuerzeichen. Ein String ist immer binär. Wenn PHP alles "binäre rausschneiden" würde, wäre der String immer leer.apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]
Kommentar
-
Zitat von BlackScorp Beitrag anzeigenkeine Ahnung, die Lösung hat ja irgendwie geholfen, wir können stunden lang weiter so hin und her diskutieren ohne der tatsächlichen CSV Vom TE werden es eh nicht herausfinden
- 1 Likes
Kommentar
-
Zitat von hellbringer Beitrag anzeigen
Mag schon sein, dass der TE was ganz anderes macht, als er hier zeigt. Aber es sollte halt hier nicht als "Lösung" für so ein Problem für andere, die zufällig drüber stolpern, stehen bleiben. Schon gar keine Annahmen, dass PHP bei einem String-Cast irgendwelche Zeichen entfernt, was ja eindeutig falsch ist. Dass dem TE geholfen wurde mag ja schön und gut sein, aber hier sollten dann bitte keine falschen Fakten stehen bleiben.apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]
Kommentar
-
trim() entfernt das:
" " (ASCII 32 (0x20)), ein normales Leerzeichen.
"\t" (ASCII 9 (0x09)), ein Tabulatorzeichen.
"\n" (ASCII 10 (0x0A)), einen Zeilenvorschub (Line Feed).
"\r" (ASCII 13 (0x0D)), ein Wagenrücklaufzeichen (Carriage Return).
"\0" (ASCII 0 (0x00)), das NUL-Byte.
"\x0B" (ASCII 11 (0x0B)), ein vertikaler Tabulator.
Was noch sein könnte, unter anderem:
NEL: Next Line, U+0085
LS: Line Separator, U+2028
PS: Paragraph Separator, U+2029
Mal davon abgesehen, dass es unzählige Unicode-Zeichen gibt, die nicht sichtbar sind. Also man müsste schon wissen was drin ist um es zu entfernen und nicht auf gut Glück irgendwelche skurrilen Löschaktionen starten.
Kommentar
-
Zitat von hellbringer Beitrag anzeigenMal davon abgesehen, dass es unzählige Unicode-Zeichen gibt, die nicht sichtbar sind. Also man müsste schon wissen was drin ist um es zu entfernen und nicht auf gut Glück irgendwelche skurrilen Löschaktionen starten.
Code:4a616e20313020323031392031323a353720
Und das kann dann anstandslos von strtotime() geparst werde und passt so gar nicht zu einigen Aussagen des TE.string( 18 ) ASCII "Jan 10 2019 12:57 "
Zitat von hellbringer Beitrag anzeigenMag schon sein, dass der TE was ganz anderes macht, als er hier zeigt....
Kommentar
-
Zitat von jspit Beitrag anzeigen
Das ist auch meine Vermutung. Und wenn ich so etwas feststelle, bin ich dann raus.
Kommentar
-
Hab ich leider öfters erlebt das Teile weggelassen wurden in der Meinung es spielt keine Rolle, Code falsch abgeschrieben wurde so das dann Fehler produziert wurden oder auch Ergebnisse publiziert wurden welche nicht zum Code passen.
Sorry, wenn ich das hier zu unrecht vermutet habe.
Warum komme ich zu so einer Vermutung?
Das habe ich im Grundsatz schon im Beitrag #24 gezeigt. Dazu noch ein weiteres Beispiel:
PHP-Code:<?php
$column[10] = "Jan 10 2019 12:57 ";
$input = $column[10];
echo bin2hex($input)."\n";
echo("<br>variablentyp input: " . gettype($input) . " inhalt: **" . $input . "**<br><br>");
$date = strtotime($input);
echo("variablentyp date: " . gettype($date) . " inhalt: **" . $date . "**<br><br>");
echo ("Datum: " . $date . "<br>");
echo date('d m Y H:i:s', $date);
Der hexcode welcher ausgegeben wird ist identisch mit einer Ausgabe welche du #11 zeigst. Im dortigen Code ist aber noch ein logischer Fehler, so dass niemals ein richtiges Datum rauskommen kann.
Eine hypothetische Variante für das merkwürdige Verhalten wäre noch das Du mit unterschiedlichen CSV-Files arbeitest von denen einige ok sind und andere noch unbekannte Zeichen enthalten.
Kommentar
-
Kein Thema. Das glaub ich Dir.
Ich hab auch die Vermutung, dass es an der CSV liegt - wobei es immer die selbe ist Datei ist.
Die CVS beinhaltet zwei Datumsangaben die identisch aufgebaut sind. Bei einer funktioniert es und bei der anderen nicht... und das mit dem selben Code...
Ich versuch mich weiter an dem Code.
Kommentar
-
Es wird an der CVS liegen.
Dort ist z.B. "51GHG6813;Task ;Jan 07 2020 09:29 ;AXDD41, " angegeben.
Wenn ich nun versuchen in der Datei " ;" durch ";" per "Suchen und ersetzen" zu ersetzen, wird " ;" nicht bei der Datumsangabe gefunden.
Nehme ich das Leerzeichen vor dem Semikolon per Hand raus, funktioniert es wieder.
Kommentar
Kommentar