Tänä aamuna kollega esitti minulta kysymyksen: sanoin, että saadut parametrit olivat sekaisin, autan ratkaisemaan sen.
Alusta, josta kollegani vastaa, on rakennettu Ext.js kehykseen, ja web.config-konfiguraatiotiedosto on konfiguroitu globaalilla "GB2312"-koodauksella:
<globalization requestEncoding="gb2312" responseEncoding="gb2312" fileEncoding="gb2312" culture="zh-CN"/>
Kun frontend lähettää "kiinalaisen tekstin", taustajärjestelmä saa sekaisin olevia merkkejä Request.QueryString["xxx"].
Riippumatta siitä, miten dekoodaat System.Web.HttpUtility.UrlDecode("xxx", "encoding type"), se ei toimi.
Periaatteen kuvaus: 1: Ensimmäinen asia, joka tulee todeta, on, että kun asiakkaan URL-parametrit toimitetaan, Ext.js koodaa ne ennen lähettämistä, ja asiakkaan koodaus on oletuksena UTF-8-koodaus
2: Miksi se sitten on sekaisin, kun vastaanotetaan parametreja Request.QueryString["xxx"]?
Käännämme käännöksen askel askeleelta, 2.1: Katso QueryString-ominaisuuden koodia:
2.2: Leikkaa FillInQueryStringCollection()-metodiin
2.3: Leikkaus: QueryStringEncoding
QueryStringEncoding-koodista järjestelmä käyttää oletuksena globalisaatiokonfiguraatiosolmun koodausmenetelmää, ja jos ei, oletus on UTF-8-koodaus 2.4: Leikkaa FillFromStringiin (string s, bool urlencoded, koodauskoodaus)
Tästä eteenpäin kaikki parametrisyötteet kutsutaan kerran: HttpUtility.UrlDecode(str2, encoding);
Kun asiakas js lähettää kiinaa palvelimelle utf-8-koodauksessa, vastaanottaessaan sen Request.QueryStringillä, se purkaa sen ensin kerran gb2312:lla, joka on globalisaation määrittämä, mikä johtaa sekavoihin merkkeihin.
1: JS-koodausmenetelmä on URT-8
2: Palvelinpuoli on konfiguroinut oletusasetukseksi GB2312
3: Request.QueryString kutsuu oletuksena HttpUtility.UrlDecodea purkaakseen vastaanotetut parametrit järjestelmäkonfiguraatiokoodauksella.
1: Järjestelmä valitsee oletuskoodauksen seuraavassa järjestyksessä: http-pyyntöotsikko - >globalisaatiokonfiguraatiosolmu - oletus UTF-8
2: Kun URL syötetään suoraan kiinaksi, eri selaimet voivat käsitellä sitä eri tavoin, esimerkiksi: IE ei koodaa ja lähettää suoraan, Firefox lähettää URL-osoitteen GB2312-koodauksen jälkeen.
3: Koodaamattomille "kiinalaisille merkeille", käyttäen Request.QueryStringin sisäistä kutsua HttpUtility.UrlDecode, tekijänä gb2312->utf-8,
Jos kiinalaista merkkiä ei löydy, se muunnetaan oletuksena muotoon "%ufffd", mikä johtaa peruuttamattomiin sekavoihin merkkeihin.
4: Ratkaisun tie Kun tuntee periaatteen, on monia tapoja ratkaista se: 1: Globaali yhtenäisyys on UTF-8-koodaus, mikä säästää vaivaa ja huolta.
2: Kun GB2312 määritellään globaalisti, url on kiinaksi, ja js täytyy koodata, kuten ext.js framework.
Näin voit hoitaa sen vain erityisesti, määrittäen koodauksen ja purkamisen palvelinpuolella. Koska oletusjärjestelmä kutsuu HttpUtility.UrlDecodea ("xxx", järjestelmän konfiguroinnin koodaus) kerran, Kutsut siis HttpUtility.UrlEncodea ("xxx", järjestelmän määrittämä koodaus) uudelleen palataksesi alkuperäiseen urt-8-koodausparametriin
Sitten käytä HttpUtility.UrlDecode("xxx", utf-8) purkaaksesi sen. merkkijono aaa = pyyntö. Request.QueryString["admin"]; Asunnonomistaja
string a1 = HttpUtility.UrlEncode(aaa, System.Text.Encoding.GetEncoding("GB2312"));
merkkijono a2 = HttpUtility.UrlDecode(a1,System.Text.Encoding.UTF8);
| 
Julkaistu 25.12.2015 18.41.49
|
|
|
|
