[PHP] problemen met uitlezen csv file

[w00d]

Ik heb een csv file die gegenereerd is met wmic. Deze zet in ik in een array in php zodat ik er volgens mee verder kan werken ( dacht ik ).

In een array zetten gaat goed, maar het probleem is dat de data type niet herkend worden. Een integer is geen integer meer en een string kan ik niet vergelijken met een andere string..

Nu heb ik al gelezen dat het niet mogelijk is om een integer die in een array staat als zodanig te herkennen als die uit een csv file komt, maar een simpele string vergelijking is dus ook al niet mogelijk.

Kan je nou gewoon echt niks met een ingelezen csv of vergeet ik nou iets

PHP:

$handle = fopen("hd.csv", "r");
while (($data = fgetcsv($handle, 1000, ",")) !== FALSE) {
        $name = $data[0];
        $free = $data[1];
        $drive = $data[2];
        $size = $data[3];
        
        print_r($data); //output: Array ( [0] => server4 [1] => 29099573248 [2] => C: [3] => 36405072384 )
        
        echo $name;  //output: server4
        if($name == "server4"){
            echo $name; 
        }else{
            echo "helaas"; //output: helaas
        }
}               
fclose($handle);

[Icekiller2k6]

php werkt niet met 'integers' of strings deze zet het gewoon om dus als je
$var == $var2 als 1ste var een getal is dan maakt hij van de 2de var ook een getal en vergelijkt hij dit
idem voor strings..

probeer zelf maar is als je vb

PHP:

$var=100;
$var2="100";
if($var==$var2){
echo "gelijk";
}else{
echo "niet gelijk";
}

of

PHP:

<?php
$var=hasselt;

if($var=="hasselt"){
echo "gelijk";
}else{
echo "niet gelijk";
}
?>

misschien dat er nog spaties ofzo errond zitten?

[ Voor 23% gewijzigd door Icekiller2k6 op 15-09-2008 18:47 . Reden: tags vergeten ]

[w00d]

nee idd php werkt niet echt met string in integer, maar hij herkend ze nu ook niet als zodanig. Ik kan u niet bijv $size - $free doen. Waarde is dan gewoon 0.

Maar als ik dit doe:

PHP:

$a = 5
$b = 4
echo $a - $b;  // 1

$free = 29099573248; 
$size = 36405072384; 
echo $size - $free; // 7305499136

Maar als ik dus waardes uit de array gebruik ( die exact hetzelfde zijn ) dan werkt et niet

Er zit zover ik kan zien geen spaties of dergelijke. Zie print_r output

[ Voor 8% gewijzigd door w00d op 15-09-2008 18:57 ]

[Noork]

w00d schreef op maandag 15 september 2008 @ 18:57:
Er zit zover ik kan zien geen spaties of dergelijke. Zie print_r output

Doe anders voor de zekerheid trim($name).

[RAJH]

Om zeker te weten dat er geen spaties en dergelijk voorstaan kan je gebruik maken van var_dump(), of door de hele string per character te doorlopen en kijken met ord() welke ASCII code er voorkomen. Er kan namelijk ook een ander non printable character in die string staan.

[Megamind]

Het kan zijn dat er nog onzichtbaar een \r of \n staat. Met trim haal je deze zowiezo weg.

[Gomez12]

of doe gewoon een : echo 'a' . $string . 'a';
en kijk of de a'tjes wel 100% aansluiten op de string. Basic Debugging volgens mij wat op 100én manieren te doen is.

[w00d]

met ord() de string doorlopen bleek er inderdaad nog verborgen karakters te zijn.
255-254-115-0-101-0-114-0-118-0-101-0-114-0-52 ( server4 )


Met trim haal ik die 2 er niet vanaf, maar dat gaat wel anders lukken. Maar ik vind het wel raar dat er ( in mijn ogen ) platte csv file nog zoveel verborgen karakters zitten..

Maar ja thnxs voor de tip over ord() die wist ik namelijk nog niet.

[RobIII]

w00d schreef op dinsdag 16 september 2008 @ 10:52:
met ord() de string doorlopen bleek er inderdaad nog verborgen karakters te zijn.
255-254-115-0-101-0-114-0-118-0-101-0-114-0-52 ( server4 )

