nicht angemeldet
String to Integer
suit
Der Martin
Gunnar BittersmannMoin,
hab ein irres Problem...
Ich lese eine CSV-Datei ein und such mir ein Datum. Wenn ich das Datum habe zerlege ich es mittels explode. Das sieht dann ganz unspektakulär so aus:
$arDate = explode(".",$strDate);
In $arData gibt es 3 Keys, eins für den Tag, eins für den Monat und eines fürs Jahr. Jetzt würde ich gerne, da es sich noch um Strings handelt (was mir die Funktion gettype() bestätigt), in Integer Werte umwandeln - Aber:
echo $arData[0] //--- gibt 11 zurück
echo gettype($arData[0]) //--- string zurück
echo intval($arData[0]) //--- gibt 1 zurück...
echo $arData[1] //--- gibt 11 zurück
echo gettype($arData[1]) //--- string zurück
echo intval($arData[1]) //--- gibt 0 zurück...
Das umwandeln nach Integer will nicht so ganz. Okay denke ich hab ich irgendwo einen Denkfehler. Also mal schön der Reihe nach. Hab nach dem explode() folgendes eingefügt:
$arData[0] = "11";
$arData[1] = "11";
$arData[2] = "2011";
echo intval($arData[0]) //--- gibt 11 zurück!
Demnach bekomme ich aus der Textdatei einen "unechten" String? Ich steh auf jeden Fall auf dem Schlauch. Es kommt auch kein Fehler oder Warnung oder so.
Zu dem Wahnsinn kommt noch hinzu dass ich hier noch eine Textdatei vom 20.08.2011 habe, bei der funktioniert es einwandfrei.
Ich steh total auf dem Schlauch und hab absolut keine Idee zwecks der Lösung...
Gruß
verwirrter
T-Rex
-
Ich steh total auf dem Schlauch und hab absolut keine Idee zwecks der Lösung...
strptime() dürfte dein Problem auf 1 bis 2 Zeilen reduzieren.
-
Ich steh total auf dem Schlauch und hab absolut keine Idee zwecks der Lösung...
strptime() dürfte dein Problem auf 1 bis 2 Zeilen reduzieren.
Nope sorry, die Funktion "strptime" gibts bei mir nicht. Ich hab PHP Version 5.3.5 auf meinem lokalen Rechner. Das gibt mir jedoch echt zu denken...
Gruß
grübbelnder
T-Rex-
Ich steh total auf dem Schlauch und hab absolut keine Idee zwecks der Lösung...
strptime() dürfte dein Problem auf 1 bis 2 Zeilen reduzieren.
Nope sorry, die Funktion "strptime" gibts bei mir nicht. Ich hab PHP Version 5.3.5 auf meinem lokalen Rechner. Das gibt mir jedoch echt zu denken...
Jop - wenn PHP ohne --enable-calendar kompiliert wurde, geht auch andere einfache Datumsfunktionen nicht.
Zu deiner Debugausgabe - macht bitte dasselbe nochmal mit var_dump()
-
Ich steh total auf dem Schlauch und hab absolut keine Idee zwecks der Lösung...
strptime() dürfte dein Problem auf 1 bis 2 Zeilen reduzieren.
Nope sorry, die Funktion "strptime" gibts bei mir nicht. Ich hab PHP Version 5.3.5 auf meinem lokalen Rechner. Das gibt mir jedoch echt zu denken...
Jop - wenn PHP ohne --enable-calendar kompiliert wurde, geht auch andere einfache Datumsfunktionen nicht.
Zu deiner Debugausgabe - macht bitte dasselbe nochmal mit var_dump()
Hmpf...dann bekomme ich string(4) "11" -> also Steuerzeichen.
Da werde ich doch gleich mal meine Debugfunktion anpassen. Die Stringlänge ist eine gute Idee!Danke
Gruß
Steuerzeichen hassender
T-Rex-
Hmpf...dann bekomme ich string(4) "11" -> also Steuerzeichen.
Steuerzeichen?
string "11" nach int gecastet ergibt aber 11 dezimal - ganz sicher :)
-
Hmpf...dann bekomme ich string(4) "11" -> also Steuerzeichen.
Steuerzeichen?
string "11" nach int gecastet ergibt aber 11 dezimal - ganz sicher :)
Bei mir ist das nicht der Fall - ganz Sicher.
Wenn ich var_dump($arData[0]) mit dem was mir explode gibt mache, dann erhalte ich string(4) "11". Wenn ich in $arData[0] vorher "11" selber reinschreibe, dann bekomme ich string(2) "11". Diesen Wert kann ich auch problemlos in ein int umwandeln. Deshalb vermute ich 2 Steuerzeichen hinter dem Problem. Ich hab ein wenig mit substr rumgespielt, deshalb kann ich jetzt sogar genau sagen wie die "11" aufgebaut ist -> "1 Steuerzeichen 1 Steuerzeichen".Jetzt ist nur noch die Frage wie ich die Steuerzeichen da raus bekomme :(.
Gruß
Steuer-(beliebiges Wort) hassender
T-Rex-
Tach!
Jetzt ist nur noch die Frage wie ich die Steuerzeichen da raus bekomme :(.
Erstmal fragen, was das für Steuerzeichen sind. Dabei hilft urlencode() ganz prima (wissenschaftlich exakt wäre allerdings bin2hex()). Die nächste Frage ist, wie kommen die da rein? Sind die schon in der CSV-Datei drin und fummelst du das auf ungünstige Art (alles andere als fgetcsv()/str_getcsv()) auseinander oder was ganz anderes?
dedlfix.
-
Tach!
Jetzt ist nur noch die Frage wie ich die Steuerzeichen da raus bekomme :(.
Erstmal fragen, was das für Steuerzeichen sind. Dabei hilft urlencode() ganz prima (wissenschaftlich exakt wäre allerdings bin2hex()). Die nächste Frage ist, wie kommen die da rein? Sind die schon in der CSV-Datei drin und fummelst du das auf ungünstige Art (alles andere als fgetcsv()/str_getcsv()) auseinander oder was ganz anderes?
dedlfix.
Also wenn ich urlencode vorher aufrufe bekomme ich diesen String: "1%001%00".
Die csv Datei öffne ich recht primitiv mit file(). Das Array gehe ich dann durch und mach ein explode(",",$arFile).Gruß
primitiver
T-Rex-
Also wenn ich urlencode vorher aufrufe bekomme ich diesen String: "1%001%00".
Da wird doch wohl nicht in einer 16-Bit-Codierung gearbeitet?
Wenn da anstatt 0x3131 einfach 0x00310031 daherkommt, wären die beiden NULL-Einschübe zu erklären.
-
Also wenn ich urlencode vorher aufrufe bekomme ich diesen String: "1%001%00".
Da wird doch wohl nicht in einer 16-Bit-Codierung gearbeitet?
Wenn da anstatt 0x3131 einfach 0x00310031 daherkommt, wären die beiden NULL-Einschübe zu erklären.
Wie gesagt die CSV Datei ist eine excel-csv Datei von Google Analytics (oder Adwords). Bei der normalen CSV Datei ist alles super. Wahrscheinlich baut Google irgendwelche Sonderzeichen für das Microsoft Excel ein?
Vielleicht hab ich aber auch den Bundestrojaner gefunden :D.Gruß
wer's findet darf's behalten
T-Rex-
Tach!
Also wenn ich urlencode vorher aufrufe bekomme ich diesen String: "1%001%00".
Wie gesagt die CSV Datei ist eine excel-csv Datei von Google Analytics (oder Adwords). Bei der normalen CSV Datei ist alles super. Wahrscheinlich baut Google irgendwelche Sonderzeichen für das Microsoft Excel ein?Nein, das sind nur dann Sonderzeichen, wenn du es falsch dekodierst. Schau dir mal die gesamte Datei mit einem Hexeditor an, da wirst du sicher noch mehr Null"zeichen" finden - und das ist dann eine 16-Bit-Kodierung. Wenn du die mit PHP verarbeiten wolltest, müsstest du das erstmal in ISO-8859-1 umkodieren. Am Anfang der Datei sollte auch noch eine BOM zu finden sein.
dedlfix.
-
-
-
Tach,
Also wenn ich urlencode vorher aufrufe bekomme ich diesen String: "1%001%00".
also Null-Bytes, sieht aus wie UTF-16.
Die csv Datei öffne ich recht primitiv mit file(). Das Array gehe ich dann durch und mach ein explode(",",$arFile).
Durch das explode hätte ich eigentlich ein Null-Byte am Anfang des Strings mehr erwartet.
mfg
Woodfighter-
Also wenn ich urlencode vorher aufrufe bekomme ich diesen String: "1%001%00".
also Null-Bytes, sieht aus wie UTF-16.
Die csv Datei öffne ich recht primitiv mit file(). Das Array gehe ich dann durch und mach ein explode(",",$arFile).
Durch das explode hätte ich eigentlich ein Null-Byte am Anfang des Strings mehr erwartet.
Du übersichst dabei, dass das BOM bei UTF-8 3 Oktette umfasst, bei UTF-16 aber nur zwei - möglicherweise erklärt sich hier die Verschiebung um ein Oktett, wenn PHP davon ausgeht, es sei UTF-8 (ohne das BOM eigentlich zu prüfen).
-
Tach!
Durch das explode hätte ich eigentlich ein Null-Byte am Anfang des Strings mehr erwartet.
Du übersichst dabei, dass das BOM bei UTF-8 3 Oktette umfasst, bei UTF-16 aber nur zwei - möglicherweise erklärt sich hier die Verschiebung um ein Oktett, wenn PHP davon ausgeht, es sei UTF-8 (ohne das BOM eigentlich zu prüfen).Davon geht PHP derzeit immer noch nicht aus - erst ab Version 6 wird sich da was ändern. Ob die 0-Bytes davor oder dahinter stehen, ist nur eine Frage der Bytereihenfolge, die Google für das Speichern gewählt hat.
dedlfix.
-
Tach,
Ob die 0-Bytes davor oder dahinter stehen, ist nur eine Frage der Bytereihenfolge, die Google für das Speichern gewählt hat.
allerdings müßte das explode in beiden Fällen ein Byte davor erzeugen, sofern die 1 nicht durch das erste Byte in der Datei kodiert wird, was unwahrscheinlich ist, da UTF-16 ohne BOM im Internet nicht viel Sinn ergibt und Excel meines Wissens auch welche erzeugt.
mfg
Woodfighter-
Tach!
Ob die 0-Bytes davor oder dahinter stehen, ist nur eine Frage der Bytereihenfolge, die Google für das Speichern gewählt hat.
Das bezieht sich auf die Anordnung in der Datei. In der Testausgabe kann und wird es durch die 1-Byte-pro-Zeichen-Stringbehandlung anders aussehen.
allerdings müßte das explode in beiden Fällen ein Byte davor erzeugen, sofern die 1 nicht durch das erste Byte in der Datei kodiert wird, was unwahrscheinlich ist, da UTF-16 ohne BOM im Internet nicht viel Sinn ergibt und Excel meines Wissens auch welche erzeugt.
Das 0-Byte dahinter ist erklärlich, weil PHPs explode() am Punkt schneidet. Der Punkt ist eingerahmt von 0-Bytes. Eins davon gehört zu ihm, das andere gehört entweder zum vorhergehenden oder nachfolgenden Zeichen, je nach Bytereihenfolge. Doch das ist PHP egal. Es sieht den Punkt und das 0-Byte davor kommt zum ersten Teilstring, das danach kommt zum zweiten Teilstring. Ob in der Testausgabe ein 0-Byte vor der ersten 1 des ersten Teils zu sehen ist oder nicht, ist auch eine Frage, an welcher Stelle der String geschnitten wurde.
dedlfix.
-
Hallo,
Das 0-Byte dahinter ist erklärlich, weil PHPs explode() am Punkt schneidet.
ja, richtig, aber ...
Der Punkt ist eingerahmt von 0-Bytes. Eins davon gehört zu ihm, das andere gehört entweder zum vorhergehenden oder nachfolgenden Zeichen, je nach Bytereihenfolge. Doch das ist PHP egal. Es sieht den Punkt und das 0-Byte davor kommt zum ersten Teilstring, das danach kommt zum zweiten Teilstring.
Eben. Der Original-String müsste in ISO-Latin gelesen "1_1_._1_1_._2_0_1_1_" gewesen sein[*], wobei ich mit den Unterstrichen hier die Nullbytes repräsentieren möchte. Trenne ich das nun mit explode() an den Punkten, erhalte ich
[0] "1_1_"
[1] "_1_1_"
[2] "_2_0_1_1_"Das erste Fragment wird durch intval zu 1 ausgewertet, die anderen beiden zu 0, weil sie nicht mit einer Ziffer beginnen. Man beachte den Hinweis im Handbuch zum Ergebnis:
Strings will most likely return 0 although this depends on the leftmost characters of the string. The common rules of integer casting apply.
There you go. Auch meinen Tests zufolge wird gewöhnlicher Whitespace (Leerzeichen, Tab, Zeilenumbruch) am Stringanfang von intval() ignoriert, ein Null-Zeichen beendet aber das Parsing sofort und das Ergebnis ist 0.
Ciao,
Martin[*] Wir wissen nicht, wie T-Rex den String ursprünglich gewinnt, vermutlich schneidet er alles vor der ersten Ziffer weg. Sonst stünde vor der ersten '1' ja auch noch ein Nullbyte.
--
Niemand lebt allein von seinen Träumen.
Aber wer träumt, lebt noch.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(-
Moin,
Das 0-Byte dahinter ist erklärlich, weil PHPs explode() am Punkt schneidet.
Der Punkt ist eingerahmt von 0-Bytes. Eins davon gehört zu ihm, das andere gehört entweder zum vorhergehenden oder nachfolgenden Zeichen, je nach Bytereihenfolge. Doch das ist PHP egal. Es sieht den Punkt und das 0-Byte davor kommt zum ersten Teilstring, das danach kommt zum zweiten Teilstring.
Eben. Der Original-String müsste in ISO-Latin gelesen "1_1_._1_1_._2_0_1_1_" gewesen sein[*], wobei ich mit den Unterstrichen hier die Nullbytes repräsentieren möchte. Trenne ich das nun mit explode() an den Punkten, erhalte ich
[0] "1_1_"
[1] "_1_1_"
[2] "_2_0_1_1_"Das erste Fragment wird durch intval zu 1 ausgewertet, die anderen beiden zu 0, weil sie nicht mit einer Ziffer beginnen. Man beachte den Hinweis im Handbuch
Woher zum Geier weiß man sowas?^^ Ich bin immer bemüht so viel wie möglich zu lernen. Aber auf alles, wenn ich etwas verstanden habe, kommen 100 Sachen, die neu sind...
Frustrierend.Grüße Marco
-
Woher zum Geier weiß man sowas?^^ Ich bin immer bemüht so viel wie möglich zu lernen. Aber auf alles, wenn ich etwas verstanden habe, kommen 100 Sachen, die neu sind...
Durch lesen der Dokumentation, ausprobieren[1] und Erfahrung/Fachwissen sammeln - das macht einen unterm Strich zum Experten.
Und sei froh, dass es immer wieder neues zu lernen gibt - wenn du alles weißt nicht nicht mehr denken musst, rostet dein Hirn ein :)
[1] das hatten wir doch gerade erst vorgestern - wenn etwas nicht ganz klar ist, mach dir ein paar Testcases und schau dir das verhalten an. Daraus lernt man sehr viel, auch wenn sowas augenscheinlich trivial erscheint, ist das auf lange sicht von vorteil, weil sich damit solche Probleme lösen lassen.
-
[1] das hatten wir doch gerade erst vorgestern - wenn etwas nicht ganz klar ist, mach dir ein paar Testcases und schau dir das verhalten an. Daraus lernt man sehr viel, auch wenn sowas augenscheinlich trivial erscheint, ist das auf lange sicht von vorteil, weil sich damit solche Probleme lösen lassen.
Das hab ich früher auch gemacht mit dem Ergebnis das ich sogar den Funktionsnamen vergessen hatte, wenn es drauf ankommt. Wenn ich heute eine Funktion teste die ich noch nicht kenne, dann hab ich das ganze Szenario in 6 Monaten wieder vergessen, wenn ich es nicht irgendwo öfters anwende.
Auf der anderen Seite kann ich mir unbedeutende Namen von Fussballern z.B. ein lebenslang merken. Ich kann sogar viele Vereine wo die mal gespielt haben zuordnen.
Am Ende kam ich zur Erkenntnis dass es eine Interessensfrage ist. Mich interessiert die Informatik eigentlich schon, ich kenne aber ein paar verrückte die machen nichts anderes als Bücher lesen und am Computer testen, tüffteln als gäbe es nichts anderes. Die Wissen dementsprechend mehr.Gruß
normaler Mensch
T-Rex
-
-
Tach!
Woher zum Geier weiß man sowas?^^ Ich bin immer bemüht so viel wie möglich zu lernen. Aber auf alles, wenn ich etwas verstanden habe, kommen 100 Sachen, die neu sind...
Erste Regel: Augen auf und nachschauen! Debugausgaben sind das wichtigste Werkzeug, weswegen man alle Funktionen kennen sollte, die einem ein genauestmögliches Ergebnis zeigen. var_dump() mit seiner Typausgabe und der Längenangabe bei String ist essentiell, gefolgt von urlencode()/bin2hex(). Der Rest ist nachdenken, Überlegungen anstellen, was es sein könnte, unbedingt prüfen ob die Überlegung stimmt oder nicht, dabei aufmerksam das Ergebnis anschauen und Hinweise auf andere Lösungsmöglichkeiten oder Ungereimtheiten finden. Das ist alles mühsame Eichhörnchenarbeit ... Hinzu kommt noch, über den Tellerrand schauen. Das Lösen eigener Probleme bringt eine gewisse Erfahrung, aber manche Fehler macht man einfach nicht, wenn man sich auskennt, man berührt also einige Problembereiche gar nicht. Das Beschäftigen mit den Problemen anderer bringt also weitere Erfahrungen.
dedlfix.
-
-
Tach!
Das 0-Byte dahinter ist erklärlich, weil PHPs explode() am Punkt schneidet.
ja, richtig, aber ...Was aber? Du bestätigst doch nur meine Aussage.
Der Original-String müsste in ISO-Latin gelesen "1_1_._1_1_._2_0_1_1_" gewesen sein[*], wobei ich mit den Unterstrichen hier die Nullbytes repräsentieren möchte. Trenne ich das nun mit explode() an den Punkten, erhalte ich
[0] "1_1_"
[1] "_1_1_"
[2] "_2_0_1_1_"Das erste Fragment wird durch intval zu 1 ausgewertet, die anderen beiden zu 0, weil sie nicht mit einer Ziffer beginnen. Man beachte den Hinweis im Handbuch zum Ergebnis:
Ja, passt alles zu den Debugausgaben und Versuchen, von denen uns T-Rex das Ergebnis gezeigt hat.
[*] Wir wissen nicht, wie T-Rex den String ursprünglich gewinnt, vermutlich schneidet er alles vor der ersten Ziffer weg. Sonst stünde vor der ersten '1' ja auch noch ein Nullbyte.
Das ist auch meine Vermutung, sonst ergäbe auch die Umwandlung des ersten Teilstrings eine 0.
dedlfix.
-
Deine Beschreibung trifft sehr genau auf mein Phänomen.
Der String steht in der ersten Zeile der CSV und lautet im ganzen ungefähr so "Text blabla (11.11.2011)". Per preg_match bekomme ich "(11.11.2011)" und schneide dann jeweils das erste und letzte Zeichen ab mittels substring.
Kann mir vielleicht noch jemand erklären wieso da Nullbytes rumstehen? Sind die zum auffüllen, da es 16 Bits sind?
Gruß
dazwischen funkender
T-Rex-
Der String steht in der ersten Zeile der CSV und lautet im ganzen ungefähr so "Text blabla (11.11.2011)". Per preg_match bekomme ich "(11.11.2011)" und schneide dann jeweils das erste und letzte Zeichen ab mittels substring.
Steht das datum nicht in einem eigenen Feld, welches du auf herkömmliche Art und Weise bekommst? Reguläre ausdrücke um CSV-Daten zu parsen sind nicht unbedingt der Bringer.
-
Steht das datum nicht in einem eigenen Feld, welches du auf herkömmliche Art und Weise bekommst? Reguläre ausdrücke um CSV-Daten zu parsen sind nicht unbedingt der Bringer.
Ich fische lediglich das Datum aus der Kopfzeile. (@dedelfix ein trim kann da schon dabei sein) Danach kommt der Head wie die Felder heißen und dann kommen die Zeilen mit den CSV Daten. *ROFL* ich parse doch nicht die komplette CSV Datei mit Regulären Ausdrücken :D.
-
Ich fische lediglich das Datum aus der Kopfzeile.
Ein CSV hat keine Kopfzeilen :)
*ROFL* ich parse doch nicht die komplette CSV Datei mit Regulären Ausdrücken :D.
Was weiß ich - mit preg_match_all wäre das übrigens garnicht so schwierig.
-
Ein CSV hat keine Kopfzeilen :)
Das musste Google sagen.
Bei der steht "Keywords (11.11.2011)" oben drüber.Da Google fast mächtiger als Chuck Norris ist, hat bei einer CSV Datei eine Kopfdatei zu existieren!
Gruß
mächtiger als Chuc...aua
T-Rex-
Da Google fast mächtiger als Chuck Norris ist, hat bei einer CSV Datei eine Kopfdatei zu existieren!
Der Gmail-Konto-Name von Chuck Norris ist gmail@chucknorris.com - mit solchen Aussagen solltest du vorsicht sein - er findet dich :p
Chuck Norris hat letztens erst eine Granate geworfen und damit 50 Leute getötet - erst danach ist sie detoniert.
-
-
-
-
-
Hallo,
Kann mir vielleicht noch jemand erklären wieso da Nullbytes rumstehen? Sind die zum auffüllen, da es 16 Bits sind?
gewissermaßen ... ;-)
Windows verwendet sowohl intern wie auch in gespeicherten Dateien gern und oft UCS-2, was weitgehend mit UTF-16 identisch ist. Das heißt, jedes Zeichen wird mit 16bit dargestellt. Das höherwertige Byte ist dann in den meisten Fällen 0.Ciao,
Martin--
"Life! Don't talk to me about life!"
(Marvin, the paranoid android in Douglas Adams' "The Hitchhiker's Guide To The Galaxy")
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:( -
Tach!
Der String steht in der ersten Zeile der CSV und lautet im ganzen ungefähr so "Text blabla (11.11.2011)". Per preg_match bekomme ich "(11.11.2011)" und schneide dann jeweils das erste und letzte Zeichen ab mittels substring.
Das passt dann allerdings nicht mehr auf die Debugausgaben. Aus dem preg_match() wird vermutlich sowas kommen:
(_1_1_._1_1_._2_0_1_1_)
also alles von erster bis zweiter Klammer. Wenn du dann vorn ein Zeichen abschneidest, bekommst du _1_... und das ergäbe beim Umwandeln in Integer wegen des führenden 0-Bytes eine 0 wie bei deinem zweiten Teilstring.
Wenn vor der Klammer noch ein 0-Byte stünde, würde das Abschneiden eines Zeichens die Klammer stehen lassen. Da ist noch irgendwas anderes, ein trim() vielleicht?
Kann mir vielleicht noch jemand erklären wieso da Nullbytes rumstehen? Sind die zum auffüllen, da es 16 Bits sind?
Vermutungen dazu wurden doch schon geäußert, inklusive der Aufforderung, mit einem Hexeditor nachzuschauen, besonders den Dateianfang.
dedlfix.
-
Vermutungen dazu wurden doch schon geäußert, inklusive der Aufforderung, mit einem Hexeditor nachzuschauen, besonders den Dateianfang.
Eben gerade bin ich dazu gekommen. HexEditor ist echt interessant und was ich sehe ist echt hammer. Zwischen jedem Zeichen ist ein Null Byte. Am Anfang sind die Bytes "ff fe".
Mein Notepad++ Editor zeigt an dass es sich um die Codierung UCS2-Little Endian handelt.Ein trim() war wahrscheinlich die ursache, dass beim Datum am Anfang kein Null Byte rumstand.
Ich hoffe das letzte Geheimnis gelüftet zu haben.
Danke an alle
Gruß
Detektiv
T-Rex-
Hallo,
Eben gerade bin ich dazu gekommen. HexEditor ist echt interessant und was ich sehe ist echt hammer. Zwischen jedem Zeichen ist ein Null Byte. Am Anfang sind die Bytes "ff fe".
Mein Notepad++ Editor zeigt an dass es sich um die Codierung UCS2-Little Endian handelt.what I told you ...
Das Zeichen FFEF am Anfang ist übrigens die BOM, die auch schon mehrmals im Thread erwähnt wurde.Ein trim() war wahrscheinlich die ursache, dass beim Datum am Anfang kein Null Byte rumstand.
Ja. Wie im Handbuch nachzulesen ist, schnibbelt trim() unter anderem auch Nullbytes weg.
Ich hoffe das letzte Geheimnis gelüftet zu haben.
Bestimmt nicht. Da kommen noch unzählige weitere. Sonst wär's ja irgendwann langweilig. :-)
Ciao,
Martin--
I do take my work seriously and the way to do that is not to take yourself too seriously.
(Alan Rickman, britischer Schauspieler)
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:( -
@@T-Rex:
nuqneH
was ich sehe ist echt hammer. Zwischen jedem Zeichen ist ein Null Byte. Am Anfang sind die Bytes "ff fe".
Der Hammer hat einen Namen: UTF-16.
Ein trim() war wahrscheinlich die ursache, dass beim Datum am Anfang kein Null Byte rumstand.
PHP (< 6) hat hat das grundsätzliche Problem, (außer bei mb_-Funktionen) keine Stringverarbeitung zu machen, sondern Bytefolgen-Operationen.
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)
-
-
-
-
-
-
-
-
-
-
-
-
Also um das ganze abzuschließen.
Ich baue eine Importmöglichkeit für Google Analytics Statistiken. Die kann man per CSV exportieren. Aber auch als excel-csv. Mein Kollege hat mir eine excel-csv und eine normale csv Datei geschickt. Bei der normalen CSV Datei hat alles wunderbar funktioniert und bei dem excel ding gab es wie gesagt die Probleme. Anscheinend sind da noch mehr Steuerzeichen im kompletten Text verstreut. Wir umgehen das Problem jetzt in dem mein Kollege die einfache CSV Datei benutzt.Bisschen unbefriedigend ist das ganze leider doch, da ich das Problem nicht lösen konnte.
Gruß
umgehender
T-Rex
-
-
-
-
-
-
-