Làm thế nào để đổi Font chữ trong file sau

[paulsteigel]

Sau một hồi nghiên cứu thì em cũng đã phát hiện ra lý do của vấn đề trong chuyển đổi mã Unicode sang Utf-8 và ngược lại của Unikey. Tất nhiên, điều này cũng gây ảnh hưởng đối với cả quá trình nhập liệu khi sử dụng bảng mã Utf-8.
Khi người dùng chọn chế độ nhập liệu ở dạng bảng mã Utf-8, cơ chế Hook bàn phím của Unikey xử lý trực tiếp mã nhập vào sau đó chuyển nhóm ký tự nhập vào sang bảng mã tương ứng được chọn trước đó. Khi quan sát cách thức xử lý với một số ký tự đặc biệt (như trong trường hợp em đã nêu trong các bài trước) như chữ Ệ, Ộ ...vv có các ký tự mở rộng trong bảng mã ASCII, Unikey thể hiện một số điểm như sau:

Chuỗi đầu vào cần nhập là "KỶ NIỆM, Ở CỬA HỘI "

(1) Nếu nhập trực tiếp sử dụng bảng mã Utf-8, kết quả là "KỶ NIỆM Ở CỬA HỘI". Sau đó sử dụng lại chuỗi này và chuyển sang Unicode thì kết quả đúng như chuỗi ban đầu. Tuy nhiên, khi nhập trực tiếp trong Excel thì khoảng trắng mà ta nhìn thấy trước chữ M hoặc I sẽ không có mặc dù trên thực tế là có một ký tự ở đó (nếu dùng Word để nhập thì khoảng trắng đó sẽ hiện ra).

(2) Nếu nhập chuỗi Unicode dựng sẵn, sử dụng công cụ chuyển đổi từ Unicode sang UTF-8 của Unikey, dán từ Clipboard vào màn hình soạn thảo, chuỗi kết quả là: "KỶ NIỆM, Ở CỬA HỘI ".
Sau đó cũng sử dụng chính chuỗi này để chuyển ngược lại từ UTF-8 sang Unicode thì kết quả giống như cũ "KỶ NIỆM, Ở CỬA HỘI"

Điểm đáng ngạc nhiên ở đây là Ký tự "†" chỉ hiển thị khi nó được xử lý trong Clipboard còn khi thao tác trực tiếp trong màn hình soạn thảo thì nó không hiển thị ra.

Tiếp nữa, nếu lưu file theo trường hợp 1 thành dạng CSV (kiểu dữ liện đơn giản nhất). Kết quả là chuỗi vừa nhập được lưu thành "KỶ NiỆM Ở CỬA HỘI". Dùng Unikey chuyển sang Unicode (bằng cách chép dán) thì xong, kết quả bị lỗi "KỶ Ni†M ž CỬA H˜I". Khi kiểm nghiệm với chuyển mã không dùng Clipboard thì lỗi này không gặp phải.

Mặc dù chúng ta không sai trong thao tác, kết quả cuối cùng lại bị sai (tương tự như vậy, file của bạn Văn cũng không có vấn đề gì). Điều này làm nảy sinh nghi vấn về cơ chế đẩy dữ liệu ra của Unikey. Có vẻ như Unikey đã không làm một việc là chuyển ký tự số mở rộng 134 này từ Byte Stream sang kiểu chuỗi (Nếu em nói sai các bác cứ dạy, vì đây chỉ là một dạng suy đoán) nên màn hình soạn thảo sẽ không hiển thị ký tự nhưng khi lưu số liệu các phần mềm soạn thảo đã chuyển các ký tự này về dạng nguyên thủy của nó. Và bản thân Unikey, khi gặp trường hợp này, phần lấy số liệu cho công cụ chuyển mã của phần mềm có thể đã không kiểm soát được tình huống này.

Điều này cũng thấy rõ hơn, nếu nhập số liệu tương tự vào trình quản lý Dữ liệu của MYSQL hoặc SQL SERVER thì các ký tự không nhìn thấy đó lại được chuyển thành dạng chuỗi "†".
Như thế có thể tạm kết luận là, riêng với bộ mã Utf-8, Unikey bị thiếu sót trong việc xử lý dữ liệu, và điều này là việc chúng ta cần nắm được để tránh khi thao tác với số liệu có liên quan đến Utf-8, đặc biệt là trong khi xử lý số liệu liên quan đến Web vì chuẩn mã hóa thông dụng đối với Unicode hiện tại đều dùng Utf-8.

Trong những trường hợp như vậy (chuyển qua lại từ Unicode sang Utf-8), ta nên tránh dùng công cụ chuyển mã của Unikey theo dạng thức copy/chuyển mã/ dán để không bị hỏng số liệu vì cơ chế này có thể đang có lỗi như kể trên.

Em xin phép được chia sẻ vài điểm như vậy!

 

[siwtom]