What the...
Weet je zeker dat je de juiste file leest? Of op de juiste plek zit te kijken in die file? Dat 255 en 254 verborgen tekens zijn (de zgn. BOM in een unicode file) evenals de 0-bytes is niet zo gek, maar "server4" zijn toch écht geen 'verborgen' tekens

Edit: oh, my bad. Ik zie dat "server4" wel in de string hoorde te staan In dat geval heb ik niets gezegd en je alleen gewezen op het feit dat je werkt met een unicode bestand

[ Voor 20% gewijzigd door RobIII op 16-09-2008 11:05 ]

[Herko_ter_Horst]

Het is dus een UTF-16 encoded file, die begint met een BOM en vervolgens per character 2 bytes gebruikt. Er zijn dus geen "verborgen" karakters, je leest de file alleen niet op de juiste manier in.

[w00d]

die ascii codes zouden dus gezamelijk server4 moeten vormen. dacht zet et er even bij. Loop nu even te testen met een txt bestand, kan daar ook naartoe exporteren, maar ook daar komt dezelfde bagger code in terug. ( maar dat komt dus door die BOM begrijp ik.. )

Toch maar is kijken of ik niet die template van wmic kan aanpassen

Het is dus een UTF-16 encoded file, die begint met een BOM en vervolgens per character 2 bytes gebruikt. Er zijn dus geen "verborgen" karakters, je leest de file alleen niet op de juiste manier in.

Ehh klinkt misschien stom, maar hoe zou ik hem dan moeten inlezen? fgetcsv() lijkt mij toch wel een beetje de manier om een csv in te lezen

[ Voor 34% gewijzigd door w00d op 16-09-2008 11:13 ]

[RobIII]

w00d schreef op dinsdag 16 september 2008 @ 11:12:
Ehh klinkt misschien stom, maar hoe zou ik hem dan moeten inlezen? fgetcsv() lijkt mij toch wel een beetje de manier om een csv in te lezen

Komaan; dat is gewoon te vinden in de manual (comments):

PHP:

setlocale(LC_ALL, 'en_US.UTF-8');

Kwestie van juiste encoding invullen dus.

[ Voor 5% gewijzigd door RobIII op 16-09-2008 11:21 ]

[w00d]

hmm ok over die notatie heb ik dus gewoon domweg heen gelezen. Verklaard het inderdaad wel.

[Herko_ter_Horst]

Hier: 115-0-101-0-114-0-118-0-101-0-114-0-52-0 staat inderdaad server4 in UTF16LE.

Met setLocale() zet je de encoding van "alles" op die waarde. Je kunt blijkbaar iets met http://nl.php.net/stream_encoding, maar die functie is niet gedocumenteerd. Mogelijk werkt het toch.

[ Voor 44% gewijzigd door Herko_ter_Horst op 16-09-2008 11:44 ]

[RobIII]

Herko_ter_Horst schreef op dinsdag 16 september 2008 @ 11:38:
Blijkbaar snapt fgetcsv() alleen single-byte encodings (bijv. UTF-8)

UTF-8 is niet single-byte maar een "variable-length character encoding".

Herko_ter_Horst schreef op dinsdag 16 september 2008 @ 11:38:
of misschien zelfs alleen maar ASCII (hoop van niet).

RobIII in "[PHP] problemen met uitlezen csv file"

[ Voor 4% gewijzigd door RobIII op 16-09-2008 11:42 ]

[Herko_ter_Horst]

RobIII schreef op dinsdag 16 september 2008 @ 11:42:
[...]

UTF-8 is niet single-byte maar een "variable-length character encoding".

Ok, ok

[...]

RobIII in "[PHP] problemen met uitlezen csv file"

Sorry, ik werd gestoord tijdens het typen en had jouw bericht niet meer meegekregen, was al bezig mijn reactie aan te passen.

[ Voor 5% gewijzigd door Herko_ter_Horst op 16-09-2008 11:52 ]

[w00d]

Ik heb het maar even anders opgelost. Het instellen van de juiste unicode had ook geen succes. Heb daarna nog even lopen testen met UTF-32 en 8 instellen in de xsl template, maar ook zonder succes.

Heb nu met behulp van pstools dezeflde info kunnen opvragen, dit genereerd een schone text bestand die ik keurig uit elkaar kan trekken en verwerken.

Bedank voor de tips, wel weer wat geleerd

[Megamind]

UTF8 + utf8_decode zou moeten werken toch in PHP?