Chuyển sang Unicode cho ứng dụng xử lý các tệp văn bản

Question

Ứng dụng Win32 Delphi của tôi phân tích các tệp văn bản được tạo bởi các ứng dụng khác không hỗ trợ Unicode. Vì vậy, các ứng dụng của tôi cần đọc và viết các chuỗi ansi, nhưng tôi muốn cung cấp một trải nghiệm người dùng bản địa hóa tốt hơn thông qua việc sử dụng Unicode trong GUI. Ứng dụng này thực hiện một số phân tích chuỗi ký tự theo ký tự khá nặng trong các đối tượng có nguồn gốc từ TList.

Khi đưa ra việc chuyển đổi sang một giao diện Unicode trong đi từ Delphi 2006 đến Delphi 2009, tôi nên có kế hoạch để:

1. đi hoàn toàn Unicode trong ứng dụng của tôi, với ngoại lệ của AnsiString tập tin I/O?
2. đóng gói mã xử lý ansistrings (tức là tiếp tục xử lý chúng dưới dạng ansistrings nội bộ) từ một ứng dụng Unicode khác.

Tôi nhận thấy phản hồi thực sự chi tiết sẽ đòi hỏi một lượng lớn mã của tôi - tôi chỉ hỏi về những lần hiển thị từ những người đã chuyển đổi này và vẫn phải làm việc với tệp văn bản thuần túy. Nơi để đặt rào cản giữa ansistrings và Unicode?

CHỈNH SỬA: nếu # 1, có đề xuất nào để ánh xạ chuỗi Unicode cho đầu ra ansistring không? Tôi đoán rằng việc chuyển đổi các chuỗi đầu vào sẽ được tự động bằng cách sử dụng tstringlist.loadfromfile (ví dụ).

Answer 1

Không có thứ gì như đầu ra AnsiString - mỗi tệp văn bản có character encoding. Thời điểm các tệp của bạn chứa các ký tự nằm ngoài phạm vi ASCII bạn phải suy nghĩ về mã hóa, thậm chí tải các tệp đó ở các quốc gia khác nhau sẽ tạo ra các kết quả khác nhau - trừ khi bạn tình cờ sử dụng mã hóa Unicode.

Nếu bạn tải tệp văn bản, bạn cần biết mã hóa của tệp đó. Đối với các định dạng như xml hoặc html thông tin đó là một phần của văn bản, đối với Unicode, có BOM, mặc dù nó không cần thiết đối với các tệp được mã hóa UTF-8.

Chuyển đổi ứng dụng sang Delphi 2009 là cơ hội để suy nghĩ về mã hóa các tệp văn bản và các lỗi trong quá khứ chính xác. Các tệp dữ liệu của một ứng dụng thường có thời lượng lâu hơn các ứng dụng, do đó, nó trả tiền để suy nghĩ về cách làm cho chúng trở nên tương lai và bằng chứng. Tôi khuyên bạn nên sử dụng UTF-8 làm mã hóa tệp văn bản cho tất cả các ứng dụng mới, theo cách đó, việc chuyển ứng dụng sang các nền tảng khác nhau thật dễ dàng. UTF-8 là mã hóa tốt nhất để trao đổi dữ liệu và đối với các ký tự trong phạm vi ASCII hoặc ISO8859-1, nó cũng tạo ra nhiều tệp nhỏ hơn nhiều so với UTF-16 hoặc UTF-32.

Nếu tệp dữ liệu của bạn chỉ chứa các ký tự ASCII, thì tất cả đều được đặt, vì chúng là các tệp được mã hóa UTF-8 hợp lệ. Nếu tệp dữ liệu của bạn có mã hóa ISO8859-1 (hoặc bất kỳ mã hóa cố định nào khác), thì hãy sử dụng chuyển đổi phù hợp trong khi tải chúng vào danh sách chuỗi và lưu chúng trở lại. Nếu bạn không biết trước họ sẽ có mã hóa nào, hãy hỏi người dùng khi tải hoặc cung cấp cài đặt ứng dụng cho mã hóa mặc định.

Sử dụng chuỗi Unicode trong nội bộ. Tùy thuộc vào lượng dữ liệu bạn cần xử lý, bạn có thể sử dụng chuỗi được mã hóa UTF-8.

Answer 2

Tôi đề xuất bạn nên sử dụng chế độ unicode đầy đủ nếu cần nỗ lực và yêu cầu. Và giữ tập tin ANSI I/O tách ra khỏi phần còn lại. Nhưng điều này phụ thuộc mạnh mẽ từ ứng dụng của bạn.

Answer 3

Bạn nói:

"Ứng dụng hiện một số khá nặng ký tự bằng ký tự phân tích chuỗi trong đối tượng có nguồn gốc từ TList."

Vì Windows chạy Unicode nguyên bản, bạn có thể thấy phân tích ký tự của mình chạy nhanh hơn nếu bạn tải tệp văn bản nội bộ dưới dạng Unicode.

Mặt khác, nếu đó là một tệp lớn, bạn cũng sẽ thấy nó mất gấp đôi bộ nhớ.

Để biết thêm về vấn đề này, xem bài viết Jan Goyvaert của: "Speed Benefits of Using the Native Win32 String Type"

Vì vậy, nó là một sự cân bằng bạn phải quyết định trên.

Answer 4

Nếu bạn định lấy đầu vào Unicode từ GUI, chiến lược sẽ là gì để chuyển đổi nó thành đầu ra ASCII? (Đây là một giả định khi bạn đề cập đến văn bản Ansi viết trở lại, giả định cho các ứng dụng không dựa trên Unicode mà bạn sẽ không viết lại và giả định không có mã nguồn cho.) Tôi khuyên bạn nên ở lại với AnsiString trong suốt ứng dụng cho đến khi các ứng dụng khác được bật Unicode. Nếu công việc chính của ứng dụng của bạn là phân tích các tệp loại ASCII không phải Unicode, thì tại sao lại chuyển sang Unicode trong nội bộ? Nếu công việc chính của ứng dụng của bạn liên quan đến việc có một GUI được bật Unicode tốt hơn thì hãy chuyển sang Unicode. Tôi không tin rằng có đủ thông tin được trình bày để quyết định lựa chọn phù hợp.

Nếu không có cơ hội cho các ký tự không dễ dịch được ghi lại cho các ứng dụng không phải Unicode này, thì đề xuất cho UTF-8 là cách có khả năng thực hiện. Tuy nhiên, nếu có cơ hội thì các ứng dụng không phải Unicode sẽ xử lý các ký tự nhiều byte như thế nào? Làm thế nào bạn sẽ chuyển đổi sang (giả định) bộ ký tự ASCII cơ bản?