leggere file non multiplo di 8 bit

Salve come da titolo, come si comporta il puntatore a file se non sono tutte sequenze di otto bit, (es. file con 15 bit dentro, il puntatore ne legge solo 8).Per favore mi fornite un file non multiplo e minore di otto bit, (credo che UTF-32 crei caratteri di 31 bit).

SEEK_END -1, cosa fa esattamente? intendo SEEK_END di fseek, recupera l'intera dimensione del file, e poi sposta il puntatore all'indietro..o trova l'eof e sposta il puntatore all'indietro.
ps. Mi riferisco a php, spero di avere vostre notizie, grazie anticipatamente.

Non puoi scrivere un file di 15 bit. Devi scrivere 16 bit e leggerne tutti 16. Poi scarti l'ultimo. Non puoi perché l'unità "elementare" è 8 bit. Quindi, volendo, alla fread devi passare come (secondo) parametro 2, quindi leggi 16 bit. Poi fai la & con 0x7F e hai il tuo numero a 15 bit (nota che comunque scrivendo un file a 15 bit perderesti sempre l'ultimo bit, che sarebbe inutilizzato).

Per la SEEK_END, quale differenza c'é tra:

Citazione:

---

recupera l'intera dimensione del file, e poi sposta il puntatore all'indietro

---

o

Citazione:

---

trova l'eof e sposta il puntatore all'indietro

---

?

Ciao!

Ciao è grazie tante per aver risposto.. come tenevo php legge solo da un byte..però la codifica base 64 implementata in php, per varie ragioni deve leggere a sei bit, e scrivere a otto bit.

di nuovo grazie, per aver riformulato la mia domanda, su SEEK_END.
SÉ lo leggesse dall'eof all' intero con segno negativo, avrei comunque come memorizzarlo su una sequenza superiore hai otto bit.

Citazione:

---

Originalmente inviato da darbula

Ciao è grazie tante per aver risposto.. come tenevo php legge solo da un byte..però la codifica base 64 implementata in php, per varie ragioni deve leggere a sei bit, e scrivere a otto bit.

---

Perché? (non conosco bene questa cosa). Perché non potrebbe leggere e scrivere a 8 bit?

Citazione:

---

Originalmente inviato da darbula

SÉ lo leggesse dall'eof all' intero con segno negativo, avrei comunque come memorizzarlo su una sequenza superiore hai otto bit.

---

Sinceramente non ricordo bene a basso livello come son organizzati i file, ma penso che comunque oltre al file ci siano altre informazioni salvate come la dimensione, e probabilmente altre cose... Una specie di "header" del file. Quindi l'EOF si trova "dopo" il contenuto del file: realmente quindi il file è un po' più grande...

Presumo sia così perché, quando stavo imparando queste cose (in C, non in PHP, ma dovrebbe essere la stessa cosa), mi è successo che per leggere file binari, mi capitava l'EOF prima della fine del file: lui leggeva -1 e lo interpretava giustamente come EOF e terminava. Invece usando una funzione apposita che restituiva la dimensione del file, non c'era questo problema. Quindi presumo che questa dimensione la prenda nelle informazioni "extra" del file.
Queste informazioni extra possono essere anche contenute in opportune tabelle: probabilmente è questo il modo usato: così la CPU sa anche a che indirizzo inizia il file da leggere, potendo salvare l'indirizzo in questa tabella... ma queste cose dovrebbero dipendere dal file system utilizzato.

Ciao!

per info leggi qui http://it.m.wikipedia.org/wiki/Base64 se non sono multipli di sei vengono aggiunti bit nulli.
enf of file, dovrebbe crearlo il filesystem, ma virtualmente.
cmq. spostare il puntatore con un segno negativo è errato in php.
poiché l'interi in php sono con segno.
su sistemi a 32 bit, l'intero con segno sarà da 0 a 4GB-1, però da 2GB (-1 per php) in poi, saranno interi negativi..
-1-1=-2 non come si aspetterebbe un essere umano..
Se SEEK_END è uguale hai byte del file, php deve controllare se è con segno meno è invertire il parametro lenght da negativo a positivo o viceversa, verificare il risultato dell'intero zero,il risultato esatto si ricava così intval('20000000000000000000');.
Ps. non l'ho testato, però mi sa tanto di bug logico di php.
se avete idee di cosa recupera SEEK_END,vi prego rispondete... Almeno ci togliamo questo dubbio.
Grazie Ale :)

