<%@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" />
è il codice proprio sopra?La codepage 65001 e utf-8 sono la stessa cosa?
Sì.
UTF-8 è CP65001 in Windows (che è solo un modo di specificare UTF-8 nel roba tabella codici legacy). Per quanto leggo ASP è in grado di gestire UTF-8 quando specificato in questo modo.
Sì, 65001 è l'identificativo della tabella codici di Windows per UTF-8, come documentato on the Microsoft website. Wikipedia suggests che la code page IBM 128 e la codepage 4110 di SAP sono anche indicatori per UTF-8.
Il codice è corretto, anche se io preferisco impostare il set di caratteri nel codice, piuttosto che utilizzare il meta tag: -
<% Response.CharSet = "UTF-8" %>
La tabella codici 65001 si riferisce al set di caratteri UTF-8. Dovresti assicurarti che la tua pagina asp (e qualsiasi include) siano salvate come UTF-8 se contengono caratteri al di fuori del set di caratteri ASCII standard.
Specificando l'attributo CODEPAGE nel blocco <% @ si sta indicando che qualsiasi cosa scritta utilizzando Response.Write deve essere codificata nella tabella codici specificata, in questo caso 65001 (utf-8). Vale la pena ricordare che ciò non influisce sul contenuto statico che viene inviato al byte letterale per byte alla risposta. Da qui il motivo per cui il file deve essere effettivamente salvato utilizzando la codepage specificata.
il set di caratteri di proprietà della risposta imposta il valore CharSet dell'intestazione Content-Type. Ciò non ha alcun impatto sul modo in cui il contenuto del mio essere codificato, ma dice semplicemente al client quale codifica viene ricevuta. Ancora una volta è importante che il suo valore corrisponda alla codifica effettiva inviata.
Il significato e l'effetto principali di '<% @ LANGUAGE =" VBSCRIPT "CODEPAGE =" 65001 "%>' è per la codifica del file di origine come UTF-8 (o qualsiasi altra cosa specificata dalla tabella codici). Si sovrappone solo alla proprietà 'Response.CharSet'. È possibile salvare il file come UTF-8 e inserire la dichiarazione CODEPAGE corrispondente e quindi utilizzare ancora un'altra codifica per 'Response.CharSet'. Mi piace la fonte in 65001 e l'output nel 1251 o nel 1252. - Probabilmente lo sai, non pensavo che fosse completamente chiaro dal tuo testo, il che inizia implicando che potrebbero essere semplici alternative. – Lumi
@Lumi: Non trovo alcuna implicazione del genere, cito "La proprietà CharSet della risposta imposta il valore CharSet dell'intestazione Content-Type, che non ha alcun impatto sul modo in cui il contenuto può essere codificato". Sembra abbastanza chiaro per me. BTW l'unico effetto __actual__ della direttiva CODEPAGE è impostare 'Response.CodePage', è la responsabilità dello sviluppatore per assicurare che il file venga salvato utilizzando la codepage corrispondente. – AnthonyWJones
hai ragione. Ho confuso 'Response.CharSet' e' Response.CodePage'. Impostare la direttiva CODEPAGE in cascata su quest'ultimo, non sul primo; non ha alcuna funzione sull'intestazione 'Content-Type'. Credo che la direttiva CODEPAGE sia meglio intesa come "codifica del file sorgente". [Ecco un esempio di dove conta.] (Http://code.activestate.com/lists/activeperl/21512/) L'espressione critica è 'domXml.createElement (" Französisch ")'. Il file era codificato in UTF-8 (doveva essere Unicode per tutto il greco, il russo, ecc.) E quindi 'codepage = 65001' era fondamentale. – Lumi
response.codepage = 65001
sembrano dare cattivo risultato quando il file fisico viene salvato come UTF-8
In caso contrario, farlo funzionare come si suppone.
come si può risolvere questo con utf8? – toxicate20
In che modo Codepage "legacy"? – AnthonyWJones
Storicamente i testi avevano una * code page * che semplicemente specificava quale set di caratteri usare. Quelli avevano un numero che differiva da venditore a venditore, Windows sembra utilizzare un intero senza segno a 16 bit per quello scopo. Oggigiorno la maggior parte delle codifiche e dei set di caratteri ha * nomi * invece di * numeri *. Considero il fatto che UTF-8 ha un numero di pagina di codice (che non è affatto specificato né utilizzati al di fuori di Microsoft) una cosa per assicurarsi che sta ancora lavorando con il vecchio codice intero sistema il numero di pagina a 16 bit. Anche se UTF-8 non è come una pagina di codice in primo luogo. – Joey
@Johannes: Il numero della tabella codici è ancora una caratteristica importante di come Windows gestisce la codifica dei caratteri. Ad esempio in .NET la classe Encoding può essere istanziata solo utilizzando il numero della tabella codici. Non penso che Codepage sia ancora "legacy". – AnthonyWJones