Văn bản & công cụ hàng ngày · Bộ công cụ văn bản
Tại sao chữ hoa không chỉ là A–Z: ß, ánh xạ chữ i và Unicode của Thổ Nhĩ Kỳ
· Lý lịch
unicode case-conversion nội địa hóa
Giải thích lý do tại sao chữ hoa và chữ thường được xác định bằng bảng Unicode thay vì số học trên các chữ cái, với các ngoại lệ nổi tiếng — ß trở thành SS, ı không dấu chấm của Thổ Nhĩ Kỳ và sigma cuối cùng của Hy Lạp — và điều đó có ý nghĩa gì đối với bất kỳ trình chuyển đổi dựa trên trình duyệt nào.
STRASSE và chữ cái lớn lên — tại sao 'straße' viết hoa lại thay đổi số lượng ký tự
Dán `straße` vào trình chuyển đổi và viết hoa nó: JavaScript tạo ra `STRASSE`. Kết quả rõ ràng là dài hơn vì chữ s sắc nét viết thường được ánh xạ tới hai chữ cái in hoa theo thao tác mặc định được sử dụng ở đây. Do đó, quy tắc xác thực giả định chuyển đổi chữ hoa chữ thường duy trì số lượng ký tự có thể từ chối, cắt bớt hoặc căn chỉnh sai văn bản tiếng Đức hợp lệ.
Hướng ngược lại không tái tạo lại nguồn. Viết thường `STRASSE` mang lại `strasse` chứ không phải `straße` vì chuỗi viết hoa cũng biểu thị một cặp chữ cái s thông thường. Do đó, chuyển đổi trường hợp là chuyển đổi văn bản chứ không phải là mã hóa có thể đảo ngược. Giữ nguyên chính tả ban đầu bất cứ khi nào nhận dạng, hiển thị độ trung thực hoặc so sánh chính xác.
Ánh xạ chữ hoa chữ thường dưới dạng bảng chứ không phải công thức - cách Unicode xác định ánh xạ chữ hoa đơn giản và đầy đủ cho mỗi chữ cái được viết hoa
Mã ASCII thường dạy một mẫu thuận tiện: các chữ cái Latinh viết hoa và viết thường chiếm các phạm vi có thể dự đoán được, do đó, một phần bù số xuất hiện để kết nối chúng. Mô hình đó không còn hữu ích khi văn bản chứa các chữ cái nằm ngoài các phạm vi đó hoặc ánh xạ tạo ra nhiều ký tự đầu ra. Do đó, trình chuyển đổi gọi các phương thức viết hoa chuỗi JavaScript thay vì thực hiện số học chữ cái.
Kho lưu trữ không hiển thị các bảng ánh xạ Unicode hoặc phân biệt ánh xạ đơn giản và ánh xạ đầy đủ, vì vậy những chi tiết đó không nên được trình bày dưới dạng tính năng của công cụ này. Hợp đồng có thể quan sát của nó hẹp hơn: `toUpperCase()` và `toLowerCase()` ủy quyền cho công cụ trình duyệt. Kết quả phải được kiểm tra trong môi trường nơi văn bản được chuyển đổi sẽ thực sự được sử dụng.
Chuyển đổi trường hợp sử dụng ánh xạ ký tự do công cụ cung cấp, không phải số học hoặc bảng được công cụ này hiển thị
Kết quả thay đổi độ dài ảnh hưởng nhiều hơn đến bộ đếm bên cạnh đầu vào. Các khoảng lệch, phạm vi lựa chọn, điểm đánh dấu và vị trí con trỏ được lưu trữ được tính toán trước khi chuyển đổi có thể không còn trỏ đến văn bản dự kiến sau đó nữa. Rủi ro tương tự cũng áp dụng cho bất kỳ quy trình công việc nào phân bổ không gian đầu ra từ độ dài đầu vào hoặc giả sử một ký tự nguồn luôn tương ứng với một ký tự kết quả.
Việc cắt vòng cũng có thể làm mất đi sự khác biệt ngay cả khi một ví dụ cụ thể giữ nguyên độ dài hiển thị. Một số cách viết nguồn có thể hội tụ về một dạng chữ hoa, khiến thao tác viết thường không có đủ thông tin để chọn bản gốc. Chỉ so sánh các giá trị được chuyển đổi khi sự mất mát đó có thể chấp nhận được; nếu không thì giữ lại bản gốc và sử dụng chiến lược so sánh được thiết kế cho yêu cầu của sản phẩm.
Ánh xạ thay đổi độ dài và tại sao việc chuyển đổi ngược lại không thể luôn khôi phục được nguồn
Sigma của Hy Lạp đưa ra một cảnh báo khác. Tiếng Hy Lạp viết thường sử dụng các dạng sigma có thể thay đổi theo vị trí trong một từ, do đó việc thay đổi kiểu chữ không phải lúc nào cũng được quyết định từ một ký tự biệt lập. JavaScript nhận chuỗi hoàn chỉnh, cho phép hành vi viết thường tích hợp của nó xem xét văn bản xung quanh thay vì thay thế mọi sigma viết hoa bằng một glyph cố định.
Kiểm tra sigma bên trong các từ hoàn chỉnh, không chỉ dưới dạng mẫu một ký tự. Dấu câu, dấu cách và ranh giới từ là một phần dữ liệu đầu vào mà công cụ đánh giá và việc chỉnh sửa chúng có thể làm thay đổi kết quả chữ thường. Để đánh giá bản địa hóa, hãy giữ nguyên toàn bộ cụm từ được giao diện sử dụng và so sánh cụm từ đó với bản dịch đã được phê duyệt thay vì chỉ kiểm tra các điểm mã.
Sigma của Hy Lạp cho thấy chữ viết thường có thể phụ thuộc vào văn bản xung quanh
Tiếng Thổ Nhĩ Kỳ phân biệt i có dấu chấm và không có dấu chấm theo cách mà việc chuyển đổi trường hợp mặc định, độc lập với ngôn ngữ không mô hình hóa hành vi dành riêng cho tiếng Thổ Nhĩ Kỳ. Cấu hình ToolAcre cho biết rõ ràng rằng ánh xạ của nó không phụ thuộc vào miền địa phương và rằng tiếng Thổ Nhĩ Kỳ có chấm và không có dấu chấm không phải là trường hợp đặc biệt. Do đó, một kết quả có vẻ hợp lý không phải là bằng chứng cho thấy tên, địa chỉ hoặc chuỗi giao diện đã được chuyển đổi chính xác cho người đọc Thổ Nhĩ Kỳ.
Phản ứng thực tế là không thêm các thay thế sau khi chuyển đổi chung. Những sự thay thế như vậy có thể làm hỏng văn bản ngôn ngữ hỗn hợp và vẫn bỏ sót ngữ cảnh. Sử dụng thao tác nhận biết ngôn ngữ trong phần mềm có ngôn ngữ đã biết và yêu cầu xem xét nội dung tiếng Thổ Nhĩ Kỳ hoặc Azeri trong cài đặt đó. Trong trình chuyển đổi này, hãy coi các ví dụ thứ i là minh chứng cho giới hạn được ghi lại.
Tiếng Thổ Nhĩ Kỳ có chấm và không có chấm tôi yêu cầu xử lý nhận biết ngôn ngữ mà trình chuyển đổi này không cung cấp
ToolAcre triển khai UPPER trở xuống bằng cách gọi các phương thức chuỗi JavaScript tương ứng trên đầu vào hoàn chỉnh. Nó không vượt qua ngôn ngữ, tải từ điển ngôn ngữ hoặc yêu cầu chuyển đổi phía máy chủ. Do đó, đầu ra là kết quả trường hợp mặc định của công cụ trình duyệt, rất hữu ích cho việc kiểm tra hành vi ứng dụng thông thường nhưng không hữu ích cho việc chứng nhận kiểu chữ dành riêng cho ngôn ngữ.
Sự khác biệt rất quan trọng khi tái tạo một lỗi. Ghi lại chuỗi nguồn chính xác, biến đổi đã chọn và chuỗi kết quả thay vì chỉ báo cáo rằng cách viết hoa có vẻ sai. Nếu mã sản xuất sử dụng cùng các phương thức JavaScript mặc định, trình chuyển đổi sẽ cung cấp một so sánh nhỏ gọn. Nếu quá trình sản xuất sử dụng API nhận biết ngôn ngữ thì việc so khớp trang này không phải là thử nghiệm chấp nhận phù hợp.
Điều này không bao gồm những gì - quy tắc đặt tiêu đề cho chữ ghép và lịch sử của thủ đô ẞ
Nút Title Case là một sự chuyển đổi khác với hợp đồng được giới hạn có chủ ý. Nó tìm thấy các dòng chữ cái, kết hợp các dấu hoặc dấu nháy đơn, viết hoa ký tự đầu tiên và viết thường các ký tự còn lại. Nó không có từ điển ngôn ngữ hoặc ngoại lệ hướng dẫn văn phong, vì vậy các từ viết tắt và danh từ riêng có thể thay đổi, trong khi các từ nhỏ như `of` và `the` được viết hoa như các từ khác.
Bài viết này không dựa vào lịch sử đề xuất của dàn bài về chữ in hoa hoặc các quy tắc rộng hơn cho cách viết chữ ghép đặt tiêu đề, bởi vì cả hai đều không được thiết lập bởi các nguồn đã được kiểm tra. Những chủ đề đó có thể có giá trị với những tài liệu tham khảo độc lập, nhưng chúng không giải thích được chức năng được vận chuyển. Ở đây hướng dẫn đáng tin cậy là xem lại mọi tiêu đề đã chuyển đổi và khôi phục chính tả có chủ ý theo cách thủ công.
Hành vi viết hoa tiêu đề trong công cụ này, không có lịch sử bảng chữ cái không được hỗ trợ
Hãy thử ba bước kiểm tra tập trung trong trình chuyển đổi chữ hoa: chữ hoa `straße`, chữ thường một từ tiếng Hy Lạp chứa sigma viết hoa và chạy các mẫu i chấm và không chấm qua cả hai hướng. Quan sát các chuỗi thực tế thay vì dự đoán chúng từ tiếng Anh. Sau đó, sử dụng Hoàn tác giữa các thử nghiệm để mỗi kết quả bắt đầu từ văn bản gốc thay vì chuyển đổi mất dữ liệu trước đó.
Bài học rộng hơn là hoạt động: chuyển đổi trường hợp có thể thay đổi độ dài, thu gọn sự khác biệt và phụ thuộc vào ngữ cảnh ngôn ngữ mà hoạt động mặc định không biết. Sử dụng công cụ này để vạch trần những hành vi đó chứ không phải để hứa hẹn tính chính xác của bản địa hóa phổ quát. Giữ nguyên văn bản nguồn, kiểm tra các cụm từ thực hoàn chỉnh và áp dụng đánh giá nhận biết ngôn ngữ ở bất cứ nơi nào cần có kết quả theo ngôn ngữ cụ thể.