Interazione PHP e Javascript

[andr3a]

allora, ho implementato la prototype alla serializer per il multibyte in serializzazione ... problemino ... come caspita faccio a tornare indietro in JS ? ... cioè, perdo la possibilità di serializzare e deserializzare nel solo JS senza passare per il PHP
(utilità ? .... i cookie, per esempio ... forms, gets o altro)


come faccio a trovare una stringa senza avere più a length reale dellastringa ?

... e poi, se non c'e' il multibytes ??? .. che php va bene e solo JS diventa uno schifo ?

[skidx]

Originariamente inviato da daniele_dll
posso dirla una cavolata ......

ma xche allora non lavorate SOLAMENTE in utf8 e basta?

Infatti sarebbe l'ideale, è la codifica migliore per il Web nell'ipotesi di aver a che fare con le lingue straniere (quasi sempre).
Il PHP ha però quel *piccolo* problema di non supportare le stringhe multibyte nativamente, senza usare estensioni, che complica un po' la vita.

---

l'estensione iconv permette le conversioni tra charset diversi

Sì, ma da quel che ho capito Fabio e andrea avevano pensato a qualcosa che non utilizzasse estensioni, ma solo serialize() / unserialize() lato server.

[skidx]

Originariamente inviato da andr3a
come faccio a trovare una stringa senza avere più a length reale dellastringa ?

Non mi ricordo una cosa, nel formato di serializzazione del php la stringa è delimitata solo dalla sua lunghezza (dal numero di byte quindi) o anche, che ne so, da apici o doppi apici?

In questo secondo caso, nella deserializzazione javascript, non si può prelevare la stringa tra apici ignorando il numero di lunghezza in byte passato dal php?

[andr3a]

Originariamente inviato da skidx
Non mi ricordo una cosa, nel formato di serializzazione del php la stringa è delimitata solo dalla sua lunghezza (dal numero di byte quindi) o anche, che ne so, da apici o doppi apici?

In questo secondo caso, nella deserializzazione javascript, non si può prelevare la stringa tra apici ignorando il numero di lunghezza in byte passato dal php?

no, la stringa è così


$test = 'stringa"di";s:0:"";';
echo serialize($test);
s:19:"stringa"di";s:0:"";";
zero slash ... una miriade di problemi senza il numero di riferimento ...
per assurdo dovrei fare un char by char su ogni stringa deserializzata e vedere s ela length encodata in UTF è uguale al numero trovato e in quel caso troncare quella parte di stringa

[skidx]

Originariamente inviato da andr3a
no, la stringa è così


$test = 'stringa"di";s:0:"";';
echo serialize($test);
s:19:"stringa"di";s:0:"";";
zero slash ...

beh, forse però un addslashes() in più lato server, a livello di prestazioni non costerebbe tanto.
Non avresti particolari problemi lato client perché lo slash, l'apice e le virgolette occupano un byte anche in UTF-8.

[andr3a]

proposta bocciata, serialize non è per la stringa, è per interi array, devo filtrre tutte le stringhe su multidimensionali / oggetti eccetera eccetera ? ... alla faccia del server senza perdita di prestazioni


Allora, ho fatto tutto, seguite il mio filo logico e ditemi se è giusto:


1 - per usare multibytes la classe deve essere istanziata con true o 1 come argomento
var php = new PHP_Serializer(1); // multibyte
var php = new PHP_Serializer(); // normale

2 - la normale non perde prestazioni, la multibyte si ma no so di quanto ... sicuramente di molto su una mole di dati consistente e soprattutto con tante stringhe

3 - se multibytes è abilitato ... JS deve solo encodare in modo compatibile con PHP e non deve mai decodare, poichè la stringa che PHP invierà, con utf8_encode sarà quella giusta, ma con stà dannata dimensione in bytes ... giusto ?
A quel punto mi è sufficiente ricreare quella lunghezza e troncare normalmente, senza badare al numero presente ... è giusto ? non devo mai decodare ? (UTF8.decode) se è così ci siamo quasi ... cioè , è pronta la serialize, però voglio ottimizzare una cosa

[skidx]

ok per l'addslashes, mi ero focalizzato solo sulle stringhe, ovviamente su dati composti farebbe un macello

ferma la premessa che funzionerebbe solo con utf-8 e non con tutte le codifiche multibyte, non ho capito nel punto 3 perché il server dovrebbe usare utf8_encode().

Se stiamo già manipolando dati in un utf-8, non vanno riconvertiti :master: (la funzione utf8_encode non si accorge se sono già in utf-8, infatti fa un troiaio se la applichi due volte di seguito).

Non ho capito come leggi la stringa nella deserialize() javascript.

[andr3a]

uppata, taggata 1.6a con la versione sperimentale della conversione per utf8 ... per chi la usasse già in modo non multibytes ... beh, non ho cambiato niente, se non passate true al costruttore è tutto come prima.

http://www.devpro.it/javascript_id_102.html

fatemi sapere

Originariamente inviato da skidx
Non ho capito come leggi la stringa nella deserialize() javascript.

if(sli > 0) {
	var a = sli > 3 ? this.__m.floor(sli/3) : 1;
	while(a > 0) {
		if(this.encode(this.__s.substr(sls,a++)) === sli) {
			sli = a - 1;
			a = 0;
		}
	}
}

[skidx]

e vabbè, so sega cosa vogliono dire quelle variabili.

In due parole, si può sapere il metodo usato?

sappiamo che il php ti manda questo:
s:22:"ÎÑTËRÑÅTÌÔñÁL"
come fai nel javascript a capire che la stringa è lunga 13 caratteri e non 22?

[andr3a]

Originariamente inviato da skidx
come fai nel javascript a capire che la stringa è lunga 13 caratteri e non 22?

se il numero è maggiore di zero, in questo caso 22, lo divido per 3 (per partire da un intero utile evitando quelli sotto il valore della divisione perchè 1 carattere massimo può essere lungo 3 bytes) quindi faccio il substring incrementale e per ogni stringa ricavata verifico se la length encodata è identica a quella della s, ovvero 22

quando questo accade imposto la variabile della lunghezza stringa su a, che sarà 14 - 1 (quindi 13) e tutto il resto è identico, sposto il puntatore e vado avanti escludendo quindi s:22:"13caratteri"; dalla stringa ... macchinoso, terribilmente rallentante, ma penso il metodo più sicuro , le regexp non mi convincono affatto su questa problematica, le stringhe potrebbero contenere altre stringhe serializzate .... insomma, così stò tranquillo, se il russo c'ha problemi, vediamo cos'altro si può fare