• Thứ Ba, 30/03/2004 15:19 (GMT+7)

    Bản chất của xử lý tiếng Việt trong môi trường đa ngữ

    Tại sao không chấp nhận mã hoá kiểu tổ hợp, coi nó là trở ngại cho việc hiển thị tiếng Việt? Ngại phức tạp, ngại khó mà không làm chủ được 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 Microsoft?

    Từ 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 Microsoft đã phát triển hệ thống xử lý đa ngữ khá hoàn chỉnh. 

    Khi phát triển ứ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ó. Tại thị trường Nhật, đ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...

    Mã hoá ký tự và cách mã hóa của Microsoft

    Mỗi ngôn ngữ, cho dù là tiếng Anh, tiếng Việt hay tiếng Hoa đều được đặc trưng bởi một tập các ký tự. Mỗi ký tự lại được gán một giá trị số nguyên gọi là điểm mã (code point). 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ữ gọi là trang mã (code page - CP), hoặc bảng mã, hay nôm na hơn là bộ mã.

    Tuỳ theo cách mã hoá, mỗi điểm mã có thể là loại 8-bit hay 16-bit. Số bit càng lớn, khả năng mã hóa càng cao, có nghĩa là bảng mã càng lớn (càng nhiều ký tự). Tuy nhiên, mã hóa 16 bit sẽ chiếm nhiều không gian lưu trữ hơn.

    Cùng lúc với máy tính cá nhân được hoàn thiện và phổ cập là sự thống trị của Microsoft trên hệ điều hành (HĐH) và các ứng dụng then chốt. Thị trường máy tính cá nhân nhanh chóng mở rộng ra khắp các châu lục, 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, các bảng mã 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ể và CP 95 cho tiếng Hoa phồn thể (truyền thống); và CP 1258 cho tiếng Việt (là nâng cấp của TCVN-5712:1993/VN2).

    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 mà các bảng mã này dần dần được các hãng máy tính quốc tế công nhận thành chuẩn thực tế (de facto) và được tích hợp vào nhiều HĐH, trong đó có Linux.

    Quan hệ giữa các bảng mã CP với Unicode



    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

    Có thể nói: các bảng mã CP (8 bit hoặc 2x8bit) và Unicode (16 bit) đều là dạng nới rộng của bảng mã ASCII chuẩn (7 bit). Bởi vậy, có thể chuyển đổi giá trị mã hóa giữa ASCII vào Unicode. Tương tự, có tương ứng 1-1 giữa bảng mã CP với một tập con của bảng mã Unicode theo lược đồ định vị Unicode. 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 CP 1258 là một biểu diễn 8 bit của bảng mã Unicode tổ hợp tiếng Việt. Trong 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 là Unicode-1258 (kèm theo giải pháp xử lý đa ngữ: tính cách bản địa + cách mã hoá + hiển thị + bàn phím)  để phân biệt với các cách xử lý tiếng Việt khác.

    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, đặ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 những nơi này thường chỉ cần 256 (28), thậm chí chỉ 128 ký tự. Ngay những quốc gia như Nhật Bản yêu cầu cách mã hoá hai byte, nhưng 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. 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 văn bản được ghi hay gửi, hoặc ngay sau khi nhận và đọc. 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 lưu dữ liệu dưới nhiều dạng mã hoá như Windows Vietnamese (CP 1258)... mà không gặp trở ngại 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, ngay cả bộ phần mềm MS Office cũng vậy. Vì thực tế các ngôn ngữ lập trình chỉ cần các ký tự 8 bit để viết những ứ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).

    Hỗ trợ ngôn ngữ bản địa và đa ngôn ngữ trong 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á 8 bit, và có khả năng chuyển đổi giữa các bảng mã thường dùng để gửi dữ liệu dạng Unicode qua mạng, đặc biệt là qua internet.  

    Khả năng hỗ trợ ngôn ngữ bản địa (NLS - National Language Support) trong Windows cho phép xử lý đúng việc nhập liệu, lưu trữ, truy vấn hệ thống và hiển thị chung, có thể thay đổi tùy theo ngôn ngữ, quốc gia/vùng, hay cách mã hoá ký tự, như 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ự.

    Sử dụng Windows, người dùng 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 (hình 1, 2, 3).

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



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

    Đã 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.

    - 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ì được 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... Riêng bộ Office XP đã kiểm soát việc bỏ dấu tiếng Việt khá tốt.

    - 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.



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

    - 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.  

    Trên hệ thống xử lý đa ngữ này, người 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 Đôrêmon"; 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 quy đị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. Nếu chấp nhận cả ký tự tổ hợp và ký tự dựng sẵn trong lưu trữ, truyền tin, xử lý, hiển thị thì trường hợp nào nên dùng loại nào, có chấp nhận loại mã hoá tương thích 1-1 hay không. Khi chọn bộ mã bản địa rồi, thì đã đăng ký với tổ chức Unicode chưa, có 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...

    - Tại sao lại viết lại các phần có sẵn của Microsoft?! 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 như trong bảng dưới.

    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 trông xấu. Người dùng có thể xem ví dụ ở phần trên hoặc tự mình cài đặt các hỗ trợ tiếng Việt trong Control Panel để gõ chữ Việt đúng của Microsoft. 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.

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



    Hình 4. Con trỏ đi tới đâu, thông tin hiển thị ra cho biết chính xác là ngôn ngữ nào.

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

    Tuy nhiên, cũng có thể có một vài trường hợp rất đặc biệt mà tiếng Việt chưa được hỗ trợ đầy đủ trong các phiên bản cũ thì sẽ hiển thị không đẹp. Tuy nhiên MS đã sửa rất nhanh trong những phiên bản mới. Sau đây là ví dụ với Win2000/XP và Office XP, dùng tiện ích Word Art, hiển thị ký tự tổ hợp khá bay bướm:

    - Chúng tôi đã làm những ứng dụng đa ngữ trên các CSDL 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ợ phức tạp và khó vì đó chính là khả năng của máy và phần thưởng cho nhà lập trình chuyên nghiệp. Còn người dùng 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 không chấp nhận mã hoá kiểu tổ hợp, lại 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, tiếng Thái... Nếu thế, liệu 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) khi ta ngại phức tạp, ngại khó mà không làm chủ được 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 Microsoft? 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ý đa ngữ khá hoàn chỉnh như hiện nay. 

    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ì khi 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ả.



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

    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.

    Rất mong một 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á. 

    Trong thời gian trước mắt, để đáp ứng "phong trào toàn cầu hoá", có lẽ vẫn phải dùng phương án xử lý đa ngữ của Microsoft cái đã.

    Các giải pháp nên theo con đường tự nhiên đến với người sử dụng và nhà phát triển. Đó là làm cho người sử dụng hiểu rõ, cùng bàn luận, tự kiểm chứng được và toàn quyền lựa chọn giải pháp tốt nhất cho mình.

    Hà Thân - Công ty Cổ Phần Lạc Việt

    ID: B0207_12