Công cụ sửa lỗi font và chuyển mã tiếng Việt là gì?
Công cụ sửa lỗi font và chuyển mã tiếng Việt là bộ chuyển đổi cách biểu diễn ký tự, giúp đưa văn bản đang được hiểu theo một bảng mã sang bảng mã khác. Nhu cầu thường gặp là lấy phần chữ trong tài liệu cũ, chuyển về Unicode để sử dụng trong email, trang web hoặc tài liệu mới. Công cụ cũng xử lý khác biệt giữa Unicode dựng sẵn và Unicode tổ hợp, dù hai dạng này có thể nhìn giống nhau.
Chẳng hạn, chuỗi TiÕng ViÖt có thể là văn bản TCVN3 đang hiển thị bằng font không phù hợp; Tieáng Vieät gợi ý cách biểu diễn VNI Windows. Khi xác định đúng nguồn và chuyển về Unicode dựng sẵn, hai trường hợp này có thể trở thành “Tiếng Việt”. Tuy nhiên, những mẫu trên chỉ là dấu hiệu tham khảo, không có nghĩa mọi đoạn chữ lạ đều thuộc TCVN3 hoặc VNI.
Công cụ xác nhận khả năng chuyển giữa TCVN3, VNI Windows, Unicode dựng sẵn, Unicode tổ hợp và VIQR; ngoài ra có đầu ra tiếng Việt không dấu. Người dùng có thể tự chỉ định nguồn hoặc để công cụ ước đoán. Kết quả là một chuỗi văn bản mới, có thể sao chép hoặc tải dưới dạng tệp văn bản, chứ không phải bản tài liệu giữ nguyên bố cục ban đầu.
“Sửa lỗi font” ở đây chủ yếu là chuyển mã và chuẩn hóa ký tự. Công cụ không trực tiếp thay font trong tài liệu, không sửa chính tả, không đoán chữ đã mất và không khôi phục dấu từ bản không dấu. Nếu lỗi nằm ở ảnh quét, thứ tự chữ trích xuất sai hoặc dữ liệu đã bị ghi đè, chuyển bảng mã không đủ để phục hồi nội dung gốc.
Các thuật ngữ cần hiểu trước khi chuyển mã tiếng Việt
Bảng mã và font chữ
Bảng mã quy định cách biểu diễn ký tự; font chữ quy định hình dạng được vẽ trên màn hình hoặc trang in. Chúng liên quan nhưng không đồng nhất. Một văn bản mã cũ có thể đọc được khi dùng đúng font, rồi xuất hiện ký tự lạ khi chuyển sang font khác. Vì vậy, tên font là manh mối để chọn cách chuyển mã, không phải bằng chứng tuyệt đối. Thay font có thể giúp nhìn đúng tại chỗ nhưng chưa làm nội dung trở thành Unicode để trao đổi thuận tiện.
TCVN3 (ABC)
TCVN3, thường gọi là ABC, là bảng mã tiếng Việt cũ hay đi cùng các font thuộc họ.Vn như.VnTime hoặc.VnArial. Khi biểu diễn bằng font Unicode thông thường, văn bản có thể mang dạng TiÕng ViÖt, lµ hoặc ®Õn. Công cụ hỗ trợ TCVN3 ở cả phía nguồn lẫn phía đích. Điểm dễ nhầm là coi.VnTime và bảng mã là một khái niệm; thực tế một bên là font, bên kia là quy ước biểu diễn. Tài liệu dùng font hoa còn cần kiểm tra riêng cách thể hiện chữ hoa.
VNI Windows
VNI Windows là bảng mã cũ thường gắn với các font như VNI-Times hoặc VNI-Helve. Một số chữ được biểu diễn bằng cặp ký tự, nên khi đọc không đúng môi trường có thể thấy Tieáng Vieät thay vì “Tiếng Việt”. Đây là nguồn và đích mà công cụ hỗ trợ. Không nên nhầm bảng mã VNI Windows với kiểu gõ VNI: kiểu gõ dùng phím số để nhập dấu, còn bảng mã nói về cách nội dung được biểu diễn sau khi nhập. Dùng kiểu gõ VNI không bắt buộc văn bản phải mang bảng mã VNI Windows.
Unicode dựng sẵn và Unicode tổ hợp
Unicode dựng sẵn dùng ký tự đã ghép khi có thể, còn Unicode tổ hợp tách chữ cơ sở và dấu kết hợp. Công cụ dùng chuẩn hóa NFC cho đích dựng sẵn và NFD cho đích tổ hợp. Một chữ nhìn như nhau có thể vì thế có cấu tạo chuỗi khác nhau, ảnh hưởng đến đếm độ dài hoặc so khớp chính xác. Không nên xem dạng tổ hợp là văn bản hỏng chỉ vì cấu tạo khác. Cũng cần phân biệt UTF-8: đó là cách mã hóa nội dung Unicode thành byte trong tệp, không phải tên font hay tên kiểu gõ.
VIQR
VIQR là quy ước biểu diễn tiếng Việt bằng ký tự ASCII: dấu mũ, dấu cộng, dấu ngoặc và một số dấu câu được dùng để thể hiện dấu chữ, dấu thanh. Ví dụ, Tie^'ng biểu diễn “Tiếng”. Công cụ có thể đọc và tạo dạng này, nhưng dấu câu đứng sát nguyên âm có thể mang ý nghĩa đặc biệt. Dấu gạch chéo ngược được dùng để giữ nghĩa đen khi giải mã. VIQR không phải phương thức bảo mật: nhìn khó đọc hơn không có nghĩa nội dung đã được mã hóa để giữ bí mật.
Đầu vào, đầu ra và cách đọc kết quả chuyển mã
Văn bản nguồn và lựa chọn bảng mã
Đầu vào chính là văn bản thuần được nhập, dán hoặc đọc từ tệp văn bản. Nguồn có các lựa chọn TCVN3, VNI Windows, Unicode dựng sẵn, Unicode tổ hợp và VIQR, bên cạnh chế độ tự động. Đích có năm dạng tương ứng cùng lựa chọn tiếng Việt không dấu. Chọn nguồn đúng là điều kiện để diễn giải đúng chuỗi; chọn đích chỉ quyết định cách biểu diễn kết quả sau đó.
Bộ đọc không phải bộ mở tài liệu Word, Excel hay PDF. Với những tài liệu này, phần chữ sao chép có thể làm đầu vào, nhưng bảng biểu, màu sắc và kiểu chữ không đi theo quy trình chuyển đổi. Khi nguồn rỗng, kết quả cũng rỗng, thông báo bảng mã được ẩn và cả hai bộ đếm trở về 0.
Ý nghĩa nhãn nhận diện và bộ đếm
Nhãn “Nhận diện” phản ánh phương án mà công cụ ước đoán; nhãn “Nguồn” phản ánh lựa chọn thủ công của người dùng. Hai nhãn không chứng nhận toàn bộ văn bản đã đúng, cũng không cung cấp phần trăm tin cậy. Cần đọc kết quả trong ngữ cảnh, nhất là tên riêng hoặc nội dung có nhiều ngôn ngữ.
Bộ đếm mang nhãn ký tự nhưng thực tế tính đơn vị mã UTF-16. Một chữ có nhiều dấu kết hợp có thể chiếm nhiều đơn vị; một số emoji cũng có độ dài khác số hình mà người đọc thấy. Đây không phải số byte của tệp, số từ hoặc phép đo độ dài hiển thị.
Nội dung sao chép khác gì tệp tải xuống?
Sao chép lấy chuỗi kết quả để đưa sang ứng dụng khác; khả năng thực hiện phụ thuộc quyền và hỗ trợ bộ nhớ tạm của trình duyệt. Tệp tải xuống được tạo dưới dạng văn bản UTF-8. Ngay cả khi đích là TCVN3 hoặc VNI, tệp vẫn chứa chuỗi ký tự biểu diễn mã cũ được lưu bằng UTF-8, không phải tệp byte TCVN3/VNI nguyên bản. Nếu bên nhận yêu cầu mã hóa byte cũ, cần phân biệt yêu cầu đó với nội dung trông giống mã cũ.
Công cụ nhận diện và chuyển mã theo nguyên tắc nào?
Chuyển qua Unicode trung gian
Đường đi chung là nguồn → Unicode trung gian → đích. Trước hết, công cụ diễn giải văn bản theo nguồn được chọn hoặc nhận diện. Sau đó, nội dung được đưa sang biểu diễn đích. Cách tổ chức này cho phép chuyển giữa hai bảng mã cũ thông qua Unicode, thay vì phải có một quy trình riêng cho mọi cặp nguồn và đích.
Khi đọc TCVN3 và VNI, công cụ ưu tiên thử cặp hai ký tự trước khi xét từng ký tự đơn. Điều này quan trọng vì một chữ tiếng Việt có thể được biểu diễn bằng nhiều ký tự trong bảng chuyển đổi. Phần không khớp bảng ánh xạ được giữ nguyên, không được đoán lại theo ngữ nghĩa. Do đó, việc một ký hiệu còn nguyên sau chuyển đổi chưa chứng minh rằng nó đúng.
Tự nhận diện bằng dấu hiệu và điểm số
Nếu gặp dấu kết hợp trong vùng U+0300–U+036F, chế độ tự động chọn Unicode tổ hợp ngay. Nếu không gặp, công cụ so sánh bốn phương án: giữ theo Unicode dựng sẵn, giải mã TCVN3, giải mã VNI và giải mã VIQR. Mỗi phương án được đánh giá bằng các dấu hiệu ký tự, không thông qua bước xác nhận từ điển.
Công thức là: điểm = 3 × số chữ Việt − 3 × số ký tự bất thường − 4 × số dấu hiệu lỗi chữ hoa + điểm dấu hiệu mã. “Chữ Việt” và “bất thường” ở đây được xác định theo các tập ký tự trong bộ xử lý. Dấu hiệu chữ hoa Latin-1 chen cạnh chữ thường bị trừ điểm. TCVN3 được cộng 4 điểm cho mỗi dấu hiệu đặc trưng; VNI được cộng 4 điểm cho mỗi cặp hợp lệ.
Đây là thang điểm ước đoán, không phải xác suất đúng. Khi bằng điểm, phương án xuất hiện trước được giữ theo thứ tự Unicode dựng sẵn, TCVN3, VNI rồi VIQR. Vì vậy, chuỗi ít dấu có thể được giữ là Unicode mà không đủ bằng chứng xác định nguồn gốc thực sự.
Chuẩn hóa, bỏ dấu và đổi chiều
Đích Unicode dựng sẵn dùng NFC, đích tổ hợp dùng NFD. Khi tạo TCVN3, VNI hoặc VIQR, nội dung được chuẩn hóa NFC trước. Bỏ dấu đổi đ/Đ thành d/D rồi loại dấu kết hợp trong vùng được xử lý. Với VIQR, cách đọc theo thứ tự nguyên âm, dấu hình dạng rồi dấu thanh; gạch chéo ngược bảo vệ ký tự kế tiếp theo nghĩa đen.
Đổi chiều lấy kết quả hiện có làm nguồn mới khi kết quả không rỗng và hoán đổi hướng chuyển phù hợp. Đây là chuyển tiếp, không phải hoàn tác có bảo đảm. Riêng kết quả không dấu được coi là Unicode dựng sẵn khi đổi chiều; thông tin dấu đã mất không xuất hiện trở lại.
Ví dụ chuyển TCVN3, VNI, Unicode tổ hợp và VIQR
Hai dạng lỗi mã cũ, một kết quả Unicode
Các ví dụ dưới đây được suy ra từ bảng ánh xạ và quy tắc xử lý đã cung cấp. Giả định mỗi chuỗi thuộc đúng bảng mã nguồn được nêu và đích là Unicode dựng sẵn. Đầu vào là văn bản, không có đơn vị đo vật lý.
| Đầu vào giả định | Nguồn chỉ định | kết quả |
|---|---|---|
| TiÕng ViÖt | TCVN3 | Tiếng Việt |
| Tieáng Vieät | VNI Windows | Tiếng Việt |
Ở trường hợp TCVN3, Õ và Ö được ánh xạ thành ế và ệ. Ở trường hợp VNI, các cặp eá và eä được đọc thành hai chữ tương ứng. Những chữ ASCII cùng khoảng trắng còn lại được giữ nguyên. Hai đầu vào độc lập cho cùng nội dung đọc được, nhưng không thể dùng chung một lựa chọn nguồn chỉ vì chúng có cùng ý nghĩa.
Chữ không đổi hình nhưng thay đổi độ dài
Giả định đầu vào chỉ có chữ ế ở dạng Unicode dựng sẵn và chọn đích Unicode tổ hợp. NFD tách chữ này thành e, dấu mũ U+0302 và dấu sắc U+0301. Nếu môi trường hiển thị dấu kết hợp đúng, người đọc vẫn thấy một chữ ế.
Tuy vậy, bộ đếm thay đổi từ 1 sang 3 đơn vị mã UTF-16, vì cả ba thành phần đều dùng một đơn vị mã. Không nên diễn đạt đây là ba chữ cái hoặc nội dung bị nhân ba. Chuyển ngược về NFC có thể ghép lại biểu diễn dựng sẵn; sự khác nhau nằm ở cấu tạo chuỗi chứ không nhất thiết ở hình thức đọc.
Bỏ dấu và giữ dấu câu trong VIQR
Với đầu vào Unicode dựng sẵn Đặng, đích không dấu cho Dang: Đ chuyển thành D, còn dấu trăng và dấu nặng trên nguyên âm bị loại bỏ sau phân tách. Đổi chiều từ “Dang” không tái tạo được “Đặng”, vì không còn thông tin xác định các dấu ban đầu.
Với nguồn VIQR, a. cho kết quả ạ, vì dấu chấm ngay sau nguyên âm được đọc là dấu nặng. Ngược lại, a\. cho kết quả a., vì gạch chéo ngược giữ dấu chấm theo nghĩa đen. Khác biệt nhỏ ở đầu vào làm thay đổi nghĩa của kết quả.
Một ví dụ nhận diện khác là abc: các phương án đều có điểm 0 nên Unicode dựng sẵn được giữ và kết quả vẫn là abc. Nhãn này phản ánh quy tắc hòa điểm, không chứng minh công cụ biết chắc bảng mã lịch sử của chuỗi ASCII.
Khi nào nên dùng công cụ chuyển mã tiếng Việt?
Tái sử dụng phần chữ từ tài liệu cũ
Công cụ phù hợp khi cần lấy nội dung từ tài liệu cũ để đưa vào email, trang web hoặc tài liệu mới mà không mang theo cách biểu diễn lỗi thời. Trước khi thay bản gốc, nên đối chiếu một số đoạn có nhiều dấu, tên người, địa danh và chữ hoa. Đọc trôi chảy phần lớn văn bản chưa đủ bảo đảm mọi ký tự đã đúng, nhất là dữ liệu sẽ dùng để công bố hoặc tra cứu.
Chuẩn hóa trước khi tìm kiếm hoặc nhập liệu
Nếu chữ nhìn đúng nhưng so khớp chính xác không như mong đợi, chuẩn hóa Unicode có thể hữu ích khi nguyên nhân là khác biệt dựng sẵn và tổ hợp. Hiệu quả còn phụ thuộc hệ thống tiếp nhận có tự chuẩn hóa hay không, cũng như cách nó xử lý khoảng trắng và các ký hiệu khác. Không nên coi chuyển về NFC là cách chữa mọi lỗi tìm kiếm.
Đầu ra không dấu phù hợp với trường nhập liệu thực sự yêu cầu bỏ dấu. Tuy nhiên, công cụ không vì thế trở thành bộ tạo đường dẫn hoặc tên tệp hợp lệ: dấu câu, khoảng trắng và các ràng buộc riêng của hệ thống vẫn cần được xem xét.
Đáp ứng yêu cầu định dạng của bên nhận
Có thể tạo VIQR hoặc biểu diễn mã cũ khi bên nhận yêu cầu rõ ràng. Trước khi sử dụng, cần xác nhận họ cần bảng mã nào, font nào và có yêu cầu mã hóa byte của tệp hay chỉ cần chuỗi để dán vào ứng dụng. Ba yêu cầu này không tự động tương đương.
Nếu nhu cầu là nhập tiếng Việt mới thay vì chuyển văn bản đã có, chủ đề phù hợp hơn là gõ tiếng Việt trực tuyến bằng Telex hoặc VNI. Đó là nhu cầu nhập chữ, khác với diễn giải lại nội dung đang có bảng mã cũ.
Đổi font, chuyển mã và chuẩn hóa Unicode khác nhau thế nào?
Ba cách xử lý này tác động đến các lớp khác nhau của văn bản. Chọn đúng lớp giúp tránh tình trạng đổi nhiều font mà nội dung vẫn lỗi khi gửi sang nơi khác, hoặc chuẩn hóa Unicode trong khi đầu vào thực chất đang là mã cũ.
| Cách xử lý | Yếu tố thay đổi | Tình huống phù hợp | Điều không giải quyết |
|---|---|---|---|
| Đổi font | Cách vẽ và thể hiện chữ | Điều chỉnh kiểu dáng hoặc đọc văn bản mã cũ bằng font tương ứng | Không tự biến nội dung mã cũ thành Unicode |
| Chuyển mã | Biểu diễn ký tự theo bảng ánh xạ | Đưa TCVN3, VNI hoặc VIQR sang cách biểu diễn cần dùng | Không phục hồi ký tự đã mất; phụ thuộc việc hiểu đúng nguồn |
| Chuẩn hóa Unicode | Cấu tạo các chuỗi Unicode tương đương | Đưa về NFC hoặc NFD để thống nhất biểu diễn | Không tự giải mã TCVN3/VNI, không chữa mọi lỗi trích xuất PDF |
Về nguyên tắc lựa chọn, nếu văn bản xuất hiện ký tự lạ như một dạng mã cũ, hãy kiểm tra cách diễn giải bảng mã. Nếu chữ đọc đúng nhưng thao tác so khớp cho kết quả khác, hãy xem xét cấu tạo Unicode cùng các yếu tố như khoảng trắng. Nếu chỉ không hài lòng về nét chữ, độ đậm hoặc kiểu dáng, vấn đề có thể nằm ở font và định dạng.
Một tài liệu có thể cần nhiều cách xử lý liên tiếp: chuyển phần chữ về Unicode trước, sau đó chọn font và định dạng trong ứng dụng soạn thảo. Công cụ này tạo chuỗi văn bản để phục vụ phần chuyển đổi; nó không tự làm toàn bộ công việc trình bày tài liệu. Cũng không nên áp dụng chuyển mã vào văn bản vốn đã đúng chỉ vì muốn thay đổi hình thức hiển thị.
Giới hạn và những điểm cần kiểm tra trước khi dùng kết quả
Nhận diện sai và nội dung trộn mã
Văn bản ngắn, ít dấu, nhiều ngôn ngữ hoặc trộn bảng mã có thể khiến nhận diện không phù hợp. Công cụ chọn một nguồn cho toàn bộ đầu vào, không phân đoạn để tự chọn mã riêng. Khi biết nguồn, nên dùng lựa chọn thủ công; nếu các phần thuộc mã khác nhau, cần xử lý riêng. Với VIQR, hãy soát dấu câu và ký hiệu đặc biệt, vì không có bảo đảm mọi chuỗi chuyển đi rồi về đều giữ nguyên văn.
Chữ hoa, tệp cũ và ký tự đã mất
Tài liệu dùng font hoa như.VnTimeH cần đối chiếu riêng: công cụ không đọc thông tin font hay phục dựng kiểu hoa dựa trên font. Khi mở tệp văn bản, bộ đọc thử UTF-8 trước rồi đọc lại bằng Windows-1252 nếu thấy ký tự �. Đây chỉ là phương án dự phòng, không phải bộ nhận diện mọi mã hóa tệp. Chữ đã bị ghi đè bằng dấu hỏi hoặc ký tự thay thế không được khôi phục nhờ phép chuyển này.
Hiệu năng, sao chép và phạm vi xác minh riêng tư
Không có giới hạn độ dài hoặc dung lượng được đặt rõ trong phần xử lý đã cung cấp, nhưng điều đó không đồng nghĩa xử lý vô hạn. Hiệu năng và khả năng sao chép thực tế trên từng trình duyệt chưa được xác minh; thông báo ở nhánh sao chép dự phòng cũng chưa đủ chứng minh bộ nhớ tạm đã nhận nội dung.
Phần chuyển đổi và đọc tệp dùng chức năng trình duyệt. Tuy nhiên, chỉ từ phần này không thể bảo đảm toàn bộ trang không lưu hoặc truyền văn bản qua thành phần khác. Với dữ liệu nhạy cảm, không nên suy ra cam kết riêng tư tuyệt đối từ phạm vi quan sát hạn chế đó.
Câu hỏi thường gặp
Tự nhận diện sai bảng mã thì nên xử lý thế nào?
Nên chọn nguồn thủ công nếu bạn biết văn bản xuất phát từ bảng mã nào, rồi đối chiếu các từ có dấu rõ ràng trong kết quả. Không nên chỉ đổi đích liên tục, vì lỗi diễn giải nguồn có thể đã xảy ra trước khi tạo đầu ra. Nếu một đoạn đúng nhưng đoạn khác sai, hãy xem xét khả năng trộn mã và xử lý từng phần riêng. Nhãn nhận diện chỉ là gợi ý từ dấu hiệu ký tự, không thay thế việc kiểm tra nội dung.
Có thể mở trực tiếp tệp Word, Excel hoặc PDF và giữ nguyên định dạng không?
Không có chức năng được xác nhận để mở trực tiếp những tài liệu đó và giữ nguyên định dạng. Đầu vào phù hợp là phần chữ được sao chép hoặc tệp văn bản thuần. Khi lấy chữ từ Word, Excel hay PDF, bạn cần phân biệt nội dung với cấu trúc tài liệu: bảng, hình ảnh, kiểu chữ và bố cục không được công cụ tái tạo. Nếu PDF đã trích xuất sai thứ tự chữ hoặc thiếu ký tự, chuyển mã cũng không tự sửa được các lỗi ấy.
Văn bản đã thành dấu hỏi hoặc ký tự � có khôi phục được không?
Không thể dựa vào công cụ này để khôi phục chữ gốc nếu thông tin đã thực sự bị thay bằng dấu hỏi hoặc �. Cần phân biệt việc đọc sai tệp còn giữ nguyên byte ban đầu với việc lưu lại một bản đã hỏng: trường hợp đầu đôi khi còn cơ hội đọc lại theo mã phù hợp, còn trường hợp sau có thể đã mất dữ liệu. Nguồn tốt hơn là bản gốc chưa bị ghi đè hoặc bản sao trước khi lỗi xuất hiện.
Đổi chiều sau khi bỏ dấu có lấy lại được dấu tiếng Việt không?
Không. Đổi chiều chỉ dùng chuỗi hiện tại để chuyển tiếp, không suy luận ngữ cảnh nhằm thêm dấu. Sau khi bỏ dấu, nhiều từ hoặc tên khác nhau có thể trở thành cùng một chuỗi, nên không còn cách xác định chắc chắn bản ban đầu từ kết quả đó. Nếu cần cả bản có dấu lẫn không dấu, hãy giữ riêng bản nguồn trước khi chuyển. Việc chọn đích Unicode không làm thông tin dấu đã loại bỏ tự xuất hiện trở lại.
Vì sao chữ nhìn giống nhau nhưng số ký tự trước và sau lại khác?
Vì bộ đếm dựa trên đơn vị mã UTF-16, trong khi mắt người nhận diện các hình chữ đã được trình bày. Một chữ dựng sẵn có thể được tách thành chữ cơ sở và nhiều dấu kết hợp khi chuyển sang NFD, khiến số đếm tăng mà nội dung đọc không đổi. Một số emoji cũng không tương ứng với một đơn vị mã. Vì vậy, chênh lệch bộ đếm cần được hiểu theo cấu tạo chuỗi, không mặc nhiên coi là thêm hoặc mất chữ.
Vì sao chọn TCVN3 hoặc VNI mà tệp tải xuống vẫn là UTF-8?
Vì lựa chọn đích quyết định chuỗi ký tự được tạo, còn thao tác tải xuống luôn lưu chuỗi ấy dưới dạng UTF-8. Hai lớp này độc lập trong cách Công cụ. Do đó, tệp chứa biểu diễn TCVN3 hoặc VNI không đồng nghĩa với tệp có byte mã cũ nguyên bản. Nếu hệ thống nhận yêu cầu một mã hóa tệp cụ thể, cần xác nhận yêu cầu kỹ thuật đó; chỉ nhìn tên đích chuyển đổi chưa đủ để kết luận tệp đáp ứng được.
Có thể khẳng định văn bản không bị lưu hoặc gửi khỏi trình duyệt không?
Chưa đủ căn cứ để khẳng định điều đó cho toàn bộ trang. Công cụ cho thấy chuyển đổi chuỗi và đọc tệp bằng chức năng trình duyệt, nhưng không đại diện đầy đủ cho mọi thành phần có thể hiện diện trên trang công cụ. Cũng chưa có xác minh độc lập về lưu trữ hoặc truyền dữ liệu. Với nội dung bí mật, thông tin cá nhân hay hồ sơ nội bộ, nên dựa vào chính sách và đánh giá phù hợp thay vì xem mô tả xử lý là bảo đảm tuyệt đối.