Vanmorgen kreeg ik een vraag van een collega: ik zei dat de ontvangen parameters verward waren, laat mij helpen om het op te lossen.
Het platform waarvoor mijn collega verantwoordelijk is, is gebouwd Ext.js framework, en het web.config-configuratiebestand is geconfigureerd met de globale "GB2312"-codering:
<globalization requestEncoding="gb2312" responseEncoding="gb2312" fileCodering="gb2312" culture="zh-CN"/>
Wanneer de frontend de "Chinese tekst" indient, ontvangt de backend vervormde tekens met Request.QueryString["xxx"].
Hoe je ook decodert met System.Web.HttpUtility.UrlDecode("xxx", "encoding type"), het werkt niet.
Hoofdbeschrijving: 1: Het eerste wat vastgesteld moet worden is dat wanneer de URL-parameters van de client worden ingediend, Ext.js deze codeert voordat hij ze indient, en de codering van de client standaard UTF-8 codering is
2: Waarom is het dan verward bij het ontvangen van parameters met Request.QueryString["xxx"]?
We draaien de compilatie stap voor stap om, 2.1: Kijk naar de code voor de eigenschap QueryString:
2.2: Snijden in de FillInQueryStringCollection()-methode
2.3: Cut: QueryStringEncoding
Uit de QueryStringEncoding-code schakelt het systeem standaard over op de coderingsmethode van de globalisatieconfiguratie-node, en als dat niet zo is, is de standaard UTF-8-codering 2.4: Snijden in FillFromString (string s, bool urlencoded, codering coderen)
Vanaf dit punt zien we dat alle parameterinvoer één keer worden aangeroepen: HttpUtility.UrlDecode(str2, encoding);
Wanneer client js Chinees indient aan de server in utf-8-codering, zal het bij ontvangst met Request.QueryString deze eerst één keer decoderen met gb2312 geconfigureerd door globalisering, wat resulteert in vervormde tekens.
1: De JS-coderingsmethode is URT-8
2: De serverzijde heeft de standaard ingesteld op GB2312
3: Request.QueryString roept standaard HttpUtility.UrlDecode aan om de ontvangen parameters te decoderen met systeemconfiguratiecodering.
1: Het systeem selecteert de standaardcodering in de volgende volgorde: http request header - >globalization configuration node - default UTF-8
2: Bij het direct invoeren van de URL in het Chinees kunnen verschillende browsers dit anders behandelen, bijvoorbeeld: IE codeert niet en stuurt het direct in, Firefox dient de URL in na de GB2312-codering.
3: Voor niet-gecodeerde "Chinese karakters", na gebruik van de interne aanroep HttpUtility.UrlDecode, na gebruik van de interne aanroep van Request.QueryString, door gb2312->utf-8,
Als het Chinese teken niet wordt gevonden, wordt het standaard omgezet naar "%ufffd", wat resulteert in onomkeerbare vervormde tekens.
4: De weg naar een oplossing Als je het principe kent, zijn er veel manieren om het op te lossen: 1: De wereldwijde unificatie is UTF-8-codering, wat problemen en zorgen bespaart.
2: Wanneer GB2312 globaal wordt gespecificeerd, is de url Chinees en moet js worden gecodeerd, zoals ext.js framework.
Op deze manier kun je het alleen specifiek afhandelen, waarbij je de codering en decodering aan de serverzijde specificeert. Omdat het standaardsysteem HttpUtility.UrlDecode("xxx", de codering van de systeemconfiguratie) één keer aanroept, Dus roep je HttpUtility.UrlEncode("xxx", de codering die door het systeem is geconfigureerd) opnieuw aan om terug te keren naar de oorspronkelijke urt-8 coderingsparameter
Gebruik vervolgens HttpUtility.UrlDecode("xxx", utf-8) om het te decoderen. string aaa = verzoek. Request.QueryString["admin"]; Huiseigenaar
string a1 = HttpUtility.UrlEncode(aaa, System.Text.Encoding.GetEncoding("GB2312"));
string a2 = HttpUtility.UrlDecode(a1,System.Text.Encoding.UTF8);
| 
Geplaatst op 25-12-2015 18:41:49
|
|
|
|
