[php] lange waardes doorgeven in een url

[RSD]

Ik wil een lange waarde doorgeven in een url. Deze heeft bijv de volgende vorm:

&w=1,4,6,3,7,9,6,4,3,65,23, .... ,323,43

Nu mag een url niet langer zijn dan 1024 karakters. Stel nu dat dit wel het geval is, hoe kan ik dan zoiets lamngs doorgeven?

Zelf dacht ik aan serialize icm unserialize. Echter vraag ik me af of dit de juiste methode is en of dit veel reources vreet van php/apache als deze opdracht heel vaak wordt uitgevoerd?

Je zou zeggen dat je zoiets in een cookie/sessie stopt, maar dit is uitgesloten, het moet via de url doorgegeven worden.

[Kuhlie]

Wat is de situaties precies? Al aan een database gedacht: 'lange waarde' in de database, id in de url?

[GlowMouse]

RSD schreef op vrijdag 17 augustus 2007 @ 15:20:
Zelf dacht ik aan serialize icm unserialize.

Serializen zal alleen maar meer tekens verbruiken. Compressie is al beter; met zo'n korte string zal het performanceverschil nihil zijn. Compressie van tekst is erg goed, maar ik weet niet of dat ook opgaat bij zo'n korte string.

[killercow]

misschien kun je de getallen sorteren en dan ipv de id's alleen de verschillen mee sturen?

dus id= 12,4,5,6,7,12,566,
wordt in code: 12,16,21,28,40,706, scheelt je met lange getallen toch behoorlijk.

[Sendy]

killercow schreef op vrijdag 17 augustus 2007 @ 15:37:
misschien kun je de getallen sorteren en dan ipv de id's alleen de verschillen mee sturen?

dus id= 12,4,5,6,7,12,566,
wordt in code: 12,16,21,28,40,706, scheelt je met lange getallen toch behoorlijk.

Ik zie eigenlijk geen enkel verschil Als je dan toch zoiets gaat doen waarom niet meteen een zip-achtig algoritme?

[Spinal]

Niet goed gelezen, sorry

[ Voor 74% gewijzigd door Spinal op 17-08-2007 15:54 ]

[killercow]

Sendy schreef op vrijdag 17 augustus 2007 @ 15:41:
[...]

Ik zie eigenlijk geen enkel verschil Als je dan toch zoiets gaat doen waarom niet meteen een zip-achtig algoritme?

naja, bij getallen die uit meer dan 6 digits bestaan kun je potentieel per getal tot 5 digits besparen.
Als je dat over 100 id's uitsmeert kun je potentieel 80% besparen, afhankelijk van je spreiding.

345600,5,18,2,123

wordt dan:
345600,345605,345623,345625,345645

[ Voor 7% gewijzigd door killercow op 17-08-2007 16:07 ]

[Room42]

killercow schreef op vrijdag 17 augustus 2007 @ 16:04:
[...]

Hmm, das wel creatief!

[ Voor 48% gewijzigd door Room42 op 17-08-2007 16:07 ]

[crisp]

RSD schreef op vrijdag 17 augustus 2007 @ 15:20:
Nu mag een url niet langer zijn dan 1024 karakters.

Er is geen arbitraire limiet voor de lengte van URL's, implementaties hebben echter wel limieten. Huidige browsers kunnen echter tegenwoordig wel meer dan 1024 karakters aan. IE6 gaat tot ongeveer 2080 karakters als ik het goed heb, IE7 zelfs tot ongeveer 4000 en de meeste andere browsers zelfs tot 8000+

[LuCarD]

Eigenlijk zo je dit soort data via post moeten sturen.

Maar goed. andere optie:

- Is het misschen het een idee om de waardes te vertalen naar hex codes?
- Ander heel wild idee Maak een vertaal tabel van mogelijkheden, en sla die op in een database.

Die vertaal tabel zou je met MD5 in combinatie van de lengte van de string kunnen doen. op die manier hoef je maar 32 chars + de lengte van string te versturen.

