Bàn thêm về Unicode và TCVN 6909

Bàn thêm về Unicode và TCVN 6909

Mã dựng sẵn và mã tổ hợp,
Bàn thêm về Unicode và TCVN 6909

Dựng sẵn và tổ hợp
Có hai dòng giải pháp chính để xử lý tiếng Việt trong công nghệ thông tin là mã dựng sẵn và mã tổ hợp. Cả hai giải pháp đều có những ưu và nhược điểm riêng và cũng là chủ đề gây nhiều tranh luận trong giới tin học trong thời gian gần đây, trong bài này chúng ta sẽ phân tích một cách có hệ thống khía cạnh kỹ thuật của cả hai giải pháp này, đồng thời cũng bàn thêm một số điểm khác xung quanh Unicode và TCVN 6909.
Trước tiên cần làm rõ các khái niệm ký tự dựng sẵn và ký tự tổ hợp. Ký tự dựng sẵn là ký tự duy nhất không được tổ hợp từ những ký tự khác. Ký tự tổ hợp là ký tự được tổ hợp từ những ký tự cơ bản, ví dụ chữ/ký tự ?~ừ?T là tổ hợp của ký tự cơ bản ?~ư?T và ký tự dấu thanh huyền ?~ ` ?T. Trong Unicode, ký tự tổ hợp còn có thể được tổ hợp từ những thành phần nhỏ hơn như ký tự ASCII, ký tự dấu nguyên âm và ký tự dấu thanh- khi đó ta có dạng biểu diễn chính tắc (canonical). Ví dụ chữ ?~ừ?T trong các dạng biểu diễn nói trên sẽ là chuỗi ký tự sau:

Tổ hợp ký tự Chuỗi mã Hex
Dựng sẵn ư 1EAB
Tổ hợp ư +` 01B0,0300
Chính tắc u + ?T + ` 0075,031B,0300

Mã dựng sẵn và mã tổ hợp là quá trình mã hóa các ký tự thành các ký tự dựng sẵn hay thành các ký tự tổ hợp. Trong bài này chúng tôi sẽ coi dạng Canonical cũng là một dạng của mã hóa tổ hợp.

Ưu điểm của mã tổ hợp
- Mã tổ hợp có phần gọn nhẹ và chiếm ít mã hơn trong bảng mã, chỉ cần 20 mã cho ký tự thuần Việt ( ă, â, ê, ô, ơ, ư, Ă, Â, Ê, Ô, Ơ, Ư, các dấu thanh: huyền, hỏi, ngã, sắc, nặng và dấu tổ hợp nguyên âm: nón, mũ, râu cho dạng canonical) trong khi đó mã dựng sẵn phải cần đến 134 mã cho ký tự thuần Việt.
- Mã tổ hợp có phần gần với ngôn ngữ tự nhiên (Việt) hơn trong quá trình ghép chữ, ghép vần.
- Mã tổ hợp sẽ dễ dàng hơn trong việc chuyển đổi chữ hoa/chữ thường, trong một số ứng dụng có thể dùng luôn tính năng Change Case có sẵn để chuyển đổi chữ hoa/chữ thường.
- Mã tổ hợp có vẻ như dễ dàng hơn trong việc sắp xếp tiếng Việt, nhưng thực ra không phải như vậy, lý do là các dấu thanh huyền, sắc, ngã, hỏi, nặng - thứ tự trong bảng mã Unicode - lại nằm không đúng theo thứ tự sắp xếp tiếng Việt là huyền, hỏi, ngã, sắc, nặng, do đó vẫn phải thiết kế thuật toán riêng để sắp xếp mà không dùng ngay các hàm sắp xếp có sẵn trong tiếng Anh (đa phần các ứng dụng chỉ hỗ trợ sắp xếp theo luật tiếng Anh). Khi đã phải dùng thuật toán riêng thì việc sắp xếp cho mã dựng sẵn cũng không khó hơn, không phức tạp nhiều hơn so với việc sắp xếp cho mã tổ hợp.
- Mã tổ hợp có phần dễ dàng hơn trong việc tìm kiếm tiếng Việt gần đúng, ví dụ tìm những chữ tiếng Việt gần với âm ?otha? chẳng hạn thì các hàm tìm kiếm phổ thông sẽ tìm ra được các chữ thà, thá, thả, thã, thạ... Nhưng nếu tìm những từ gần với âm ?othan? thì lúc ấy lại phải thiết kế thuật toán riêng, mà khi đã phải dùng thuật toán riêng thì giữa tổ hợp và dựng sẵn thuật toán không khó hơn nhau nhiều.
- Trong thực tế, mã tổ hợp được hỗ trợ tốt hơn trong môi trường Windows 2000, và bộ MS Office 2000, ý tốt hơn ở đây là chuyển đổi chữ hoa/thường, sắp xếp tiếng Việt được thiết kế ngay trong hệ điều hành và trong một số ứng dụng. Mã tổ hợp do các mã vẫn nằm trong miền W4L nên có thể hiện thị tốt hơn trong một số control có sẵn của Windows 2000, XP. Tuy nhiên lên môi trường Windows XP, Microsoft đã hỗ trợ luôn cả mã dựng sẵn với tính năng sắp xếp tiếng Việt cũng được tích hợp vào trong hệ điều hành do đó trong môi trường Windows XP, Office XP thì sự khác biệt về sự hỗ trợ tổ hợp và dựng sẵn cũng đã gần như nhau. Vietkey Group đã phối hợp với Microsoft Hà Nội tiến hành một loạt thí nghiệm trên các môi trường Windows và rút ra kết luận như vậy. Các kết luận này không đúng cho các môi trường cũ hơn như Windows 95 và Windows 98.

Nhược điểm của bộ mã tổ hợp
- Cài đặt mã tổ hợp khá phức tạp, số lượng môi trường cài đặt được hạn chế hơn nhiều so với mã dựng sẵn, thông thường chỉ cài đặt được với font vector và bộ font cho phép định nghĩa các ký tự có độ rộng âm, khi đó 2 ký tự có độ rộng âm và dương tổ hợp lại sẽ cho ra ký tự cần hiển thị. Một khó khăn khá lớn nữa là đa phần các công nghệ font phổ biến ngày nay như TrueType, OpenType, Type1...không cho phép thay đổi động vị trí các nét trong hình chữ, mà điều này lại rất cần thiết. Ví dụ chữ ?oà?, và ?oÀ?, thì vị trí của dấu huyền phải nằm ở 2 cao độ khác nhau tuỳ theo chữ cái cơ sở là chữ thường hay chữ hoa, việc thay đổi động cao độ của dấu thanh theo ngữ cảnh là chưa thực hiện được bằng kỹ thuật Font chữ hiện hành. Để khắc phục vấn đề này, VNI đã phải đề xuất 2 mã riêng cho từng dấu thanh: 2 dấu huyền, một mã cho chữ hoa và một mã cho chữ thường. Trong CP 1258 và Unicode để đảm bảo tính đơn trị (tính một-một) các dấu thanh chỉ có một mã vì thế sẽ rất khó khăn trong việc hiển thị. Phương án thứ 2 mà Microsoft đưa ra để giải quyết vấn đề tăng giảm độ cao dấu thanh là dùng kỹ thuật Hook API thay đổi các hàm Display qua đó ánh xạ (Map) chuỗi ký tự tổ hợp về chuỗi ký tự dựng sẵn để hiển thị và in ấn. Cơ chế này chỉ có trong Windows 95 tiếng Việt, Windows 2000, Windows XP mà không có trong Windows 95, Windows 98. Thêm nữa cơ chế này không phải bao giờ cũng thực hiện tốt, ngay cả trên Windows XP (mới nhất), hiện tượng xa rời dấu vẫn xẩy ra với MS Office 2000 (xem hình minh họa ở phần dưới với PowerPoint 2000 trên XP).
- Từ việc cài đặt mã tổ hợp phức tạp như vậy dẫn đến một nhược điểm thứ hai khá nghiêm trọng đó là tính tương thích của mã tổ hợp kém hơn. Có nghĩa là một văn bản gõ bằng mã tổ hợp ở môi trường này thì có thể sẽ không đọc được trong môi trường khác. Nhất là trong các môi trường dùng font ma trận (bitmap) thường dùng để làm font hệ thống thì hầu như không thể cài đặt được mã tổ hợp. Các môi trường như Dos, text console trong nhiều môi trường Unix, Linux cũng không thể cài được mã tổ hợp. Mã tổ hợp cài đặt trên các hệ điều hành phổ biến hiện nay là Windows 98 thì chữ rất xấu (xem hình minh họa) không thể chấp nhận được (thua xa VNI và ABC), sẽ là một vấn đề lớn khi dùng mã tổ hợp phải nâng cấp phần cứng máy tính lên để cài đặt các hệ Windows 2000, XP (theo khuyến cáo của Microsoft để chạy mã tổ hợp tốt hơn), như vậy sẽ cần một kinh phí rất lớn để nâng cấp máy tính, cài đặt lại hệ điều hành, rồi đào tạo lại...
- Độ mỹ thuật của mã tổ hợp thường kém hơn nhiều so với mã dựng sẵn, lý do là một ký tự dấu thanh (có vị trí và cao độ xác định trong font chữ) thường được dùng chung cho nhiều nguyên âm khác nhau và chúng được tổ hợp tự động sau khi nhập đoạn text. Vị trí của dấu thanh có thể hợp và đẹp với nguyên âm này nhưng lại có thể không phù hợp với nguyên âm khác. Ví dụ độ rộng của nguyên âm A thì khác với độ rộng của nguyên âm I (độ rộng rất hẹp) vì thế nếu đẹp cho chữ A thì xấu cho chữ I và ngược lại, để khắc phục tình trạng này VNI phải định nghĩa riêng các mã cho các chữ ì, í, ỉ, ĩ, ị. Vì vậy chúng ta thường coi VNI là giải pháp khắc phục tình thế hơn là một bộ mã, vì nó không đảm bảo tính đơn trị, và nhất quán (có nhiều mã cho một dấu ?" với chữ i lại có xử lý khác so với xử lý các nguyên âm khác). Trong khi đó mã dựng sẵn được thiết kế từ trước (dựng sẵn) nên có thể bố trí vị trí dấu thanh ở vào vị trí thích hợp nhất cho từng nguyên âm, nên bao giờ cũng có khả năng đẹp hơn nhiều so với mã dựng sẵn.
- Xử lý hiệu ứng với đoạn mã tổ hợp có nhiều vấn đề khó khăn hơn so với mã dựng sẵn. Trong nhiều trường hợp, một con chữ tiếng Việt trong lưu trữ và hiển thị với mã tổ hợp lại không phải là một thể thống nhất (tổ hợp từ những ký tự rời rạc) cho nên khi thực hiện các hiệu ứng với đoạn văn bản như co dãn text, xoay, dồn chữ, canh đều hai bên...thì các dấu và chữ thường bị tách rời nhau, chữ đi một nơi và dấu đi một nơi, ảnh hưởng đến mỹ thuật và độ chính xác. Có thể thường thấy trên các title báo dùng font chữ VNI hay xuất hiện các hiện tượng xa rời dấu thanh (xem hình minh họa trên Windows XP).
- Xử lý với các ký tự mã tổ hợp phức tạp hơn so với mã dựng sẵn, do mỗi chữ cái trong mã tổ hợp có độ rộng thay đổi, lúc có thể là một ký tự, lúc khác lại được tổ hợp từ nhiều byte khác nhau. Khi tách từ, tách ký tự (theo ngôn ngữ tự nhiên), thường dùng để phân tích cú pháp hay đánh chỉ số phải xây dựng thuật toán riêng khá phức tạp, trong khi mã dựng sẵn có độ rộng cố định nên việc rút ký tự từ đoạn text ra rất đơn giản, không cần xây dựng thuật toán riêng. Ngoài ra việc các xử lý ký tự khác như: xóa ký tự, di chuyển cho trỏ đi theo đơn vị ký tự thì thực hiện với mã tổ hợp khó khăn và phức tạp hơn nhiều: thường phải xóa 2 lần cho một chữ, di chuyển 2 lần con trỏ mới đi ra khỏi một chữ, những điều này là xa lạ với ngôn ngữ tự nhiên.
- Kích thước các tệp dữ liệu lưu ở dạng tổ hợp thường lớn hơn so với mã dựng sẵn khoảng 25-30%, do đó nó chiếm nhiều không gian trong đĩa cứng, bộ nhớ hơn, và trên đường truyền mạng (internet/intranet) ngốn nhiều băng thông hơn.
- Trong lĩnh vực cơ sở dữ liệu, thiết kế cấu trúc CSDL với mã tổ hợp thường phức tạp hơn, vì mặc dù biết trước số chữ cái max nhưng lại khó đoán nhận chính xác độ dài chuỗi byte tương ứng lớn nhất, nếu thiết kế không khéo sẽ bị tràn bộ nhớ. Và khó khăn trong việc phân tách ký tự, phân tách từ cũng làm khó khăn thêm trong việc xử lý text trong lĩnh vực cơ sở dữ liệu.
- Trong lĩnh vực đánh chỉ số (index), và tìm kiếm toàn văn (Full Text Search), mã tổ hợp cũng gây nhiều khó khăn hơn (phân tách từ, phân tách ký tự) và các ký tự dấu thanh trong mã tổ hợp thường bị coi là dấu phân cách từ, dẫn đến việc đánh index bị sai và tìm kiếm toàn văn cũng không đúng. Hiện tượng này thường gặp với đa số các bộ search engine, các công cụ tìm kiếm toàn văn trong Oracle và Lotus Notes 5.0 đều bị lỗi đánh chỉ số sai. Tuy rằng Oracle và Lotus Notes đều hỗ trợ Unicode trong phần Encoding, nhưng đáng tiếc phần Full Text Search mua lại của hãng thứ 3 INSO (do Oracle sử dụng) và Verity (do Lotus Notes sử dụng) đều thực hiện các phân cách từ sai đối với mã tổ hợp. Các lỗi này lại không xuất hiện với mã dựng sẵn.
- Tính thực tế của mã tổ hợp kém hơn mã dựng sẵn: ngày nay đa số ở Việt Nam cũng như ở nước ngoài, Unicode dựng sẵn được dùng rất phổ biến, các website của Việt Nam như VnExpress và Vasc Orient hàng ngày có gần 2 triệu lượt truy nhập chứng tỏ số lượng người dùng mã dựng sẵn rất lớn, trong khi các website dùng mã tổ hợp rất ít. Cho nên nếu chuyển sang tổ hợp sẽ phải chuyển một khối lượng không nhỏ các mã dựng sẵn sang tổ hợp.

Ưu và nhược điểm của mã dựng sẵn
- Những ưu và nhược điểm của mã dựng sẵn cũng đã được phân tích khá kỹ và song song trong quá trình phân tích các ưu và nhược điểm của mã tổ hợp. Chúng tôi chỉ xin được tổng kết lại một cách tóm tắt: mã dựng sẵn không bị những nhược điểm của mã tổ hợp, các file sử dụng mã dựng sẵn tốn ít không gian hơn, cài đặt đơn giản hơn, chữ hiển thị đẹp hơn, mỹ thuật hơn, xử lý với xâu ký tự dựng sẵn dễ dàng hơn (phân tách từ, phân tách ký tự, xóa và di chuyển con trỏ), chữ và dấu là một khối thống nhất nên khi co dãn text không bị hiện tượng xa rời dấu thanh, và đặc biệt tính tương thích của mã dựng sẵn cao hơn có thể chạy được trên nhiều môi trường khác nhau (từ font vector đến bitmap, từ Windows, MacIntosh đến Linux), vì chuyển mang văn bản dữ liệu giữa các môi trường không đồng nhất (MultiPlatform) là một điều cũng rất cần thiết.
- Tất cả những ưu điểm của mã tổ hợp, thì lại không phải là căn bản và đều có thể giải quyết được tương đối khá dễ dàng (xem tiếp mục sau), trong khi đó mã tổ hợp có những vấn đề về kỹ thuật khá phức tạp (vấn đề cài đặt, hiển thị...). Vẫn biết kỹ thuật phải theo chuẩn, nhưng tại thời điểm hiện nay có những giới hạn nhất định về kỹ thuật và công nghệ, ví dụ cách đây 30 năm, mã hóa 8 bit là giới hạn chưa giải quyết được do không gian nhớ eo hẹp... ngày nay cài đặt mã tổ hợp trong nhiều môi trường chưa thể làm được hoặc phải làm rất khó khăn và đi vòng vo như map từ tổ hợp về dựng sẵn. Các nhược điểm của mã tổ hợp có thể khắc phục được một phần ở thời điểm hiện nay và có thể khắc phục hoàn toàn trong tương lai, nhưng theo ý kiến chúng tôi, chúng ta nên chọn những phương án đơn giản, dễ cài đặt hơn, đẹp hơn...và nhiều ưu điểm ở trên là mã dựng sẵn bởi vì cái lợi của mã tổ hợp mang lại thì không có gì đáng kể mà để thực hiện hoàn hảo nó thì lại có quá nhiều khó khăn, rắc rối và đôi khi lại phải quay về dùng dựng sẵn để thực hiện. Chân lý nhiều khi lại ở chính sự đơn giản của vấn đề.
- Cái có thể gọi là nhược điểm của mã dựng sẵn hiện nay là chưa được Microsoft chú ý hỗ trợ nhiều. Microsoft trong thời gian trước có thiên hướng đi theo mã tổ hợp (là phần nâng cấp từ mã 8-Bit CP1259 lên). Những xử lý về tiếng Việt như sắp xếp, chuyển đổi chữ hoa/thường...được tích hợp luôn vào hệ điều hành như thế tốt hơn so với mã dựng sẵn, nhưng điều này chỉ đúng với Windows 2000 (không đúng với Windows 95,98), ngoài ra trên Windows XP, Microsoft đã bắt đầu hỗ trợ thêm mã dựng sẵn vào trong hệ điều hành: phần sắp xếp tiếng Việt và việc trong tương lai Microsoft hỗ trợ hoàn toàn mã dựng sẵn vào hệ điều hành không phải là vấn đề phức tạp về kỹ thuật có thể tiến hành rất nhanh. Ngoài ra trước kia với các mã VNI, ABC-TCVN 5712, bao nhiêu năm qua chúng ta đâu có được Microsoft hỗ trợ tiếng Việt ở mức hệ điều hành, chúng ta vẫn không bị ảnh hưởng mấy, công nghệ thông tin vẫn tiến triển tốt. Thêm nữa hiện đã có những hỗ trợ tiếng Việt ở mức thấp API (giống như Windows) do các đơn vị ở trong nước thực hiện và đáp ứng đầy đủ các yêu cầu về xử lý tiếng Việt ở tầng thấp. Vietkey Group đã xây dựng bộ thư viện Vietkey API cho phép xử lý hầu hết các vấn đề về tiếng Việt: tìm kiếm, sắp xếp, chuyển đổi chữ hoa, chữ thường, chuyển mã, và cả kiểm tra chính tả tiếng Việt ở mức hệ thống, có thể nhúng trong rất nhiều ứng dụng và các công cụ lập trình trong môi trường Windows. Vietkey API xử lý tiếng Việt ở một số góc cạnh còn đầy đủ và hoàn hảo hơn những hộ trợ từ mức hệ điều hành của Windows.
Tóm lại mã dựng sẵn với nhiều ưu điểm nổi trội có thể đáp ứng được nhu cầu trước mắt cũng như lâu dài và có thể sử dụng trong nhiều lĩnh vực: chế bản văn phòng, web, email, cơ sở dữ liệu và nhiều lĩnh vực khác, theo ý kiến của chúng tôi nên chọn mã dựng sẵn, và tổ hợp chỉ có thể dùng trong một số bài toán đặc thù như phân tích chuỗi ký tự hay để biểu diễn các hình chữ cho dấu thanh.
Bàn thêm về Unicode và TCVN 6909
Trước tiên cần phải nêu rõ mối quan hệ giữa Unicode và TCVN 6909. TCVN 6909 là một tập con của Unicode, nhưng đã được chọn lọc kỹ lưỡng để lấy ra đúng những ký tự sẽ dùng trong ngôn ngữ Việt. TCVN 6909 quy định rõ ràng hơn và tính đơn trị một-một cao hơn trong Unicode. Ví dụ trong Unicode có đến 3 chữ ?~Đ?T, 8 dấu nặng ?~.?T nếu không quy định rõ sẽ gây nhầm lẫn, mà thực tế đã xây ra nhầm lẫn chữ ?~Đ?T trong bộ gõ Unicode: Vps của Việt Kiều Pháp. TCVN 6909 chứa tất cả các ký tự dựng sẵn và cũng có đầy đủ các mã để hiển thị cho dấu thanh, mã cho việc biểu diễn các dấu tổ hợp nguyên âm, như vậy TCVN 6909 là bộ mã rất đầy đủ (trong đó có mã cho tất cả các thành phần cấu thành tiếng Việt). TCVN 6909 không quy định các biểu diễn dựng sẵn hay tổ hợp. Vì vậy nói TCVN 6909 là mã dựng sẵn là không chính xác.
TCVN 6909 kế thừa các ưu điểm của bộ mã Unicode và ISO 10646, cho nên nó hoàn toàn cho phép hội nhập tiếng Việt với các ngôn ngữ khác trong cộng đồng Unicode. Hiện nay đa số các ứng dụng phổ thông đều đã hỗ trợ Unicode: Phần mềm văn phòng, cơ sở dữ liệu, Web, Email... tuy nhiên cũng còn một số các phần mềm chuyên ngành chưa hỗ trợ Unicode.
Vấn đề kỹ thuật của Unicode không chỉ là vấn đề bộ gõ Unicode (như một số chuyên gia đã lầm tưởng) mà là một loạt các vấn đề khác đặc biệt là các công cụ chuyển mã cho văn bản, dữ liệu (MS Office, Web pages, Database...) vấn đề chuyển mã là vấn đề lớn hơn nhiều, vì khối lượng dữ liệu cần chuyển đổi sang Unicode rất lớn, lại rất đa dạng về khuôn dạng, loại hình, chủng loại. Cần phải có các công cụ mạnh để chuyển đổi nhanh nhất, tốt ít thời gian, công sức nhiều nhất. Ngoài ra còn các vấn đề sắp xếp, chuyển đổi chữ hoa, chữ thường, tìm kiếm toàn văn, kiểm tra chính tả tiếng Việt, đặc biệt các hỗ trợ ở mức lập trình cho các công cụ phát triển cũng là điều rất cần thiết (hiển thị, lưu trữ...).
Vietkey Group trong những năm qua là một trong những đơn vị đi tiên phong trong vấn đề xử lý tiếng Việt Unicode, không chỉ có bộ gõ đa ngữ Unicode Vietkey2000 (có nhiều tính năng xử lý thông minh, gõ tắt, lặp dấu, kiểm tra chính tả online...) mà còn có các bộ công cụ khác như Vietkey Office tích hợp và biến bộ MS Office chuẩn thành bộ Office có những tính năng xử lý tiếng Việt (kiểm tra chính tả, sắp xếp, chuyển chữ hoa/thường cho tiếng Việt) đặc biệt là chuyển mã giữ nguyên mọi định dạng, đối tượng đồ họa, bảng biểu trong văn bản cho Word, Excel, PowerPoint. Trong bó công cụ của Vietkey còn có bộ chuyển mã cho toàn bộ Website sang Unicode, bộ chuyển mã cho cơ sở dữ liệu Oracle, SQL Server, Access...từ các bảng mã khác sang tiếng Việt Unicode thông qua các cơ chế ODBC, DAO và ADO.
Về hỗ trợ tiếng Việt ở mức hệ thống, Vietkey Group còn có bộ thư viện Vietkey API cho phép xử lý các vấn đề tiếng Việt như so sánh xâu ký tự Việt, chuyển đổi chữ hoa/thường, sắp xếp tiếng Việt, chuyển mã và kiểm tra chính tả tiếng Việt, các công cụ này có thể nhúng được trong rất nhiều ứng dụng và các công cụ lập trình: Visual C, Basic, Delphi, Access, SQL Server... Một vấn đề cũng khá phức tạp và nổi cộm đối với những nhà phát triển ứng dụng là các môi trường phổ biến hiện nay như Windows 98, Visual Studio 97 lại hầu như chưa hỗ trợ Unicode hay hỗ trợ rất hạn chế, nhất là hiển thị tiếng Việt Unicode trong các ứng dụng tự phát triển trong các Control: menu, textbox, listbox, treeview, buttons... lại không hiển thị được Unicode trong các môi trường phổ biến nói trên. Vietkey Group cũng đã phát triển, xây dựng lại toàn bộ các control đó cho phép xử lý, hiển thị tiếng Việt trong tất cả các môi trường, biến các công cụ chưa hỗ trợ Unicode thành các công cụ có thể hiển thị lưu trữ tiếng Việt Unicode.
Hệ thống Vietkey Messager là ATOL do Vietkey Group phát triển là một ví dụ điển hình về việc hỗ trợ Unicode trong các môi trường, từ Windows 95 cho đến XP, tất cả mọi thành phần trong hệ thống này : Email, Chat, Forum, FTP...(các dịch vụ tích hợp) đều được hiển thị và xử lý bằng tiếng Việt Unicode. Điều này là rất khó thực hiện nếu dùng sẵn các công cụ, các Control chuẩn sẵn có trên thị trường.
Cuối cùng, có thể nói chuyển đổi sang Unicode là một việc làm rất cần thiết và phải làm càng sớm càng tốt, vì càng để chậm, kho dữ liệu, các website càng ngày càng phát triển với dữ liệu càng lớn thì quá trình chuyển mã về sau càng phức tạp, càng tốn kém nhiều công sức và tiền của. Vấn đề Unicode, không bao giờ chỉ là vấn đề bộ gõ, mà phải nghĩ đó là một loạt các công cụ đằng sau để chuyển mã và hỗ trợ tiếng Việt ở mức hệ thống cho nhiều ứng dụng và nhiều môi trường khác nhau.

Đặng Minh Tuấn
Trưởng nhóm Vietkey Group
Thành viên dự thảo TCVN 6909
dangtuan@vietkey.net
www.vietkey.com