Phương pháp lưu trữ thông tin: dạng văn bản và nhị phân

Chúng ta đã thấy trong nhiều phần trước rằng cùng một thông tin có thể được biểu diễn dưới dạng văn bản và nhị phân. Ví dụ, các số ở định dạng int, long, và double, ngày giờ (datetime) và màu sắc (color) được lưu trữ trong bộ nhớ dưới dạng một chuỗi byte có độ dài nhất định. Phương pháp này gọn gàng và phù hợp hơn để máy tính diễn giải, nhưng đối với con người, việc phân tích thông tin dưới dạng văn bản sẽ thuận tiện hơn, mặc dù nó mất nhiều thời gian hơn. Do đó, chúng ta đã dành nhiều sự chú ý cho việc chuyển đổi số thành chuỗi và ngược lại, cũng như các hàm làm việc với chuỗi.

Ở cấp độ tệp, sự phân chia giữa biểu diễn dữ liệu dạng nhị phân và văn bản cũng được duy trì. Tệp nhị phân được thiết kế để lưu trữ dữ liệu dưới dạng biểu diễn nội bộ giống như trong bộ nhớ. Tệp văn bản chứa biểu diễn dạng chuỗi.

Tệp văn bản thường được sử dụng cho các định dạng tiêu chuẩn như CSV (Comma Separated Values - Giá trị phân tách bằng dấu phẩy), JSON (JavaScript Object Notation - Ký hiệu đối tượng JavaScript), XML (Extensible Markup Language - Ngôn ngữ đánh dấu mở rộng), HTML (HyperText Markup Language - Ngôn ngữ đánh dấu siêu văn bản).

Tệp nhị phân, tất nhiên, cũng có các định dạng tiêu chuẩn cho nhiều ứng dụng, đặc biệt là cho hình ảnh (PNG, GIF, JPG, BMP), âm thanh (WAV, MP3), hoặc kho lưu trữ nén (ZIP). Tuy nhiên, định dạng nhị phân ban đầu giả định mức độ bảo vệ cao hơn và làm việc ở cấp độ thấp với dữ liệu, do đó thường được sử dụng để giải quyết các vấn đề nội bộ, khi chỉ quan tâm đến hiệu quả lưu trữ và khả năng truy cập dữ liệu cho một chương trình cụ thể. Nói cách khác, các đối tượng của bất kỳ cấu trúc hoặc lớp ứng dụng nào cũng có thể dễ dàng lưu và khôi phục trạng thái của chúng trong tệp nhị phân, thực chất là tạo ra một bản sao bộ nhớ mà không cần lo lắng về tính tương thích với bất kỳ tiêu chuẩn nào.

Về lý thuyết, chúng ta có thể tự tay chuyển đổi dữ liệu thành chuỗi khi ghi vào tệp nhị phân và sau đó chuyển đổi ngược lại từ chuỗi thành số (hoặc cấu trúc, hoặc mảng) khi đọc tệp. Điều này sẽ tương tự như những gì chế độ tệp văn bản tự động cung cấp nhưng sẽ đòi hỏi thêm công sức. Chế độ tệp văn bản giúp chúng ta tránh khỏi công việc thường xuyên như vậy. Hơn nữa, hệ thống tệp của MQL5 ngầm thực hiện một số thao tác tùy chọn nhưng quan trọng cần thiết khi làm việc với văn bản.

Thứ nhất, khái niệm văn bản dựa trên một số quy tắc chung về việc sử dụng các ký tự phân tách. Cụ thể, người ta giả định rằng tất cả các văn bản đều gồm các chuỗi. Cách này thuận tiện hơn để đọc và phân tích chúng theo thuật toán. Do đó, có những ký tự đặc biệt phân tách một chuỗi này với chuỗi khác.

Tại đây, chúng ta đối mặt với những khó khăn đầu tiên liên quan đến việc các hệ điều hành khác nhau chấp nhận các tổ hợp ký tự phân tách khác nhau. Trong Windows, ký tự phân tách dòng là chuỗi hai ký tự '\r\n' (có thể dưới dạng mã thập lục phân: 0xD 0xA, hoặc tên CRLF, viết tắt của Carriage Return và Line Feed - Quay về đầu dòng và Xuống dòng). Trong Unix và Linux, ký tự đơn '\n' là tiêu chuẩn, nhưng một số phiên bản và chương trình trên MacOS có thể sử dụng ký tự đơn '\r'.

Mặc dù MetaTrader 5 chạy trên Windows, chúng ta không có gì đảm bảo rằng bất kỳ tệp văn bản kết quả nào cũng sẽ không được lưu với các ký tự phân tách bất thường. Nếu chúng ta đọc nó ở chế độ nhị phân và tự kiểm tra các ký tự phân tách để tạo thành chuỗi, những khác biệt này sẽ đòi hỏi xử lý cụ thể. Ở đây, chế độ hoạt động tệp văn bản trong MQL5 đến để giải cứu: nó tự động chuẩn hóa các ngắt dòng khi đọc và ghi.

INFO

MQL5 có thể không sửa ngắt dòng cho tất cả các trường hợp. Cụ thể, ký tự đơn '\r' sẽ không được diễn giải thành '\r\n' khi đọc tệp văn bản, trong khi ký tự đơn '\n' được diễn giải chính xác thành '\r\n'.

