BẢN CHẤT CỦA XỬ LÝ TIẾNG VIỆT
TRÊN MÔI TRƯỜNG ĐA NGỮ.

Hà Thân.

Chúng tôi cố gắng mô tả lại một số vấn đề căn bản, có thể là hơi dài dòng đối với những chuyên gia, nhưng để đi từng bước logic, cung cấp thông tin cho đông đảo Người Sử Dụng(NSD) nắm được vấn đề. Nếu có gì vụng về xin người đọc chỉ giáo cho và xin được tha thứ.

Khi phát triển các ứng dụng cho người sử dụng bản địa, các chuyên gia phần mềm đứng trước thách thức làm sao cho tiếng bản địa trong các ứng dụng đó phải thể hiện đúng và đầy đủ bản sắc bản địa của nó́- chứ không thể lẫn vào ngôn ngữ nào khác. Hơn nữa khi đưa những ứng dụng đó tìm thị trường ngoài nước thì quá trình toàn cầu hoá sản phẩm chính là bản địa hoá. Thị trường Nhật đại đa số dùng ứng dụng tiếng Nhật; Pháp dùng tiếng Pháp; ...Bên cạnh vấn đề hiển thị được các ký hiệu bản địa đặc trưng, người sử dụng bản địa còn muốn các ứng dụng trên máy tính của họ đáp ứng được những tập quán, quy ước của ngôn ngữ viết, định dạng về ngày tháng, tiền tệ, thứ tự sắp xếp...

Do đó, bất kỳ một ứng dụng có xử lý ngôn ngữ bản địa hoặc xử lý đa ngữ đều phải xử lý và đáp ứng đầy đủ các yêu cầu căn bản sau: 

-         Tính bản địa(locales).

-         Mã hoá ký tư(encoding)̣: Biểu diễn các ký tự của ngôn ngữ trong máy để xử lý, trao đổi, lưu trữ thông tin.

-         Hiển thị ký tự bản địa(display).

-         Bàn phím nhập ký tự bản địa(input method). 

Các khái niệm căn bản về xử lý ngôn ngữ bản địa và xử lý đa ngôn ngữ.

Tính bản địa.

Tính cách bản địa(locale) là tập hợp các thông tin liên quan đến ngôn ngữ của người sử dụng và ngôn ngữ trực hệ(sublanguage) của nó. Ví dụ ngôn ngữ trực hệ tiếng Anh là loại tiếng Anh dùng ở Singapore, Úc, ...Xử lý thông tin bản địa (locale factors) bao gồm các công việc sau đây:

-         định dạng kiểu ngày, giờ.

-         tạo ra lịch.

-         định dạng con số và ký hiệu tiền tê.

-         so sánh các chuỗi.

-         xếp thứ tự các chuỗi.

-         xác định các bảng mã.

-         phát sinh ra dấu hiệu font chữ bản địa.

-         đánh số các bảng mã trong hệ thống.

-         cách viết tắt tên quốc gia/ tỉnh.

-         hệ thống đơn vị đo lường.

-         chiều viết của chữ, thông tin mã hoá ký hiệụ,..

-         ......

HĐH và các ứng dụng xử lý đúng tính cách bản địa của văn bản theo một cách mã hoá chuẩn được HĐH hỗ trợ.

Lược đồ mã hoá ký tự(ánh xạ ký tự).

Lược đồ mã hoá ký tự (Character Encoding Scheme)là quá trình biến các ký tự thành dạng biểu diễn như dữ liệu thực tại trong máy tính. CES thường gọi gọn lại là (cách hoặc dạng) mã hoá(Encoding).

Trước tiên xác định tập các ký tự cần mã hoá. Tiếp theo, gán(ánh xạ) cho mỗi ký tự một số nguyên không âm- số nguyên đó được gọi là điểm mã(code point) cho ký tự đó. Ký tự đã được gán cho một số nguyên như vậy gọi là một ký tự được mã. Tập hợp những điểm mã của một tập ký tự của một hoặc một nhóm ngôn ngữ còn gọi là một Trang mã(CP: Code Page), hoặc Bảng mã hoặc nôm na hơn là Bộ mã. Các điểm mã thường viết dưới dạng thập lục phân. Như trong Bảng mã CP1258 và bảng mã Unicode, điểm mã của chữ ơ lần lượt là F5 và 01A1. 

Việc tiếp theo nữa là gán cho(ánh xạ) mỗi điểm mã một dãy những byte, mỗi byte đó gọi là một đơn vị mã(code unit). Dãy các đơn vị mã không nhất thiết có cùng chiều dài, có thể là 1, 2,3, 4 bytes,...và các đơn vị mã không nhất thiết phải là một phần của tập ký tự được mã hoá.

Ký tự được biểu diễn bởi dãy các đơn vị mã đều có cùng chiều dài được gọi là dạng mã hoá ký tự có chiều ngang cố định. Ví dụ:

-         Dạng mã hoá ký tự một byte(SBCS), dùng 8 bit để mã hoá 256 ký tự khác nhau, ví dụ như các ký tự của hệ chữ châu Âu. 

-         Mã hoá ký tự hai byte(DBCS), dùng đến 16 bit để mã hoá cho các ngôn ngữ, phần lớn là các ngôn ngữ tượng hình của châu Á. Ví dụ: bảng mã CP 932 cho tiếng Nhật, CP 950 cho tiếng Hàn ....

