<%@LANGUAGE="VBSCRIPT" CODEPAGE="65001"%>
<!--#include file="conn.asp"-->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
Является ли приведенный выше код правильным?Является ли кодовая страница 65001 и utf-8 той же самой?
Да.
UTF-8 - это CP65001 в Windows (это всего лишь способ указать UTF-8 в устаревшем кодексе). Насколько я читаю, ASP может обрабатывать UTF-8, когда указывается именно так.
Да, 65001 - идентификатор кодовой страницы Windows для UTF-8, как задокументировано on the Microsoft website. Wikipedia suggests, что кодовая страница IBM 128 и кодовая страница SAP 4110 также являются индикаторами для UTF-8.
Ваш код правильный, хотя я предпочитаю, чтобы установить НабораСимволов в коде, а не использовать мета-тег: -
<% Response.CharSet = "UTF-8" %>
Кодовая страница 65001 действительно относится к набору символов UTF-8. Вам нужно будет убедиться, что ваша страница asp (и все включено) сохраняется как UTF-8, если они содержат любые символы вне стандартного набора символов ASCII.
Указывая атрибут CODEPAGE в блоке <% @, вы указываете, что что-либо, написанное с использованием Response.Write, должно быть закодировано в указанную Codepage, в данном случае 65001 (utf-8). Стоит иметь в виду, что это не влияет на какое-либо статическое содержимое, которое отправляется дословно для байта для ответа. Следовательно, причина, по которой файл должен быть фактически сохранен, используя указанную кодовую страницу.
Свойство CharSet ответа задает значение CharSet заголовка Content-Type. Это не влияет на то, как кодировать контент, который он кодирует, он просто сообщает клиенту, какая кодировка будет получена. Опять же важно, чтобы его значение соответствовало фактической кодировке.
Основное значение и эффект '<% @ LANGUAGE =" VBSCRIPT "CODEPAGE =" 65001 "%>' для кодировки исходного файла как UTF-8 (или того, что указано в кодовой странице). Он только каскадируется до свойства 'Response.CharSet'. Вы можете сохранить свой файл как UTF-8 и поместить соответствующее объявление CODEPAGE, а затем использовать еще одну кодировку для 'Response.CharSet'. Как источник в 65001 и выводятся в 1251 или 1252. - Вы, возможно, знаете, что я просто не думал, что это совершенно ясно из вашего текста, который начинается с того, что они могут быть простыми альтернативами. – Lumi
@Lumi: Я не нахожу такой импликации, я цитирую: «Свойство CharSet ответа задает значение CharSet заголовка Content-Type. Это не влияет на то, как содержимое может быть закодировано». Кажется мне довольно понятным. BTW единственным эффектом __actual__ директивы CODEPAGE является установка «Response.CodePage», его ответственность разработчика за сохранение файла с использованием соответствующей кодовой страницы. – AnthonyWJones
Вы правы. Я смутил «Response.CharSet» и «Response.CodePage». Установка каскада директивы CODEPAGE для последнего, а не первого; он не имеет никакого отношения к заголовку «Content-Type». Я считаю, что директива CODEPAGE лучше всего понимать как «кодирование исходного файла». [Вот пример того, где это важно.] (Http://code.activestate.com/lists/activeperl/21512/) Критическое выражение - 'domXml.createElement (« Französisch »)'. Файл был закодирован в UTF-8 (должен был быть Unicode для всех греческих, русских и т. Д.), И поэтому 'codepage = 65001' был критическим. – Lumi
response.codepage = 65001
, кажется, дают плохой результат, когда физический файл будет сохранен как UTF-8
В противном случае, он работает, как предполагается.
как вы могли исправить это с помощью utf8? – toxicate20
Каким способом является «наследство» кодекса? – AnthonyWJones
Исторически тексты имели * кодовую страницу *, которая просто указывала, какой набор символов использовать. У них было некоторое число, которое отличалось от поставщика к поставщику, для этой цели Windows, похоже, использует 16-разрядное целое без знака. В настоящее время большинство кодировок и наборов символов имеют * имена * вместо * numbers *. Я считаю, что UTF-8 имеет номер кодовой страницы (который нигде не указан и не используется вне Microsoft), чтобы убедиться, что он все еще работает со старой 16-разрядной целочисленной кодовой страницей. Несмотря на то, что UTF-8 ничем не отличается от кодовой страницы. – Joey
@ Johannes: номер кодовой страницы по-прежнему является важной особенностью того, как Windows обрабатывает кодировку символов. Например, в .NET класс Encoding может быть установлен только с использованием номера кодовой страницы. Я не думаю, что Codepage еще является «наследием». – AnthonyWJones