Thứ hai, chuỗi có thể được lưu trữ trong bộ nhớ dưới nhiều biểu diễn khác nhau. Theo mặc định, kiểu string trong MQL5 bao gồm các ký tự hai byte. Điều này cung cấp hỗ trợ cho mã hóa Unicode phổ quát, điều này rất tuyệt vì nó bao gồm tất cả các bảng chữ cái quốc gia. Tuy nhiên, trong nhiều trường hợp, tính phổ quát như vậy không cần thiết (ví dụ, khi lưu trữ số hoặc thông điệp bằng tiếng Anh), trong trường hợp đó, việc sử dụng chuỗi ký tự một byte trong mã hóa ANSI sẽ hiệu quả hơn. Các hàm API của MQL5 cho phép bạn chọn cách ghi chuỗi ưa thích trong chế độ văn bản vào tệp. Nhưng nếu chúng ta kiểm soát việc ghi trong chương trình MQL của mình, chúng ta có thể đảm bảo tính hợp lệ và độ tin cậy khi chuyển từ Unicode sang ký tự một byte. Trong trường hợp này, khi tích hợp với một số phần mềm hoặc dịch vụ web bên ngoài, trang mã ANSI trong tệp của nó có thể là bất kỳ. Về vấn đề này, điểm tiếp theo xuất hiện.

Thứ ba, do sự hiện diện của nhiều ngôn ngữ khác nhau, bạn cần sẵn sàng cho các văn bản trong các mã hóa ANSI khác nhau. Nếu không diễn giải đúng mã hóa, văn bản có thể được ghi hoặc đọc với sự méo mó, hoặc thậm chí trở nên không thể đọc được. Chúng ta đã thấy điều này trong phần Làm việc với ký tự và trang mã. Đây là lý do tại sao các hàm tệp đã bao gồm các phương tiện để xử lý ký tự chính xác: chỉ cần chỉ định mã hóa mong muốn hoặc dự kiến trong các tham số. Việc lựa chọn mã hóa được mô tả chi tiết hơn trong một phần riêng.

Và cuối cùng, chế độ văn bản có hỗ trợ tích hợp cho định dạng CSV nổi tiếng. Vì giao dịch thường yêu cầu dữ liệu dạng bảng, CSV rất phù hợp cho điều này. Trong tệp văn bản ở chế độ CSV, các hàm API của MQL5 không chỉ xử lý các ký tự phân tách để xuống dòng văn bản mà còn xử lý một ký tự phân tách bổ sung cho ranh giới của các cột (các trường trong mỗi hàng của bảng). Điều này thường là ký tự tab '\t', dấu phẩy ',' hoặc dấu chấm phẩy ';'. Ví dụ, dưới đây là cách một tệp CSV với tin tức Forex trông như thế này (đoạn phân tách bằng dấu phẩy được hiển thị):

Title,Country,Date,Time,Impact,Forecast,Previous
Bank Holiday,JPY,08-09-2021,12:00am,Holiday,,
CPI y/y,CNY,08-09-2021,1:30am,Low,0.8%,1.1%
PPI y/y,CNY,08-09-2021,1:30am,Low,8.6%,8.8%
Unemployment Rate,CHF,08-09-2021,5:45am,Low,3.0%,3.1%
German Trade Balance,EUR,08-09-2021,6:00am,Low,13.9B,12.6B
Sentix Investor Confidence,EUR,08-09-2021,8:30am,Low,29.2,29.8
JOLTS Job Openings,USD,08-09-2021,2:00pm,Medium,9.27M,9.21M
FOMC Member Bostic Speaks,USD,08-09-2021,2:00pm,Medium,,
FOMC Member Barkin Speaks,USD,08-09-2021,4:00pm,Medium,,
BRC Retail Sales Monitor y/y,GBP,08-09-2021,11:01pm,Low,4.9%,6.7%
Current Account,JPY,08-09-2021,11:50pm,Low,1.71T,1.87T

Và đây là dạng bảng để rõ ràng hơn:

Title	Country	Date	Time	Impact	Forecast	Previous
Bank Holiday	JPY	08-09-2021	12:00am	Holiday
CPI y/y	CNY	08-09-2021	1:30am	Low	0.8%	1.1%
PPI y/y	CNY	08-09-2021	1:30am	Low	8.6%	8.8%
Unemployment Rate	CHF	08-09-2021	5:45am	Low	3.0%	3.1%
German Trade Balance	EUR	08-09-2021	6:00am	Low	13.9B	12.6B
Sentix Investor Confidence	EUR	08-09-2021	8:30am	Low	29.2	29.8
JOLTS Job Openings	USD	08-09-2021	2:00pm	Medium	9.27M	9.21M
FOMC Member Bostic Speaks	USD	08-09-2021	2:00pm	Medium
FOMC Member Barkin Speaks	USD	08-09-2021	4:00pm	Medium
BRC Retail Sales Monitor y/y	GBP	08-09-2021	11:01pm	Low	4.9%	6.7%
Current Account	JPY	08-09-2021	11:50pm	Low	1.71T	1.87T