Ký tự được biểu diễn bởi dãy các đơn vị mã không có cùng chiều dài được gọi là dạng mã hoá ký tự có chiều ngang biến thiên. Ví dụ:

-         Dạng mã hoá ký tự UTF-8 trong bộ ký tự Unicode có từ một cho tới sáu đơn vị mã 8-bit.

-         Dạng mã hoá ký tự UTF-16 trong bộ ký tự Unicode có từ một cho tới hai đơn vị mã 16-bit.

Trong Unicode để kết thúc quá trình mã hoá thì còn cần phải làm tuần tự hoá (serialization) các đơn vị mã cho mọi điểm mã rộng hơn một byte, nghĩa là đặt byte thấp trước(sử dụng trong các HĐH Windows) hoặc byte cao trước(thường sử dụng trong các HĐH Unix). Mỗi chuỗi ký tự Unicode(Unicode stream) được ghi dấu ở đầu bằng dấu thứ tự byte(BOM: Byte Order Mark) cho biết phải hoán chuyển thứ tự byte cho phù hợp khi hai hệ thống trao đổi dữ liệu với nhau, như giữa một trạm Windows và một server Unix chẳng hạn.

Các dạng biến đổi Unicode(UTF: Unicode Transformation Format).

Mỗi điểm mã của bảng mã Unicode căn bản được ký hiệu U+nnnn, trong đó nnnn là số thập lục phân trong khoảng 0000 đến FFFF.

Các dạng biến đổi Unicode chính là các lược đồ mã hoá ký tự cho bảng ký tự Unicode, gán mỗi ký tự Unicode thành một dãy duy nhất các byte tuần tự hoá.

UTF-8: là kết quả của dạng biến đổi Unicode tạo nên từ các đơn vị 8 bit. UTF-8 có chiều dài thay đổi:

-         128 ký tự đầu tiên của Unicode từ điểm mã U+0000 đến U+007F, được mã hoá thành 1 byte.

-         Từ U+0080 đến U+07FF, được mã hoá thành hai byte.

-         Từ U+0800 đến U+FFFF, được mã hoá thành ba byte.

-         Từ U+100000 đến U+10FFFF(phần nới rộng của Unicode), được mã hoá thành bốn byte.

UTF-16: là kết quả của dạng biến đổi Unicode tạo nên từ các đơn vị 16 bit. Dạng mã hoá mặc định của các ký tự Unicode căn bản là 16 bit, còn đối với phần Unicode nới rộng là các đơn vị 16 bit.

UTF-16LE: là kết quả của dạng biến đổi Unicode tạo nên từ các đơn vị 16 bit, theo định dạng đầu cuối bé.     

UTF-16BE: là kết quả của dạng biến đổi Unicode tạo nên từ các đơn vị 16 bit, theo định dạng đầu cuối lớn.

Như vậy có nhiều cách mã hoá trong Unicode nghĩa là nhiều cách biểu diễn(gán) một ký tự thành chuỗi nhị phân trong máy để xử lý. Một cách biểu diễn như vậy còn gọi là một ánh xạ ký tự(character map). Ta thấy cách mã hoá mặc định của Unicode là 16 bit, nhưng còn có cách mã hoá chỉ cần 8 bit(UTF-8) cho những ký tự ANSI. Có thể chuyển đổi mà không mất thời gian tìm kiếm giữa các dạng mã hoá của Unicode, từ UTF-8 sang UTF-16 và ngược lại. Dùng dạng mã hoá nào là tùy ngữ cảnh: dùng UTF-8 lợi hơn khi đa số ký tự trong văn bản là chữ La tinh; UTF-16 lợi hơn khi đa số ký tự không phải là ký tự ANSI.

Các cách mã hoá ngôn ngữ của Microsoft.

Máy tính được phát minh và phát triển hoàn chỉnh ở Mỹ, nên bộ ký tự mã hoá hoàn chỉnh đầu tiên là của Mỹ và dĩ nhiên cho các ký tự, ký hiệu Anh-Mỹ, vốn gọi là ASCII(American Standard Code for Information Interchange) hay còn gọi là các ký tự ANSI. Bộ mã này có 128 ký tự: ngoài các ký tự tiếng Anh, ký tự số, các ký hiệu tiền tệ Anh Mỹ,..còn có 31 ký tự điều khiển các hệ thống ngoại vi. ASCII chỉ dùng 7 bit để mã hoá ký tự(2⁷ = 128), bit cuối cùng (MSB) là bit giúp phát hiện lỗi khi truyền dữ liệu số. 

Dĩ nhiên bộ mã ASCII căn bản không đủ cho các ký tự của các quốc gia và các vùng địa chính trị khác. Do đó, phải đặt ra nhiều cách mã hoá ký tự như đã nói ở trên:  

-          Dạng mã hoá ký tự một byte(SBCS) dùng 8 bit để mã hoá 256 ký tự khác nhau.

Ví dụ, chuẩn ISO 646 dựa vào bộ mã ASCII và bổ sung thêm 1 bit, chứa được đủ các chữ cái của các thứ tiếng ở Tây Âu, còn gọi là mã La tinh 1(sau này là ISO 8859-1). Tổ chức ISO tiếp tục phát triển các bộ mã ký tự 8-bit mang tên ISO 8859-x cho các nước ở châu Âu. Sau đó là những phát triển cho các bộ mã 8-bit cho các nước khác trong đó có Việt nam. Ví dụ: TCVN 5712; CP 1258, ... Các bảng mã dạng SBCS luôn giống nhau ở chỗ, 128 ký tự đầu tiên của mọi bảng mã bao gồm tập ký tự ASCII chuẩn. Các ký tự từ điểm mã 128 đến 255 biểu diễn các ký tự bổ sung và thay đổi tùy tập hợp các tập ký tự diễn đạt cho bộ chữ viết (scripts) của một ngôn ngữ nào đó. 