Citazione:

---

Originalmente inviato da alemoppo

Sinceramente non ricordo bene a basso livello come son organizzati i file, ma penso che comunque oltre al file ci siano altre informazioni salvate come la dimensione, e probabilmente altre cose... Una specie di "header" del file. Quindi l'EOF si trova "dopo" il contenuto del file: realmente quindi il file è un po' più grande...

---

Citazione:

---

Originalmente inviato da darbula

enf of file, dovrebbe crearlo il filesystem, ma virtualmente.

---

Da come lo scrivete, sembra che EOF sia un carattere o qualcos'altro che dice: ecco dopo di me il file è finito.
In realtà non è così (altrimenti come potrebbe uno scrivere un file ad esempio binario in cui potrebbe presentarsi questo carattere?): il file system annota la precisa lunghezza del file (al byte) insieme a tutte le relative informazioni (permessi, cartella padre, data di modifica, creazione e simili), ma solitamente non sono immediatamente prima dei dati dello stesso. La funzione feof riesce quindi a determinare se il puntatore interno di lettura o scrittura ha raggiunto la fine solamente basandosi sulla lunghezza riportata. Questo ovviamente solo nel caso di normali file presenti nel file system locale.

Citazione:

---

Originalmente inviato da alemoppo

Mi è successo che per leggere file binari, mi capitava l'EOF prima della fine del file: lui leggeva -1 e lo interpretava giustamente come EOF e terminava. Invece usando una funzione apposita che restituiva la dimensione del file, non c'era questo problema. Quindi presumo che questa dimensione la prenda nelle informazioni "extra" del file.

---

Citazione:

---

Originalmente inviato da alemoppo

Queste informazioni extra possono essere anche contenute in opportune tabelle: probabilmente è questo il modo usato: così la CPU sa anche a che indirizzo inizia il file da leggere, potendo salvare l'indirizzo in questa tabella... ma queste cose dovrebbero dipendere dal file system utilizzato.

---

Esatto!. Ti consiglio, per avere una idea più chiara di come funziona un file system di dare un'occhiata a qualcosa di semplice come il FAT.

Citazione:

---

Originalmente inviato da alemoppo

---

Citazione:

---

Originalmente inviato da darbula

cmq. spostare il puntatore con un segno negativo è errato in php.
poiché l'interi in php sono con segno.

---

Non ti seguo...

Citazione:

---

Originalmente inviato da darbula

su sistemi a 32 bit, l'intero con segno sarà da 0 a 2GB-1, però da 1GB (-1 per php) in poi, saranno interi negativi..

---

Continuo ad essere confuso. Dunque, un intero senza segno a 32bit può arrivare a rappresentare al massimo il numero 4294967295, se questo dovesse rappresentare la dimensione di un file in byte, quest'ultima sarebbe oltre i 4GB (ma un byte più piccola di 4GiB). Nel caso dei file system FAT16 e FAT32, la dimensione dei singoli file è proprio registrata in un intero senza segno a 32bit.

Citazione:

---

Originalmente inviato da darbula

-1-1=-2 non 0 come si aspetterebbe un essere umano..

---

Continuo a non comprendere... Meno uno sottratto a meno uno per me ha come risultato meno due. E ti giuro di essere umano al cento per cento.

Citazione:

---

Originalmente inviato da darbula

Se SEEK_END è uguale hai byte del file, php deve controllare se è con segno meno è invertire il parametro lenght da negativo a positivo o viceversa.
Ps. non l'ho testato, però mi sa tanto di bug logico di php.
se avete idee di cosa recupera SEEK_END,vi prego rispondete... Almeno ci togliamo questo dubbio.

---

