Впервые опубликовано на Что должен знать каждый разработчик о кодировке символов .
Если вы пишете код, который касается текстового файла, вам, вероятно, это нужно.
Давайте начнем с двух ключевых элементов
1. Юникод не решает эту проблему для нас (пока).
2.Каждый текстовый файл кодируется. Не существует такой вещи, как незашифрованный файл или «общая» кодировка.
И давайте добавим к этому codacil - большинство американцев могут обходиться без необходимости учитывать это - большую часть времени. Поскольку символы для первых 127 байтов в подавляющем большинстве схем кодирования отображаются на один и тот же набор символов (более точно называемый глифами). И поскольку мы используем только A-Z без каких-либо других символов, акцентов и т. Д., Мы готовы идти вперед. Но когда вы используете те же самые предположения в файле HTML или XML, в котором символы находятся за пределами первых 127, - тогда проблема начинается.
Компьютерная индустрия начиналась с дискового пространства и памяти с наценкой. Любой, кто предложил бы использовать 2 байта для каждого символа вместо одного, посмеялся бы. На самом деле нам повезло, что байт работал лучше всего как 8 бит, или у нас могло быть меньше 256 бит на каждый символ. Конечно, на раннем этапе были разработаны многочисленные наборы символов (или кодовые страницы). Но в итоге большинство из нас использовали стандартный набор кодовых страниц, где первые 127 байтов были идентичны для всех, а вторые были уникальными для каждого набора. Были наборы для Америки / Западной Европы, Центральной Европы, России и т. Д.
А затем для Азии, поскольку 256 символов было недостаточно, некоторые из диапазона 128 - 255 имели то, что называлось DBCS (двухбайтовые наборы символов). Для каждого значения первого байта (в этих более высоких диапазонах) второй байт затем идентифицирует один из 256 символов. Это дало в общей сложности 128 * 256 дополнительных символов. Это был взлом, но он сводил использование памяти к минимуму. Китайский, японский и корейский имеют свои собственные кодовые страницы DBCS.
И какое-то время это работало хорошо. Операционные системы, приложения и т. Д. В основном были настроены на использование указанной кодовой страницы. Но потом появился Интернет. Веб-сайт в Америке, использующий XML-файл из Греции для отображения данных для пользователя, просматривающего в России, где каждый вводит данные в зависимости от своей страны, - это нарушило эту парадигму.
Перенесемся в сегодня. Два формата файлов, где мы можем объяснить это лучше всего, и где все спотыкаются об этом, это HTML и XML. Каждый файл HTML и XML может дополнительно иметь кодировку символов, заданную в его метаданных заголовка. Если он не установлен, то большинство программ предполагают, что это UTF-8, но это не стандарт и не всегда соблюдается. Если кодировка не указана и программа, считывающая файл, угадала неправильно - файл будет прочитан неправильно.
Пункт 1 - Никогда не считайте указание кодировки необязательным при записи файла. Всегда записывайте это в файл. Всегда. Даже если вы готовы поклясться, что в файле никогда не будет символов вне диапазона 1 - 127.
Теперь давайте посмотрим на UTF-8, потому что как стандарт и как он работает, он доставляет людям массу неприятностей. UTF-8 был популярен по двум причинам. Сначала он соответствовал стандартным кодовым страницам для первых 127 символов, поэтому большинство существующих HTML и XML соответствовали бы ему. Во-вторых, он был спроектирован так, чтобы использовать как можно меньше байтов, что имело большое значение в то время, когда он был спроектирован, и многие люди все еще использовали модемы.
UTF-8 займред из конструкций DBCS из азиатских кодовых страниц.Первые 128 байтов являются однобайтовыми представлениями символов.Затем для следующего наиболее распространенного набора он использует блок во вторых 128 байтах, чтобы быть двухбайтовой последовательностью, дающей нам больше символов.Но подождите, это еще не все.Для менее распространенных есть первый байт, который приводит к второстепенным вторым байтам.Затем каждый из них ведет к третьему байту, и эти три байта определяют символ.Это идет до 6 байтовых последовательностей.Используя MBCS (многобайтовый набор символов), вы можете написать эквивалент каждого символа Юникода.И если предположить, что вы пишете не список редко используемых китайских символов, сделайте это в меньшем количестве байтов.
Но вот то, что все спотыкаются - у них есть файл HTML или XML, он отлично работает, и они открывают его в текстовом редакторе.Затем они добавляют символ, который в своем текстовом редакторе, используя кодовую страницу для своего региона, вставляет символ, такой как ß, и сохраняет файл.Конечно, это должно быть правильно - их текстовый редактор показывает это правильно.Но передайте его любой программе, которая читает в соответствии с кодировкой и которая теперь является первым символом для 2-байтовой последовательности.Вы либо получаете другой символ, либо если второй байт не является допустимым значением для этого первого байта - ошибка.
Пункт 2. Всегда создавайте HTML и XML в программе, которая правильно их записывает, используя кодирование.Если вам необходимо создать текстовый редактор, просмотрите окончательный файл в браузере.
А как насчет того, когда код, который вы пишете, будет читать или записывать файл?Мы говорим не о двоичных файлах / файлах данных, где вы записываете их в своем собственном формате, а о файлах, которые считаются текстовыми файлами.Java, .NET и т. Д. Имеют кодировщики символов.Назначение этих кодировщиков - переводить последовательность байтов (файла) и символы, которые они представляют.Давайте возьмем то, что на самом деле является очень сложным примером - ваш исходный код, будь то C #, Java и т. Д. Это, по большому счету, «простые старые текстовые файлы» без подсказок по кодированию.Так как же программы справляются с ними?Многие предполагают, что они используют локальную кодовую страницу.Многие другие предполагают, что все символы будут в диапазоне от 0 до 127 и будут подавлены чем-либо еще.
Вот ключевой момент в этих текстовых файлах - каждая программа все еще использует кодировку.Возможно, это не устанавливается в коде, но по определению используется кодировка.
Пункт 3 - Всегда устанавливайте кодировку при чтении и записи текстовых файлов.Не только для HTML и XML, но даже для таких файлов, как исходный код.Хорошо, если вы установите кодовую страницу по умолчанию, но установите кодировку.
Точка 4 - Используйте наиболее полный из возможных кодировщиков.Вы можете написать свой собственный XML как текстовый файл, закодированный для UTF-8.Но если вы напишите это с использованием XML-кодировщика, тогда он будет включать кодировку в метаданные, и вы не сможете ошибиться.(он также добавляет преамбулу с порядком байтов в файл.)
Хорошо, вы правильно читаете и пишете файлы, но как насчет внутри вашего кода.Что там?Это где легко - Unicode.Это то, для чего предназначены эти кодировщики, созданные во время выполнения Java & .NET.Вы читаете и получаете Unicode.Вы пишете Unicode и получаете закодированный файл.Вот почему тип char равен 16 битам и является уникальным типом ядра для символов.Это вы, вероятно, имеете право, потому что современные языки не дают вам большого выбора в этом вопросе.
Пункт 5 - (Для разработчиков на языках, которые существовали некоторое время назад) - Всегда используйте Юникод для внутреннего использования.В C ++ это называется широкими символами (или чем-то похожим).Не умейте экономить пару байтов, память дешевая, и у вас есть более важные дела.
Подведение итогов
Я думаю, что здесь есть два ключевых момента, о которых следует помнить.Во-первых, убедитесь, что кодировка включена в текстовые файлы.Во-вторых, это на самом деле все очень просто и понятно.Люди редко облажаются, как использовать кодировку, именно когда они игнорируют проблему, они попадают в неприятности.