Ответ 1
Я хотел бы ответить на это более схожим образом, чтобы ответить на него, поэтому нам нужна небольшая история. Джоэл Спольский написал очень хорошую ознакомительную статью абсолютный минимум, который должен знать каждый разработчик в кодировке символов Unicode.
Потерпите меня здесь, потому что это будет как-то ответом looong.:)
Как история, я укажу на некоторые цитаты оттуда: (Большое спасибо Джоэлю!:))
Единственными символами, которые имели значение, были старые добрые английские буквы без акцента, и у нас был код для них под названием ASCII, который мог представлять каждый символ, используя число от 32 до 127. Пространство было 32, буква "A" составляла 65 и т.д. Это удобно хранить в 7 бит. Большинство компьютеров в те дни использовали 8-битные байты, поэтому не только вы могли хранить все возможные символы ASCII, но у вас было целая часть, чтобы избавиться, что, если бы вы были злы, вы могли использовать для своих собственных коварных целей.
И все было хорошо, если бы вы были английским оратором. Поскольку у байт есть место для до восьми бит, многие люди думают: "Черт, мы можем использовать коды 128-255 для наших собственных целей". Проблема заключалась в том, что у многих людей была эта идея одновременно, и у них были свои идеи о том, что должно происходить там, где в пространстве от 128 до 255.
Итак, теперь "OEM-наборы персонажей" были распространены с ПК, и все они были все разные и несовместимы. И нашему современному изумлению - все было в порядке! У них не было Интернета, и люди редко обменивались файлами между системами с разными локалями.
Джоэл продолжает говорить:
На самом деле, как только люди начали покупать ПК за пределами Америки, все идеи разных персональных наборов персонажей были задуманы, и все они использовали верхние 128 символов для своих целей. В конечном итоге этот OEM-производитель полностью кодифицирован в стандарте ANSI. В стандарте ANSI все согласились с тем, что делать ниже 128, что было почти таким же, как ASCII, но было много разных способов обработки символов от 128 и выше, в зависимости от того, где вы жили. Эти различные системы назывались кодовые страницы.
И вот, в конце концов, родились "страницы кодов Windows". На самом деле они были "родительскими" на кодовых страницах DOS. А потом появился Юникод!:) и UTF-8 - "еще одна система для хранения вашей строки кодовых точек Unicode", и на самом деле "каждая точка кода от 0 до 127 хранится в одном байте" и совпадает с ASCII. Я больше не буду вдаваться в подробности Unicode и UTF-8, но вы должны прочитать в спецификацию, Endianness и Кодировка символов как общий.
В связи с "заговором ANSI" Microsoft фактически допускает промаркировку Windows-1252 в глоссарий терминов:
Так называемый набор символов Windows (WinLatin1 или кодовая страница Windows 1252, если быть точным) использует некоторые из этих позиций для печатаемых символов. Таким образом, набор символов Windows НЕ идентичен ISO 8859-1. Набор символов Windows часто называют "набором символов ANSI", но это СЕРЬЕЗНО НЕПРАВИЛЬНО. Он НЕ был одобрен ANSI.
Таким образом, ANSI при обращении к наборам символов Windows не сертифицирован по ANSI!:)
Как указал Юкка (кредиты идут вам на приятный ответ)
Windows-1252 ISO Latin 1, также известный как ISO-8859-1 как кодировка символов, так что диапазон кода от 0x80 до 0x9F зарезервирован для управляющих символов в ISO-8859-1 (так называемые C1 Controls) В Windows-1252 некоторые из кодов назначаются печатным символам (в основном символам пунктуации), остальные - undefined.
Однако мое личное мнение и техническое понимание заключаются в том, что как Windows-1252, так и ISO-8859-1 НЕ ЯВЛЯЮТСЯ ВЕБ-ЭНЕРГИЯМИ!:) Итак:
-
Для веб-страниц используйте UTF-8 в качестве кодировки для содержимого Поэтому сохраните данные как UTF-8 и "выплюните" с помощью Заголовок HTTP:
Content-Type: text/html; charset=utf-8.Существует также вещь, называемая метатег HTML-типа контента:
<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8">Теперь, что браузеры действительно делают, когда сталкиваются с этим тегом, это то, что они начинаются с начала документа HTML снова, чтобы они могли переосмыслить документ в объявленной кодировке. Это должно произойти только в том случае, если заголовок Content-type отсутствует. -
Используйте другие специальные кодировки, если пользователям вашей системы нужны файлы, созданные из нее. Например, некоторым западным пользователям могут потребоваться файлы сгенерированных Excel или CSV в Windows-1252. Если это так, закодируйте текст в этой локали, а затем сохраните его в fs и подайте в виде файла с возможностью загрузки.
-
В дизайне HTTP есть еще одна вещь: Механизм распределения содержимого должен работать следующим образом.
я. Клиент запрашивает веб-страницу в определенных типах контента и кодировках через: "Accept" и "Accept-Charset" заголовки запросов.
II. Затем сервер (или веб-приложение) возвращает содержимое, закодированное для этой кодировки и набора символов.
Это НЕ ДЕЛО в большинстве современных веб-приложений. Что на самом деле происходит, так это то, что веб-приложения служат (заставляют клиента) контент как UTF-8. И это работает, потому что браузеры интерпретируют полученные документы на основе заголовков ответов, а не на том, что они на самом деле ожидали.
Мы все должны пойти в Юникод, поэтому, пожалуйста, пожалуйста, используйте UTF-8, чтобы распространять ваш контент, где это возможно, и, самое главное, применимо. Или еще старейшины Интернета будут преследовать вас!:)
P.S. Еще несколько полезных статей об использовании символов MS Windows в веб-страницах можно найти здесь и .