Ok, forse questo l'ho capito. Da come scrivi sembra che per te SEEK_END sia una costante che assume di volta in volta come valore la dimensione del file il byte, giusto? Per questo nel primo messaggio l'hai usata all'interno di un espressione aritmetica, no? In realtà non è così (e basta controllare la sintassi della funzione fseek): è una costante punto e basta, in realtà non devi curiosarne il valore, in quanto ha significato solo all'interno della chiamata a quella funzione. Ti serve solo per indicare che il primo parametro indica una posizione riferita alla fine del file, null'altro. Queste funzioni ricopiano la sintassi delle omonime del C, quindi credo che l'interprete PHP passi i valori a queste ultime senza fare troppi controlli in mezzo. Queste ultime vanno poi a dialogare direttamente con il kernel del sistema operativo, mediante apposite chiamate di sistema.
In generale comunque queste funzioni in PHP non gestiscono i cosiddetti LFS (file grandi), a meno di essere state compilate appositamente: http://www.php.net/manual/en/intro.filesystem.php.

Però mi sfugge ancora cosa centri tutto ciò con la codifica BASE64.

ciao grazie per il tuo contributo, ehm il post io lo ho editato, perché nel tuo commento è tale e quale a prima della mia modifica 1.40 am.

l'intero di php è con segno, su un sistema operativo sarà sempre con segno, per colpa di php, per info leggi sul manuale, le funzioni filesize e intval.
s.o a 32 bit il massimo e 4GB-1 (da -2147483647 a 0 sino 2147483647), se il file è di 2GB, espresso -1 il puntatore interno per me si trova in clonflitto.. ad es.

Codice PHP:

---

<?php
$resource='file.txt';//file da 2 GB su O.S 32 bit
$fp=fopen($resource,'rb'); //puntatore esterno
while(!feof($fp)){//fread non accetta interi negativi
$contents.=fread($fp,8192);
}
rewind($fp);
$end_char=fseek($fp,-1,SEEK_END);//-1-1=-2 il puntatore avanza invece di andare indietro 2147483647
$end_char2=fseek($fp,2,SEEK_CUR);//il puntatore sarà spostato a zero non -4
fclose($fp);
?>

---

mi riferivo alla codifica base 64, perché può inserire bit nulli, a me serviva qualcosa come questa, per salvare informazioni da file non otto bit.

Citazione:

---

Originalmente inviato da darbula

ciao grazie per il tuo contributo, ehm il post io lo ho editato, perché nel tuo commento è tale e quale a prima della mia modifica 1.40 am.

l'intero di php è con segno, su un sistema operativo sarà sempre con segno, per colpa di php, per info leggi sul manuale, le funzioni filesize e intval.

---

Citazione:

---

Originalmente inviato da darbula

s.o a 32 bit il massimo e 4GB-1 (da -2147483647 a 0 sino 2147483647), se il file è di 2GB, espresso -1 il puntatore interno per me si trova in conflitto.

---

Stai facendo un po' di confusione con le unità di misura. Non è proprio così: un intero a trentadue bit con segno rappresentato mediante il complemento a due, come in PHP, può assumere valori nell'intervallo da -2147483648 a 2147483647, estremi compresi (tu hai omesso il valore più piccolo). Inoltre stai facendo un po' di confusione con le unità di misura: non puoi dire che il massimo è 4GB-1, perché stai sottraendo ad una misura dell'informazione (byte) un numero puro (scalare). Inoltre è sempre bene distinguere tra KB (kilobyte) e KiB (kibibyte): il primo indica mille byte, il secondo mille e ventiquattro. Per maggiori dettagli: http://it.wikipedia.org/wiki/KiB.
Quindi, scrivendo le cose per bene possiamo affermare che usando un intero con segno a trentadue bit possiamo rappresentare la dimensione di un file, grande fino a 2147483647B, ovvero 2GiB-1B.

Citazione:

---

Originalmente inviato da darbula

. ad es.

Codice PHP:

---

