2011-03-01 6 views
7

Qualcuno sa quale sarebbe il "corretto" tipo di mime per i file di patch? Ho usato application/octet-stream perché non vedo nulla di meglio a iana.org. L'applicazione/octet-stream è corretta o c'è qualcos'altro che si adatta meglio? Perché non esiste un tipo di "applicazione/patch"?Corretto tipo mime per file di patch

Ovviamente, una possibile risposta è 'text/plain', ma ho visto molti file di patch che includono dati che non sono puramente di testo. Il testo/testo è la scelta migliore se sai per certo che tutto il contenuto è di testo, o è meglio essere coerenti su tutti i file di patch?

Devo dire che il contesto su cui sto principalmente pensando è impostare mime-type come indizio di sovversione sulla gestione delle terminazioni di riga (svn: mime-type e svn: eol-style). Il problema è che un file di patch può applicare una patch a entrambi i file che usano sia nativo in stile eol che non nativo, il che può portare a stranezze di fine linea quando si applica una patch dopo il checkout.

risposta

7

Non ho trovato nemmeno una versione autorevole. Ecco alcune altre possibilità:

  • text/x-diff
  • text/x-patch
  • application/x-patch

Per quel che vale, Trac (un tracker biglietto con un buon supporto svn) utilizza text/x-patch per diff, e git.kernel.org utilizza text/plain .

0

Sono curioso del motivo per cui si stanno verificando i file patch su SVN. A parte questo, vorrei dire che se hai la possibilità di controllare i file di patch binari per usare application/octet-stream. Non sono sicuro di cosa succederebbe se li mescolassi ... testo per testo, ottetto per binario ... che potrebbe anche essere possibile?

+2

I file di patch sono comunemente usati in RPM per prodotti open source. È un modo agnostico SCM per mantenere le modifiche locali discrete dalla sorgente upstream. Controllo un buon numero di quelli. –

+0

È facile mantenere le patch dei file di testo separati dalle patch ai file binari per le patch create dall'utente. In effetti non creo mai patch con parti binarie. Ma altri li creano a volte. E se li stai gestendo, sembra che non dovresti fare un'analisi del contenuto reale di un file per scoprire se hai bisogno di text/plain (?) O application/octet-stream. Ecco perché penso che l'applicazione/patch abbia un senso. Un file di patch può essere un mix di testo e binario con requisiti di traduzione EOL speciali. Forse i file di patch dovrebbero includere un descrittore di tipo mime per ciascuno dei loro componenti? –

0

Se la patch contiene solo testo, preferisco text/plain su text/x-patch o text/x-diff. IMO, text/x-patch o -diff è più adatto a questo scopo ed è consigliato da some projects, ma il motivo principale per text/plain è la compatibilità.

In Gmail se l'allegato è text/plain, quando si fa clic su esso verrà automaticamente visualizzata un'anteprima del documento; ma non lo sarà per text/x-patch o text/x-diff. Un altro esempio è l'interfaccia di archivio di Mailman (un popolare software di gestione della mailing list): shows the text con text/plain, ma does not con text/x-patch.

Se la tua patch contiene dati binari, vorrei usare application/octet-stream, non perché sia ​​corretto, ma ti farà risparmiare qualche problema dalle terminazioni di linea.