Phân loại có ý nghĩa gì với ngôn ngữ không phải chữ cái (nghĩa là Châu Á)?

Question

Tôi có một số mã sắp xếp cột bảng theo thuộc tính đối tượng. Nó xảy ra với tôi rằng trong tiếng Nhật hoặc tiếng Trung Quốc (ngôn ngữ không phải chữ cái), các chuỗi được gửi đến chức năng sắp xếp sẽ được so sánh theo cách một ngôn ngữ chữ cái sẽ.

Đưa ví dụ như một danh sách các tên họ của Nhật Bản:

寿拘 (Suzuki) 
松坂 (Matsuzaka) 
松井 (Matsui) 
山田 (Yamada) 
藤本 (Fujimoto) 

Khi tôi sắp xếp danh sách trên qua Javascript, kết quả là:

寿拘 (Suzuki) 
山田 (Yamada) 
松井 (Matsui) 
松坂 (Matsuzaka) 
藤本 (Fujimoto) 

Điều này khác với thứ tự của Nhật Bản syllabary , sẽ sắp xếp danh sách theo ngữ âm (theo cách mà từ điển tiếng Nhật sẽ):

寿拘 (Suzuki) 
藤本 (Fujimoto) 
松井 (Matsui) 
松坂 (Matsuzaka) 
山田 (Yamada) 

Điều tôi muốn biết là:

1. Có một ký tự 2 byte thực sự được so sánh với tính năng sắp xếp khác không?
2. Điều gì thực sự diễn ra theo kiểu như vậy?
3. (Tín dụng thêm) Kết quả của một loại như vậy có ý nghĩa gì không? Khái niệm phân loại có thực sự hoạt động trong các ngôn ngữ Châu Á (và các ngôn ngữ khác) không? Nếu có, ý nghĩa của nó là gì và nên cố gắng gì để tạo ra một hàm so sánh cho các ngôn ngữ đó?

---

PHỤ LỤC SƠ KẾT TRẢ LỜI VÀ VẼ KẾT LUẬN:

Thứ nhất, nhờ vào tất cả những ai đã đóng góp vào cuộc thảo luận. Điều này rất thông tin và hữu ích. Đặc biệt shout-outs để bobince, Lie Ryan, Gumbo, Jeffrey Zheng và Larry K, cho sâu và phân tích chu đáo. Tôi đã trao dấu kiểm cho số Larry K để chỉ cho tôi một giải pháp mà câu hỏi của tôi không thể thấy trước, nhưng tôi đã đánh dấu mọi câu trả lời tôi thấy hữu ích.

Sự đồng thuận dường như là:

1. Trung Quốc và Nhật Bản chuỗi ký tự được sắp xếp theo điểm mã Unicode, và đặt hàng của họ có thể được xác định trên một lý do mà bạn có thể bằng cách nào đó dễ hiểu đối với độc giả am hiểu nhưng không có khả năng có giá trị thực tiễn nhiều trong việc giúp người dùng tìm thấy thông tin họ đang tìm kiếm.

2. Loại hàm so sánh sẽ được yêu cầu để sắp xếp theo ngữ nghĩa hoặc ngữ âm hữu ích là quá cồng kềnh để xem xét theo đuổi, đặc biệt là vì kết quả có thể ít hơn thỏa đáng và trong mọi trường hợp, các thuật toán so sánh sẽ có được thay đổi cho từng ngôn ngữ. Tốt nhất chỉ để cho phép sắp xếp để tiếp tục mà không cần thử hàm so sánh.

3. Tôi có thể đã đặt câu hỏi sai ở đây.Đó là, tôi đã suy nghĩ quá nhiều "bên trong hộp" mà không xem xét câu hỏi thực sự không phải là cách tôi phân loại hữu ích bằng các ngôn ngữ này, nhưng làm cách nào để cung cấp cho người dùng một cách hữu ích để tìm kiếm các mục trong danh sách. Người phương Tây tự động nghĩ đến việc phân loại cho mục đích này, và tôi đã phạm tội. Larry K đã chỉ cho tôi một bài viết trên Wikipedia đề xuất chức năng lọc có thể hữu ích hơn cho độc giả Châu Á. Đây là những gì tôi có kế hoạch theo đuổi, vì nó ít nhất là nhanh như phân loại, phía khách hàng. Tôi sẽ giữ cho cột phân loại bởi vì nó được hiểu rõ trong các ngôn ngữ phương Tây, và bởi vì các loa của bất kỳ ngôn ngữ nào sẽ tìm thấy sắp xếp ngày tháng và các kiểu dữ liệu dựa trên số khác hữu ích. Nhưng tôi cũng sẽ thêm cơ chế lọc đó, nó sẽ hữu ích trong các danh sách dài cho bất kỳ ngôn ngữ nào.