<?php
$resource='file.txt';//file da 2 GB su O.S 32 bit
$fp=fopen($resource,'rb'); //puntatore esterno
while(!feof($fp)){//fread non accetta interi negativi
$contents.=fread($fp,8192);
}
rewind($fp);
$end_char=fseek($fp,-1,SEEK_END);//-1-1=-2 il puntatore avanza invece di andare indietro 2147483647
$end_char2=fseek($fp,2,SEEK_CUR);//il puntatore sarà spostato a zero non -4
fclose($fp);
?>

---

---

Come già spiegavo nel precedente messaggio, il PHP usa internamente le funzioni omonime della libreria standard stdio.h. Non è però definito il comportamento di queste nel caso di file così grandi, quindi le varie implementazioni sono libere di comportarsi in maniera differente. In alcuni casi potresti ricevere un errore, in altri potrebbe accadere internamente un overflow come suggerisci tu. Non è quindi possibile fornire una risposta generica. E non è nemmeno possibile dare colpa al PHP, è un problema che eredita da altri.

Citazione:

---

Originalmente inviato da darbula

mi riferivo alla codifica base 64, perché può inserire bit nulli, a me serviva qualcosa come questa, per salvare informazioni da file non otto bit.

---

Come ti ha già spiegato Alemoppo non esistono file system, sistemi operativi e librerie che non usano come unità elementare il byte.

Mi piace come ti spieghi e come commenti..detto questo prova

Codice PHP:

---

<?php
$num=-2147483648;
var_dump($num);
?>

---

Su php su O.S 32 BIT, il valore massimo degli interi con segno è -2147483647 cioè 4GiB -2 BYTES (il 0 indica vuoto).
Per quanto riguarda le funzioni sul filesystem, php siccome conosce i suoi limiti, cioè una variabile può contenere sino 2GiB (-1 byte), avrà sicuramente previsto di convertire gli interi in negativo..(certo e da verificare).
EDIT: ecco la conferma, php suggerisce di usare sprintf("%u",filesize($file)); tradotto, il formato u converte gli interi nel segno opposto. http://php.net/manual/it/function.filesize.php (se si recupera il tempo dello script, possiamo pure capire, se un file è piccolo, o un file che giustamente supera i 4GiB-2 BYTES, che ritorna un intero positivo).
Ps.serve una funzione per il tempo di recupero dei dati su filesystem, nativa in php.
Io e php la pensiamo allo stesso modo XD.
Riformulo la domanda, è possibile leggere/scrivere, avendo cura di formare un file, di sequenze di ottetti?
Scusate se sono assillante, zip trasforma il byte in 1bit 2bit 3bit e così via, non capisco il senso logico,perché non si potrebbe fare.

Citazione:

---

Originalmente inviato da darbula

Mi piace come ti spieghi e come commenti..detto questo prova

Codice PHP:

---

<?php
$num=-2147483648;
var_dump($num);
?>

---

---

Ok, tu invece prova a prevedere gli esiti di questo script e poi verifica:

Codice PHP:

---

<?php
$large_number = 2147483647;
var_dump($large_number);

$large_number = 2147483648;
var_dump($large_number);

$large_number = -2147483647;
var_dump($large_number);

$large_number = -2147483648;
var_dump($large_number);

$large_number = -2147483647-1;
var_dump($large_number);

$large_number = (int)-2147483648;
var_dump($large_number);

$large_number = -2147483649;
var_dump($large_number);

$large_number = (int)-2147483649;
var_dump($large_number);

$large_number = -2147483648-1;
var_dump($large_number);

$large_number = (int)(-2147483648-1);
var_dump($large_number);
?>

---

Citazione:

---

Originalmente inviato da darbula

Su php su O.S 32 BIT, il valore massimo degli interi con segno è -2147483647 cioè 4GiB -2 BYTES (il 0 indica vuoto).

---

Al più quello potrebbe essere il minimo, e continuo ad insistere che uno scalare (numero puro) è assai differente da una misura (byte e multipli). Al più puoi usare il prefisso singolarmente, in quanto il suo significato è solamente quello di un prodotto (per la relativa potenza di dieci o di due), quindi -2147483648=-2^31=-2*2^30=-2Gi. Invece 2147483647=2^31-1=2*2^30-1=2Gi-1.

