2010-03-16 18 views
14

Ho bisogno di analizzare una rappresentazione stringa RFC 2822 di una data in Java. Una stringa di esempio è qui:Analisi della data RFC 2822 in JAVA

Sab 13 Mar 2010 11:29:05 -0800

Sembra piuttosto brutto così ho voluto fare in modo che stavo facendo tutto bene e avrei incontrato strano problemi più tardi con la data che viene interpretata erroneamente tramite AM-PM/Problemi di orario militare, problemi di orario UTC, problemi che non prevedo, ecc ...

Grazie!

+3

Hai provato a utilizzare 'java.text.SimpleDateFormat'? – skaffman

+0

Sembra che sia quello giusto da usare, ero preoccupato anche di cosa fosse la stringa di formato corretta, sembrava qualcosa che sarebbe stato facile rovinare. Questa sembra essere la stringa giusta per RFC 2822 però: "EEE, d MMM yyyy HH: mm: ss Z" (come da risposta sotto) –

+1

non 'd' ma' dd'. –

risposta

19

Questo è un codice rapido che fa quello che si chiede (utilizzando SimpleDateFormat)

String rfcDate = "Sat, 13 Mar 2010 11:29:05 -0800"; 
String pattern = "EEE, dd MMM yyyy HH:mm:ss Z"; 
SimpleDateFormat format = new SimpleDateFormat(pattern); 
Date javaDate = format.parse(rfcDate); 

//Done. 

PS. Non ho trattato eccezioni e concomitanza qui (dato che SimpleDateFormat non è sincronizzato quando si analizza la data).

+0

utilizzare questo collegamento http://docs.oracle.com/javase/8/docs/api/java/text/SimpleDateFormat.html per gli ultimi valori accettabili – rajadilipkolli

19

Se l'applicazione utilizza una lingua diversa dall'inglese, si consiglia di forzare il locale per la data parsing/formattazione utilizzando un supplente SimpleDateFormat costruttore:

String pattern = "EEE, dd MMM yyyy HH:mm:ss Z"; 
SimpleDateFormat format = new SimpleDateFormat(pattern, Locale.ENGLISH); 
+4

L'impostazione delle impostazioni internazionali è obbligatoria. Android javadoc per Locale suggerisce l'utilizzo di Locale.US per la comunicazione da computer a computer. [collegamento] (https://developer.android.com/reference/java/util/Locale.html) –

+0

+1 Locale.ROOT sarebbe anche una buona scelta, ma non è disponibile su tutti i sistemi. – Jules

+0

@jasongilbert Puoi spiegare perché dici che l'impostazione "è sicuramente necessaria"? Secondo i documenti, non lo è: http://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html - ma forse intendevi "richiesto se ..." ed è la continuazione del "se" che mi interessa ... –

4

Si prega di tenere presente che la [giorno- of-week ","] è facoltativo in RFC-2822, quindi gli esempi suggeriti non coprono tutti i formati di data RFC-2822. Inoltre, il tipo di data RFC-822 consentiva molte diverse notazioni relative al fuso orario (zona obs), che non sono coperte dall'identificatore di formato "Z".

Immagino che non ci sia una via d'uscita facile, oltre a cercare "," e "- | +" per determinare quale modello utilizzare.

+1

+1 per indicare che il giorno della settimana è facoltativo. Sto impostando una cascata di try/catch con vari pattern per continuare a provare le varianti finché non ne trova una che funzioni. –

+0

non solo il 'giorno della settimana' è facoltativo, anche i secondi nell'ora sono dichiarati come facoltativi:' ora del giorno = ora ":" minuto [":" secondo] ' –