-         Mã hoá ký tự hai byte(DBCS) dùng cho các ngôn ngữ châu Á, sử dụng 8 đến 16 bit để mã hoá từng ký tự.

Cùng lúc với máy vi tính được hoàn thiện và phổ cập là sự thống trị của Microsoft trên HĐH và các ứng dụng then chốt. Thị trường máy vi tính nhanh chóng mở rộng qua các châu lục khác, khiến Microsoft đã thừa kế các mã trên chuẩn ISO và các mã hoá bản địa để đặt ra cách mã hoá riêng của mình cho các tập ký tự tại những quốc gia “đáng để đầu tư” và kèm vào đó khá đầy đủ cơ sở dữ liệu các tính cách bản địa đi kèm. Chẳng hạn như các bảng mã(sau đây gọi là bảng mã CP):

-         CP 1252: cho Mỹ và Tây Âu.

-         CP 874: cho tiếng Thái.

-         CP 949: cho tiếng Hàn.

-         CP 932: cho tiéng Nhật.

-         CP 936: cho tiếng Hoa giản thể. CP 950: cho tiếng Hoa phồn thể(truyền thống).

-         CP 1258: cho tiếng Việt.

-         . . .

Một số tính cách bản địa có thể dùng chung một bảng mã CP. Ví dụ: Mỹ và các nước Tây Âu cùng sử dụng CP 1252.

Do địa vị thống trị của Windows và các công cụ lập trình hỗ trợ ngôn ngữ bản địa Win32 API mà các bảng mã này dần dần được các hãng CNTT quốc tế các công nhận thành chuẩn thực tế(de facto), và được tích hợp vào nhiều hệ thống mã nguồn mở.

Oracle hỗ trợ CP 1258, xem http://otn.oracle.com/products/oracle8i/pdf/817nls_fo.pdf

IBM Lotus Notes hỗ trợ CP1258, xem http://www-10.lotus.com/ldd/today.nsf/lookup/think_globally

Quan hệ mật thiết giữa các bảng mã CP và bảng mã Unicode.

1-     Có thể nói rằng các bảng mã CP và Unicode đều là dạng nới rộng của bảng mã ASCII chuẩn. Unicode nới rộng ASCII lên 16 bit. 128 điểm mã đầu tiên của Unicode(U+0000 đến U+007F) tương ứng với ISO 646. 256 điểm mã đầu tiên(U+0000 đến U+00FF) tương ứng với ISO 8859-1. Vì thế nếu 9 bit cao của một ký tự Unicode là zero, thì có thể coi đó đúng là bảng mã 7 bít ASCII, nên nhiều khi còn gọi là UTF-7. Tương tự, nếu byte cao là zero, thì có thể coi byte thấp đó chính là ký tự ASCII(nới rộng). Ngược lại, có thể chuyển bảng mã ASCII vào Unicode một cách đơn giản là thêm vào các số 0. Cách mã hoá này bảo toàn tính trong suốt của các ký tự ANSI để nhằm tương hợp với các hệ thống xử lý mã hoá 7 bit và 8 bit. Tuy rằng các HĐH hiện đại đều dùng mã hoá Unicode để xử lý bên trong hệ thống, thực chất vẫn là dưới dạng mã hoá 7 hoặc 8 bit.

2-     Tương tự, có tương ứng một-một giữa một bảng mã CP với một tập con của bảng mã Unicode theo lược đồ định vị Unicode. Tập con đó bao gồm mọi ký tự được mã hoá của ngôn ngữ tương ứng với bảng mã CP, và được gọi là bảng mã Unicode của ngôn ngữ đó. Các HĐH và các ngôn ngữ lập trình đều hỗ trợ chuyển đổi giữa hai bảng mã này. Do đó, có thể nói rằng bảng mã CP 1258 là một biểu diễn 8 bit của bảng mã Unicode tổ hợp tiếng Việt và trong rất nhiều xử lý thực tế, người sử dụng không còn thấy sự phân biệt giữa hai bảng mã này, nên cũng có thể gọi tập con của Unicode tương ứng với CP 1258 là Unicode-1258 để phân biệt với các cách mã hoá tiếng Việt khác. Ta cũng tạm gọi tập con của bảng mã Unicode chứa các ký tự tiếng Việt được mã là Unicode-DS. Do đó có thể nói tập con của bảng mã Unicode chứa các ký tự của bảng mã TCVN 6909 là phần hợp của Unicode 1258 và Unicode DS.

