2014-08-29 14 views
7

Tôi đã chạy vào một điều siêu lạ mà dường như là IE cụ thể trong toLocaleString vào những ngày.IE của toLocaleString có các ký tự lạ trong kết quả

Trong giao diện điều khiển cửa sổ IE:

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

Bây giờ, gõ ra chuỗi bằng tay như là một chuỗi và so sánh nó với những gì phương pháp trả về:

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

Có ai có bất kỳ ý tưởng tại sao điều này đang xảy ra trong IE? Điều này không xảy ra trong Chrome.

Cập nhật: ví dụ khác:

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 
+0

phiên bản IE nào? – danwellman

+0

internet explorer 11. –

+0

Xem [Ted Bicknell's - Một ngày tồi tệ với Internet Explorer 11: Sự cố với các ký tự Unicode mới trong chuỗi ngày Javascript] (https://www.csgpro.com/blog/2016/08/a-bad- date-with-internet-explorer-11-trouble-với-new-unicode-characters-in-javascript-date-strings) – KyleMit

Trả lời

7

Thứ nhất, một chút của nền: IE11 thực hiện các ECMA-402 ECMAScript Quốc tế hóa API đã xác định lại Date.prototype.toLocaleString (cũng như toLocaleDateStringtoLocaleTimeString) làm cuộc gọi đến format trên Intl.DateTimeFormat. Như vậy, d.toLocaleString() tương đương với

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

Bạn có thể nghĩ rằng đây là khá rõ ràng nhưng các trình duyệt đều cho phép một lượng lớn mất nhiều thời gian với những gì các định dạng hỗ trợ họ và những gì nhân vật soạn định dạng. Điều này là do thiết kế - với tất cả các ngôn ngữ và ngôn ngữ trên khắp hành tinh, xác định điều này sẽ khá nặng nề và rất khó khăn để giữ cho up-to-date. Vì lý do này, bạn không thể mong đợi để có thể so sánh kết quả của toLocaleString trên các trình duyệt hoặc thậm chí mong đợi cùng một trình duyệt tiếp tục đưa ra kết quả tương tự từ bản phát hành đến bản phát hành. Khi dữ liệu địa phương cơ bản thay đổi (có lẽ vì tùy chỉnh cục bộ đã thay đổi hoặc có nhiều dữ liệu hơn hoặc các định dạng tốt hơn được thêm vào), định dạng này cũng được trả về từ API này.

Việc rút tiền từ điều này là bạn nên cố gắng không dựa vào so sánh đầu ra của các API toLocaleString với một số giá trị tĩnh trong ứng dụng của bạn. Hơn nữa, được đưa ra ngày d, Date.parse(d.toLocaleString()) đôi khi có thể hoạt động nhưng không hoạt động tùy thuộc vào ngôn ngữ, vì vậy tốt nhất nên tránh điều này.

Với điều đó đã nói, en-US tương đối ổn định và đối với hầu hết các trình duyệt phần (hiện tại) đồng ý về định dạng cơ bản đó là gì. Tuy nhiên, IE chèn các ký tự kiểm soát hai chiều xung quanh ngày. Điều này là do thiết kế để văn bản đầu ra sẽ chảy đúng khi nối với văn bản khác. Điều này đặc biệt quan trọng khi trộn nội dung LTR và RTL như ghép một ngày RTL được định dạng với văn bản LTR.

+0

đó là những gì chúng tôi đã làm, trước tiên thay đổi các thử nghiệm của chúng tôi để không phụ thuộc vào đầu ra cụ thể của 'toLocaleString', và sau đó chỉ sử dụng' toLocaleString' trong mẫu loại bỏ của chúng tôi ràng buộc thay vì trong chính mã đó và để lại các đối tượng ngày tháng là ngày thực tế trong phần còn lại của mã. –

5

Hóa ra bạn không thể nhìn thấy chúng, nhưng Date.toLocaleString của IE được rõ ràng bao gồm trái sang bên phải dấu trong nó (U + 200E):

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

tuyệt vời. Tôi đoán đã đến lúc gửi lỗi cho IE?

+0

Nhóm IE tham gia qua email. sẽ cập nhật thông tin này nếu tôi nhận được thêm một số thông tin. –

+0

brian từ nhóm IE thêm câu trả lời cụ thể hơn, vì vậy câu trả lời của tôi không còn là câu trả lời hay nhất :) –

0

Tôi không thấy điều này trong IE11 của tôi vì vậy nó có thể là một cái gì đó để làm với các thiết lập của bạn/cấu hình trong IE hoặc máy tính của bạn. Đối với tôi kết quả là:

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

Bạn có sao chép-dán chuỗi ngày trôi qua để các nhà xây dựng từ một trang web?

Tôi không nghĩ rằng đội IE sẽ chấp nhận nó như là một lỗi ở giai đoạn này vì nó không có repro rõ ràng bước

+0

cho nơi tôi làm việc, họ có thể chấp nhận nó :) Chúng tôi có thể kiểm tra lại bài kiểm tra đơn vị trong QUnit bằng IE, v.v. mọi người trong tổ chức của chúng tôi đều có thể. –

1

Hãy nhìn vào 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)); 

Ở phía trên độ dài của x là 14 trong IE nhưng 9 trong các trình duyệt khác. Điều này hỗ trợ nhận xét của John rằng IE đang thêm dấu từ trái sang phải. Điều này chắc chắn trông giống như một lỗi đối với tôi.

+0

chúng tôi nghĩ rằng đó là lỗi, nhóm IE/Edge là người thực sự phản hồi ở trên và "Bạn có thể nghĩ rằng điều này khá rõ ràng nhưng các trình duyệt được cho phép một số lượng lớn mất nhiều thời gian với những định dạng mà họ hỗ trợ và Đây là do thiết kế - với tất cả các ngôn ngữ và ngôn ngữ trên khắp hành tinh, xác định điều này sẽ khá nặng nề và rất khó để cập nhật. " –

4

Sử dụng

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

này sẽ loại bỏ ký tự đặc biệt không mong muốn.

+0

Đây không phải là xấu, nhưng März bây giờ là Mrz, mà ở Đức là một tên tháng hợp lệ – Devid

Các vấn đề liên quan