Một thắc mắc với font TCVN3

[muontennguoikhac]

Dùng hàm PROPER cho VNI bị lỗi như trên khi nguyên âm có dấu mũ, dấu thanh nằm ở đầu từ (án, ếch, ...).
Do hàm PROPER chuyển các ký tự đầu từ thành chữ hoa, các ký tự cón lại thành chữ thường.
Còn font VNI là 2 byte, á có 2 ký tự là a và dấu sắc. PROPER chì chuyển ký tự đầu là a thành A, còn dấu sắc không chuyển nên nhìn nó hơi kỳ kỳ.

Vì thế, trong Window khi dùng Unicode ta nên dùng bảng mã Vietnamese Locale CP 1258.
Hình như chỉ bộ gõ Unikey mới có.

Đối với VNI, khi thì chữ cái là 1 byte, lúc lại là 2 byte nên khó tương thích với các ứng dụng.

 

[ptm0412]

Dùng hàm PROPER cho VNI bị lỗi như trên khi nguyên âm có dấu mũ, dấu thanh nằm ở đầu từ (án, ếch, ...).
Do hàm PROPER chuyển các ký tự đầu từ thành chữ hoa, các ký tự cón lại thành chữ thường.
Còn font VNI là 2 byte, á có 2 ký tự là a và dấu sắc. PROPER chì chuyển ký tự đầu là a thành A, còn dấu sắc không chuyển nên nhìn nó hơi kỳ kỳ.

Theo tôi thì ngay cả VNI cũng không đúng.
Bởi vì dấu ^/ của chữ ấ (thường) thì có vị trí thấp hơn dấu ^/ của chữ Ấ (hoa) cho nên PROPER sẽ cho chữ Ấ rất kỳ: chữ A (hoa) nhưng dấu ^/ thì nằm thấp, dính vào chữ A.

Như đã nói ở bài trên, đối với bảng mã VNI, hàm Upper() đúng hơn hàm Proper(), vì Upper() thực thi cho mọi ký tự:

- Bảng mã VNI: Do dùng 2 ký tự để thể hiện 1 chữ nguyên âm có dấu, nên Upper(<kytu>) là Upper 2 ký tự: 1 ký tự chữ và 1 ký tự dấu. Kết quả là 1 chữ hoa không dấu và 1 dấu giống y vậy mà nằm cao hơn.

 

[muontennguoikhac]

Nói thêm, Font ABC còn 1 nhược điểm mà font Unicode cũng bị, là dùng hàm UPPER() của Excel, không chuyển được các chữ có dấu:
- Nguyên âm có dấu của ABC bị biến dạng khi dùng UPPER(), hết đọc được luôn.
- nguyên âm có dấu của Unicode còn nguyên chữ thường nhưng còn đọc được.

Trong khi đó font Vni-xxx thì xài UPPER ngon lành.

Hình như nguyên nhân là Excel cộng thêm 1 tham số vào character code của chữ thường để chuyển thành chữ in. Font ABC và Unicode không theo quy luật đó nên sai, Font Vni-xxx theo quy luật nên đúng.

Nói về Unicode mà không phân biệt Unicode 1byte, 2byte, 3byte và 4byte, dựng sẵn và tổ hợp thì sẽ cho những sai sót đáng tiếc.
Với 2 byte thì chỉ có thể có hơn 65 ngàn ký tự. Riêng cho tiếng Hoa thì nhiêu đó đâu có đủ. Mà chỉ riêng tiếng Hoa còn có tiếng phổ thông và địa phương. Rồi các nước khác nữa.

Chổ này cần bổ sung một tí. Không phải tất cả các phần mềm bộ gõ đều dùng Clipboard. Unikey có tùy chọn nếu bạn dùng clipboard hay không. Và mặc định là không. Thế nên dùng Unikey ít phải suy nghĩ hơn một số phần mềm bộ gõ khác.

Riêng chỗ này mình cũng chưa hiểu, nếu không dùng clipboard thì Unikey lấy từ đâu ký tự trước đó và ký tự vừa đánh để ghép lại, và để so sánh với những nhóm ký tự đã định nghĩa?

Cái này thì em không biết.
Nhưng em nghĩ Unikey hoàn toàn có thể đòi hỏi windows cấp phát cho mình một ô nhớ nào đó trong Ram (hoặc ổ cứng) để lưu chứ đâu nhất thiết phải phụ thuộc vào Clipboard.

Hiển nhiên là thế. Viết VBA hẳn ta rất quen thuộc với "DIM xxx, yyy ..." và sử dụng các biến nhớ.
Vì thế phát biểu của ptm0412 như vầy là sai:

5. Nói về bộ gõ:

Các phần mềm tạo bộ gõ đều phải sử dụng bộ nhớ clipboard.
Khi ta gõ 1 phát vào bàn phím, ký tự đó được lưu lại trong bộ nhớ clipboard.

- ...

Hệ quả:

Sử dụng bộ nhớ clipboard và cho hiện lên màn hình, đối với hệ điều hành thì tương tự như là copy/ cut và paste. ...

