<%@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" />
Czy powyższy kod jest prawidłowy?Czy strona kodowa 65001 i utf-8 to samo?
Tak.
UTF-8 to CP65001 w systemie Windows (jest to tylko sposób określania UTF-8 na starszej stronie strony kodowej). O ile czytam ASP może obsłużyć UTF-8, gdy zostanie to określone w ten sposób.
Tak, 65001 to identyfikator strony kodowej systemu Windows dla UTF-8, zgodnie z dokumentacją on the Microsoft website. Wikipedia suggests, że strona kodowa IBM 128 i strona kodowa SAP 4110 są również wskaźnikami dla UTF-8.
Twój kod jest prawidłowy, chociaż ja wolę, aby ustawić kodowanie znaków w kodzie zamiast użyć tagu meta: -
<% Response.CharSet = "UTF-8" %>
kodowa 65001 odnosi się do zestawu znaków UTF-8. Musisz się upewnić, że twoja strona asp (i jakiekolwiek inne) są zapisywane jako UTF-8, jeśli zawierają dowolne znaki spoza standardowego zestawu znaków ASCII.
Po określeniu atrybutu CODEPAGE w bloku <% @ wskazuje się, że cokolwiek napisane za pomocą Response.Write powinno być zakodowane na określonej stronie kodowej, w tym przypadku 65001 (utf-8). Warto pamiętać, że nie ma to wpływu na zawartość statyczną, która jest wysyłana dosłownym bajtem dla bajtu odpowiedzi. Stąd też powód, dla którego plik musi zostać faktycznie zapisany przy użyciu podanej strony kodowej.
Właściwość CharSet odpowiedzi ustawia wartość CharSet nagłówka Content-Type. Nie ma to wpływu na sposób, w jaki treść, którą zakodowałem, jedynie informuje klienta, jakie kodowanie jest odbierane. Ponownie ważne jest, aby jego wartość była zgodna z faktycznym wysłanym kodowaniem.
Głównym znaczeniem i skutkiem '<% @ LANGUAGE =" VBSCRIPT "CODEPAGE =" 65001 "%>' jest kodowanie pliku źródłowego jako UTF-8 (lub jakakolwiek by nie była określona strona kodowa). Przechodzi tylko kaskadowo do właściwości 'Response.CharSet'. Możesz zapisać swój plik jako UTF-8 i wstawić odpowiednią deklarację CODEPAGE, a następnie użyć innego kodowania dla 'Response.CharSet'. Jak źródło w 65001 i wyjście w 1251 lub 1252. - Prawdopodobnie wiesz, po prostu nie sądziłem, że jest to całkowicie jasne z twojego tekstu, co zaczyna się od sugerowania, że mogą one być prostymi alternatywami. – Lumi
@Lumi: Nie znajduję takiej implikacji, cytuję "Właściwość CharSet odpowiedzi ustawia wartość CharSet nagłówka Content-Type, co ma wpływ na sposób kodowania treści". Wydaje mi się całkiem jasne. BTW jedynym skutkiem __aktual__ dyrektywy CODEPAGE jest ustawienie opcji 'Response.CodePage', jej odpowiedzialności dewelopera, aby upewnić się, że plik jest zapisany przy użyciu zgodnej strony kodowej. – AnthonyWJones
masz rację. Myliłem 'Response.CharSet' i' Response.CodePage'. Ustawienie kaskadowej dyrektywy CODEPAGE na drugą, a nie na pierwszą; nie ma żadnego wpływu na nagłówek 'Content-Type'. Uważam, że dyrektywa CODEPAGE jest najlepiej rozumiana jako "kodowanie pliku źródłowego". [Oto przykład tego, gdzie to ma znaczenie.] (Http://code.activestate.com/lists/activeperl/21512/) Krytyczne wyrażenie to "domXml.createElement (" Französisch ")'. Plik został zakodowany w UTF-8 (musiał działać w standardzie Unicode dla wszystkich greckich, rosyjskich itp.), Więc "codepage = 65001" było krytyczne. – Lumi
response.codepage = 65001
wydają się dać zły wynik, gdy plik jest zapisywany jako fizyczny UTF-8
W przeciwnym razie, to działa jak to ma.
jak to naprawić za pomocą utf8? – toxicate20
W jaki sposób jest strona kodowa "dziedzictwo"? – AnthonyWJones
Historycznie teksty miały * stronę kodową *, która po prostu określała, który zestaw znaków ma być użyty. Te miały pewną liczbę, która różniła się od dostawcy do dostawcy, Windows wydaje się używać do tego celu 16-bitową liczbę całkowitą bez znaku. W dzisiejszych czasach większość kodowań i zestawów znaków ma * nazwy * zamiast * liczby *. Uważam, że kodowanie UTF-8 ma numer strony kodowej (który nigdzie nie jest określony ani używany poza Microsoftem), aby zapewnić, że nadal działa ze starym 16-bitowym systemem numerów stron kodowych. Mimo że UTF-8 w niczym nie przypomina strony kodowej. – Joey
@Johannes: Numer strony kodowej nadal jest ważną funkcją sposobu, w jaki system Windows obsługuje kodowanie znaków. Na przykład w .NET klasa Encoding może być instancowana tylko przy użyciu numeru strony kodowej. Nie sądzę, aby strona kodowa była jeszcze "starsza". – AnthonyWJones