易支付對接java（易支付對接碼支付）

本文目錄一覽：

• 1、java開發業務網上支付功能，需要準備些什麼業務、與哪些機構協商，和在技術上介面對接有哪些。
• 2、易支付怎麼配置支付介面?在哪個文件?
• 3、易支付有哪些app對接
• 4、易支付可以對接易支付的嗎?
• 5、java接入易寶支付時,商品名稱為UTF-8編碼的中文，如何轉換成GBK編碼的中文

java開發業務網上支付功能，需要準備些什麼業務、與哪些機構協商，和在技術上介面對接有哪些。

網上支付一般都需要找銀行做介面的。銀行都有自己的軟體開發部。支付流程先得經過甲方同意，至於介面實現詳細內容和銀行技術部談談就清楚了。

易支付怎麼配置支付介面?在哪個文件?

用掛機寶掛機就可以了，不需要配置文件，有掛機軟體提供給你，掛上即可使用！

易支付有哪些app對接

對接支付寶,微信,QQ錢包,財付通

EasyPay(易支付)集成並高度封裝了Android平台的微信支付,支付寶支付以銀聯支付。

易支付可以對接易支付的嗎?

易支付可以對接易支付的。而且對接流程很簡單，在後台找到支付通道配置選項，如圖：

然後直接選中易支付，填寫相應參數並保存即可。

java接入易寶支付時,商品名稱為UTF-8編碼的中文，如何轉換成GBK編碼的中文

1.編碼基礎知識

最早的編碼是iso8859-1，和ascii編碼相似。但為了方便表示各種各樣的語言，逐漸出現了很多標準編碼，重要的有如下幾個。

1.1. ISO-8859-1 通常叫做Latin-1

屬於單位元組編碼，最多能表示的字元範圍是0-255，應用於英文系列。比如，字母a的編碼為0x61=97。

很明顯，iso8859-1編碼表示的字元範圍很窄，無法表示中文字元。但是，由於是單位元組編碼，和計算機最基礎的表示單位一致，所以很多時候，仍舊使用iso8859-1編碼來表示。

而且在很多協議上，默認使用該編碼。比如，雖然”中文”兩個字不存在iso8859-1編碼，

以gb2312編碼為例，應該是”d6d0 cec4″兩個字元（java字元佔2個位元組），

使用iso8859-1編碼的時候則將它拆開為4個位元組來表示：”d6 d0 ce c4″（事實上，在進行存儲的時候，也是以位元組為單位處理的）。

而如果是UTF編碼，則是6個位元組”e4 b8 ad e6 96 87″。

很明顯，這種表示方法還需要以另一種編碼為基礎。

1.2. GB2312/GBK

這就是漢字的國標碼，專門用來表示漢字，是雙位元組編碼，而英文字母和iso8859-1一致（兼容iso8859-1編碼）。

其中gbk編碼能夠用來同時表示繁體字和簡體字，

而gb2312隻能表示簡體字，gbk是兼容gb2312編碼的。

1.3 unicode

這是最統一的編碼，可以用來表示所有語言的字元，而且是定長雙位元組（也有四位元組的）編碼，包括英文字母在內。所以可以說它是不兼容iso8859-1編碼的，也不兼容任何編碼。不過，相對於iso8859-1編碼來說，uniocode編碼只是在前面增加了一個0位元組，比如字母a為”00 61″。

需要說明的是，定長編碼便於計算機處理（注意GB2312/GBK不是定長編碼），而unicode又可以用來表示所有字元，所以在很多軟體內部是使用unicode編碼來處理的，比如java。

1.4 UTF

考慮到unicode編碼不兼容iso8859-1編碼，而且容易佔用更多的空間：因為對於英文字母，unicode也需要兩個位元組來表示。所以unicode不便於傳輸和存儲。因此而產生了utf編碼，utf編碼兼容iso8859-1編碼，同時也可以用來表示所有語言的字元，不過，utf編碼是不定長編碼，每一個字元的長度從1-6個位元組不等。另外，utf編碼自帶簡單的校驗功能。一般來講，英文字母都是用一個位元組表示，而漢字使用三個位元組。

注意，雖然說utf是為了使用更少的空間而使用的，但那只是相對於unicode編碼來說，如果已經知道是漢字，則使用GB2312/GBK無疑是最節省的。不過另一方面，值得說明的是，雖然utf編碼對漢字使用3個位元組，但即使對於漢字網頁，utf編碼也會比unicode編碼節省，因為網頁中包含了很多的英文字元。

