2012-06-24 27 views
11

Khi hiển thị văn bản Unicode sau trong HTML, nó chỉ ra rằng trình duyệt (Google Chrome) thực hiện một số hình thức Unicode normalization khi đăng dữ liệu trở lại máy chủ. (Có lẽ trong số Form C).Làm thế nào để tránh các trình duyệt Unicode chuẩn hóa khi gửi một biểu mẫu với Unicode

Nhưng khi sử dụng văn bản tiếng Do Thái Kinh thánh (בְּרִיךְ הוּא), điều này có thể dễ dàng phá vỡ văn bản, như được nêu trong here (trang 9).

Có cách nào để tránh việc chuẩn hóa văn bản tự động của trình duyệt không?

tôi đã viết một bài đăng blog mô tả chi tiết hơn về vấn đề mà tôi đang phải đối mặt: http://blog.hibernatingrhinos.com/12449/would-it-be-possible-to-have-a-web-browser-based-editor-for-an-hebrew-text

+0

@Hans không. Tại sao bạn nghĩ vậy? –

+0

Bạn không thể đơn giản áp dụng cách giải quyết được mô tả trong cùng một tài liệu? – jalf

+1

Bạn đang hỏi về các trình duyệt cụ thể nào? Không có API được chuẩn hóa duy nhất cho "vô hiệu hóa bình thường khi gửi biểu mẫu", theo như tôi biết. Các trình duyệt riêng lẻ có thể có hoặc không có tùy chọn để kiểm soát điều này. Và bạn có muốn một cách để trang web của bạn vô hiệu hóa việc chuẩn hóa hoặc một cách để người dùng trình duyệt định cấu hình trình duyệt của mình không bình thường hóa không? – jalf

Trả lời

10

Điều này dường như là một là một tính năng/lỗi trong trình duyệt WebKit (Chrome, Safari); họ chuẩn hóa dữ liệu biểu mẫu thành NFC, có nghĩa là, trong số những thứ khác, sắp xếp lại các dấu kết hợp liên tiếp thành một thứ tự "chuẩn". Điều này là mới đối với tôi, và tin xấu trong những trường hợp như thế này. Điều tồi tệ nhất là các trình duyệt khác nhau hoạt động khác nhau.

Sử dụng phiên bản đơn giản của trường hợp thử nghiệm http://blog.hibernatingrhinos.com/12449/would-it-be-possible-to-have-a-web-browser-based-editor-for-an-hebrew-text (sử dụng tập lệnh phía máy chủ chỉ lặp lại dữ liệu thô), tôi nhận thấy rằng Chrome và Safari sắp xếp lại các dấu phụ trong U + 05E9 U + 05C1 U + 05B5 (SHIN , SHIN DOT, TSERE), trong khi IE, Firefox và Opera thì không.

Tôi cũng đã chạy một bài kiểm tra đơn giản với chữ cái Latinh e tiếp theo là kết hợp sự xếp loại U + 0308. Trình duyệt WebKit chuyển đổi nó thành ký tự đơn ë, theo quy tắc NFC, trong khi các trình duyệt khác giữ nguyên cặp ký tự.

Đây có vẻ là một tính năng có chủ ý, kể từ năm 2006; https://bugs.webkit.org/show_bug.cgi?id=8769 tự hào thông báo đây là một phần của bản sửa lỗi! Điều này có thể giải thích tình trạng của tài liệu chính sách W3C; phiên bản hiện tại của nó là WebKit-minded trong vấn đề này, nhưng các nhà cung cấp trình duyệt khác hoặc không quan tâm hoặc cố ý phản đối ý tưởng “bình thường hóa sớm”.

Tôi không nghĩ rằng có một cách để ngăn chặn điều này. Nhưng bạn có thể cảnh báo người dùng chống lại việc sử dụng Chrome và Safari. Bạn thậm chí có thể sử dụng trường ẩn chứa trường hợp sự cố đơn giản, sau đó kiểm tra phía máy chủ xem liệu nó có được truyền dưới dạng − hay không và yêu cầu người dùng thay đổi trình duyệt nếu không.