3-     Unicode có lẽ không phải là cách hiệu quả nhất trong vấn đề lưu trữ và chuyển văn bản(text), đặc biệt ở các quốc gia ở thuộc châu Mỹ và nhiều nơi ở châu Âu. Vì các phần mềm phát triển cho các nơi này thường chỉ cần 256, thậm chí 128 ký tự thôi. Ngay những quốc gia như Nhật Bản yêu cầu cách mã hoá hai byte, phần lớn tài liệu của họ cũng chỉ chứa các ký tự từ những tập ký tự 7 bit hoặc 8 bit thôi. Vả lại, các dữ liệu “di sản” của các nước có nền kinh tế tri thức phát triển mạnh  còn quá nhiều như Nhật chẳng hạn, nên việc chuyển qua Unicode của Nhật vẫn thông qua con đường bảng mã CP, và hiện nay vẫn chủ yếu dùng bảng mã CP. Người lập trình quan tâm đến việc giảm thiểu bộ nhớ lưu trữ và tối ưu hoá thông lượng truyền dữ liệu thì luôn làm công việc chuyển đổi giữa bảng mã CP và Unicode. Việc chuyển đổi này thường xuất hiện “giữa cuộc” của chương trình, trước khi text được ghi hoặc gởi hoặc ngay sau khi nhận hoặc đọc text. Vì thế nhà lập trình thường tùy cơ tận dụng Unicode cho xử lý bên trong và mã CP để lưu trữ và truyền dũ liệu. Các ứng dụng trong Windows vẫn cho lưu dữ liệu dưới nhiều dạng mã hoá như Windows Vietnamese(chính là CP 1258), Unicode UTF-8, ...mà không trở ngại gì khi xử lý nhờ tính tương thích 1-1 như đã nêu ở trên.

Hầu hết các ứng dụng hiện nay vẫn là non-Unicode, tức là được dịch dưới mode ANSI, ngay cả bộ phần mềm Office của MS cũng vậy. Vì thực tế các ngôn ngữ lập trình chỉ cần các ký tự ANSI 8 bit để viết các ứng dụng như vậy(các công cụ lập trình vẫn hoàn toàn bằng tiếng Anh!).

Ví dụ nữa là các ký tự thuần Việt chỉ có 134 ký tự, có lẽ không cần sử dụng tới không gian mã quá lớn của Unicode(đến 65535 ký tự căn bản); nghĩa là có thể sử dụng một dạng mã hoá 8-bit, không cần đúng dạng mã hoá đến 16-bit; nhưng khi lưu trữ thì phải đưa về đúng một chuẩn mã hoá để còn có thể chuyển đổi đúng giữa các dạng mã hoá và gắn kết chặt chẽ được với tính cách bản địa, không thể “encoding” pha trộn được. Như vậy, cách lưu trữ tiếng Việt tiết kiệm nhất vẫn là ở dưới các dạng chuẩn CP 1258 hoặc “dạng nén” UTF-8.

4-     HĐH và các ứng dụng xử lý đúng tính cách bản địa của văn bản theo một cách mã hoá chuẩn được HĐH hỗ trợ. Ví dụ, hiện nay Win9x(với MLP)/Me/2000/XP xử lý đúng tính cách bản địa tiếng Việt chỉ với các bảng mã CP 1258 và Unicode-1258.

Các ký hiệu của một ngôn ngữ trong Unicode có thể không theo một thứ tự nhất định và không gắn liền với tính cách bản địa nếu không có thông tin về mã hoá. Do đó, lưu dữ liệu dưới một dạng mã hoá ký tự trong Unicode (UTF-8, UTF-16, ...) chưa được HĐH hỗ trợ thì dữ liệu đó không có thông tin bản địa.

Hiển thị ngôn ngữ bản địa.

Hiển thị ngôn ngữ bản địa liên quan chặt chẽ đến các tính cách bản địa sau:

-         Ký tự bản địa: bao gồm các bộ chữ, bảng mã, ....

-         Chiều viết: theo dòng hay cột, từ trái qua phải hay từ phải qua trái, ...

-         Cách viết: bỏ dấu, sắp thứ tự trong văn bản, chấm câu, ...

Các ứng dụng chạy dưới các HĐH hỗ trợ đa ngôn ngữ có thể đáp ứng tự động sự khác biệt giữa các tính cách bản địa bằng cách tham chiếu đến các “Bảng thông tin quốc gia (country information table)” và các công cụ lập trình qua locale ID(ký hiệu định danh tính cách bản địa của một ngôn ngữ). Ngoài ra người sử dụng cuối có thể chọn trực tiếp các thiết lập tùy chọn từ ngay HĐH.

Việc hiển thị ký tự bản địa cũng liên quan chặt chẽ đến font chữ. Có thể hiểu font là cơ sở dữ liệu các ký hiệu đồ hoạ trừu tượng- gọi là dáng chữ(glyph), có thể vẽ ra trên một thiết bị xuất liệu tương thích như màn hình, máy in, máy vẽ.  Một font không nhất thiết chứa mọi dáng chữ dành cho một bảng mã nào mà còn có thể chứa dáng chữ dùng chung cho nhiều bảng mã. Do font là csdl của dáng chữ, nên thông tin về font cũng cho một vài phương tiện để định dạng dáng chữ như bộ định dạng dáng chữ. Hiển thị font trên Unicode với TrueType font(TTF) lại dễ dàng hơn rất nhiều lúc hiển thị đa ngữ mà phải chuyển qua lại giữa các bảng mã như trước đây. Một font Unicode chứa các dáng chữ dùng cho nhiều vùng chữ của Unicode(ranges). Hơn nữa do chuyển đổi tương thích một-một giữa các bảng mã CP với các tập con tương ứng của Unicode mà có các font dùng chung cho một số bảng mã và các vùng chữ của Unicode. 