[GlowMouse]

LuCarD schreef op vrijdag 17 augustus 2007 @ 16:17:
- Ander heel wild idee Maak een vertaal tabel van mogelijkheden, en sla die op in een database.

Als ik het getal 323 zie staan in zijn startpost, en ik ervanuitga dat de getallen oplopend zijn en alle combinaties mogelijk zijn, is dat niet zo'n goed idee (2^323 is vrij groot).

[Crysania]

en via de post meegeven van de variabelen is geen optie?

[RSD]

Nee posten is geen optie.. het moet in de url meegegeven worden.

Het liefst codeer ik de boel op de een of andere manier en decodeer het om de oorspronkelijke waarde te achterhalen... dit moet vrij snel gaan en wienig resorces kosten in het geval het heel vaak gebruikt gaat worden....

base64_encode ofzo zat ik ook aan te denken... maar weet niet of dat wat is.

Als ik bijvoorbeeld 3 variabelen in de url meegeef die allemaal zo een vorm hebben, dan zou ik met base64 encode iets van maximaal 64*3 karakters gebruiken plus een rest van de url toch?

Ik lees net dat base64_encode het ook niet is..

De spreiding zal beginnen bij 10-tallen en oplopen tot misschien maximaal 200-300

[ Voor 10% gewijzigd door RSD op 18-08-2007 08:39 . Reden: Foutje bedankt! ]

[simon]

Kun je er geen cookie van maken ofzo?

[Verwijderd]

RSD schreef op zaterdag 18 augustus 2007 @ 08:34:
Nee posten is geen optie.. het moet in de url meegegeven worden.

Het liefst codeer ik de boel op de een of andere manier en decodeer het om de oorspronkelijke waarde te achterhalen... dit moet vrij snel gaan en wienig resorces kosten in het geval het heel vaak gebruikt gaat worden....

base64_encode ofzo zat ik ook aan te denken... maar weet niet of dat wat is.

Als ik bijvoorbeeld 3 variabelen in de url meegeef die allemaal zo een vorm hebben, dan zou ik met base64 encode iets van maximaal 64*3 karakters gebruiken plus een rest van de url toch?

Ik lees net dat base64_encode het ook niet is..

De spreiding zal beginnen bij 10-tallen en oplopen tot misschien maximaal 200-300

In plaats van je request string om te zetten naar base64 zou je natuurlijk wel je getallen van base 10 kunnen omzetten naar de base van de grootte van de set karakters die niet url geëncode worden (wat vast rond de 64 ligt ). Dat verkleint je set dan met een factor log(nieuwe base) / log(oude base) . In het geval met als oude base base10 dus met een factor log(nieuwe base), ofwel gemiddeld met een factor 1.8, waar de meeste winst te behalen is bij getallen > 9 (base 10). Je zou dit kunnen vergelijken hoe de binaire string representatie van een getal langer is dan de decimale string representatie van een getal. Dit dus (hoewel wel wat implementatie werk) in combinatie met alleen de verschillen in een gesorteerde lijst mee sturen moet je al wat verder brengen.

_{PS: persoonlijk zou ik toch alternatieven gaan overwegen}

[Martinspire]

