Hôm nay chúng ta sẽ nói về nguồn gốc của krakozyabrs trên một trang web và trong các chương trình, những mã hóa văn bản nào tồn tại và những mã nào nên được sử dụng. Chúng ta hãy xem xét kỹ hơn lịch sử phát triển của chúng, bắt đầu với ASCII cơ bản, cũng như các phiên bản mở rộng CP866, KOI8-R, Windows 1251 và kết thúc bằng mã hóa tập đoàn Unicode hiện đại UTF 16 và 8 .
Đối với một số người, thông tin này có vẻ không cần thiết, nhưng bạn có biết tôi nhận được bao nhiêu câu hỏi cụ thể liên quan đến krakozyabrs đang thu thập dữ liệu (bộ ký tự không thể đọc được). Bây giờ tôi sẽ có cơ hội để mọi người tham khảo nội dung bài viết này và tự tìm ra những sai sót của mình. Chà, hãy sẵn sàng tiếp thu thông tin và cố gắng theo dõi diễn biến của câu chuyện.
ASCII - mã hóa văn bản cơ bản cho bảng chữ cái Latinh
Sự phát triển của mã hóa văn bản xảy ra đồng thời với sự hình thành của ngành CNTT và trong thời gian này, chúng đã trải qua khá nhiều thay đổi. Trong lịch sử, tất cả đều bắt đầu với EBCDIC, một ngôn ngữ khá khác biệt trong cách phát âm tiếng Nga, giúp mã hóa các chữ cái trong bảng chữ cái Latinh, chữ số Ả Rập và dấu chấm câu bằng các ký tự điều khiển. Tuy nhiên, điểm khởi đầu cho sự phát triển của mã hóa văn bản hiện đại nên được coi là ASCII nổi tiếng (Mã trao đổi thông tin tiêu chuẩn Mỹ, mà trong tiếng Nga thường được phát âm là “hỏi”). Nó mô tả 128 ký tự đầu tiên được người dùng nói tiếng Anh sử dụng phổ biến nhất - chữ cái Latinh, chữ số Ả Rập và dấu chấm câu. 128 ký tự được mô tả trong ASCII này cũng bao gồm một số ký tự dịch vụ như dấu ngoặc, dấu thăng, dấu hoa thị, v.v. Trên thực tế, bạn có thể tự mình nhìn thấy chúng: Chính 128 ký tự này từ phiên bản gốc của ASCII đã trở thành tiêu chuẩn và trong bất kỳ bảng mã nào khác, bạn chắc chắn sẽ tìm thấy chúng và chúng sẽ xuất hiện theo thứ tự này. Nhưng thực tế là với sự trợ giúp của một byte thông tin, bạn có thể mã hóa không phải 128 mà là 256 giá trị khác nhau (hai lũy thừa của tám bằng 256), do đó, sau phiên bản cơ bản của Asuka, toàn bộ loạt mã hóa ASCII mở rộng đã xuất hiện , trong đó có thể, ngoài 128 ký tự cơ bản còn có thể được mã hóa bằng các ký tự mã hóa quốc gia (ví dụ: tiếng Nga). Ở đây, có lẽ cần phải nói thêm một chút về hệ thống số được sử dụng trong phần mô tả. Thứ nhất, như các bạn đã biết, máy tính chỉ làm việc với các số trong hệ nhị phân, tức là với số 0 và số 1 (“đại số Boolean”, nếu có ai học ở viện, trường). Một byte bao gồm tám bit, mỗi bit đại diện cho lũy thừa hai của hai, bắt đầu từ 0 và lên đến hai đến thứ bảy: Không khó hiểu rằng tất cả các kết hợp có thể có của số 0 và số 1 trong cấu trúc như vậy có thể chỉ là 256. Chuyển một số từ hệ nhị phân sang hệ thập phân khá đơn giản. Bạn chỉ cần cộng tất cả lũy thừa của hai với lũy thừa ở trên chúng. Trong ví dụ của chúng ta, kết quả này là 1 (2 lũy thừa 0) cộng 8 (hai lũy thừa 3), cộng 32 (hai lũy thừa năm), cộng 64 (lũy thừa sáu), cộng 128 (đến lũy thừa thứ bảy). Tổng số là 233 theo ký hiệu thập phân. Như bạn có thể thấy, mọi thứ đều rất đơn giản. Nhưng nếu bạn nhìn kỹ vào bảng có các ký tự ASCII, bạn sẽ thấy chúng được biểu diễn dưới dạng mã thập lục phân. Ví dụ: "dấu hoa thị" tương ứng với số thập lục phân 2A trong Aski. Chắc hẳn bạn đã biết rằng trong hệ thập lục phân, ngoài chữ số Ả Rập, các chữ cái Latinh từ A (có nghĩa là mười) đến F (có nghĩa là mười lăm) cũng được sử dụng. Vâng, để chuyển đổi một số nhị phân thành số thập lục phânhãy áp dụng phương pháp đơn giản sau đây. Mỗi byte thông tin được chia thành hai phần bốn bit. Những thứ kia. Trong mỗi nửa byte, chỉ có mười sáu giá trị (hai đến lũy thừa thứ tư) có thể được mã hóa ở dạng nhị phân, có thể dễ dàng biểu diễn dưới dạng số thập lục phân. Hơn nữa, ở nửa bên trái của byte, độ sẽ cần được tính lại bắt đầu từ 0 chứ không phải như trong ảnh chụp màn hình. Kết quả là chúng ta có được số E9 được mã hóa trong ảnh chụp màn hình. Tôi hy vọng rằng quá trình lập luận của tôi và lời giải cho câu đố này đã rõ ràng với bạn. Chà, trên thực tế, bây giờ chúng ta hãy tiếp tục nói về mã hóa văn bản.
Phiên bản mở rộng của mã hóa Asuka - CP866 và KOI8-R với đồ họa giả
Vì vậy, chúng tôi bắt đầu nói về ASCII, vốn là điểm khởi đầu cho sự phát triển của tất cả các bảng mã hiện đại (Windows 1251, Unicode, UTF 8). Ban đầu, nó chỉ chứa 128 ký tự của bảng chữ cái Latinh, chữ số Ả Rập và một số ký tự khác, nhưng trong phiên bản mở rộng, nó có thể sử dụng tất cả 256 giá trị có thể được mã hóa trong một byte thông tin. Những thứ kia. Có thể thêm các ký hiệu chữ cái trong ngôn ngữ của bạn vào Aski. Ở đây chúng ta sẽ cần phải lạc đề một lần nữa để giải thích lý do tại sao mã hóa văn bản lại cần thiết và tại sao nó lại quan trọng đến vậy. Các ký tự trên màn hình máy tính của bạn được hình thành dựa trên hai thứ - tập hợp các hình dạng vectơ (biểu diễn) của các ký tự khác nhau (chúng nằm trong các tệp có phông chữ được cài đặt trên máy tính của bạn) và mã cho phép bạn lấy ra chính xác ký tự đó từ tập hợp các hình dạng vector (tệp phông chữ) biểu tượng này sẽ cần được chèn vào đúng vị trí. Rõ ràng là bản thân các phông chữ chịu trách nhiệm tạo ra các hình dạng vectơ, nhưng hệ điều hành và các chương trình được sử dụng trong đó chịu trách nhiệm mã hóa. Những thứ kia. bất kỳ văn bản nào trên máy tính của bạn sẽ là một tập hợp các byte, mỗi byte mã hóa một ký tự duy nhất của chính văn bản này. Chương trình hiển thị văn bản này trên màn hình (trình soạn thảo văn bản, trình duyệt, v.v.), khi phân tích mã, đọc mã hóa của ký tự tiếp theo và tìm dạng vectơ tương ứng trong tệp phông chữ được yêu cầu, được kết nối để hiển thị văn bản này dữ liệu văn bản. Mọi thứ đều đơn giản và tầm thường. Điều này có nghĩa là để mã hóa bất kỳ ký tự nào chúng ta cần (ví dụ: từ bảng chữ cái quốc gia), phải đáp ứng hai điều kiện: dạng vectơ của ký tự này phải ở phông chữ được sử dụng và ký tự này có thể được mã hóa theo bảng mã ASCII mở rộng trong một byte. Vì vậy, có rất nhiều lựa chọn như vậy. Chỉ để mã hóa các ký tự tiếng Nga, có một số loại Aska mở rộng. Ví dụ: CP866 ban đầu xuất hiện , có khả năng sử dụng các ký tự từ bảng chữ cái tiếng Nga và nó là phiên bản mở rộng của ASCII. Nghĩa là, phần trên của nó hoàn toàn trùng khớp với phiên bản cơ bản của Aska (128 ký tự Latinh, số và những thứ nhảm nhí khác), được trình bày trong ảnh chụp màn hình ngay phía trên, nhưng phần dưới của bảng có mã hóa CP866 có giao diện như được chỉ ra trong ảnh chụp màn hình ngay bên dưới và được phép mã hóa thêm 128 ký tự khác (chữ cái tiếng Nga và tất cả các loại đồ họa giả): Bạn thấy đấy, ở cột bên phải, các số bắt đầu bằng 8, bởi vì các số từ 0 đến 7 đề cập đến phần cơ bản của ASCII (xem ảnh chụp màn hình đầu tiên). Như vậy, chữ Cyrillic “M” trong CP866 sẽ có mã là 9C (nằm ở giao điểm của dòng tương ứng với 9 và cột có số C trong hệ thập lục phân), có thể viết bằng một byte thông tin. và nếu có phông chữ phù hợp với các ký tự tiếng Nga thì chữ cái này sẽ xuất hiện trong văn bản mà không gặp vấn đề gì. Số tiền này đến từ đâu?bút danh trong CP866 ? Vấn đề chung là cách mã hóa văn bản tiếng Nga này đã được phát triển từ những năm tháng tồi tàn khi hệ điều hành đồ họa chưa phổ biến như bây giờ. Và trong Dosa và các hệ điều hành văn bản tương tự, bút danh ít nhất có thể đa dạng hóa thiết kế văn bản bằng cách nào đó, và do đó CP866 và tất cả các hệ điều hành tương tự khác của nó thuộc danh mục phiên bản mở rộng của Asuka có rất nhiều trong đó. CP866 được IBM phân phối, nhưng ngoài ra, một số mã hóa đã được phát triển cho các ký tự tiếng Nga, ví dụ: KOI8-R có thể được quy cho cùng loại (ASCII mở rộng) : Nguyên tắc hoạt động của nó vẫn giống như của CP866 được mô tả trước đó một chút - Mỗi ký tự của văn bản được mã hóa thành một byte đơn. Ảnh chụp màn hình hiển thị nửa sau của bảng KOI8-R, bởi vì nửa đầu hoàn toàn phù hợp với Asuka cơ bản, được hiển thị trong ảnh chụp màn hình đầu tiên trong bài viết này. Trong số các tính năng của mã hóa KOI8-R, có thể lưu ý rằng các chữ cái Cyrillic trong bảng của nó không theo thứ tự bảng chữ cái, như đã được thực hiện trong CP866. Nếu bạn nhìn vào ảnh chụp màn hình đầu tiên (của phần cơ bản, được bao gồm trong tất cả các bảng mã mở rộng), bạn sẽ nhận thấy rằng trong KOI8-R, các chữ cái tiếng Nga nằm trong cùng các ô của bảng với các chữ cái tương ứng của bảng chữ cái Latinh từ phần đầu tiên của bảng. Điều này được thực hiện để thuận tiện cho việc chuyển đổi từ các ký tự tiếng Nga sang tiếng Latinh bằng cách loại bỏ chỉ một bit (hai đến lũy thừa thứ bảy hoặc 128).
Windows 1251 - phiên bản hiện đại của ASCII và lý do xuất hiện các vết nứt
Sự phát triển hơn nữa của mã hóa văn bản là do các hệ điều hành đồ họa ngày càng phổ biến và nhu cầu sử dụng đồ họa giả trong chúng biến mất theo thời gian. Kết quả là, cả một nhóm phát sinh ra rằng về bản chất, vẫn là các phiên bản mở rộng của Asuka (một ký tự văn bản được mã hóa chỉ bằng một byte thông tin), nhưng không sử dụng các ký hiệu giả. Chúng thuộc về cái gọi là mã hóa ANSI, được phát triển bởi Viện Tiêu chuẩn Hoa Kỳ. Theo cách nói thông thường, tên Cyrillic cũng được sử dụng cho phiên bản có hỗ trợ tiếng Nga. Một ví dụ về điều này sẽ là Windows 1251 . Nó khác biệt thuận lợi so với CP866 và KOI8-R được sử dụng trước đó ở chỗ vị trí của các ký hiệu giả trong đó được thay thế bằng các ký hiệu còn thiếu của kiểu chữ tiếng Nga (ngoại trừ dấu trọng âm), cũng như các ký hiệu được sử dụng trong các ngôn ngữ Slav gần với Tiếng Nga (tiếng Ukraina, tiếng Belarus, v.v.). ): Do có quá nhiều bảng mã của tiếng Nga nên các nhà sản xuất phông chữ, nhà sản xuất phần mềm liên tục phải đau đầu, còn bạn và tôi, những độc giả thân mến, thường xuyên gặp rắc rối với những lỗi khét tiếng tương tự khi có sự nhầm lẫn với phiên bản được sử dụng trong văn bản. Chúng thường xuất hiện khi gửi và nhận tin nhắn qua e-mail, điều này đòi hỏi phải tạo ra các bảng chuyển đổi rất phức tạp, trên thực tế, không thể giải quyết vấn đề này về cơ bản và người dùng thường sử dụng phiên âm các chữ cái Latinh để trao đổi thư từ. tránh tình trạng vô nghĩa khét tiếng khi sử dụng bảng mã tiếng Nga như CP866, KOI8-R hoặc Windows 1251. Trên thực tế, các vết nứt xuất hiện thay vì văn bản tiếng Nga là kết quả của việc sử dụng không chính xác bảng mã của một ngôn ngữ nhất định, không tương ứng với ngôn ngữ trong mà tin nhắn văn bản ban đầu được mã hóa. Giả sử rằng nếu bạn cố gắng hiển thị các ký tự được mã hóa bằng CP866 bằng bảng mã Windows 1251, thì những từ vô nghĩa tương tự này (một bộ ký tự vô nghĩa) sẽ xuất hiện, thay thế hoàn toàn văn bản của tin nhắn. Một tình huống tương tự rất thường xảy ra khi tạo và thiết lập các trang web, diễn đàn hoặc blog, khi văn bản có ký tự tiếng Nga bị lưu nhầm bằng mã hóa sai được sử dụng trên trang web theo mặc định hoặc trong trình soạn thảo văn bản sai, điều này tạo thêm một cảm giác bịt miệng vô hình vào mã bằng mắt thường. Cuối cùng, nhiều người cảm thấy mệt mỏi với tình trạng này với rất nhiều mã hóa và liên tục phát ra những thứ nhảm nhí, và các điều kiện tiên quyết đã xuất hiện để tạo ra một biến thể phổ quát mới có thể thay thế tất cả những biến thể hiện có và giải quyết vấn đề với sự xuất hiện của các văn bản không thể đọc được. . Ngoài ra, còn có vấn đề với các ngôn ngữ như tiếng Trung, nơi có nhiều ký tự ngôn ngữ hơn 256.
Unicode - bảng mã phổ biến UTF 8, 16 và 32
Hàng ngàn ký tự thuộc nhóm ngôn ngữ Đông Nam Á này không thể được mô tả bằng một byte thông tin được phân bổ để mã hóa các ký tự trong các phiên bản mở rộng của ASCII. Kết quả là, một tập đoàn có tên Unicode (Unicode Consortium) đã được thành lập với sự hợp tác của nhiều nhà lãnh đạo ngành CNTT (những người sản xuất phần mềm, người mã hóa phần cứng, người tạo phông chữ), những người quan tâm đến sự xuất hiện của mã hóa văn bản phổ quát. Biến thể đầu tiên được phát hành dưới sự bảo trợ của Hiệp hội Unicode là UTF 32 . Số trong tên mã hóa có nghĩa là số bit được sử dụng để mã hóa một ký tự. 32 bit tương đương 4 byte thông tin sẽ cần thiết để mã hóa một ký tự đơn trong mã hóa UTF phổ quát mới. Kết quả là, cùng một tệp có văn bản được mã hóa ở phiên bản mở rộng của ASCII và UTF-32, trong trường hợp sau, sẽ có kích thước (nặng) lớn hơn bốn lần. Điều này thật tệ, nhưng bây giờ chúng ta có cơ hội mã hóa bằng UTF một số ký tự bằng hai lũy thừa ba mươi giây ( hàng tỷ ký tự sẽ bao gồm bất kỳ giá trị thực sự cần thiết nào với một lề khổng lồ). Nhưng nhiều quốc gia có ngôn ngữ thuộc nhóm Châu Âu hoàn toàn không cần sử dụng số lượng ký tự khổng lồ như vậy trong mã hóa, tuy nhiên, khi sử dụng UTF-32, không vì lý do gì mà trọng lượng của tài liệu văn bản tăng gấp bốn lần, và kết quả là khối lượng lưu lượng truy cập Internet và khối lượng dữ liệu được lưu trữ tăng lên. Đây là rất nhiều, và không ai có thể đủ khả năng lãng phí như vậy. Là kết quả của sự phát triển của Unicode, UTF-16 đã xuất hiện , hóa ra nó thành công đến mức nó được sử dụng làm không gian cơ sở theo mặc định cho tất cả các ký tự mà chúng tôi sử dụng. Nó sử dụng hai byte để mã hóa một ký tự. Hãy xem thứ này trông như thế nào. Trong hệ điều hành Windows, bạn có thể đi theo đường dẫn “Bắt đầu” - “Chương trình” - “Phụ kiện” - “Công cụ hệ thống” - “Bảng ký tự”. Kết quả là một bảng sẽ mở ra với các hình dạng vector của tất cả các phông chữ được cài đặt trên hệ thống của bạn. Nếu bạn chọn bộ ký tự Unicode trong “Tùy chọn nâng cao”, bạn sẽ có thể xem riêng toàn bộ phạm vi ký tự có trong đó cho từng phông chữ. Nhân tiện, bằng cách nhấp vào bất kỳ trong số chúng, bạn có thể thấy mã hai byte của nó ở định dạng UTF-16 , bao gồm bốn chữ số thập lục phân: Có bao nhiêu ký tự có thể được mã hóa bằng UTF-16 bằng 16 bit? 65.536 (hai lũy thừa mười sáu) và đây là con số được sử dụng làm không gian cơ sở trong Unicode. Ngoài ra, có nhiều cách để mã hóa khoảng hai triệu ký tự bằng cách sử dụng nó, nhưng chúng bị giới hạn trong không gian mở rộng gồm một triệu ký tự văn bản. Nhưng ngay cả phiên bản thành công này của mã hóa Unicode cũng không mang lại nhiều sự hài lòng cho những người viết chương trình chỉ bằng tiếng Anh, bởi vì sau khi chuyển đổi từ phiên bản mở rộng của ASCII sang UTF-16, trọng lượng của tài liệu đã tăng gấp đôi (một byte mỗi ký tự trong Aski và hai byte cho cùng một ký tự trong YUTF-16). Chính xác là để làm hài lòng tất cả mọi người và mọi thứ trong tập đoàn Unicode mà người ta đã quyết định đưa ra một bảng mã có độ dài thay đổi . Nó được gọi là UTF-8. Mặc dù có tên là tám, nhưng nó thực sự có độ dài thay đổi, tức là Mỗi ký tự của văn bản có thể được mã hóa thành một chuỗi có độ dài từ một đến sáu byte. Trong thực tế, UTF-8 chỉ sử dụng phạm vi từ một đến bốn byte, bởi vì ngoài bốn byte mã, về mặt lý thuyết, thậm chí không thể tưởng tượng được bất cứ điều gì. Tất cả các ký tự Latinh trong đó được mã hóa thành một byte, giống như trong ASCII cũ. Điều đáng chú ý là trong trường hợp chỉ mã hóa bảng chữ cái Latinh, ngay cả những chương trình không hiểu Unicode vẫn sẽ đọc những gì được mã hóa bằng YTF-8. Nghĩa là, phần cơ bản của Asuka chỉ đơn giản được chuyển giao cho đứa con tinh thần này của tập đoàn Unicode. Các ký tự Cyrillic trong UTF-8 được mã hóa thành hai byte và ví dụ: các ký tự Georgia được mã hóa thành ba byte. Hiệp hội Unicode, sau khi tạo UTF 16 và 8, đã giải quyết được vấn đề chính - bây giờ chúng tôi có một không gian mã duy nhất trong phông chữ của mình . Và bây giờ các nhà sản xuất của họ chỉ có thể lấp đầy nó bằng các dạng ký tự văn bản vector dựa trên điểm mạnh và khả năng của chúng. Trong “Bảng ký tự” ở trên, bạn có thể thấy rằng các phông chữ khác nhau hỗ trợ số lượng ký tự khác nhau. Một số phông chữ giàu Unicode có thể khá nặng. Nhưng bây giờ chúng khác nhau không phải ở chỗ chúng được tạo ra cho các bảng mã khác nhau, mà ở chỗ nhà sản xuất phông chữ đã lấp đầy hoặc không lấp đầy hoàn toàn không gian mã đơn bằng các dạng vectơ nhất định.
Những từ điên rồ thay vì chữ Nga - cách khắc phục
Bây giờ chúng ta hãy xem cách krakozyabrs xuất hiện thay vì văn bản hay nói cách khác là cách chọn mã hóa chính xác cho văn bản tiếng Nga. Trên thực tế, nó được đặt trong chương trình mà bạn tạo hoặc chỉnh sửa chính văn bản hoặc mã này bằng cách sử dụng các đoạn văn bản. Theo tôi, để chỉnh sửa và tạo các tệp văn bản, cá nhân tôi sử dụng một trình soạn thảo Html và PHP Notepad++ rất tốt . Tuy nhiên, nó có thể làm nổi bật cú pháp của hàng trăm ngôn ngữ lập trình và đánh dấu khác, đồng thời có khả năng mở rộng bằng cách sử dụng các plugin. Đọc bài đánh giá chi tiết về chương trình tuyệt vời này tại liên kết được cung cấp. Trong menu trên cùng của Notepad++ có một mục “Mã hóa”, nơi bạn sẽ có cơ hội chuyển đổi tùy chọn hiện có thành tùy chọn được sử dụng trên trang web của mình theo mặc định: Trong trường hợp trang web trên Joomla 1.5 trở lên, như Cũng như trong trường hợp blog trên WordPress, bạn nên tránh hiện tượng Krakozyabrov chọn tùy chọn UTF 8 không có BOM . Tiền tố BOM là gì? Thực tế là khi họ đang phát triển mã hóa YUTF-16, vì lý do nào đó, họ đã quyết định gắn vào nó một thứ như khả năng viết mã ký tự theo cả chuỗi trực tiếp (ví dụ: 0A15) và ngược lại (150A) . Và để các chương trình hiểu được trình tự đọc mã, BOM (Byte Order Mark hay nói cách khác là chữ ký) đã được phát minh, được thể hiện bằng việc thêm ba byte bổ sung vào đầu tài liệu. Trong mã hóa UTF-8, không có BOM nào được cung cấp trong tập đoàn Unicode và do đó việc thêm chữ ký (ba byte bổ sung khét tiếng ở đầu tài liệu) chỉ đơn giản là ngăn một số chương trình đọc mã. Vì vậy, khi lưu file dưới dạng UTF, chúng ta phải luôn chọn tùy chọn không có BOM (không có chữ ký). Vì vậy, bạn sẽ tự bảo vệ mình trước khỏi việc bò ra khỏi krakozyabrs . Điều đáng chú ý là một số chương trình trong Windows không thể thực hiện được điều này (chúng không thể lưu văn bản ở dạng UTF-8 mà không có BOM), chẳng hạn như Windows Notepad khét tiếng. Nó lưu tài liệu ở dạng UTF-8, nhưng vẫn thêm chữ ký (ba byte bổ sung) vào đầu tài liệu. Hơn nữa, các byte này sẽ luôn giống nhau - đọc mã theo trình tự trực tiếp. Nhưng trên các máy chủ, vì điều nhỏ nhặt này, một vấn đề có thể nảy sinh - kẻ gian sẽ lộ diện. Do đó, không sử dụng notepad Windows thông thường trong mọi trường hợp.để chỉnh sửa tài liệu trên trang web của bạn nếu bạn không muốn bất kỳ vết nứt nào xuất hiện. Tôi coi trình soạn thảo Notepad++ đã được đề cập là tùy chọn tốt nhất và đơn giản nhất, thực tế không có nhược điểm và chỉ bao gồm các ưu điểm. Trong Notepad++, khi bạn chọn một kiểu mã hóa, bạn sẽ có tùy chọn chuyển đổi văn bản sang mã hóa UCS-2, về bản chất rất gần với tiêu chuẩn Unicode. Ngoài ra, Notepad còn có thể mã hóa văn bản ở định dạng ANSI, tức là liên quan đến tiếng Nga, đây sẽ là Windows 1251, mà chúng tôi đã mô tả ở trên. Thông tin này đến từ đâu? Nó được đăng ký trong sổ đăng ký hệ điều hành Windows của bạn - nên chọn mã hóa nào trong trường hợp ANSI, nên chọn mã hóa nào trong trường hợp OEM (đối với ngôn ngữ tiếng Nga, nó sẽ là CP866). Nếu bạn đặt ngôn ngữ mặc định khác trên máy tính của mình thì các bảng mã này sẽ được thay thế bằng các ngôn ngữ tương tự từ danh mục ANSI hoặc OEM cho cùng ngôn ngữ đó. Sau khi lưu tài liệu trong Notepad++ ở dạng mã hóa bạn cần hoặc mở tài liệu từ trang web để chỉnh sửa, bạn sẽ có thể thấy tên của nó ở góc dưới bên phải của trình chỉnh sửa: Để tránh nhầm lẫn , ngoài các bước được mô tả ở trên , sẽ rất hữu ích nếu viết mã nguồn vào tiêu đề của nó tất cả các trang trên trang web có thông tin về chính cách mã hóa này để không có sự nhầm lẫn trên máy chủ hoặc máy chủ cục bộ. Nói chung, tất cả các ngôn ngữ đánh dấu siêu văn bản ngoại trừ Html đều sử dụng khai báo xml đặc biệt, chỉ định mã hóa văn bản.
<?xml version="1.0" encoding="windows-1251"?>
Trước khi phân tích mã, trình duyệt sẽ biết phiên bản nào đang được sử dụng và cách nó cần diễn giải mã ký tự của ngôn ngữ đó một cách chính xác như thế nào. Nhưng điều đáng chú ý là nếu bạn lưu tài liệu ở dạng Unicode mặc định thì có thể bỏ qua phần khai báo xml này (mã hóa sẽ được coi là UTF-8 nếu không có BOM hoặc UTF-16 nếu có BOM). Trong trường hợp tài liệu HTML, phần tử Meta được sử dụng để biểu thị mã hóa , được đặt giữa thẻ Head mở và đóng:
<head>...<meta charset="utf-8">...</head>
Mục nhập này khá khác so với tiêu chuẩn trong Html 4.01, nhưng hoàn toàn tuân thủ tiêu chuẩn Html 5 và mọi trình duyệt hiện đang sử dụng sẽ hiểu chính xác nó. Về lý thuyết, phần tử Meta biểu thị mã hóa của tài liệu Html sẽ được đặt ở vị trí cao nhất có thể trong tiêu đề tài liệu , để khi văn bản gặp ký tự đầu tiên không phải từ ANSI cơ bản (luôn được đọc chính xác và đúng chuẩn). bất kỳ biến thể nào), trình duyệt phải có sẵn thông tin về cách giải thích mã của các ký tự này. Link nguồn gốc: Mã hóa văn bản ASCII (Windows 1251, CP866, KOI8-R) và Unicode (UTF 8, 16, 32) - cách khắc phục sự cố với cracker
Chính 128 ký tự này từ phiên bản gốc của ASCII đã trở thành tiêu chuẩn và trong bất kỳ bảng mã nào khác, bạn chắc chắn sẽ tìm thấy chúng và chúng sẽ xuất hiện theo thứ tự này. Nhưng thực tế là với sự trợ giúp của một byte thông tin, bạn có thể mã hóa không phải 128 mà là 256 giá trị khác nhau (hai lũy thừa của tám bằng 256), do đó, sau phiên bản cơ bản của Asuka, toàn bộ loạt mã hóa ASCII mở rộng đã xuất hiện , trong đó có thể, ngoài 128 ký tự cơ bản còn có thể được mã hóa bằng các ký tự mã hóa quốc gia (ví dụ: tiếng Nga). Ở đây, có lẽ cần phải nói thêm một chút về hệ thống số được sử dụng trong phần mô tả. Thứ nhất, như các bạn đã biết, máy tính chỉ làm việc với các số trong hệ nhị phân, tức là với số 0 và số 1 (“đại số Boolean”, nếu có ai học ở viện, trường). Một byte bao gồm tám bit, mỗi bit đại diện cho lũy thừa hai của hai, bắt đầu từ 0 và lên đến hai đến thứ bảy: 
Không khó hiểu rằng tất cả các kết hợp có thể có của số 0 và số 1 trong cấu trúc như vậy có thể chỉ là 256. Chuyển một số từ hệ nhị phân sang hệ thập phân khá đơn giản. Bạn chỉ cần cộng tất cả lũy thừa của hai với lũy thừa ở trên chúng. Trong ví dụ của chúng ta, kết quả này là 1 (2 lũy thừa 0) cộng 8 (hai lũy thừa 3), cộng 32 (hai lũy thừa năm), cộng 64 (lũy thừa sáu), cộng 128 (đến lũy thừa thứ bảy). Tổng số là 233 theo ký hiệu thập phân. Như bạn có thể thấy, mọi thứ đều rất đơn giản. Nhưng nếu bạn nhìn kỹ vào bảng có các ký tự ASCII, bạn sẽ thấy chúng được biểu diễn dưới dạng mã thập lục phân. Ví dụ: "dấu hoa thị" tương ứng với số thập lục phân 2A trong Aski. Chắc hẳn bạn đã biết rằng trong hệ thập lục phân, ngoài chữ số Ả Rập, các chữ cái Latinh từ A (có nghĩa là mười) đến F (có nghĩa là mười lăm) cũng được sử dụng. Vâng, để chuyển đổi một số nhị phân thành số thập lục phânhãy áp dụng phương pháp đơn giản sau đây. Mỗi byte thông tin được chia thành hai phần bốn bit. Những thứ kia. Trong mỗi nửa byte, chỉ có mười sáu giá trị (hai đến lũy thừa thứ tư) có thể được mã hóa ở dạng nhị phân, có thể dễ dàng biểu diễn dưới dạng số thập lục phân. Hơn nữa, ở nửa bên trái của byte, độ sẽ cần được tính lại bắt đầu từ 0 chứ không phải như trong ảnh chụp màn hình. Kết quả là chúng ta có được số E9 được mã hóa trong ảnh chụp màn hình. Tôi hy vọng rằng quá trình lập luận của tôi và lời giải cho câu đố này đã rõ ràng với bạn. Chà, trên thực tế, bây giờ chúng ta hãy tiếp tục nói về mã hóa văn bản.
Bạn thấy đấy, ở cột bên phải, các số bắt đầu bằng 8, bởi vì các số từ 0 đến 7 đề cập đến phần cơ bản của ASCII (xem ảnh chụp màn hình đầu tiên). Như vậy, chữ Cyrillic “M” trong CP866 sẽ có mã là 9C (nằm ở giao điểm của dòng tương ứng với 9 và cột có số C trong hệ thập lục phân), có thể viết bằng một byte thông tin. và nếu có phông chữ phù hợp với các ký tự tiếng Nga thì chữ cái này sẽ xuất hiện trong văn bản mà không gặp vấn đề gì. Số tiền này đến từ đâu?bút danh trong CP866 ? Vấn đề chung là cách mã hóa văn bản tiếng Nga này đã được phát triển từ những năm tháng tồi tàn khi hệ điều hành đồ họa chưa phổ biến như bây giờ. Và trong Dosa và các hệ điều hành văn bản tương tự, bút danh ít nhất có thể đa dạng hóa thiết kế văn bản bằng cách nào đó, và do đó CP866 và tất cả các hệ điều hành tương tự khác của nó thuộc danh mục phiên bản mở rộng của Asuka có rất nhiều trong đó. CP866 được IBM phân phối, nhưng ngoài ra, một số mã hóa đã được phát triển cho các ký tự tiếng Nga, ví dụ: KOI8-R có thể được quy cho cùng loại (ASCII mở rộng) : 
Nguyên tắc hoạt động của nó vẫn giống như của CP866 được mô tả trước đó một chút - Mỗi ký tự của văn bản được mã hóa thành một byte đơn. Ảnh chụp màn hình hiển thị nửa sau của bảng KOI8-R, bởi vì nửa đầu hoàn toàn phù hợp với Asuka cơ bản, được hiển thị trong ảnh chụp màn hình đầu tiên trong bài viết này. Trong số các tính năng của mã hóa KOI8-R, có thể lưu ý rằng các chữ cái Cyrillic trong bảng của nó không theo thứ tự bảng chữ cái, như đã được thực hiện trong CP866. Nếu bạn nhìn vào ảnh chụp màn hình đầu tiên (của phần cơ bản, được bao gồm trong tất cả các bảng mã mở rộng), bạn sẽ nhận thấy rằng trong KOI8-R, các chữ cái tiếng Nga nằm trong cùng các ô của bảng với các chữ cái tương ứng của bảng chữ cái Latinh từ phần đầu tiên của bảng. Điều này được thực hiện để thuận tiện cho việc chuyển đổi từ các ký tự tiếng Nga sang tiếng Latinh bằng cách loại bỏ chỉ một bit (hai đến lũy thừa thứ bảy hoặc 128).
Do có quá nhiều bảng mã của tiếng Nga nên các nhà sản xuất phông chữ, nhà sản xuất phần mềm liên tục phải đau đầu, còn bạn và tôi, những độc giả thân mến, thường xuyên gặp rắc rối với những lỗi khét tiếng tương tự khi có sự nhầm lẫn với phiên bản được sử dụng trong văn bản. Chúng thường xuất hiện khi gửi và nhận tin nhắn qua e-mail, điều này đòi hỏi phải tạo ra các bảng chuyển đổi rất phức tạp, trên thực tế, không thể giải quyết vấn đề này về cơ bản và người dùng thường sử dụng phiên âm các chữ cái Latinh để trao đổi thư từ. tránh tình trạng vô nghĩa khét tiếng khi sử dụng bảng mã tiếng Nga như CP866, KOI8-R hoặc Windows 1251. Trên thực tế, các vết nứt xuất hiện thay vì văn bản tiếng Nga là kết quả của việc sử dụng không chính xác bảng mã của một ngôn ngữ nhất định, không tương ứng với ngôn ngữ trong mà tin nhắn văn bản ban đầu được mã hóa. Giả sử rằng nếu bạn cố gắng hiển thị các ký tự được mã hóa bằng CP866 bằng bảng mã Windows 1251, thì những từ vô nghĩa tương tự này (một bộ ký tự vô nghĩa) sẽ xuất hiện, thay thế hoàn toàn văn bản của tin nhắn. 
Một tình huống tương tự rất thường xảy ra khi tạo và thiết lập các trang web, diễn đàn hoặc blog, khi văn bản có ký tự tiếng Nga bị lưu nhầm bằng mã hóa sai được sử dụng trên trang web theo mặc định hoặc trong trình soạn thảo văn bản sai, điều này tạo thêm một cảm giác bịt miệng vô hình vào mã bằng mắt thường. Cuối cùng, nhiều người cảm thấy mệt mỏi với tình trạng này với rất nhiều mã hóa và liên tục phát ra những thứ nhảm nhí, và các điều kiện tiên quyết đã xuất hiện để tạo ra một biến thể phổ quát mới có thể thay thế tất cả những biến thể hiện có và giải quyết vấn đề với sự xuất hiện của các văn bản không thể đọc được. . Ngoài ra, còn có vấn đề với các ngôn ngữ như tiếng Trung, nơi có nhiều ký tự ngôn ngữ hơn 256.
Có bao nhiêu ký tự có thể được mã hóa bằng UTF-16 bằng 16 bit? 65.536 (hai lũy thừa mười sáu) và đây là con số được sử dụng làm không gian cơ sở trong Unicode. Ngoài ra, có nhiều cách để mã hóa khoảng hai triệu ký tự bằng cách sử dụng nó, nhưng chúng bị giới hạn trong không gian mở rộng gồm một triệu ký tự văn bản. Nhưng ngay cả phiên bản thành công này của mã hóa Unicode cũng không mang lại nhiều sự hài lòng cho những người viết chương trình chỉ bằng tiếng Anh, bởi vì sau khi chuyển đổi từ phiên bản mở rộng của ASCII sang UTF-16, trọng lượng của tài liệu đã tăng gấp đôi (một byte mỗi ký tự trong Aski và hai byte cho cùng một ký tự trong YUTF-16). Chính xác là để làm hài lòng tất cả mọi người và mọi thứ trong tập đoàn Unicode mà người ta đã quyết định đưa ra một bảng mã có độ dài thay đổi . Nó được gọi là UTF-8. Mặc dù có tên là tám, nhưng nó thực sự có độ dài thay đổi, tức là Mỗi ký tự của văn bản có thể được mã hóa thành một chuỗi có độ dài từ một đến sáu byte. Trong thực tế, UTF-8 chỉ sử dụng phạm vi từ một đến bốn byte, bởi vì ngoài bốn byte mã, về mặt lý thuyết, thậm chí không thể tưởng tượng được bất cứ điều gì. Tất cả các ký tự Latinh trong đó được mã hóa thành một byte, giống như trong ASCII cũ. Điều đáng chú ý là trong trường hợp chỉ mã hóa bảng chữ cái Latinh, ngay cả những chương trình không hiểu Unicode vẫn sẽ đọc những gì được mã hóa bằng YTF-8. Nghĩa là, phần cơ bản của Asuka chỉ đơn giản được chuyển giao cho đứa con tinh thần này của tập đoàn Unicode. Các ký tự Cyrillic trong UTF-8 được mã hóa thành hai byte và ví dụ: các ký tự Georgia được mã hóa thành ba byte. Hiệp hội Unicode, sau khi tạo UTF 16 và 8, đã giải quyết được vấn đề chính - bây giờ chúng tôi có một không gian mã duy nhất trong phông chữ của mình . Và bây giờ các nhà sản xuất của họ chỉ có thể lấp đầy nó bằng các dạng ký tự văn bản vector dựa trên điểm mạnh và khả năng của chúng. Trong “Bảng ký tự” ở trên, bạn có thể thấy rằng các phông chữ khác nhau hỗ trợ số lượng ký tự khác nhau. Một số phông chữ giàu Unicode có thể khá nặng. Nhưng bây giờ chúng khác nhau không phải ở chỗ chúng được tạo ra cho các bảng mã khác nhau, mà ở chỗ nhà sản xuất phông chữ đã lấp đầy hoặc không lấp đầy hoàn toàn không gian mã đơn bằng các dạng vectơ nhất định.
Trong trường hợp trang web trên Joomla 1.5 trở lên, như Cũng như trong trường hợp blog trên WordPress, bạn nên tránh hiện tượng Krakozyabrov chọn tùy chọn UTF 8 không có BOM . Tiền tố BOM là gì? Thực tế là khi họ đang phát triển mã hóa YUTF-16, vì lý do nào đó, họ đã quyết định gắn vào nó một thứ như khả năng viết mã ký tự theo cả chuỗi trực tiếp (ví dụ: 0A15) và ngược lại (150A) . Và để các chương trình hiểu được trình tự đọc mã, BOM (Byte Order Mark hay nói cách khác là chữ ký) đã được phát minh, được thể hiện bằng việc thêm ba byte bổ sung vào đầu tài liệu. Trong mã hóa UTF-8, không có BOM nào được cung cấp trong tập đoàn Unicode và do đó việc thêm chữ ký (ba byte bổ sung khét tiếng ở đầu tài liệu) chỉ đơn giản là ngăn một số chương trình đọc mã. Vì vậy, khi lưu file dưới dạng UTF, chúng ta phải luôn chọn tùy chọn không có BOM (không có chữ ký). Vì vậy, bạn sẽ tự bảo vệ mình trước khỏi việc bò ra khỏi krakozyabrs . Điều đáng chú ý là một số chương trình trong Windows không thể thực hiện được điều này (chúng không thể lưu văn bản ở dạng UTF-8 mà không có BOM), chẳng hạn như Windows Notepad khét tiếng. Nó lưu tài liệu ở dạng UTF-8, nhưng vẫn thêm chữ ký (ba byte bổ sung) vào đầu tài liệu. Hơn nữa, các byte này sẽ luôn giống nhau - đọc mã theo trình tự trực tiếp. Nhưng trên các máy chủ, vì điều nhỏ nhặt này, một vấn đề có thể nảy sinh - kẻ gian sẽ lộ diện. Do đó, không sử dụng notepad Windows thông thường trong mọi trường hợp.để chỉnh sửa tài liệu trên trang web của bạn nếu bạn không muốn bất kỳ vết nứt nào xuất hiện. Tôi coi trình soạn thảo Notepad++ đã được đề cập là tùy chọn tốt nhất và đơn giản nhất, thực tế không có nhược điểm và chỉ bao gồm các ưu điểm. Trong Notepad++, khi bạn chọn một kiểu mã hóa, bạn sẽ có tùy chọn chuyển đổi văn bản sang mã hóa UCS-2, về bản chất rất gần với tiêu chuẩn Unicode. Ngoài ra, Notepad còn có thể mã hóa văn bản ở định dạng ANSI, tức là liên quan đến tiếng Nga, đây sẽ là Windows 1251, mà chúng tôi đã mô tả ở trên. Thông tin này đến từ đâu? Nó được đăng ký trong sổ đăng ký hệ điều hành Windows của bạn - nên chọn mã hóa nào trong trường hợp ANSI, nên chọn mã hóa nào trong trường hợp OEM (đối với ngôn ngữ tiếng Nga, nó sẽ là CP866). Nếu bạn đặt ngôn ngữ mặc định khác trên máy tính của mình thì các bảng mã này sẽ được thay thế bằng các ngôn ngữ tương tự từ danh mục ANSI hoặc OEM cho cùng ngôn ngữ đó. Sau khi lưu tài liệu trong Notepad++ ở dạng mã hóa bạn cần hoặc mở tài liệu từ trang web để chỉnh sửa, bạn sẽ có thể thấy tên của nó ở góc dưới bên phải của trình chỉnh sửa: 
Để tránh nhầm lẫn , ngoài các bước được mô tả ở trên , sẽ rất hữu ích nếu viết mã nguồn vào tiêu đề của nó tất cả các trang trên trang web có thông tin về chính cách mã hóa này để không có sự nhầm lẫn trên máy chủ hoặc máy chủ cục bộ. Nói chung, tất cả các ngôn ngữ đánh dấu siêu văn bản ngoại trừ Html đều sử dụng khai báo xml đặc biệt, chỉ định mã hóa văn bản.
GO TO FULL VERSION