Chẳng có bộ gõ nào dùng clipboard rồi copy/ cut và paste. ...cả.
"Unikey dùng clipboard" : nghĩa là nó sẽ chuyển mã khi clipboard đổ ra (khi bạn nhấn Ctrl+V) sang bảng mã đang dùng.
Ví dụ bạn copy đoạn văn mã VNI rồi paste vào diễn đàn này thì Unikey có thể chuyển sang mã UTF-8 luôn cho bạn (nếu không, bạn post lên đây sẽ chẳng đọc được).
Chỉ là cho tiện khi dùng tiện ích chuyển mã văn bản của Unikey mà thôi.
Còn trả lời cho thắc mắc:

Riêng chỗ này mình cũng chưa hiểu, nếu không dùng clipboard thì Unikey lấy từ đâu ký tự trước đó và ký tự vừa đánh để ghép lại, và để so sánh với những nhóm ký tự đã định nghĩa?

thì câu trả lời là: đọc lại văn bản đang gõ.
Ngay trong Excel chứ chẳng xa xôi đâu ta cũng có thể tìm hiểu vấn đề bằng cách dùng textbox hoặc RefEdit cùng với các properties: SelLenght, SelStart, SelText và các event: keydown, keyup ...

3. Tại sao Unicode không sắp xếp tiếng Việt tiếng Việt vào 1 khu vực nào đó theo nguyên tắc ±32 để dùng đúng với hàm PROPER ?
Tôi có đọc 1 tài liệu giải thích vấn đề này (giờ không nhớ nguồn ở đâu) như sau : do bảng mã Unicode là bảng mã đa ngôn ngữ, nên có một số ký tự được nhiều ngôn ngữ dùng chung (ví dụ é là ký tự chung của Việt, Pháp, ...) nên nếu đúng với ngôn ngữ này thì sai với ngôn ngữ nọ. Nên Unicode là như vậy. Còn việc phát triển, xử lý như thế nào là tùy từng quốc gia, từng ngôn ngữ.

Đây là nhận xét cá nhân, có thể còn nhiều điều không đúng. các bạn góp ý thêm !

Mặc dù ngay khi mới thành lập, tổ chức Unicode cũng đã có người gốc Việt tham gia, nhưng vì lực không mạnh nên không thể xí phần ngon được.
Ta không thể đòi lấy mã theo quy tắc ±32 để dùng đúng cho tiếng Việt.
Tuy nhiên đó cũng không phải là giải pháp. Bởi vì:
- Nếu ta xí phần ngon thì các nước khác sẽ như thế nào?
Chắc là họ sẽ tìm giải pháp cho họ thôi.
Mà nếu họ tìm được giải pháp cho họ thì sao VN ta trong tình huống khó như họ lại không tìm được?
Mà giành nhau chỗ ngon, tức nhau tiếng gáy không phải là thói quen của các nhà khoa học.

Dẫu sao đi nữa thì cũng đã có giải pháp Unicode tổ hợp.
Khi đó người nước nào thì tích vào tổ hợp bảng mã của mình, loại bỏ phần tổ hợp của nước khác ra. Khi đó nước nào cũng có phần ngon cả (tất nhiên chỉ đúng trên máy có cài đúng tổ hợp đó thôi).
Nếu trong môi trường Window mà dùng bảng mã Vietnamese Locale CP 1258 là bảng mã Unicode tổ hợp được Window hổ trợ thì dù đó cũng là 2 byte như VNI nhưng nó lại được Window hiểu rõ ràng hơn cả dùng VNI bởi vì VNI thực ra là 1byte+1byte mà cái byte sau (chứa dấu) bị đẩy lui vị trí pixel bắt đầu ra phía trước.
Chính vì thế khi dùng VNI thì hàm PROPER lại tưởng byte sau là ký tự khác.
Nếu sử dụng Vietnamese Locale CP 1258 thì bạn có thể gõ vào Excel, thực hiện trên VBA dễ dàng: trên msgbox, trên thanh tiêu đề cửa sổ msgbox, trên form, trên khung properties, trên cửa sổ soạn thảo VBA .... và dĩ nhiên cả với hàm PROPER, UPPER và 1 số hàm khác ....

Tất nhiên nó cũng có những bất tiện của nó...

 

[nguyenmanhnam]

Híc, hôm nay đọc đến phần này quả thực bản thân em mới thấy mình chẳng hiểu gì về các khái niệm này cả, trước đây chỉ quen ứng dụng theo kiểu trâu bò thôi. Tuy nhiên, em cũng phần nào lờ mờ đoán được tại sao (dù chỉ là suy luận chưa được chắc chắn lắm) là tại sao một số trường hợp mình dùng Unicode để đánh trong một số trường hợp mà nó lại không hiển thị Tiếng Việt như: Khi tra từ điển Việt - Anh, tạo tiêu đề cho book CHM...,

Xin các thày có thể chỉ bảo giúp em hiểu thêm tại sao không thể dùng bộ gõ Unicode để gõ tiêu đều cho sách CHM mà lại tự nhiên cứ "phức tạp vấn đề" là phải dùng đến bảng mã Vietnamese Local CP 1258 với ah?