2.Unicode、UTF-8 和 ISO8859-1區別與聯繫

將以”中文”兩個字為例，經查表可以知道其

GB2312編碼是”d6d0 cec4″，

Unicode編碼為”4e2d 6587″，

UTF編碼就是”e4b8ad e69687″。

注意，這兩個字沒有iso8859-1編碼，但可以用iso8859-1編碼來表示。

2.1 Unicode與各編碼之間的直接轉換

下面以對中文字元串＂a中文＂的編碼轉換為例，來了解各種編碼之間的轉換

1）Unicode和GBK

測試結果如下，每個漢字轉換為兩個位元組，且是可逆的，即通過位元組可以轉換回字元串

String－GBK〉ByteArray：/u0061/u4E2D/u6587（a中文）－〉0x61 0xD6 0xD0 0xCE 0xC4 ByteArray－GBK〉String：0x61 0xD6 0xD0 0xCE 0xC4－〉/u0061/u4E2D/u6587（a中文）

2）Unicode和UTF-8

測試結果如下，每個漢字轉換為三個位元組，且是可逆的，即通過位元組可以轉換回字元串

String－UTF-8〉ByteArray：/u0061/u4E2D/u6587（a中文）－〉0x61 0xE4 0xB8 0xAD 0xE6%0x96 0x87 ByteArray－UTF-8〉String：0x61 0xE4 0xB8 0xAD 0xE6%0x96 0x87－〉/u0061/u4E2D/u6587（a中文）

3）Unicode和ISO-8859-1

測試結果如下，當存在漢字時轉換失敗，非可逆，即通過位元組不能再轉換回字元串

String－ISO-8859-1〉ByteArray：/u0061/u4E2D/u6587（a中文）－〉0x61 0x3F 0x3F ByteArray－ISO-8859-1〉String：0x61 0x3F 0x3F－〉/u0061/u003F/u003F（a??）

2.2 Unicode與各編碼之間的交叉轉換

在上面直接轉換中，由字元串（Unicode）生成的位元組數組，在構造回字元串時，使用的是正確的編碼集合，如果使用的不是正確的編碼集合會怎樣呢？會正確構造嗎？如果不能正確構造能有辦法恢復嗎？會信息丟失嗎？

下面我們就來看看這種情況，這部分可以說明在某些情況下雖然我們最終正確顯示了結果，但其間仍然進行了不正確的轉換。

1）能夠正確顯示的中間不正確轉換

我們知道String－GBK〉ByteArray－GBK〉String是正確的，但如果我們採用String－GBK〉

ByteArray－ISO-8859-1〉String呢？通過測試結果如下：

String－GBK〉ByteArray－ISO-8859-1〉String：/u0061/u4E2D/u6587（a中文）－〉0x61 0xD6 0xD0 0xCE 0xC4－〉/u0061/u00D6/u00D0/u00CE/u00C4（a????

這時我們得到的字元串為？亂碼「a????」，但是通過繼續轉換我們仍然可以復原回正確的字元串「a中文」，過程如下：

String－GBK〉ByteArray－ISO-8859-1〉String－ISO-8859-1〉ByteArray－GBK〉String

對應：/u0061/u4E2D/u6587（a中文）－〉0x61 0xD6 0xD0 0xCE 0xC4－〉/u0061/u00D6/u00D0/u00CE/u00C4（a????）－〉0x61 0xD6 0xD0 0xCE 0xC4－〉/u0061/u4E2D/u6587（a中文）

也就是我們在首次構造字元串時，我們用了錯誤的編碼集合得到了錯誤的亂碼，但是我們通過錯上加錯，再用錯誤的編碼集合獲取位元組數組，然後再用正確的編碼集合構造，就又恢復了正確的字元串。這時就屬於是「能夠正確顯示的中間不正確轉換」。在Jsp頁面提交數據處理時常常發生這種情況。

此外能夠正確顯示的中間不正確轉換還有：

String－UTF-8〉ByteArray－ISO-8859-1〉String－ISO-8859-1〉ByteArray－UTF-8〉String

和

String－UTF-8〉ByteArray－GBK〉String－GBK〉ByteArray－UTF-8〉String