Sau một hồi nghiên cứu thì em cũng đã phát hiện ra lý do của vấn đề trong chuyển đổi mã Unicode sang Utf-8 và ngược lại của Unikey. Tất nhiên, điều này cũng gây ảnh hưởng đối với cả quá trình nhập liệu khi sử dụng bảng mã Utf-8.
Khi người dùng chọn chế độ nhập liệu ở dạng bảng mã Utf-8, cơ chế Hook bàn phím của Unikey xử lý trực tiếp mã nhập vào sau đó chuyển nhóm ký tự nhập vào sang bảng mã tương ứng được chọn trước đó. Khi quan sát cách thức xử lý với một số ký tự đặc biệt (như trong trường hợp em đã nêu trong các bài trước) như chữ Ệ, Ộ ...vv có các ký tự mở rộng trong bảng mã ASCII, Unikey thể hiện một số điểm như sau:

Chuỗi đầu vào cần nhập là "KỶ NIỆM, Ở CỬA HỘI "

(1) Nếu nhập trực tiếp sử dụng bảng mã Utf-8, kết quả là "KỶ NIỆM Ở CỬA HỘI". Sau đó sử dụng lại chuỗi này và chuyển sang Unicode thì kết quả đúng như chuỗi ban đầu. Tuy nhiên, khi nhập trực tiếp trong Excel thì khoảng trắng mà ta nhìn thấy trước chữ M hoặc I sẽ không có mặc dù trên thực tế là có một ký tự ở đó (nếu dùng Word để nhập thì khoảng trắng đó sẽ hiện ra).

(2) Nếu nhập chuỗi Unicode dựng sẵn, sử dụng công cụ chuyển đổi từ Unicode sang UTF-8 của Unikey, dán từ Clipboard vào màn hình soạn thảo, chuỗi kết quả là: "KỶ NIỆM, Ở CỬA HỘI ".
Sau đó cũng sử dụng chính chuỗi này để chuyển ngược lại từ UTF-8 sang Unicode thì kết quả giống như cũ "KỶ NIỆM, Ở CỬA HỘI"

Điểm đáng ngạc nhiên ở đây là Ký tự "†" chỉ hiển thị khi nó được xử lý trong Clipboard còn khi thao tác trực tiếp trong màn hình soạn thảo thì nó không hiển thị ra.

Tiếp nữa, nếu lưu file theo trường hợp 1 thành dạng CSV (kiểu dữ liện đơn giản nhất). Kết quả là chuỗi vừa nhập được lưu thành "KỶ NiỆM Ở CỬA HỘI". Dùng Unikey chuyển sang Unicode (bằng cách chép dán) thì xong, kết quả bị lỗi "KỶ Ni†M ž CỬA H˜I". Khi kiểm nghiệm với chuyển mã không dùng Clipboard thì lỗi này không gặp phải.

Mặc dù chúng ta không sai trong thao tác, kết quả cuối cùng lại bị sai (tương tự như vậy, file của bạn Văn cũng không có vấn đề gì). Điều này làm nảy sinh nghi vấn về cơ chế đẩy dữ liệu ra của Unikey. Có vẻ như Unikey đã không làm một việc là chuyển ký tự số mở rộng 134 này từ Byte Stream sang kiểu chuỗi (Nếu em nói sai các bác cứ dạy, vì đây chỉ là một dạng suy đoán) nên màn hình soạn thảo sẽ không hiển thị ký tự nhưng khi lưu số liệu các phần mềm soạn thảo đã chuyển các ký tự này về dạng nguyên thủy của nó. Và bản thân Unikey, khi gặp trường hợp này, phần lấy số liệu cho công cụ chuyển mã của phần mềm có thể đã không kiểm soát được tình huống này.

Điều này cũng thấy rõ hơn, nếu nhập số liệu tương tự vào trình quản lý Dữ liệu của MYSQL hoặc SQL SERVER thì các ký tự không nhìn thấy đó lại được chuyển thành dạng chuỗi "†".
Như thế có thể tạm kết luận là, riêng với bộ mã Utf-8, Unikey bị thiếu sót trong việc xử lý dữ liệu, và điều này là việc chúng ta cần nắm được để tránh khi thao tác với số liệu có liên quan đến Utf-8, đặc biệt là trong khi xử lý số liệu liên quan đến Web vì chuẩn mã hóa thông dụng đối với Unicode hiện tại đều dùng Utf-8.

Trong những trường hợp như vậy (chuyển qua lại từ Unicode sang Utf-8), ta nên tránh dùng công cụ chuyển mã của Unikey theo dạng thức copy/chuyển mã/ dán để không bị hỏng số liệu vì cơ chế này có thể đang có lỗi như kể trên.

Em xin phép được chia sẻ vài điểm như vậy!

Cám ơn bạn đã chia sẻ.

Đúng là việc chuyển qua lại utf8 <-> unicode thông qua Clipboard nó bấp bênh thế nào ấy. Tôi không sử dụng Unikey nhưng có cảm giác là tốt hơn là dùng chuyển tập tin. Mà tốt nhất là dùng phần mềm, code khác.
Tôi rất thích "nghiên cứu" nhưng rất tiếc là không biết C++. Chỉ xem code và dựa trên những hàm API và ngữ cảnh để đoán là code làm gì. Có một lần trong quá khứ tôi chỉ nghiên cứu xem Unikey xử lý các phím nhấn như ra sao. Vì hook thì ai cũng biết nhưng xem để biết nó "đánh tráo" các ký tự như thế nào. Tuy nhiên nếu không lập trình C++ mà đọc code thì mệt ơi là mệt.