Answer 1

Bạn có thể triển khai Unicode Collation Algorithm trong Javascript nếu bạn muốn thứ gì đó tốt hơn loại JS mặc định cho chuỗi. Có thể cải thiện một số thứ. Mặc dù tài liệu Unicode tuyên bố:

Không phải đồng bộ; nó thay đổi theo ngôn ngữ và văn hóa: Người Đức, người Pháp và người Thụy Điển phân loại cùng một ký tự khác nhau. Nó có thể cũng thay đổi theo ứng dụng cụ thể: ngay cả trong cùng một ngôn ngữ, từ điển có thể sắp xếp khác với danh bạ hoặc chỉ mục sách. Đối với các tập lệnh không phải chữ cái, chẳng hạn như Đông chữ viết số Châu Á, đối chiếu có thể là hoặc là phiên âm hoặc dựa trên hình thức của ký tự.

Wikipedia article chỉ ra rằng vì việc đối chiếu quá khó trong các tập lệnh không phải chữ cái, nên việc tìm kiếm thông tin bằng cách nhập ký tự rất dễ dàng hơn là xem qua danh sách.

Tôi khuyên bạn nên nói chuyện với những người dùng cuối thực sự hiểu biết về ứng dụng của bạn để xem họ thích ứng xử tốt nhất của họ như thế nào. Vấn đề đặt hàng ký tự Trung Quốc không phải là duy nhất cho ứng dụng của bạn.

Ngoài ra, nếu bạn không muốn triển khai đối chiếu trong hệ thống của mình, một giải pháp khác sẽ giúp bạn tạo dịch vụ Ajax lưu trữ tên trong MySql hoặc cơ sở dữ liệu khác, sau đó tra cứu dữ liệu .

Answer 2

Có, các ký tự được so sánh. Chúng thường được so sánh dựa trên các điểm mã Unicode của chúng, tuy nhiên, nó khá khác nhau giữa chữ hiragana và kanji - làm cho kiểu sắp xếp này trở nên vô dụng trong tiếng Nhật. (Kanji mượn từ tiếng Trung, nhưng thứ tự chúng xuất hiện bằng tiếng Trung không tương ứng với thứ tự của chữ hiragana có cùng ý nghĩa). Có những sự đối chiếu có thể khiến một số nhân vật "bình đẳng" cho mục đích so sánh, nhưng tôi không biết liệu có một chữ kanji nào tương đương với chữ hiragana có cách phát âm của nó hay không - đặc biệt là từ một ký tự có thể có một số cách phát âm khác nhau.

Bằng tiếng Trung Quốc hoặc tiếng Hàn hoặc các ngôn ngữ khác không có 3 bảng chữ cái khác nhau (một trong số đó là khá bất thường), có thể nó sẽ ít gặp vấn đề hơn.

Answer 3

Chúng được sắp xếp theo giá trị điểm mã, tăng dần. Điều này chắc chắn là vô nghĩa đối với độc giả của con người. Không thể đưa ra một kế hoạch phân loại hợp lý cho người Nhật, nhưng việc phân loại các ký tự Trung Quốc rất khó (một phần vì chúng tôi không nhất thiết phải biết liệu chúng tôi đang tìm kiếm tiếng Nhật hay tiếng Trung), và rất nhiều lập trình viên tham gia giải pháp này.

Answer 4

Strings được so sánh từng ký tự nơi code point value defines the order:

Việc so sánh các chuỗi sử dụng một trật tự tự từ điển đơn giản trên chuỗi giá trị giá trị điểm mã. Không có nỗ lực để sử dụng các định nghĩa phức tạp hơn, ngữ nghĩa định hướng về ký tự hoặc chuỗi bình đẳng và thứ tự đối chiếu được xác định trong đặc tả Unicode. Do đó các chuỗi có giá trị ngang hàng theo chuẩn Unicode có thể kiểm tra không bằng nhau. Trong thực tế thuật toán này giả định rằng cả hai chuỗi đã ở dạng chuẩn hóa.

