本文目录一览：
- 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者不兼容,所以会 是乱码.