Do Windows NT/2000/XP hỗ trợ Unicode bản sinh nên hễ có font là nó hiển thị lên dễ dàng qua ứng dụng gọi, chứ không có “dùng loại HookAPI ...”nào cả.

Bàn phím nhập ký tự bản địa.

Nhập ký tự bản địa trong môi trường đa ngôn ngữ cần phải cho phép:

-         Chọn bàn phím bản địa, thể hiện được ký hiệu bản địa và đáp ứng yêu cầu hiển thị ngôn ngữ bản địa.

-         Phân biệt được trong một văn bản, chỗ nào là tiếng nước nào.

HĐH lưu giữ thông tin bố trí bàn phím(keyboard layout) trong các bảng xác định phát sinh ký tự nào ra khi người sử dụng gõ một phím trên bàn phím. HĐH có thể kiểm soát bố trí bàn phím nào đang sử dụng cho người dùng nào và áp dụng nào tại bất kỳ thời điểm nào. Hiện nay viết một trình bố trí bàn phím(keyboard driver) theo thói quen NSD(Ví dụ: kiểu gõ Telex, VNI) bản địa là một chuyện hết sức dễ dàng. Tuy nhiên, Người sử dụng còn phải có được tiện ích chọn nhập tính cách bản địa(input locales), gắn liền với bàn phím bản địa đang sử dụng.

Hỗ trợ ngôn ngữ bản địa và đa ngôn ngữ trong HĐH Windows NT/2000/XP.

Windows(NT/2000/XP) dùng Unicode là cách mã hoá ký tự cơ bản, theo nghĩa mọi chuỗi ký tự bên trong hệ thống, đều được mã hoá theo Unicode. Windows cũng hỗ trợ cách mã hoá ANSI và các cách mã hoá của ISO, EBCDIC, Macintosh. Nó cũng chứa các bảng chuyển đổi cho các chuẩn UTF-7 và UTF-8, thường dùng để gởi dữ liệu dạng Unicode qua mạng, đặc biệt là qua Internet.  

Hỗ trợ ngôn ngữ bản địa(NLSAPI).

Hỗ trợ ngôn ngữ bản địa(NLS: National Language Support) trong Windows NT bao gồm một tập các bảng trong hệ thống mà các ứng dụng có thể khai thác qua NLSAPI. Nhà lập trình có thể dùng các API cấp hệ thống để tạo ra mã chung để xử lý đúng việc nhập liệu, lưu trữ và hiển thị chung cho các ngôn ngữ. NLSAPI chứa các hàm để biến đổi chuỗi, truy tìm và chế tác thông tin về bảng mã, tìm kiếm và chế tác thông tin bản địa. Các API này liệt kê trong Bảng 1. Các hàm NLSAPI cho phép ứng dụng truy vấn hệ thống về các loại thông tin có thể thay đổi tùy theo ngôn ngữ, quốc gia/vùng, hay cách mã hoá ký tự. Ví dụ: LCMapString chuyển một chuỗi thành dạng chữ hoa, chữ thường, hay thành một khoá sắp thứ tự tùy vào tham số ngôn ngữ chuyển cho hàm gọi.GetCurrencyFormat trả lại mọi thông tin một ứng dụng cần để định dạng một chuỗi tiền tệ của một quốc gia nào – nghĩa là ký hiệu tiền tệ đó là gì, đứng trước hay đứng sau con số,... MultiByteToWideChar sẽ chuyển một chuỗi từ một bảng mã hoá kiểu ANSI vào đúng vùng ký tự của Unicode và ngược lại. Ví dụ muốn chuyển tiếng Việt CP 1258 qua tiếng Việt Unicode tổ hợp chỉ cần gọi hàm MultiBytetoWideChar(1258, ...) và ngược lại với WideChartoMultiByte(1258, ...). Các hàm NLSAPI được dùng cho mọi ngôn ngữ chỉ cần đưa vào đúng CP hoặc locale ID.

Bảng 1. NLSAPI functions.

Các API này cũng hỗ trợ các bộ định dạng cho các ngôn ngữ, tính cách bản địa, hoặc các lược đồ mã hoá ký tự.Các ứng dụng vì thế có thể đưa các locale hệ thống, locale theo luồng, locale chỗ người dùng đến một API để nhận lại thông tin tương ứng từ các bảng thông tin do HĐH quản lý. Nếu locale hệ thống hoặc của người dùng thay đổi thì ứng dụng tự động điều chỉnh không cần lập trình lại hoặc cần động tác gì từ phía người dùng. Nhà lập trình có thể thiết đặt locale của một luồng(thread) trước khi đưa nó qua cho một API nhằm tìm thông tin về một locale nào đó. Ví dụ, nếu một đoạn tài liệu được đánh dấu thẻ là văn bản tiếng Việt, một ứng dụng có thể thiết đặt locale của luồng qua tiếng Việt trước khi gọi GetDateFormat, sao cho bất kỳ dạng ngày tháng trong đoạn tài liệu này được định dạng theo đúng kiểu Việt nam.

Hỗ trợ đa ngôn ngữ(MLAPI).

Các API cho xử lý đa ngữ chứa các hàm để chuyển đổi bố trí bàn phím cũng như các font dùng để hiển thị text. Các ứng dụng dùng các API này để tạo ra các tài liệu đa ngôn ngữ. Trong đó có cả các vấn đề xử lý bố trí văn bản như tiếng Nhật chiều đi từ trên xuống, hoặc từ phải qua trái cho chữ ghép tiếng Ả Rập...