Nếu bạn cần nhiều hơn thế này, bạn sẽ cần sử dụng so sánh chuỗi có thể tính đến collations.

Answer 5

Nhớ lại rằng trong JavaScript, bạn có thể vượt qua thành sort() là một chức năng mà bạn có thể thực hiện phân loại chính mình, để đạt được một loại mà quan trọng đối với con người:

myarray.sort(function(a,b){

//return 0, 1, or -1 based on the comparison of the two strings

});

Answer 6

Một ký tự 2 byte thực sự có được so sánh với một đối tượng khác trong chức năng sắp xếp không?

Loại gốc String loại JavaScript dựa trên đơn vị mã UTF-16 và đó là những gì được so sánh. Đối với các ký tự trong Mặt phẳng đa ngôn ngữ cơ bản (tất cả đều là), điều này giống với các điểm mã Unicode.

Thuật ngữ ‘double-byte’ như trong mã hóa như Shift-JIS không có ý nghĩa trong ngữ cảnh web: chuỗi DOM và JavaScript là Unicode nguyên bản, byte gốc trong trang được mã hóa nhận được bởi trình duyệt đã biến mất.

Kết quả của kiểu như vậy có ý nghĩa gì không?

Ít. Các điểm mã Unicode không yêu cầu cung cấp bất kỳ thứ tự cụ thể nào ... cho một, bởi vì có là không có thứ tự được chấp nhận toàn cầu. Ngay cả đối với trường hợp cơ bản nhất của các ký tự Latin ASCII, các ngôn ngữ không đồng ý (ví dụ: v và w có cùng chữ cái hay không hoặc chữ hoa i là I hoặc İ). Và CJK nhận được nhiều gnarlier hơn thế.

Khối Unicode Unified Unicode UK thống nhất chính xảy ra theo thứ tự và số lần đột quỵ (thứ tự từ điển Khang Hy), có thể hữu ích một cách mơ hồ. Nhưng sử dụng các ký tự từ bất kỳ khối mở rộng CJK nào khác, hoặc trộn vào một số kana, hoặc romaji, và sẽ không có thứ tự có ý nghĩa giữa chúng.

Hiệp hội Unicode do attempt để xác định một số quy tắc đặt hàng chung, nhưng nó phức tạp và thường không cố gắng ở cấp độ ngôn ngữ. Các hệ thống thực sự cần khả năng phân loại ngôn ngữ nhạy cảm (ví dụ: Hệ điều hành, cơ sở dữ liệu) có xu hướng có các lược đồ đối chiếu riêng của chúng.

Điều này khác với thứ tự trong bảng âm tiết Nhật Bản

Yes. Trên và ngoài các vấn đề đối chiếu nói chung, đó là một nhiệm vụ ồ ạt khó khăn để xử lý kanji chính xác bằng âm tiết, bởi vì bạn phải đoán phát âm. JavaScript thực tế không thể biết rằng bằng ‘藤 本’, bạn có nghĩa là ‘Fujimoto’ chứ không phải ‘touhon’; loại điều này yêu cầu các từ điển có sẵn chuyên sâu và các khái niệm không đáng tin cậy ... không phải là thứ bạn muốn xây dựng trong một ngôn ngữ lập trình.

Answer 7

Những người khác đã trả lời các câu hỏi khác, tôi sẽ đảm nhận một điều này:

những gì ta nên phấn đấu trong việc tạo ra một so sánh chức năng cho những ngôn ngữ?

Một cách để làm điều đó là, bạn sẽ cần phải tạo một chương trình có thể "đọc" các ký tự; nghĩa là, có thể ánh xạ các ký tự hanzi/kanji thành "âm thanh" của chúng (đọc bính âm/hiragana). Ở mức đơn giản nhất, điều này có nghĩa là cơ sở dữ liệu ánh xạ hanzi/kanji thành âm thanh. Tất nhiên điều này khó hơn âm thanh (chơi chữ không dự định), vì nhiều nhân vật có thể có cách phát âm khác nhau trong các ngữ cảnh khác nhau, và tiếng Trung có nhiều phương ngữ khác nhau để xem xét.