Citazione:

---

Originalmente inviato da darbula

Per quanto riguarda le funzioni sul filesystem, php siccome conosce i suoi limiti, cioè una variabile può contenere sino 2GiB (-1 byte)

---

Di nuovo? No, al più questo potrebbe essere corretto per una variabile di tipo stringa.

Citazione:

---

Originalmente inviato da darbula

, avrà sicuramente previsto di convertire gli interi in negativo..(certo e da verificare).
EDIT: ecco la conferma, php suggerisce di usare sprintf("%u",filesize($file)); tradotto, il formato u converte gli interi nel segno opposto.

---

Più semplicemente, lo legge come se fosse un unsigned long.

Citazione:

---

Originalmente inviato da darbula

http://php.net/manual/it/function.filesize.php (se si recupera il tempo dello script, possiamo pure capire, se un file è piccolo, o un file che giustamente supera i 4GiB-2 BYTES, che ritorna un intero positivo).
Ps.serve una funzione per il tempo di recupero dei dati su filesystem, nativa in php.
Io e php la pensiamo allo stesso modo XD.

---

Perché ti dovrebbe servire il tempo?

Citazione:

---

Originalmente inviato da darbula

Riformulo la domanda, è possibile leggere/scrivere, avendo cura di formare un file, di sequenze di ottetti?
Scusate se sono assillante, zip trasforma il byte in 1bit 2bit 3bit e così via, non capisco il senso logico,perché non si potrebbe fare.

---

Tutti i file normali sono sequenze di ottetti (byte).

Ciao scusa per il ritardo.
Non si possono prevedere i risultati in virgola mobile.

Vuoi creare un algoritmo per superare ogni limite?
Ho tale algoritmo su carta, se ritieni di perderci un pò di tempo.

I GiB-2 anche se sbagliati concettualmente, rendono un idea più semplice di n elevato a n meno n, per utenti con poca dimestichezza con la programmazione.
Grazie per la tua espansione di tutto.
Non ho ancora capito come inserire i bit in php, codice perfavore. vorrei creare un'algoritmo di compressione.

Citazione:

---

Originalmente inviato da darbula

Non ho ancora capito come inserire i bit in php, codice perfavore. vorrei creare un'algoritmo di compressione.

---

Cioè?

Codice PHP:

---

$i = 1; //00000001
$i = 5; //00000101
//etc etc...


---

Ciao!

None, propio i bit.

Codice PHP:

---

<?php
$var='AAAAAAAA';//01000001 per otto volte
$var2='BBBBBBBB';//01000010 per otto volte
$var3='CCCCCCCC';//01000011 per otto volte
$var4='DDDDDDDD';//01000100
$var5='EEEEEEEE';//01000101
//compressione
$var=;//0 come bit
$var2=;//1 come bit
$var3=;//00 come bit
$var4=;//01 come bit
$var5=;//10 come bit
?>

---

grazie comunque.

Codice PHP:

---

$var=0;//0 come bit
$var2=1;//1 come bit
$var3=0;//00 come bit
$var4=1;//01 come bit
$var5=2;//10 come bit
?>


---

Cioè, che differenza c'é tra 0 e 00? Volendo, puoi forzarli a zero con una and, del tipo:

Codice PHP:

---

$var &= ~1;//0
$var3 &= ~3;//00


---

Altrimenti, non sto capendo la richiesta.



Ciao!

ehm, non è facile spiegare qualcosa che ancora non esiste (l'algoritmo di compressione).
tra 0 e 00, c'è un overflow..
ad esempio la rappresentazione di un binario ad otto bit è (da 00000000 a 11111111) in decimale da 0 a 255, la massima compressione con perdita (non di dati, ma impossibile da decomprimere), sarà 2^1 +2^2+2^3+2^4+2^5+2^6+2^7+2^8-254=256bit su un file di 256B da 00000000 a 11111111 binario.
si è solo spiegato la massima compressione,per dare una risposta a alemoppo, non l'algoritmo che adottero.
Grazie.