Unire file video su linux

(No Ratings Yet)

 Loading ...

Posted by raphe | Filed under Appunti, Linux

Se vi è capitato di ritrovarvi con il classico video lungo spezzettato in più file del tipo NOMEFILE.avi.001, NOMEFILE.avi.002 e così via, allora questo piccolo trucchetto potrà risultarvi utile.

Per concatenare i file video non necessitiamo di utilizzare software di elaborazione video ma basta la vecchia, cara e potente shell. Il seguente comando è quello che fa per voi:

cat NOMEFILE.avi* > FILEUNICO.avi

Il potente comando cat non farà altro che leggere a basso livello i diversi file e redirigere l’output in un altro file da noi scelto. Ovviamente al posto di NOMEFILE.avi dovrete mettere l’inizio del nome dei vostri file. Alcune cose da ricordarvi:

• i file dovranno avere un prefisso in comune (per poter utilizzare ‘*’ correttamente) e poi un numero incrementale che li ordini;
• i file devono appartenere allo stesso file originale ed avere, ovviamente, stesso framerate, risoluzione, codec, ecc.

In generale, ricordatevi, che potete unire file di ogni tipo con cat in questo modo:

cat NOMEFILE_1, NOMEFILE_2, NOMEFILE_N > FILEUNICO

Il risultato dipende da quello che state cercando di unire

Tags: Appunti > avi > cat > concatenare > Linux > shell > tips > unire > video

Caratteri speciali & codifiche su php, mysql e javascript: la soluzione definitiva

(1 votes, average: 5,00 out of 5)

 Loading ...

Posted by raphe | Filed under Appunti, Programming

Il titolo del post è un po’ caotico ma non avevo idea di come scrivere qualcosa di più esplicativo.
Come per i post relativi alle sessioni, anche questo post ha l’obiettivo di essere un appunto per me per il futuro e un riepilogo di cose conoscenze acquisite nel tempo.

Dimentichiamoci delle funzioni htmlspecialchars, htmlentities, html_entity_decode, addslashes, escape, encodeURI, ecc…con una buona configurazione dei vari componenti potremo lavorare in modo trasparente!

Un po’ di teoria

La questione “caratteri speciali” è ben nota a chi si trova a sviluppare per il web, in giro per la rete ci sono centinaia di blog, forum e siti che suggeriscono modi per mostrare al meglio i caratteri accentati e ogni tipo di entità html. La difficoltà sta quasi sempre nell’uso di diverse codifiche nei vari componenti coinvolti (linguaggi di programmazione, database, browser, ecc.). Come prima cosa è bene, quindi, decidere all’inizio quale codifica utilizzare e portare avanti questa scelta in tutti i settaggi che verranno fatti in futuro.

UTF-8 è la codifica che andremo ad utilizzare (dato l’elevato numero di caratteri rappresentabili) ma il discorso vale per qualsiasi codifica vogliate usare.

Innanzitutto è bene sapere che anche i linguaggi di programmazione hanno diversi modi di rappresentare e gestire i caratteri speciali. Ne consegue che ad ogni passaggio da db a linguaggio e da linguaggio a browser si debbano fare delle conversioni. A questo proposito esistono numerose funzione di encoding e decoding in php, js, ecc.

Questa operazione è macchinosa e non scalabile (ci si deve ricordare ogni volta di convertire tutti i dati in transito). L’approccio che presenterò in questo post è diverso: utilizziamo i caratteri speciali per come sono senza convertirli in nessun modo utilizzando solo qualche settaggio e molta attenzione.

Passiamo alla pratica

Innanzitutto è bene iniziare con il database. Nel nostro caso stiamo lavorando su mysql quindi ricordiamoci di creare il database sul quale lavoreremo con collation utf8_general_ci (o altri tipi di utf8), di settare lo stesso valore anche per:

• connessione mysql;
• ogni tabella creata;
• ogni campo testuale di ogni tabella.

Dopo questo passo sappiamo per certo che il database è pronto a gestire dati UTF-8.

Ovviamente dovremo ora comunicare con il database. Per questo esempio utilizzerò la libreria PEAR::MDB2 (consiglio a tutti di lavorare con qualche libreria e non a mano, per avere alcuni automatismi e funzionalità aggiuntive). Nel caso di MDB2 dovremo solo ricordarci di settare il charset sulla connessione al db al primo utilizzo, con il seguente metodo:

$mdb2->setCharset(‘utf8′);

Ora sappiamo che ogni comunicazione (lettura e scrittura) con il database avverrà utilizzando utf8.

Fase seguente è l’inserimento dei dati da parte dell’utente. Ovviamente, come detto sopra, se codifichiamo i dati che l’utente inserisce dovremo poi decodificarli ad ogni utilizzo. Noi non lo faremo. Lasciamo inserire all’utente ogni tipo di carattere (àé!’^$%…) e mettiamolo in database “senza toccarlo”, possiamo farlo perché le tabelle e la connessione in utf-8 ce lo permettono.

