IPv4 adres compressor

dus als ik het goed begrijp, worden hiermee simpelweg de punten uit een ip adres gehaald? Mocht dat zo zijn, hoe weet je dan later waar je die punten terug moet zetten? Een ipv4 adres heeft toch niet altijd 12 tekens?

Hij haalt de punt weg, en van de drie cijfers maakt hij one-character string containing the character specified by ascii . (Klik).
Dan krijgt hij dus een string met vier tekens, die hij dan later 1 voor 1 weer terug kan zetten en effe een punt moet tussen zetten.

En dit is nuttig omdat? Wat heb je nu aan een ip-adres zonder punten, 192.168.1.1 kan ook worden 192.16.81.1 of 192.16.8.11 (niet dat dit mogelijk ivm subnetting, maar even als voorbeeld)

@toby hinloopen
Is dit niet veel makkelijker als substr?

@Jurgen en Nils
Als jullie nu eerst eens goed naar de code kijken(misschien ook even testen), en de functies die er gebruikt worden even opzoeken in de PHP-handleiding. Dan wordt het vast duidelijker.

maak er nog even een controle op of het ip-address wel . bevat. Mijn localhost geeft bij remote addr bijv ::1 terug..

http://[::1]/ is bij mij een geldig adres.

beetje overbodig die functies, want je kan ook gewoon ip2long( $ip ); gebruiken en dan opslaan als INT (4 bytes) in MySQL.

+ dan kan je nog 'hogere' en 'lagere' ip bewerkingen op uitvoeren, bv. ip range check

Tis toch wel de besparing van 15 bytes naar 4 bytes per adres! Dat is dus 11 bytes verschil. Zo rond de 1000 adressen zit je dan al op maarliefst een besparing van rond de 1 kilobytes.

Daarnaast zie ik meer in globaal ondersteunde functies als ip2long ipv dit

Servers hebben tegenwoordig tussen de 4 en 32 GB geheugen dus het voegt niet veel toe, maar toch wel leuk om een snippet te zien die wat bytes bespaart.

Ben het er mee eens dat het een leuke snippet is, maar databases hebben zelf ondersteuning hiervoor zoals reeds gezegd. MySQL heeft een functie, echte databases hebben een datatype. Dat scheelt niet alleen opslagruimte maar ook snelheid. En ik zie verder niet in waarom je dit buiten je database zou willen gebruiken. Conclusie is dus dat het script eigenlijk volledig nutteloos is als je het zo bekijkt. Stel je slaat het wel zo op in je database dan verpest je eigenlijk ook het nut van je database aangezien je gecomprimeerd data gaat opslaan waar je op wil kunnen query'en zonder afhankelijk te zijn van een applicatie. En voor die onafhankelijkheid zal je dan een functie in je database moeten maken, terwijl die al bestaat.

M.a.w. leuk snippet maar ik vind het niet verstandig om te gebruiken.

Leuk en nutteloos. Ik kende de functie chr() niet. Nu wel.

Haha je durft het nutteloos te noemen zonder onderbouwing terwijl je de basisfunctie chr() niet kent? Dat is wel heel makkelijk en niet echt geloofwaardig hè.

@PHPerik

Wat is het nut er dan van?

Zie mijn vorige reply.

Er zit zelfs een voorbeeld bij, nog steeds snappen ze niet. :P

Deze functie veranderd alle 4e getallen in 1 teken en verwijderd de punt.

1 teken kost 8 bits, er zijn dus 2^8 = 256 tekens in totaal.

Heel toevallig gaat een IPv4 getal ook van 0 tot 255: 256 opties dus.

Als het 1e getal '192' is, dan zal deze omgezet worden in teken nummer 192.
De punten worden genegeerd en dus verwijderd.

Er worden dus 4 8bits tekens teruggestuurd door deze functie.

Bij decoderen leest ie de 4 tekens in.

Hij bepaalt voor ieder teken de teken nummer en return-t deze met een . tussen ieder getal.

Nut van de functie?
wees creatief, bijv. bij een zelfgemaakte text-files database o.i.d. kan je op deze manier dus de IPs verwerken.

Kijk maar wat je ermee doet :P

@ terence: dit is een IPv4 encoder en decoder, controle of het écht een IPv4 adres is zit er dus niet bij, dat zal je zelf moeten maken.

Weinig dus, gezien de functies ip2long en long2ip in PHP al sinds jaar en dag bestaan. Daar kun je ook mee rekenen, en zijn een stuk handiger dan dit.

@toby hinloopen: zie mijn vorig post ..

Ik vind het wel een leuke aanwinst! het is idd handig om zo van een xxx.xxx.xxx.xxx notatie een 4 letterige notatie te maken, scheelt idd een berg op een hoop IP adressen in een text bestand.

Het mag dan wel simpel zijn maar ik heb er nog niet eerder aangedacht (ook nooit de behoefte gehad het nodig te zijn)

@ericbruggema: Ja idd, voor opslag in een textfile is dit zeker handig! Maar zoals de maker het script bedoelde, voor in een DB, is dit nutteloos vergeleken met ip2long

@hipska:
was een voorbeeld, dacht ik eigenlijk niet echt bij na :P
ik had dit scriptje gemaakt na een discussie met iemand, niet in praktijk gebruikt.

Discussie was dat een IPv4 adres niet kleiner kon: dus wel :P
als 'bewijs' had ik dit scriptje gemaakt.

Zette em maar ook hier neer en als voorbeeld de (MySQL) database.
Bij MySQL is ie waarschijnlijk nutteloos: er schijnt een functie in MySQL te zitten (wist ik veel :P), maar dan nog is ie bij TEXT/XML database o.i.d. wel handig.

PHP - ip2long, long2ip
MySQL - inet_aton , inet_ntoa

:)

Ah tof dat MySQL die functies ingebakken heeft..

PostgreSQL gaat daar nog een stap verder in. Waar je bij MySQL nog steeds de gegevens opslaat als unsigned int, kan je in PostgreSQL ze opslaan in het type INET. Scheelt weer even wat berekenwerk en complexere query's door de omrekening.

Mysql kan dan ook alleen maar IPv4 aan op het moment. IPv6 heeft geen enkel support. PgSQL heeft met beide geen problemen, maar zoals gezegd die werkt heel anders met dergelijke data.

heb nu ook voor binair toegevoegd. Heb overigens die ingebouwde functie in MySQL niet gevonden :P
maakt op zich voor mij ook niet uit. Kleiner dan 32bits kan je dat IP niet krijgen en ik doe niks anders dan simpelweg opslaan en daarna weer ophalen.