1. 客戶端 -> 服務(wù)端的問(wèn)題
1.1. get 方式提交短數(shù)據(jù)效率比 post 方式高
原因：個(gè)人感覺(jué)
1.2. post 方式提交時(shí)，若數(shù)據(jù)中含有中文，則服務(wù)端獲得的數(shù)據(jù)中文部分會(huì)變?yōu)閬y碼
原因：　　可能是提交時(shí) XMLHttpRequest 自動(dòng)對(duì)非標(biāo)準(zhǔn) ASCII 字符進(jìn)行了編碼。
　　　　　可能只是簡(jiǎn)單的逸碼轉(zhuǎn)換，但具體編碼方式不詳， 在服務(wù)端就很難還原。
解決：(a) 在客戶端提交前，對(duì)串中的非標(biāo)準(zhǔn) ASCII 字符用 escape() 手動(dòng)轉(zhuǎn)碼。
　　　　　這種方法對(duì)非標(biāo)碼位置比較有規(guī)律(比如存放在不同的變量中)的情況比較合適。
　　　　　在服務(wù)端獲取后無(wú)須用 unescape() 轉(zhuǎn)換即可正常處理。
　　　(b) 對(duì)非標(biāo)碼多而不方便分別 escape() 的，可以用 encodeURI() 兩次(是兩次，不是一次)。
　　　　　服務(wù)端獲取后用 decodeURI() 一次即得到原正確內(nèi)容。
疑惑：
　　　　　以上兩個(gè)解決方法經(jīng)測(cè)試都正確可行。
　　　　　有個(gè)疑惑就是，瀏覽器在提交數(shù)據(jù)的時(shí)候，看起來(lái)是對(duì)非標(biāo)碼進(jìn)行了一次轉(zhuǎn)換，
　　　　　而在服務(wù)端獲取時(shí)(如 Request(), getAttribute() 等)，看起來(lái)又偷偷進(jìn)行了一次逆向轉(zhuǎn)換。
　　　　　而這兩次轉(zhuǎn)換似乎沒(méi)有遵循同樣的標(biāo)準(zhǔn)，從而對(duì)非標(biāo)碼的默認(rèn)轉(zhuǎn)換會(huì)導(dǎo)致取不到正確的內(nèi)容。
　　　　　而在客戶端 escape() 后，服務(wù)端的逆轉(zhuǎn)換結(jié)果就是正確的?？上?escape() 會(huì)對(duì)串中的所有可轉(zhuǎn)換
　　　　　字符都進(jìn)行轉(zhuǎn)換，而標(biāo)準(zhǔn) ASCII 碼轉(zhuǎn)換后，在服務(wù)端取出來(lái)又成了錯(cuò)的了(神奇....)。
　　　　　所以 escape() 僅適合用來(lái)轉(zhuǎn)非標(biāo)碼。
　　　　　終極解決方案就是，在客戶端進(jìn)行連續(xù)的兩次 encodeURI()。
　　　　　這個(gè)規(guī)律是從分析服務(wù)端轉(zhuǎn)碼后的結(jié)果串得到的。
　　　　　比如‘中'字，在 encodeURI() 一次后被轉(zhuǎn)碼為‘%E4%B8%AD'，而在服務(wù)端手動(dòng)進(jìn)行一次
　　　　　decodeURI() 卻得到了亂碼，猜想會(huì)不會(huì)是 Request() 偷偷進(jìn)行那一次轉(zhuǎn)碼把不該轉(zhuǎn)的重要標(biāo)志
　　　　　‘%'也轉(zhuǎn)掉了，于是在客戶端多做一次 encodeURI()，此時(shí)‘中'字的轉(zhuǎn)碼結(jié)果就成了
　　　　　‘%25E4%25B8%25AD'，25h 恰好便是‘%'，這樣一來(lái)，服務(wù)端偷轉(zhuǎn)一次，把‘%25'解為
　　　　　‘%'，再由手動(dòng) decodeURI() 轉(zhuǎn)的時(shí)候，串已經(jīng)變成了‘%E4%B8%AD'，這樣就得到了正確的
　　　　　內(nèi)容。
　　　　　好像沒(méi)有說(shuō)清楚，不過(guò)我是明白了，希望以后忘掉的時(shí)候也能再看懂。
2. 服務(wù)端 -> 客戶端的問(wèn)題
2.1. 回轉(zhuǎn)含有中文的數(shù)據(jù)時(shí)，客戶端收到的是亂碼
原因：　　肯定是頁(yè)面編碼的問(wèn)題，因?yàn)槲业那疤峋褪遣粡?qiáng)求使用統(tǒng)一的編碼，所以這個(gè)問(wèn)題要解決。
解決：　　太簡(jiǎn)單，只需要在服務(wù)端向客戶端回寫數(shù)據(jù)前任何地方設(shè)置 Response.Chartset = "gb2312" 即可，
　　　　　不需要像很多討論到的要轉(zhuǎn)碼甚至有人寫出大段的轉(zhuǎn)碼程序，當(dāng)然，客戶端如果是別的編碼方式，
　　　　　改一下就行了。
2.2. 客戶端用 JSON 方式處理接收數(shù)據(jù)時(shí)，eval() 函數(shù)不能正確地把收到的數(shù)據(jù)解釋為代碼片段
　　　　　比如用 var obj = eval( "{ p1:1, p2:2 }" ) 這樣的形式，obj 是不能正確被初始化為對(duì)象實(shí)例的，而是會(huì)
　　　　　收到一個(gè)缺少分號(hào)的錯(cuò)誤，而用 eval( "var obj = { p1:1, p2:2 }" ) 這樣的形式，就能正確地生成一個(gè)
　　　　　obj 的有效對(duì)象實(shí)例。
　　　　　其實(shí)仔細(xì)想一下，似乎也對(duì)，eval() 并不是如書(shū)上所講，直接把串作為代碼的一部分插入到整個(gè)代碼
　　　　　段中，而是返回轉(zhuǎn)入的表達(dá)式的值，而以‘{...}'的形式定義的空函數(shù)對(duì)象，其表達(dá)式值本身是
　　　　　undefined，而若其中成員多于一個(gè)，則此表達(dá)值根本不能作為合法語(yǔ)法獨(dú)立存在，所以才會(huì)報(bào)錯(cuò)；
　　　　　而后一種形式，其實(shí)質(zhì)其實(shí)是一個(gè)賦值表達(dá)式，雖然前綴了 var 會(huì)導(dǎo)致整個(gè)表達(dá)式值為 undefined，
　　　　　但此過(guò)程中卻真實(shí)地生成了 obj 對(duì)象實(shí)例。在之后的上下文中引用 obj 就是有效的了。
　　　　　經(jīng)過(guò)實(shí)驗(yàn)看來(lái)，書(shū)上和部分前輩文章提到的第一種用法，其實(shí)是不能正確工作的，至少在我的機(jī)器
　　　　　上，它確實(shí)失敗了。當(dāng)然，不能不考慮有可能是我的瀏覽器甚至是 OS 本身的原因，這個(gè)就深了。
　　　　　解決：不管有多深，問(wèn)題總是要解決的。也很簡(jiǎn)單，只需要按第二種形式，把接收變量的定義一起放
　　　　　到 eval() 中，即可正常工作。
　　　　　另外，回轉(zhuǎn) JSON 數(shù)據(jù)時(shí)，也要考慮B/S雙方編碼問(wèn)題，如果不一致，按 2.2 中的方法即可解決。
　　　　　很重要的一點(diǎn)是，有時(shí)候 debug 或 trace 出來(lái)的結(jié)果，特別是字符串，看起來(lái)確實(shí)是正確的，但就
　　　　　是不能正常工作，那時(shí)候就需要從編碼的層次去驗(yàn)證，而不要僅僅考慮代碼本身邏輯的問(wèn)題。因?yàn)橛?
　　　　　些非打印編碼，在 debug 和 trace 時(shí)都是不會(huì)被回顯到屏幕上的。“眼見(jiàn)非實(shí)”，這一點(diǎn)，在任何
　　　　　地方永遠(yuǎn)適用。
綜合感受
　　　　　Ajax 作為一種技術(shù)，其本身并無(wú)先進(jìn)之處，相反過(guò)多地依賴和信仰會(huì)令其成為開(kāi)發(fā)中的累贅，大量
　　　　　的精力耗費(fèi)在基礎(chǔ)工作中，思路游離于業(yè)務(wù)邏輯之外，這是一件好事，可以令你的工作更快地以失敗
　　　　　告終。
　　　　　但，Ajax 作為一種思想，反而是值得推崇的，這種思想，早已經(jīng)由賣童裝的美特斯邦威作出了精辟
　　　　　的概括——不走尋常路。
　　　　　數(shù)年來(lái)，在世界各地，
　　　　　有 80% 的開(kāi)發(fā)人員沒(méi)有想到在 submit 之外去找路，他們是幸福的，他們走在一條熟悉的路上。
　　　　　另外 10% 的人走在了 iframe 的路上，他們是幸運(yùn)的，他們找到了一條風(fēng)景更加美好的路。
　　　　　另外 8% 的人在草叢中發(fā)現(xiàn)了 XMLHttpRequest，他們是值得尊敬的，他們替人們找到了新的路。
　　　　　另外 2% 的人把這條新路命名為 Ajax，他們是偉大的，他們替人們找到了加班到累死的理由。

最新評(píng)論