Một cách khác, là đặt hàng theo thứ tự nét. Điều này có nghĩa là sẽ cần phải có một cơ sở dữ liệu mà bản đồ hanzi/kanji để đột quỵ của họ. Một vấn đề khác: Trung Quốc và Nhật Bản viết theo thứ tự đột quỵ khác nhau. Tuy nhiên, ngoài sự khác biệt giữa Nhật Bản và Trung Quốc, việc sử dụng lệnh đột quỵ phù hợp hơn trong một văn bản đơn, vì ký tự hanzi/kanji hầu như luôn được viết bằng cách sử dụng cùng một thứ tự nét bất kể ý nghĩa của chúng hoặc cách đọc. Một ý tưởng tương tự là sắp xếp theo các gốc tự do thay vì các lệnh đột quỵ đơn giản.

Cách thứ ba, được sắp xếp theo các điểm mã Unicode. Điều này rất đơn giản và luôn đưa ra thứ tự nhất quán không thể chối cãi; tuy nhiên, vấn đề là thứ tự sắp xếp là vô nghĩa đối với con người.

Cách cuối cùng là suy nghĩ lại về nhu cầu đặt hàng tuyệt đối và chỉ sử dụng một số phỏng đoán để sắp xếp theo mức độ phù hợp với nhu cầu của người dùng. Ví dụ: trong phần mềm giỏ hàng, bạn có thể sắp xếp tùy thuộc vào thói quen mua của người dùng hoặc theo giá. Loại này tránh được vấn đề, nhưng phần lớn thời gian nó hoạt động (trừ khi bạn đang biên dịch từ điển). Khi bạn nhận thấy, hai phương pháp đầu tiên yêu cầu tạo ra một cơ sở dữ liệu khổng lồ của ánh xạ một-nhiều, nhưng chúng vẫn không phải lúc nào cũng đưa ra một kết quả hữu ích. Phương pháp thứ ba cũng yêu cầu một cơ sở dữ liệu khổng lồ, nhưng nhiều ngôn ngữ lập trình đã có cơ sở dữ liệu này được xây dựng trong ngôn ngữ. Cách cuối cùng là một chút của heuristic, có lẽ hữu ích nhất, tuy nhiên họ đang cam chịu không bao giờ cung cấp cho trật tự phù hợp (tồi tệ hơn nhiều so với hai phương pháp đầu tiên).

Answer 8

Chức năng so sánh chuỗi bình thường trong nhiều ngôn ngữ lập trình được thiết kế để đảm bảo rằng chuỗi có thể được sắp xếp thành thứ tự duy nhất, cho phép các thuật toán như tìm kiếm nhị phân và phát hiện trùng lặp hoạt động chính xác. Để sắp xếp dữ liệu theo kiểu thời trang có ý nghĩa với người đọc, người ta phải biết dữ liệu đại diện cho cái gì. Ví dụ, trong một danh sách các tựa phim tiếng Anh, "El Mariachi" thường sẽ phân loại theo "E", nhưng trong một danh sách các tựa phim tiếng Tây Ban Nha, nó sẽ phân loại theo "M". Ứng dụng sẽ cần thông tin nằm ngoài các chuỗi có trong chính chuỗi để biết cách sắp xếp các chuỗi.

Answer 9

Câu trả lời cho Q1 (bạn có thể sắp xếp) và Q3 (sắp xếp có ý nghĩa) đều là "có" cho Trung Quốc (từ góc độ đại lục). Đối với Q2 (cách sắp xếp):

Tất cả các ký tự Trung Quốc có cách phát âm nhất định (một số là đa âm) như được định nghĩa trong pinyin và nó phổ biến hơn nhiều (như hầu như tất cả từ điển tiếng Trung) sắp xếp theo bính âm, không có sự mơ hồ. Các ký tự có cùng cách phát âm sau đó được sắp xếp theo thứ tự nét vẽ.

Nhân vật đa âm đặt ra nhiều thách thức cho việc sắp xếp, vì bính âm của họ thường phụ thuộc vào từ họ đang ở (tôi nghe các ký tự tiếng Nhật có thể còn lông hơn). Ví dụ, ký tự 阿 được phát âm là (1) trong 阿姨 (âm trong ngoặc đơn), và e (1) trong 阿胶. Vì vậy, nếu bạn cần sắp xếp các từ hoặc câu, bạn không thể chỉ đơn giản là nhìn vào một nhân vật tại một thời điểm từ mỗi mục.