IE toLocaleString ha caratteri strani nei risultati

Ho incontrato una cosa stranissima che apparentemente è specifica per IE in toLocaleString in date.IE toLocaleString ha caratteri strani nei risultati

Nella finestra della console di IE:

new Date("2014-08-28T20:51:09.9190106Z").toLocaleString(); 
"‎8‎/‎28‎/‎2014‎ ‎1‎:‎51‎:‎09‎ ‎PM"

Ora, digitare che stringa manualmente come una stringa e confrontarlo con ciò che il metodo ha restituito:

"8/28/2014 1:51:09 PM" === new Date("2014-08-28T20:51:09.9190106Z").toLocaleString(); 
false

Qualcuno ha qualche idea del perché questo si sta verificando in IE? Questo non si verifica in Chrome.

Aggiornamento: altri esempi:

new Date("8/28/2014 1:51:09 PM") 
[date] Thu Aug 28 2014 13:51:09 GMT-0700 (Pacific Daylight Time)[date] Thu Aug 28 2014 13:51:09 GMT-0700 (Pacific Daylight Time) 

new Date(new Date("2014-08-28T20:51:09.9190106Z").toLocaleString()) 
[date] Invalid Date[date] Invalid Date

fonte

2014-08-29 John Gardner

quale versione di IE? – danwellman

internet explorer 11. –

Vedere [Ted Bicknell's: una data non valida con Internet Explorer 11: problemi con i nuovi caratteri Unicode nelle stringhe di data JavaScript] (https://www.csgpro.com/blog/2016/08/a-bad- data-con-internet-explorer-11-trouble-with-new-unicode-characters-in-javascript-date-string) – KyleMit

primo luogo, un po 'di background: IE11 implementato l'ECMA-402 ECMAScript Internazionalizzazione API che ha ridefinito (nonché toLocaleDateString e toLocaleTimeString) come chiamate a format su Intl.DateTimeFormat. Come tale, d.toLocaleString() è equivalente a

Intl.DateTimeFormat(undefined, { 
    year: 'numeric', 
    month: 'numeric', 
    day: 'numeric', 
    hour: 'numeric', 
    minute: 'numeric', 
    second: 'numeric' 
}).format(d)

Si potrebbe pensare che questo è abbastanza esplicito, ma i browser sono ammessi una grande quantità di margine di manovra quali formati supportano e quali caratteri compongono il formato. Questo è per definizione - con tutti i linguaggi e le lingue in tutto il pianeta, specificare ciò sarebbe alquanto oneroso e molto difficile da tenere aggiornato. Per questo motivo non puoi aspettarti di poter confrontare i risultati di toLocaleString attraverso i browser o aspettare che lo stesso browser continui a fornire lo stesso risultato dal rilascio al rilascio. Man mano che cambiano i dati locali sottostanti (forse perché la personalizzazione locale è cambiata o sono disponibili più dati o vengono aggiunti formati migliori), anche il formato restituito da questa API.

Il takeaway da questo è che si dovrebbe cercare di non fare affidamento sul confronto dell'output delle API toLocaleString con qualche valore statico nell'applicazione. Inoltre, data una data d, Date.parse(d.toLocaleString()) potrebbe funzionare a volte ma non altri a seconda delle impostazioni locali, quindi è meglio evitare anche questo.

Detto ciò, en-US è relativamente stabile e per la maggior parte i browser (per ora) concordano su quale sia il formato di base. Tuttavia, IE inserisce caratteri di controllo bidirezionale attorno alla data. Questo è progettato in modo che il testo di output scorrerà correttamente quando è concatenato con un altro testo. Ciò è particolarmente importante quando si mescolano contenuti LTR e RTL come concatenare una data RTL formattata con testo LTR.

fonte

2014-09-12 17:00:37

che è quello che abbiamo finito, prima di cambiare i nostri test per non dipendere dallo specifico output di 'toLocaleString', e poi usare solo' toLocaleString' nel nostro binding template a eliminazione diretta invece che nel codice stesso, e lasciare gli oggetti data come date effettive nel resto del codice. –

Si scopre non si può vedere loro, ma Date.toLocaleString di IE è apparentemente incluso sinistra a destra marchi in esso (U + 200E):

8<200E>/<200E>21<200E>/2014<200E> <200E> 9<200E>:<200E>16<200E>:<200E>:18<200E> <200E>AM

fantastico. Immagino sia giunto il momento di presentare un bug a IE?

fonte

2014-08-29 19:35:34

IE Team impegnato via email. aggiornerà questo se avrò qualche informazione in più. –

Brian dal team di IE ha aggiunto una risposta più specifica, quindi la mia risposta non è più la migliore risposta :) –

Non vedo questo nel mio IE11, quindi potrebbe essere qualcosa a che fare con le impostazioni/config in IE o la vostra macchina. Per me il risultato è:

"‎28‎/‎08‎/‎2014‎ ‎21‎:‎51‎:‎09" === new Date("2014-08-28T20:51:09.9190106Z").toLocaleString(); true

Forse si copia-incollare la stringa data passata al costruttore da una pagina web?

Non credo che il team di IE lo accetterà come un bug in questa fase perché non ha Repro chiaro passi

fonte

2014-08-30 08:14:18 danwellman

dato dove lavoro, potrebbero accettarlo :) Possiamo riproporlo in unit test in QUnit usando IE, ecc, tutti nella nostra org possono. –

prega di guardare al http://jsbin.com/mehowehase/1/edit?html,js,console

var dt = new Date(); 
var x = dt.toLocaleDateString(); 
console.log("length : "+x.length); 
var arr = x.split("/"); 
console.log("month : "+parseInt(arr[0],10));

Nel sopra la lunghezza x 14 è in IE, ma 9 in altri browser. Questo supporta il commento di John secondo cui IE sta aggiungendo marchi da sinistra a destra. Questo sicuramente mi sembra un insetto.

fonte

2015-11-03 22:35:35 dev

pensiamo che si tratti di un bug, il team IE/Edge è stato quello che ha risposto in precedenza, e "Si potrebbe pensare che questo sia piuttosto esplicito ma ai browser è consentito un ampio margine di manovra con i formati supportati e quali caratteri compongono il format. Questo è in base alla progettazione, con tutti i linguaggi e le lingue in tutto il pianeta, specificando che ciò sarebbe piuttosto oneroso e molto difficile da tenere aggiornato. " –

Usa

Str.replace(/[^ -~]/g,'')

Questo eliminerà i caratteri speciali indesiderati.

fonte

2017-07-05 09:59:26

Questo non è male, ma März è ora Mrz, che in Germania è un nome mese valido – Devid

IE toLocaleString ha caratteri strani nei risultati

risposta

Problemi correlati