Bảng 2. Các hàm API cho đa ngữ.

Qua các API này, nhà lập trình có thể tạo ra các ứng dụng xử lý việc nhập văn bản và hiển thị bất kỳ số lượng ngôn ngữ nào, ngay cả khi giao diện đồ hoa(UI) chưa được thực hiện cho tất cả các ngôn ngữ. Lấy ví dụ, các ứng dụng giao diện tiếng Anh trên Windows 2000 sẽ tự động xử lý việc nhập liệu văn bản tiếng Nhật chừng nào ứng dụng còn dựa vào Unicode. Nguyên do là mọi API đều hoạt động đầy đủ với mọi phiên bản ngôn ngữ của HĐH.

Hỗ trợ trực tiếp cho Người sử dụng.

Trên Windows, Người sử dụng(NSD) có thể tự mình cài đặt phần Hỗ trợ Ngôn ngữ bản địa cho bất kỳ ngôn ngữ nào qua các hình trực quan sau đây:

Hình 1. Bảng điều khiển các đặc tính xác lập cho ngôn ngữ trong Windows 2000.

Hình 2. Thêm một input locale và chỉ định một bố trí bàn phím.

Hình 3. Bảng chỉ dẫn chọn ngôn ngữ ở taskbar.

Hình 4. Windows 2000 tiếng Anh chạy MS Word XP. NSD có thể gõ chữ Ả Rập cùng với tiếng Việt(cùng là kí tự tổ hợp).

Chữ Việt hiển thị ở trên có xấu không?

Xử lý tiếng Việt trong môi trường đa ngữ của MS.

Đã có một hệ thống xử lý đa ngữ(trong đó có tiếng Việt) khá hoàn chỉnh do chính Microsoft và các hãng phần mềm quốc tế khác phát triển và hỗ trợ.

-         Hoàn chỉnh theo nghĩa nó đã đáp ứng đầy đủ các yêu cầu căn bản về xử lý đa ngữ, trong đó có tiếng Việt như đã nêu ở đầu bài viết này.

-         Các dạng mã hoá của hệ thống này kế thừa và tương thích với bộ chuẩn TCVN5712:1993/VN2 do chính Tổng Cục TCĐLCL Việt nam đưa ra, cũng như TCVN 6909, phần các ký tự tổ hợp.

-         Hệ thống này đương nhiên tuân thủ các chuẩn về mã hoá ngôn ngữ và Unicode và vì do các hãng máy tính quốc tế hỗ trợ nên nó cũng là chuẩn thực tế.

-         Người sử dụng không cần phải lập trình gì thêm cũng vẫn xử lý tốt tiếng Việt trong tài liệu đa ngữ. NSD ở bất kỳ đâu trên thế giới vẫn liên lạc tốt với nhau bằng tiếng Việt vì tiếng Việt đã có sẵn trong HĐH Windows.

-         Trong bộ MS Office 2000/XP đã có sẵn bộ kiểm chính tả tiếng Việt, dùng chung với các thứ tiếng khác như Anh, Hoa, ...

-         Nhà phát triển ứng dụng có sẵn đầy đủ các công cụ xử lý cho tiếng Việt và cho từng ngôn ngữ ở mức hệ thống khác để đem ứng dụng của mình ra hội nhập và toàn cầu hoá, và miễn phí!. Các công cụ đó của MS nên độ tin cậy cao, rủi ro thấp  – mà không cần phải mua các “công cụ riêng” để đè lên một số công cụ có sẵn của Windows.

-         Với hệ thống xử lý đa ngữ này, tiếng Việt được thể hiện với đầy đủ bản sắc của nó và rõ ràng “Tiếng Anh cũng chỉ là một ngôn ngữ trên máy tính” mà thôi.

Hình 5: Con trỏ đi tới đâu, thanh trạng thái báo cho biết chính xác là ngôn ngữ nào. Ở đây, phân biệt rất chính xác 5 ngôn ngữ lần lượt: Việt, Anh, Trung, Nhật, Pháp.

 Khả năng trên cho giải bài toán kiểm chính tả và đọc văn bản đa ngữ. Điều này chưa thể làm được hiện nay với giải pháp tiếng Việt với mã dựng sẵn.  

 Trên hệ thống xử lý đa ngữ này thì người sử dụng chỉ chú trọng vào việc sử dụng, nhà lập trình chỉ tập trung vào làm ứng dụng đa ngữ, mọi công cụ như lấy ra trong “túi thần kỳ của Doremon”; chỉ có một việc duy nhất là viết bộ gõ phím hỗ trợ cho cách gõ Telex hoặc VNI vốn quen thuộc ở nước ta nếu không muốn dùng một bộ gõ tiếng Việt có sẵn của MS(khá giống kiểu gõ VNI).

Bộ tiêu chuẩn cần đáp ứng đầy đủ các yêu cầu của xử lý ngôn ngữ và đăng ký quốc tế.