Ik snap niet dat je zo moeilijk doet.
Maak een tabel aan in MySQL oid en zet daarin 2 velden waarvan 1 een ID en de andere de getallen (gescheiden door comma's of whatever). Dan maak je voor elke keer dat je zulke lange getallen nodig hebt, een verbinding naar de database om ze erin te zetten en je retouneerd de ID. Dan laad je de volgende pagina met die ID, die je dan opzoekt in de database. Zo heb je geen gezeur met een te lange URL en je behoud de mogelijkheid om de getallen door een andere user te laten gebruiken (wat denk ik je bedoeling is?).

Een tekstbestand of cookie ervoor bijhouden kan ook, maar in MySQL kun je denk ik langere tekens kwijt zonder dat het echt dramatische langzamer gaat.

[ Voor 16% gewijzigd door Martinspire op 18-08-2007 13:05 ]

[FragFrog]

Ik vermoed dat die URL ergens anders vandaan komt dan een website, en als hij met die andere applicatie al niet in staat is POST data te bakken betwijfel ik of'ie iets in een database kan doen.

Andere optie is dat'ie vanaf een compleet ander domein dingen door wil gaan pompen, maar dan geldt doorgaans hetzelfde verhaal.

Toch zou ik aan de TS willen vragen waarom hij geen POST / sessie / etc data mee kan sturen. Waar komen de gegevens vandaan, wat roept die URL op, etc?

[Johnny]

Het gaat hier om een lijst met oplopende getallen, de makkelijkste manier om het efficient te comprimeren is het omzetten naar een hogere base en dan de scheidingstekens komma's er uit halen, en alleen een scheidingsteken neerzetten om te markeren wanneer het getal een teken langer wordt.

De lijst '1,3,6,16,36,100,351' zal dan worden gecomprimeerd naar '136Ga,1c5f' waarbij de komma aangeeft dan de eerste getallen 1 karakter hebben, en die daarop volgen uit 2 karakters bestaan enz. Dit simpele voorbeeld geeft al 45% minder tekens!

Met een simpele functie kun je met explode() en substr() de getallen weer terugvertalen.

In dit voorbeeld heb ik 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz als karakters gebruikt om base62 getallen te maken.

Als je dit combineert met de bovengenoemde oplossing om alleen de verschillen door te geven kun je nog meer besparen.

[ Voor 24% gewijzigd door Johnny op 18-08-2007 14:09 ]

[Verwijderd]

Johnny schreef op zaterdag 18 augustus 2007 @ 14:00:
Als je dit combineert met de bovengenoemde oplossing om alleen de verschillen door te geven kun je nog meer besparen.

Los van de base wijzing. Valt het berekenen van de verschillen en het toevoegen van een komma bij verlenging van een getal wel te combineren? De verschillen kunnen immers niet gesorteerd worden.

[ Voor 3% gewijzigd door Verwijderd op 18-08-2007 15:04 ]

[Thralas]

Ben ik nou de eerste die denkt aan pack? Hiermee kun je het VEEL efficienter opslaan dan in ASCII vorm.

• Optimaliseer eerst je source data array. De verschillen opslaan lijkt me een goed idee. Als je het onder 255 weet te houden zou het helemaal voordelig zijn. Als je bv. weet dat je alleen even getallen hebt dan kun je het verschil / 2 opslaan om zo 'grotere' verschillen in een lagere waarde op te slaan.
• Bedenk dan hoe je het 't beste kunt representeren, ik zie iedereen het over ASCII hebben, maar dit is verre van optimaal. Gooi alle cijfers in een array, en gebruik pack om het te packen tot een binary string (van unsigned chars als je het <255 weet te houden, anders als ushort - of een combinatie, maar dan heb je er iets van een struct bij nodig om aan te geven of het volgende getal een short of char is).
• Compress de binary string eventueel met gzcompress/gzdeflate. Geen idee of hier nog winst te behalen valt.
• Omdat binary data in een URL niet zo lekker werkt zul je het waarschijnlijk nog moeten base64 encoden.

[ACM]

Thralas schreef op zaterdag 18 augustus 2007 @ 16:44:
Bedenk dan hoe je het 't beste kunt representeren, ik zie iedereen het over ASCII hebben, maar dit is verre van optimaal.

En dan:

Omdat binary data in een URL niet zo lekker werkt zul je het waarschijnlijk nog moeten base64 encoden.

Waardoor je er effectief weer ASCII van maakt. Het kan dus handig zijn om een efficientere, directere mapping naar URL-safe characters te bedenken dan eerst alles te packen en dat dan omzetten naar ascii. Maar niettemin geef ik je gelijk dat het zinvol kan zijn om integers als binary waarden te behandelen en vervolgens om te zetten.

Een paar "domme algoritmes", hier heb ik 1024 random integers in een array gestopt en daarna gesorteerd:
serialize: 18815
serialize gz b64: 10520
serialize bz2 b64: 8708
implodelist: 10699
implodelist gz b64: 6916
implodelist bz2 b64: 6392
pack_list b64: 5464
pack_list gz b64: 5476
pack_list bz2 b64: 6068

Bij de pack_list-versie zie je mooi de overhead van base64, want die list is zonder b64 precies 4096 bytes lang. Er is vast wel iets efficienters te vinden dan base64, hier missen natuurlijk nog allerlei toegestane characters zoals -_.,?&;= en nog wel wat meer, maar ik had geen zin dat te maken

[ Voor 34% gewijzigd door ACM op 18-08-2007 18:03 ]

[Verwijderd]

Het rekenen in een decimaal stelsel heeft meer karakters nodig dan in het hexadecimaal stelsel. Om het mooi te maken maak je het getallenstelsel met het gehele alphabet erbij [0..9a..z], zodat getal < 36 in 1 byte past, < 1296 in 2 bytes etc.

edit:

Glowmouse ipv anderen te vertellen dat het niet werkt, vertel eens iets wat dan wèl werkt. Maar het werkt dus wel.

En inderdaad, Ik geef een base-36 encoding, wat veel minder efficiënt is dan de voorgetelde coderingen van ACM.

[ Voor 34% gewijzigd door Verwijderd op 19-08-2007 09:20 ]

[Verwijderd]

zend de reeks in 2x?

[Icelus]

Idee om de getallen als Unicode karakters te behandelen en om te zetten naar UTF-8?

Bij 1024 gesorteerde getallen (tussen de 1 en 100.000) krijg ik dan een string van gemiddeld 3.000 karakters; met base64 erbij komt dat op 4.000 bytes/karakters.

Een stap verder is om het verschil tussen twee getallen op te slaan. Dit verschil dan ook als Unicode karakter behandelen en vervolgens omzetten naar UTF-8. Bij 1024 getallen kom ik dan op een string van zo'n 1300 bytes, met base64 wordt dat zo'n 1700 bytes.

[GlowMouse]

Verwijderd schreef op zaterdag 18 augustus 2007 @ 19:11:
Het rekenen in een decimaal stelsel heeft meer karakters nodig dan in het hexadecimaal stelsel. Om het mooi te maken maak je het getallenstelsel met het gehele alphabet erbij [0..9a..z], zodat getal < 36 in 1 byte past, < 1296 in 2 bytes etc.

Hoofdletters erbij doen zou het al iets efficienter maken, maar de aanpak lijkt me niet zo goed. De string 00 kan namelijk zowel twee keer het getal 0 zijn als een keer het getal 36. Je bent dus ook weer bytes kwijt om op te slaan uit hoeveel karakters ieder getal is opgebouwd.

[ACM]

GlowMouse schreef op zondag 19 augustus 2007 @ 00:38:
De string 00 kan namelijk zowel twee keer het getal 0 zijn als een keer het getal 36.

Het getal 00 bestaat in principe niet En als ie wel bestaat is ie hetzelfde als het getal 0, dus zolang je met getallen werkt is er niets aan de hand.

Maar ik snap niet wat jullie beider opmerkingen nog toevoegen, er is al lang voorgesteld om de getallen met base64 te coderen om zo meer data per byte kwijt te kunnen. Terwijl er door jullie over base 36 en base 62 wordt gesproken

We zitten nu vooral te wachten op verdere details van de topicstarter over meer details van zijn probleem, want tot die tijd blijft het vooral speculeren wat de beste optie is Als er bijvoorbeeld sprake is van enkel shorts, dan kan elk getal in 2 bytes gecodeerd worden en vervolgens met base64's 33% overhead voor 1024 getallen uitkomen op 2732 bytes/karakters oid. Als er echter sprake is van een nog kleinere getallenbereik, kan er uiteraard nog minder bits per getal gebruikt worden, etc.
Of als er andere bijzondere eigenschappen aan de datareeks zijn, die het geschikt maken voor datacompressie, kan daar gebruik van gemaakt worden.

[RSD]

Ik zie dus dat er niet een eenduidige manier is om dit het beste te doen. Dat is jammer.

De getallen die in de url staan slaan op het id van een categorie. Deze komen uit een database.

Ik wil dat mensen aan de hand van een lijst met categorieen dit zullen er hooguit 300 zijn een url kunnen samenstellen waarmee ze zelf een soort van banner kunnen maken die dan de gegevens uit de database weer haalt. Nu kan ik die getallenreeks wel in een database opslaan, maar als er veel wordt gegenereerd dan staat die database binnen notime vol met eventueel ook veel ongebruikte reeksen, dit lijkt me dus niet echt wat.

Het verschil opslaan lijkt me nog het beste, maar dan wel het verschil met de vorige en niet het eerste element.

Bij sommige banners komen er soms wel drie variabelen die uit een reeks bestaan.

[ Voor 80% gewijzigd door RSD op 19-08-2007 09:33 ]

[Verwijderd]

Ach bedenk mijzelf net, het decimale stelsel (en je scheidingsteken) bestaan in totaal uit maar 11 karakters. Huffman coding is een leuke methode om karakters in 1..n=11 bits te stoppen.

[RSD]

Dat is idd een leuke encoding, maar daar zit een flink stuk wiskunde achter, heb dat allemaal wel gehad, alleen dat is alweer zo lang geleden

Als ik het zo bekijk moet je bij deze methode het volgende doen.

Je telt eerst het aantal keer dat een bepaald karakter voor komt, dus:

0 komt a keer voor => a / 11 = ...
1 komt b keer voor => b / 11 = ...
2 komt c keer voor => c / 11 = ...
....
9 komt j keer voor => j / 11 = ...
, komt x keer voor => x / 11 = ...
------------------------------------------------------ +
= 1

Als je dit geteld hebt ga je die tree maken en kijk je bij elke node welke getallen erin voorkomen. Eerst moeten die karakters nog in binary format geschreven worden denk ik, dan moet je die tree maken en dan ???

[ACM]

Huffman gaat niet enkel over losse karakters hoor. Het idee is juist meer dat je zo lang mogelijke groepen tekens tot een zo kort mogelijke nieuwe reeks weet om te vormen, maar dan wel zo dat je uiteindelijk natuurlijk winst maakt in lengte. Je oud-naar-nieuw mapping heet dan de dictionary. Als je die dictionary echter al weet aan beide zijden kan je er aardige winsten mee maken omdat je die niet hoeft mee te sturen in je url.
Maar dat is dus alleen bruikbaar als je een vooraf bekend bereik van getallen hebt en je daar ook al van weet welke (ruwweg) het meest gaan voorkomen. Anders kan je waarschijnlijk net zo goed gewoon gzip of bzip2 loslaten op je string, dat scheelt je weer van alles zelf implementeren.

[Kuhlie]

300 categorieen? Dus eigenlijk 300 bits: de categorie wordt gebruikt, of niet. Maak dan gewoon een bitrij. Dat maakt 300/8 =~ 38 bytes, die je makkelijk kunt urlencoden om zo op maximaal 3x38=114 tekens uit te komen.

Edit: of base64, dan zit je zelfs op slechts 57 bytes. Op die manier gaat het 'goed' tot zo'n 900 base64bytes = 600 echte bytes = 4800 categorieen.

Edit2: ik nam 900 omdat je in de url zelf ook al wat van de beschikbare 1024 (of blijkbaar meer) bytes gebruikt.

[ Voor 38% gewijzigd door Kuhlie op 19-08-2007 10:46 ]

[RSD]

Dat kan ook idd, maar als er categorieen bijkomen, dan volstaat die niet meer, jah dan zou je ze als niet bestaand kunnen bestempelen.

[GlowMouse]

Met 300 categorieën is de verschilrij doorsturen al voldoende. Nooit ben je dan meer dan 599 karakters kwijt (aannemende dat er tussen de id's geen grote gaten zitten).

[ Voor 62% gewijzigd door GlowMouse op 19-08-2007 11:34 ]

[harp00n]

ik zoek zelf ook iets om decimale getallen (van binaire naar decimaal, dus kleiner dan 256) om te zetten naar ascii tekens... probleem is dat ik ascii niet kan gebruiken...

daarvoor had ik iets "bedacht" maar nog niet helemaal goed uitgewerkt (ik weet niet zeker of dit werkt voor een url, maar wel voor mijn doel)...

je maakt een array bestaande uit [a-zA-Z ()[]<>/|\*-+=.,:;?!@#$%^&_~`] die array gebruik je dus om decimale getallen te veranderen..
vb:
0=a
1=b
...
79=`

stel je voor dat je 80 wil doen... op dat moment begin je de array gewoon opnieuw... met:
80=1a
81=1b
...
160=1`

op deze manier kan je besparen op alle komma's tussen de waarden (want je kijkt of huidige teken een is_int is, op dat moment moet hij gaan rekenen) en je hebt een grote besparing want je kan met 9` al 0 t/m 720 bestrijken (ongeveer)...

is dit efficient of zijn er betere manieren? ik zoek namelijk zelf ook nog wat en dit is wat ik tot nu toe gevonden heb wat volgens mij wel redelijk efficient is (qua compressie)...

[FragFrog]

RSD schreef op zondag 19 augustus 2007 @ 09:26:
Ik wil dat mensen aan de hand van een lijst met categorieen dit zullen er hooguit 300 zijn een url kunnen samenstellen waarmee ze zelf een soort van banner kunnen maken die dan de gegevens uit de database weer haalt. Nu kan ik die getallenreeks wel in een database opslaan, maar als er veel wordt gegenereerd dan staat die database binnen notime vol met eventueel ook veel ongebruikte reeksen, dit lijkt me dus niet echt wat.

Je beseft dat bijvoorbeeld Google Analytics ook gewoon werkt met een ID wat meegestuurd wordt? Tenzij jou bannersysteem groter gaat worden dan Google Analytics lijkt het me dan veilig te stellen dat je database echt niet zomaar vol gaat staan

Keuze is natuurlijk helemaal voor jezelf maar ik zou als ik jou was toch echt overwegen met een ID te gaan werken. Op die manier kunnen mensen tenminste ook een nieuwe catagorie toevoegen of verwijderen zonder dat ze eerst hun hele bannercode moeten aanpassen. Om nog maar te zwijgen over het feit dat op veel lokaties (zoals bijvoorbeeld signatures op fora) je maar een beperkt aantal tekens beschikbaar hebt

Voor MMOlist heb ik trouwens eenzelfde systeem geschreven, mensen kunnen een plaatje includen met de status van hun server (online / offline) die uit de database gehaald wordt, dat wordt een ~5000 keer per dag gedaan zonder noemenswaardige load. Als je een koppelingstabel maakt met smallints en een index op ID hoort dat echt geen probleem te zijn en desnoods maak je een array field aan voor je ID's zodat elke keer maar 1 record uit de database gehaald moet worden - then again, met een koppelingstabel kun je vrij simpel met 1 subquery zowel de catagorieen ophalen als een catagorie eruit pakken om weer te geven. Ik vraag me eigenlijk af of je dan nog uberhaupt performanceverschil ziet met een decodingalgoritme en vervolgens een select op een of meer van die waardes.

[ Voor 24% gewijzigd door FragFrog op 19-08-2007 16:07 ]