Skip to main content

Aprire, leggere o visualizzare i file Winmail.DAT

Se state leggendo questo articolo è probabile che abbiate ricevuto un messaggio contenente un file winmail.dat come allegato. Non si tratta di un virus o di un contenuto pericoloso bensì di un particolare tipo di file di scambio generato da Microsoft Outlook in un formato proprietario, il cosiddetto TNEF (Transport-Neutral Encapsulation Format), molto utilizzato dal software in tecnologia Microsoft appartenente alla grande famiglia che orbita attorno a Exchange (Outlook, SharePoint, etc.) per veicolare file, note e meta-dati di vario tipo in allegato a un qualsiasi messaggio di posta.

Per poter visualizzare questo tipo di file al di fuori dell’ecosistema suddetto è necessario far ricorso ad alcuni software esterni, tra cui raccomandiamo:

L’utilizzo di entrambi i software è estremamente semplice, è sufficiente installarli per poter aprire i file winmail.dat come un qualsiasi altro archivio (zip, rar etc).

Se utilizzate Mozilla Thunderbird potete ricorrere a una soluzione ancora più pratica installando il componente aggiuntivo LookOut+ di Attila K. Mergl, evoluzione del quasi-identico (e non più aggiornato) LookOut originariamente sviluppato da Aron Rubin: il componente, una volta attivato, mostra automaticamente il contenuto del file winmail.dat eventualmente presente in allegato a ciascuno dei vostri messaggi.

Se invece utilizzate Outlook e volete evitare che i vostri allegati vengano incapsulati all’interno di un winmail.dat, potete scoprire come fare leggendo questo articolo.

Alla prossima!

Gestire le GitHub Pages con Mercurial e TortoiseHG

Abbiamo già visto in un precedente articolo come sia possibile creare, pubblicare e gestire un repository su github.com senza bisogno di installare Git, avvalendosi unicamente di MercurialTortoiseHG. In questo articolo spiegheremo come sia possibile utilizzare lo stesso metodo per impostare branch aggiuntivi, come ad esempio il branch gh-pages mediante il quale GitHub consente di pubblicare le cosiddette project pages.

GitHub Pages: cosa sono e a cosa servono

Come spiega il sito, le GitHub pages non sono altro che pagine web ospitate sui server di GitHub. Si dividono in due tipologie:

  • User & Organization Pages: si tratta di pagine legate al nostro account GitHub. Per crearle è sufficiente creare un repository con un nome particolare legato al nostro account. La sintassi da seguire è la seguente:  <username>.github.io  , dove al posto di <username> andrà inserito il nome corrispondente al proprio account GitHub. Una volta creato sarà possibile aggiungere una o più pagine web (e relativi css, js, immagini etc.) che diventeranno immediatamente accessibili all’indirizzo:  http(s)://<username>.github.io .  Queste pagine sono solitamente utilizzate per creare un mini sito web relativo al proprio account GitHub: presentazione e informazioni sullo sviluppatore, portfolio, mission del team di sviluppo, etc.
  • Project Pages: si tratta di pagine legate a un progetto specifico pubblicato su GitHub. Possono essere create manualmente utilizzando gli appositi comandi Git oppure automaticamente utilizzando il software di generazione automatico messo a disposizione da GitHub. In entrambi i casi verrà aggiunto un branch apposito, denominato gh-pages, dove sarà possibile aggiungere una o più pagine web alle quali si potrà accedere mediante l’indirizzo: http(s)://<username>.github.io/<projectname> . Queste pagine sono solitamente utilizzate per creare un sito web relativo al proprio progetto: descrizione, istruzioni per l’uso, esempi, demo, documentazione, API, etc.

Poiché le User & Organization Pages utilizzano il branch master del repository a loro dedicato, per gestirle è sufficiente fare riferimento all’articolo pubblicato in precedenza, che illustra appunto come gestire un repository Git tramite Mercurial. Nel caso delle Project Pages la questione è resa leggermente più complicata dal fatto che dobbiamo creare un branch apposito: vediamo come.

Approfondisci

Utilizzare GitHub con Mercurial e TortoiseHG

Introduzione

Non esiste sviluppatore degno di questo nome che non conosca GitHub, il popolare servizio di hosting di progetti software basato su tecnologia Git. Nel remoto caso in cui non ne abbiate mai sentito parlare vi consigliamo di recuperare le apposite voci di wikipedia relative rispettivamente a GitHub e a Git e i relativi siti ufficiali github.comgit-scm.com.

In caso contrario, continuate a leggere: saprete infatti fin troppo bene che l’utilizzo del servizio GitHub è convenzionalmente vincolato all’adozione di Git, un sistema di controllo di versione (source-control manager o SCM) particolarmente innovativo che in questi ultimi anni ha avuto – anche grazie alla popolarità dello stesso GitHub – una grandissima affermazione, soppiantando gli antichi e gloriosi standard open-source come CVS e SVN grazie ad un’architettura più moderna e basata su un sistema di versioning distribuito piuttosto che centralizzato.

Grazie a queste caratteristiche innovative oggi Git è senza ombra di dubbio il SCM più utilizzato da tutta la comunità Linux – non per niente è stato ideato da un certo Linus Torvalds. Ha avuto però certamente minore fortuna in ambiente Windows, per via di due principali motivi:

  • una tardiva diffusione delle principali interfacce grafiche di gestione – msysgit e TortoiseGit su tutte – particolarmente care agli utenti Windows, per loro natura meno avvezzi all’uso della command-line.
  • la quasi-contemporanea diffusione di Mercurial (noto anche come HG), un SCM distribuito dalle caratteristiche innovative simili a quelle di Git e caratterizzato da un maggiore supporto a livello applicativo per il sistema operativo di casa Microsoft.

Ad influire notevolmente sulla diffusione di Mercurial in ambiente windows è stato, nel 2008, il lancio del sito bitbucket.org, interamente basato su Mercurial (fino al 2011, anno in cui è stato integrato anche Git) e avente caratteristiche in tutto e per tutto simili a quelle offerte da GitHub.

Non è mia intenzione addentrarmi ulteriormente sull’argomento, né dire la mia su quale sia effettivamente il SCM e/o il sito migliore: personalmente, da affezionato utilizzatore di entrambi, ritengo che siano due ottimi prodotti e che – al di là della diversa filosofia di approccio – garantiscano allo sviluppatore funzionalità grossomodo analoghe per la quasi totalità degli utilizzi comuni.

Per una analisi approfondita delle somiglianze e differenze tra Git e Mercurial consiglio di leggere questi due ottimi (seppur datati) articoli. Il primo ha un approccio più tecnico e schematico, il secondo adotta invece un registro più ironico e discorsivo: scegliete quello che più vi ispira, allo stesso modo con cui spesso si finisce per scegliere l’SCM da utilizzare.

Approfondisci

Close