-         Bộ tiêu chuẩn cho một ngôn ngữ không thể chỉ có đưa cách mã hoá, nghĩa là chọn (theo tiêu chuẩn nào?)vị trí cho các ký tự bản địa trong bảng mã Unicode, rồi hiển thị nó ra. Mà còn phải qui định cho đầy đủ các vấn đề về tính cách bản địa của tiếng nước mình là gì? dạng biểu diễn bên trong máy ra sao, dùng 8 bit hay 16 bit? Nếu chấp nhận cả kí tự tổ hợp và kí tự dựng sẵn thì trong lưu trữ, truyền tin, xử lý, hiển thị thì trường hợp nào dùng loại nào?, có chấp nhận loại mã hoá chuyển đổi 1-1 hay không?. Nếu đã chọn bộ ký tự bản địa mã hoá rồi, thì đã đăng ký với tổ chức Unicode chưa, đã làm việc với các hãng sản xuất HĐH để được hỗ trợ bản sinh(native) ngay trong hệ thống xử lý đa ngữ của họ hay không?(Hậu quả của việc này là HĐH vẫn xem cái tiếng Việt đó là tiếng Anh!). Đã đưa ra thảo luận rộng rãi, công khai trong cộng đồng những chuyên viên CNTT trong nước chưa? Nếu không thì chỉ có xử lý cục bộ, một số ít người biết với nhau thôi làm sao hội nhập quốc tế được.

-         Nếu còn các thiếu sót trong bộ chuẩn và khi triển khai chuẩn lại đưa ra một cài đặt mang tính một chiều, có xu hướng bác bỏ hệ thống có sẵn khác(vốn đã tuân thủ đầy đủ chuẩn ), lại dùng hệ thống công quyền để áp xuống, thì mục đích thống nhất ngôn ngữ quốc gia trên máy tính liệu có thể đạt tới mức nào?. Trong bối cảnh đó đương nhiên NSD rất ít thông tin để có thể hiểu đúng và không còn chọn lựa nào khác, dẫn đến việc sử dụng của họ được lấy như một minh chứng “tính thực tế” của cài đặt đó.

-         Một kinh nghiệm cần rút ra là tính kế thừa hoặc tương thích ngược: Bộ chuẩn mới không có mối liên hệ nào với bộ chuẩn cũ. Các ứng dụng nếu viết cho TCVN 5712:1993/TCVN2(CP 1258) thì vẫn có thể chạy thông suốt từ Win9x đến WinXP, và chuyển qua Unicode với chỉ một hàm API đơn giản: MultiBytetoWideChar(1258, ...). Còn nếu các ứng dụng viết cho TCVN 5712:1993 thì gần như viết lại gần hết khi chuyển qua TCVN 6909 với giải pháp “mã dựng sẵn”?. Điều đó luôn làm phiền và gây lãng phí cho Người sử dụng.    

-         Tại sao lại viết các API thay thế cho NLSAPI và MLAPI có sẵn của MS.? Có nên không? Ví dụ, hậu quả của một biến đổi bình thường từ chữ thường sang hoa:

Hình 6: Do HĐH Windows hiện nay không hỗ trợ tính bản địa cho mã dựng sẵn, nên Unicode-DS hiển thị không đúng so với Unicode-1258. Chú ý thêm hiển thị tiếng Việt của Unicode-1258, tuy khá đẹp- nhưng vẫn thua dựng sẵn; nhưng lại đẹp không kém trên Windows 2000(SA Edition)/XP(Xem hình 5,7).

Các ngộ nhận về hệ thống xử lý đa ngữ của Microsoft.

-         Một “nhược điểm” hay được nêu ra là chữ Việt có sẵn trong Windows là xấu. NSD có thể xem ví dụ ở phần trên hoặc tự mình cài đặt các các hỗ trợ tiếng Việt trong Control Panel để tự gõ chữ Việt đúng của MS. Có thể dùng một bộ gõ có hỗ trợ Windows Vietnamese với các cách gõ mà bạn quen thuộc.

NSD có thể thấy ngay chữ Việt ở đây cũng đẹp không kém các bộ chữ của VNI, VietWare, ABC, ...

Đúng là chữ Việt trong các HĐH cũ như Windows 95/98 còn khá xấu nếu không cài đặt Multi-Language Pack(MLP) của MS. Lý do, vì MS lúc đó mới bắt đầu hỗ trợ tiếng Việt trong HĐH của mình, chưa kịp ra MLP. MS đã ngưng hỗ trợ Win95 từ lâu và sẽ ngưng hỗ trợ Win98 trong thời gian gần đây. Lý do vì đã có các HĐH khác tin cậy hơn(không có những lỗ hổng quá lớn về bảo mật và dễ bị treo như Win98). Như vậy, nếu NSD dùng các HĐH Win Me/2000/XP và Win98 với MLP thì hiển thị tiếng Việt rất tốt trong mọi ứng dụng của Office; IE 5.5, ... nếu biết xử lý đúng tiếng Việt; chứ nếu đối xử với tiếng Việt như tiếng Anh thì làm sao mà ra đúng được!.

Hình 7: Hiển thi ký tự tiếng Việt, kiểu tổ hợp, với Word Art.

-         Chúng tôi đã làm những ứng dụng đa ngữ trên các CSDL MS SQL Server 7, 2000; Oracle 8i, 9i; IBM DB2 7.1, 7.2; và Lotus Notes 5.5 mà không gặp khó khăn gì, kể cả với các kỹ thuật Index và Full Text Search. Vấn đề là phải làm chủ được kỹ thuật xử lý đa ngữ. Đừng sợ “thuật toán riêng khá phức tạp, khó” vì đó chính là công việc của “sức máy đã quá thừa thãi” và phần thưởng cho nhà lập trình chuyên nghiệp. Còn NSD thì sử dụng quá dễ dàng, chẳng cần biết đến sự khó khăn, phức tạp nào.