Fatto questo nel database avremo i caratteri veri e propri e sarà più facile gestire la fase di visualizzazione. Proprio quest’ultima di solito crea problemi di conversione, soprattutto quando si lavora con javascript che codifica i caratteri speciali in modo diverso dalle entità html.

In fase di visualizzazione dovremo assicurarci che le pagine html generate abbiano anche esse la codifica settata ad utf-8 con l’utilizzo del tag meta, in questo modo:

<meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″ />

Il testo estratto dal database sarà quindi mostrato direttamente nella pagina che, usando charset utf-8, mostrerà i caratteri speciali senza problemi.

Lo stesso vale se questi dati vengono passati a funzioni javascript per elaborarli o mostrarli: non sarà necessario nessuna chiamata a funzioni di decodifica perché javascript è in grado di visualizzare i caratteri speciali se passati esplicitamente.

Prima di concludere è  importante dire qualcosa relativa al fatto di lasciare inserire all’utente tutti i caratteri che vuole. Questo potrebbe essere un baco di sicurezza per la possibilità di inserire codice malevolo o tentare sql injection. Dal punto di vista delle injection saremo protetti dalla libreria in uso (perciò dovreste usarne una) che si occuperà di gestire le query in ingresso al meglio con opportuni escape – quando necessari – e uso di altre protezioni. Ciò significa che non dovremo fare l’escape di caratteri potenzialmente pericolosi come apice singolo (‘) o doppio apice (“), né lasciarlo fare ad apache. Un escape di questo tipo richiederebbe, infatti, l’unescape al momento della lettura di tutti dati e non avremmo risolto niente.

Per evitare che apache faccia l’escape automatico settiamo nel file php.ini tutte le direttive relative a magic_quotes a Off. In particolare:

magic_quotes_gpc = Off

A questo punto l’ultima cosa che ci resta da fare è evitare che l’utente inserisca codice malevolo nel database. Questo possiamo realizzarlo tranquillamente con l’utilizzo della funzione strip_tags di php. Ad ogni query di inserimento chiamiamo questa funzione che pulirà il testo dai tag inseriti. In visualizzazione non dovremo fare nulla…che era proprio il nostro obiettivo.

Tags: Appunti > caratteri speciali > codifica > entità > html > javascript > mysql > php > Programming > utf-8

Distruggere sessioni in php

(No Ratings Yet)

 Loading ...

Posted by raphe | Filed under Appunti, Programmi

Come promesso ecco la seconda parte del mio articolo/appunto riguardante le sessioni in php.

Dopo aver inizializzato una sessione e averla usato durante la visita di un utente nel sito è importante permettere il classico logout.

Il metodo che uso di solito è realizzare un file logout.php dove inserisco una serie di istruzioni riguardanti la sessione poi alla fine un redirect alla index del sito.

Ecco un esempio di file logout.php:

require(“session.php”);
session_destroy();
session_unset();
unset($_SESSION);
$_SESSION = null;
header(“Location: index.php”);

Nella prima riga importo il file costruito nel precedente articolo, se non l’avete fatto e state usando le sessioni in modo classico basta sostituire quella riga con un classico session_start().

Dopodiché la chiamata a session_destroy() permette di cancellare i dati associati alla sessione. Però è importante ricordare che questa funzione non cancella le variabili e i cookie! Ecco perché non basta usarla da sola.

Le successive chiamate di session_unset e unset($_SESSION) permettono appunto di cancellare le variabili di sessione. In realtà non è necessario effettuare entrambe (perché fanno la stessa cosa) ma io sono paranoico e mi piace così, anche il $_SESSION=null serve, ancora una volta a ribadire che la sessione deve essere svuotata.

Come abbiamo detto, oltre a cancellare le variabili si dovrebbero cancellare anche i cookie manualmente. Se è stato utilizzato il procedimento descritto nel precedente articolo nella creazione della sessione, la chiamata a session_regenerate_id(true) si occuperà appunto di cancellare anche il cookie (grazie al parametro true), altrimenti basta aggiungere in questo file una chiamata a set_cookie(‘nome_cookie’) senza altri parametri e il cookie verrà cancellato!

Alla fine facciamo un redirect alla pagina iniziale del sito o a qualsiasi altra pagina si voglia far visualizzare dopo il logout.

N.B.: è importante ricordarsi di non utilizzare session_register e session_unregister per settare le variabili in sessioni. Queste due funzioni sono deprecate e funzionano solo se register_globals è attivo (grave falla di sicurezza). Verranno addirittura eliminate in php 6.

Tags: Appunti > logout > php > Programming > sessioni