Intestazione agente utente – abbreviazione per la memorizzazione di mysql

Secondo questo thread, e specialmente questo post: https://stackoverflow.com/a/6595973/1125465 , Microsoft mostra come sempre. Le size dell'agente utente possono essere davvero enormi.

Sto lavorando su una piccola libreria di visitatori in php e voglio memorizzare le informazioni sugli user agent. Non riesco a decidere il tipo e la lunghezza dei dati.

Quindi la mia domanda è: hai qualche idea, su come abbreviare l'agente utente, ad alcune size "normali"? (ad esempio 256 caratteri) .


Nota: gli sviluppatori utilizzano i programmi utente per rilevare il browser utente e i sisthemes operativi. Quindi, secondo l'esempio collegato, tutti gli stupidi numbers da M $ sono solo … Proprio così. Come sempre, dai nervi. Quindi l'idea è di creare una function che accorcia la string di user agent ma non perda le informazioni importnti.

Penso che una tale function dovrebbe:

  • Non dipende dagli aggiornamenti futuri e dai nuovi browser (nessuna string hardcoded)
  • Avere un semplice meccanismo che decide cosa eliminare (per esempio, se c'è un numero, una virgola, un numero, una virgola, un numero, una virgola, un numero, …, può cancellarlo, non è interessante).
  • Alla fine, se tutte le operazioni risultano ancora in un agente utente troppo lungo (diciamo 256 caratteri), non c'è più nulla da fare, quindi basta tagliare il resto. Questo è uno per milione, quindi i dati possono essere persi.

Nota aggiuntiva: so che posso creare una function che ottiene il browser e il tipo di sistema operativo da un agente utente e salva solo questi valori. Ma come sempre tali funzioni hanno nomi con hardcoded, e se il browser non viene riconosciuto, ad esempio restituisce "Browser non riconosciuto", quindi in futuro tutti devono ricordare di aggiornare queste funzioni e, se si risparmia abbreviare l'agente utente, l'informazione non è 'perso (come solo lo script che sta leggendo il database deve avere un nuovo sistema di riconoscimento), ma le voci nel database sono affidabili e coerenti, come dovrebbe essere.


AGGIORNAMENTO: Poiché ci dovrebbe essere del codice, e c'è un problema con l'idea, e non il problema con il codice esistente, scriverò un codice minimo, che ho scritto finora;):

<?php function shorten($useragent, $maxsize = 256) { $shorten = $useragent; ... // ? $shorten = substr($shorten, 0, $maxsize); // the "last hope" cut return $shorten; } echo shorten($_SERVER['HTTP_USER_AGENT']); ?> 

Non ci sono regole per le stringhe User-Agent, quindi non c'è modo di creare un parser completamente corretto e a prova di futuro. C'è un model generale però:

 User-Agent: <engine-string> <engine-string> ... 

Dove ha la forma del engine-string :

 <agent-name> (<comment>; <comment>; ...) 

Ogni string del motore (l'ho appena detto che, a quanto ho capito, potrebbe non essere corretto) potrebbe o less avere commenti.

Per esempio:

 Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) ↲ AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5376e ↲ Safari/8536.25 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) 

(Questa è una singola string, l'ho appena spezzata in righe.) Sembra che, each volta che qualcuno fa un fork di un motore di ricerca, aggiunga semplicemente la sua cosa alla fine. Quindi abbiamo un browser "Mozilla" astratto (un retaggio della "Prima guerra del browser") che pensa sia su iPhone. Poi vediamo che c'è un WebKit (che ricorda che è nato come KHTML molto tempo fa). Poi c'è qualche modifica Version / 6.0, che è stata poi modificata in Mobile / 10A5376e, che è diventato Safari / 8536.25, che rivela finalmente il segreto che si tratta di un bot Google mobile.

Un altro esempio:

 Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB7.4; ↲ InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; ↲ .NET CLR 3.5.30729; .NET CLR 1.1.4322) 

Questo è un motore singolo, ma ha molto da dire tra parentesi.

Quindi l'osservazione generale è:

  • le ultime stringhe del motore sono le più importnti,
  • gli ultimi commenti in parentesi sono less importnti.

Avendo questo in mente, la mia idea sarebbe quella di analizzare la string in questi motori e commentare i token, quindi da each sezione del motore buttare via i commenti a partire da, diciamo, il quinto. Poi, se non è ancora abbastanza, buttare via le sezioni del motore a partire dal secondo (il primo è spesso un "Mozilla" astratto, ma spesso ha dei commenti utili, anche a volte è in realtà qualcosa di concreto, soprattutto per i web crawler).

Durante l'analisi, dobbiamo tenere presente che occasionalmente potrebbero esserci stringhe che non seguono questo formato. Possono essere salvati in un file di registro per un'ispezione successiva e quindi semplicemente tagliati alla lunghezza necessaria per adattarsi al database.