-         Tại sao cứ khăng khăng phải bác bỏ mã hoá kiểu tổ hợp, coi nó là một trở ngại cho việc hiển thị tiếng Việt, trong khi nó là công cụ mã hoá chủ yếu cho các ngôn ngữ có cách viết nhìn còn “ghê” hơn tiếng Việt nhiều như tiếng Ả Rập, Thái, ...Như thế thì ta sẽ làm sao đây với đồng bào Thái, Chăm(có hai hệ Chăm Khmer dùng phần lớn ký tự Thái và Chăm Phan Rang dùng phần lớn các ký tự Ả Rập và thêm 6 ký tự Chăm riêng nữa); nếu ta ngại phức tạp, khó mà không làm chủ được thêm kỹ thuật tổ hợp, nói rộng hơn là kỹ thuật xử lý đa ngữ sẵn có của MS?. Hơn nữa, đó là thái độ tự phủ nhận vì TCVN 5712:1993/VN2 cho đến TCVN 6909 đều công nhận kiểu “mã hoá tổ hợp”, trên cơ sở đó – gần 10 năm nay, MS đã phát triển ra hệ thống xử lý tiếng Việt khá hoàn chỉnh như hiện nay.  Và cũng trên cơ sở đó, kể từ 1998, hàng loạt những ứng dụng đa ngữ từ Quản trị xí nghiệp đến Từ điển đa ngữ đã được phát triển và có hàng ngàn người sử dụng, sao lại nói không ai dùng giải pháp của MS?

Hình 8: Ví dụ về một phần mềm đa ngữ. Nội dung có thể trao đổ́i với bất kỳ file Office nào. Chạy trên Win98/Me/2000/XP. Không cần viết lại code, nếu đổi tiếng Hoa hoặc tiếng Việt thành một thứ tiếng nào khác như Ả Rập, Thái, ...do tính tương thích với các bảng mã CP.

Bỏ phiếu cho xử lý đa ngữ. Tổ hợp hay dựng sẵn không phải là vấn đề.

Mã hoá kiểu dựng sẵn hay tổ hợp sẽ không còn là vấn đề của người dùng, miễn là cho họ biết dữ liệu mà họ đang có là kiểu gì, để lỡ có trục trặc gì trong trao đổi dữ liệu trong tình hình hiện nay thì còn biết cách xoay sở. Cũng không còn là vấn đề của nhà lập trình nếu mã nào cũng được HĐH hỗ trợ đầy đủ mà không cần phải làm thêm gì cả. Có người nói “Không theo Marx, không theo Jesus”, hoặc khăng khăng theo một trong hai. Xin ủng hộ cho cả hai như TCVN 6909 đã làm, và hơn nữa, nếu cả hai đều đáp ứng được yêu cầu xử lý đa ngữ cho cả nhân loại, không riêng gì tiếng Việt. Ở nước ta hiện nay, có thể nói thẳng: “I hate Microsoft” (ghét Microsoft), cũng không cần bênh vực cho MS. Nhưng cứ phải nêu đầy đủ giải pháp của MS về xử lý đa ngữ, không nên lấy bàn tay của mình cố che đi ánh sáng bản chất của sự vật hoặc gán ghép một cách hiểu mơ hồ của mình lên ảnh hưởng(đến 99%) của MS ở Việt nam. Bên cạnh đó, chẳng ủng hộ ai muốn độ̣c quyền bằng thủ đoạn gì đi nữa làm tốn nhiều tiền của NSD nhất là hỗ trợ kiểu MS- muốn nhanh, tốt hơn cứ phải có gì hấp dẫn cụ thể đáp trả lại ...

Chưa hẳn giải pháp của MS đã là hoàn thiện cả, nhưng rõ ràng đó là giải pháp được cải tiến liên tục, và có lẽ là giải pháp xử lý đa ngữ hoàn thiện nhất hiện nay cho tiếng Việt và là một công cụ chung cho hàng trăm ngôn ngữ khác nữa trong bối cảnh chúng ta đang tìm  chìa khoá cho các lối đi vào “hội nhập toàn cầu”.

 Trên bước đường phát triển của CNTT Việt nam, chúng ta không chỉ mong muốn có mà còn tích cực đóng góp vào bộ chuẩn xử lý tiếng Việt đầy đủ hơn, đặt trong bối cảnh xử lý đa ngữ và chính thức được các hãng phần mềm quốc tế công nhận và hỗ trợ đầy đủ – kết hợp được sức mạnh của cả hai cách mã hoá.

Hơn nữa, cá́c giải pháp đưa ra nên theo con đường tự nhiên đến với Người sử dụng (Nhà nước và Nhân dân) và nhà phát triển ứng dụng. Con đường đó là: nêu đúng và đầy đủ sự thật để cho Người sử dụng biết rõ, cùng bàn luận công khai, tự kiểm chứng được, thực hiện được và toàn quyền lựa chọn giải pháp tốt nhất cho mình.

Và đó cũng là con đường đúng đắn để Người sử dụng có thể sẽ đỡ mất đi nhiều tỉ đồng và các Nhà phát triển ứng dụng Việt nam kiếm thêm được nhiều tỉ đồng từ thị trường ngoài nước

Hà Thân. T6/2002.

PcLeHoan 1996 - 2002
Mirror : http://www.pclehoan.com
Mirror : http://www.lehoanpc.net
Mirror : http://www.ktlehoan.com