對應：/u0061/u4E2D/u6587（a中文）－〉0x61 0xE4 0xB8 0xAD 0xE6%0x96 0x87－〉/u0061/u6D93/uE15F/u6783（a涓枃）－〉0x61 0xE4 0xB8 0xAD 0xE6%0x96 0x87－〉/u0061/u4E2D/u6587（a中文）

2.3 編碼過程中錯誤診斷參考

1）一個漢字對應一個問號

在通過ISO-8859-1從字元串獲取位元組數組時，由於一個Unicode轉換成一個byte，當遇到不認識的Unicode時，轉換為0x3F，這樣無論用哪種編碼構造時都會產生一個？亂碼。

2）一個漢字對應兩個問號

在通過GBK從字元串獲取位元組數組時，由於一個Unicode轉換成兩個byte，如果此時用ISO-8859-1或用UTF-8構造字元串就會出現兩個問號。

若是通過ISO-8859-1構造可以再通過上面所說的錯上加錯恢復（即再通過從ISO-8859-1解析，用GBK構造）；

若是通過UTF-8構造則會產生Unicode字元＂/uFFFD＂，不能恢復，若再通過String－UTF-8〉ByteArray－GBK〉String，則會出現雜碼，如a錕斤拷錕斤拷

3）一個漢字對應三個問號

在通過UTF-8從字元串獲取位元組數組時，由於一個

這是java字元串處理的一個標準函數，其作用是將字元串所表示的字元按照charset編碼，並以位元組方式表示。注意字元串在java內存中總是按unicode編碼存儲的。比如”中文”，正常情況下（即沒有錯誤的時候）存儲為”4e2d 6587″，如果charset為”gbk”，則被編碼為”d6d0 cec4″，然後返回位元組”d6 d0 ce c4″.如果charset為”utf8″則最後是”e4 b8 ad e6 96 87″.如果是”iso8859-1″，則由於無法編碼，最後返回 “3f 3f”（兩個問號）。

3. java對字元的處理

在java應用軟體中，會有多處涉及到字符集編碼，有些地方需要進行正確的設置，有些地方需要進行一定程度的處理。

3.1 getBytes(charset)

這是java字元串處理的一個標準函數，其作用是將字元串所表示的字元按照charset編碼，並以位元組方式表示。

注意字元串在java內存中總是按unicode編碼存儲的。

比如”中文”，正常情況下（即沒有錯誤的時候）存儲為”4e2d 6587″，

如果charset為”gbk”，則被編碼為”d6d0 cec4″，然後返回位元組”d6 d0 ce c4″。

如果charset為”utf8″則最後是”e4 b8 ad e6 96 87″。

如果是”iso8859-1″，則由於無法編碼，最後返回 “3f 3f”（兩個問號）。

3.2 new String(charset)

這是java字元串處理的另一個標準函數，和上一個函數的作用相反，將位元組數組按照charset編碼進行組合識別，最後轉換為unicode存儲。

參考上述getBytes的例子，”gbk” 和”utf8″都可以得出正確的結果”4e2d 6587″，但iso8859-1最後變成了”003f 003f”（兩個問號）。

因為utf8可以用來表示/編碼所有字元，所以new String( str.getBytes( “utf8” ), “utf8” ) === str，即完全可逆。

3.3 setCharacterEncoding()

該函數用來設置http請求或者相應的編碼。

對於request，是指提交內容的編碼，指定後可以通過getParameter()則直接獲得正確的字元串，如果不指定，則默認使用iso8859-1編碼，需要進一步處理。

參見下述”表單輸入”。值得注意的是在執行setCharacterEncoding()之前，不能執行任何getParameter()。

java doc上說明：This method must be called prior to reading request parameters or reading input using getReader()。

該指定只對POST方法有效，對GET方法無效。分析原因:

POST方法在執行第一個getParameter()的時候，java將會按照編碼分析所有的提交內容，而後續的getParameter()不再進行分析，所以setCharacterEncoding()無效。

GET方法提交表單是，提交的內容在URL中，一開始就已經按照編碼分析所有的提交內容，setCharacterEncoding()自然就無效。

注意：iso-8859-1是JAVA網路傳輸使用的標準字符集,而gb2312是標準中文字符集,當你作出提交表單等需要網路傳輸的操作的時候,就需要把 iso-8859-1轉換為gb2312字符集顯示,否則如果按瀏覽器的gb2312格式來解釋iso-8859-1字符集的話,由於2者不兼容,所以會 是亂碼.