Việc sửa mặt hàng của máy chủ đơn hàng không đơn giản, bởi vì các thường trình bình thường hóa dường như không hỗ trợ thứ tự cần thiết. Bạn có thể bình thường hóa thành dạng phân tách hoàn toàn (NFD), sau đó sắp xếp lại các dấu kết hợp bằng cách sử dụng mã của riêng bạn cho mục đích. Có lẽ đơn giản và an toàn hơn, bạn chỉ có thể chạy một thói quen thay thế quảng cáo thay thế trình tự kết hợp các dấu bằng các chuỗi khác. Điều này sẽ an toàn hơn vì nó sẽ không ảnh hưởng đến các nhân vật khác ngoài những nhân vật bạn muốn ảnh hưởng, trong khi NFD phân tách các chữ cái La tinh bằng dấu phụ, trong số những thứ khác.

Theo nguyên tắc Unicode, các chuỗi tương đương về mặt kinh điển (ví dụ: khác nhau theo thứ tự các dấu phụ liên tiếp) là các biểu diễn khác nhau của cùng một dữ liệu nhưng khác biệt với chuỗi ký tự Unicode (điểm mã); họ không được dự kiến ​​sẽ khác nhau trong bài thuyết trình, nhưng họ có thể, và thường làm. Nói chung, bạn không nên mong đợi chương trình xử lý chuỗi tương đương về mặt kinh điển là khác nhau, mặc dù chương trình có thể tạo sự khác biệt. Xem Unicode Normalization FAQ.

Mục Câu hỏi thường gặp xác nhận rằng các vấn đề của tiếng Hebrew trong Kinh thánh đã được giải quyết bằng cách giới thiệu COMBINING GRAPHEME JOINER. Mặc dù nó ngăn cản việc sắp xếp lại trong Chrome, đó là một phương pháp vụng về, và nó có thể làm rối tung lên (nó có trong các trình duyệt web; các dấu phụ có thể bị đặt sai chỗ).

+0

Tôi nghĩ rằng đây là lỗi nhiều hơn một tính năng, vì việc chuẩn hóa không xuất hiện trên hiển thị văn bản, mà là gửi biểu mẫu. Tại thời điểm này, các quyết định chuẩn hóa phải là một trong những máy chủ, không phải trình duyệt. –

+0

Tôi đã tạo một vấn đề cho điều đó, https://code.google.com/p/chromium/issues/detail?id=134623&thanks=134623&ts=1340703693 –

+0

+1: "Nhưng bạn có thể cảnh báo người dùng chống lại việc sử dụng Chrome và Safari". Thông thường người dùng được cảnh báo về việc sử dụng ie6-8. –

0

Bạn có thể thao tác văn bản trên các mặt hàng trước khi bạn gửi. Nếu chèn một Joiner Joiner Joiner hoạt động, bạn có thể chèn nó thông qua JavaScript.

Là một điểm nhìn chằm chằm, nhưng đây là một JSFiddle mà được thư ký tự bằng chữ cái (thử nghiệm trong Safari và nó không bình thường hóa văn bản): http://jsfiddle.net/TmtnA/

1

Có thể tránh được những chuỗi bình thường bằng cách gửi một Uint8Array chứ không phải là một chuỗi. Đầu tiên, lấy dữ liệu UTF-8 của chuỗi của bạn như một Uint8Array như mô tả here bởi @Moshev:

function utf8AbFromStr(str) { 
    var strUtf8 = unescape(encodeURIComponent(str)); 
    var ab = new Uint8Array(strUtf8.length); 
    for (var i = 0; i < strUtf8.length; i++) { 
     ab[i] = strUtf8.charCodeAt(i); 
    } 
    return ab; 
} 

Sau đó, bạn có thể đăng bài mà Uint8Array với XHR đồng bằng hoặc thư viện Ajax yêu thích của bạn. Nếu bạn đang sử dụng jQuery, hãy nhớ rằng bạn cần phải xác định processData: false để ngăn chặn jQuery từ cố gắng để stringify nó và hoàn tác tất cả các công việc khó khăn của bạn.

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