2

У меня возникла проблема с получением PayPal Payflow Gateway, который принимает мой HTTPS POST с неамериканскими символами ASCII. Не важно, что я публикую с этими специальными символами, похоже, хочет принять только закодированные в US-ASCII байты. Если я отправляю кодированные байты UTF-8, он все равно работает, но не выполняет синтаксический анализ некоторых значений запроса NVP. Я знаю, что это возможно, потому что я отправил тестовую страницу другого разработчика в мою учетную запись (NVP Quick Test), и это сообщение, похоже, сохраняет специальные символы.PayPal Payflow Gateway UTF-8 Персонажи

Вот пример. Я пробовал с МНОГО разных заголовков Content-Type и Accept/Accept-Charset, включая указание «; charset = UTF-8» или «; charset = utf-8» в Content-Type после текста/имени.

POST https://pilot-payflowpro.paypal.com/ HTTP/1.1 
Content-Type: text/namevalue 
User-Agent: KLMS Payflow API for Java 
X-VPS-Request-ID: 36A4ED051A8B492ABF70E6BE51CB13D5 
X-VPS-CLIENT-TIMEOUT: 20 
Connection: close 
X-VPS-VIT-INTEGRATION-PRODUCT: KLMS Payflow API for Java 
X-VPS-VIT-INTEGRATION-VERSION: 2.0.008 
X-VPS-VIT-PROXY: Y 
X-VPS-VIT-RUNTIME-VERSION: 20.45-b01 
X-VPS-VIT-OS-ARCHITECTURE: amd64 
X-VPS-VIT-OS-VERSION: 6.1 
X-VPS-VIT-OS-NAME: Windows 7 
Cache-Control: no-cache 
Pragma: no-cache 
Host: pilot-payflowpro.paypal.com 
Content-Length: 694 

USER[8]=XXXXXXXX&VENDOR[13]=XXXXXXXXXXXXX&PARTNER[6]=PayPal&PWD[8]=XXXXXXXX&VERBOSITY[4]=HIGH&BILLTOEMAIL[28][email protected]&TRXTYPE[1]=A&TENDER[1]=C&ACCT[16]=4111111111111111&EXPDATE[4]=1117&CVV2[3]=123&BILLTOFIRSTNAME[4]=Josè&BILLTOLASTNAME[7]=Elkjærd&BILLTOSTREET[14]=123 Elm Street&BILLTOCITY[9]=Elm Creek&BILLTOSTATE[2]=VA&BILLTOZIP[5]=22203&BILLTOCOUNTRY[2]=US&BILLTOPHONENUM[12]=763-221-5593&CUSTBROWSER[108]=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.91 Safari/537.36&CUSTHOSTNAME[12]=192.168.1.10&CUSTIP[12]=192.168.1.10&AMT[6]=600.00&CURRENCY[3]=USD&COMMENT1[26]=Law Enforcement Curriculum&COMMENT2[16]=Standard Version 

HTTP/1.1 200 OK 
Connection: close 
Server: VPS-3.033.00 
X-VPS-Request-ID: 36A4ED051A8B492ABF70E6BE51CB13D5 
Date: Sun, 25 Jan 2015 17:45:05 GMT 
Content-type: text/namevalue 
Content-length: 199 

RESULT=104&PNREF=B70P7B6EBAE7&RESPMSG=Timeout waiting for Processor response&TRANSTIME=2015-01-25 09:44:47&BILLTOFIRSTNAME=Jos &BILLTOLASTNAME=NotProvided&AMT=600.00&ACCT=1111&EXPDATE=1117&CARDTYPE=0 

Игнорируйте это время ожидания 104. PayPal работает над этим. Вы можете видеть, что BILLTOFIRSTNAME - это Jos (странный персонаж, который не является), а символ æ в BILLTOLASTNAME, должно быть, заставил алгоритм синтаксического анализа NVP полностью не разбираться, потому что он говорит NotProvided.

Вот код, который преобразует строку Java в НВП отформатированный форме в байтах:

 final byte[] requestBytes = requestString.getBytes(Charsets.UTF_8); 

Любая идея, какой символ, кодирующий серверный НВП анализатор ищет по умолчанию, или как сказать ему, какой характер кодирование Я отправляю тело POST в?

+0

[Payflow шлюз Документы:] (https://developer.paypal.com/webapps/developer/docs/classic/payflow/integration-guide/#supported-languages) 'Payflow шлюз поддерживает только ввод клиента и значения параметров API, которые находятся в обычных символах ASCII (английский язык). Payflow не поддерживает расширенные символы ASCII или любые другие наборы символов, отличные от обычного ASCII в это время. – EdSF

ответ

2

Я нашел решение. Похоже, что он не поддерживается Payflow Gateway Docs. Документы кажутся устаревшими и нуждаются в обновлении. Я работал с поддержкой PayPal, и похоже, что Gateway Payflow поддерживает UTF-8. Вот трюк: либо вам нужно НЕ указывать параметр длины в парах имя/значение, которые вы отправляете (например, BILLTOFIRSTNAME = Josè), либо вам нужно указать в параметре длины как не длину в CHARACTERS (т. Е. Not value.length ()), но фактическая длина в байтах кодированного байтового потока UTF-8 для значения (т.е. length.getBytes («UTF-8»). length). Эта транзакция сработала, сохранила символы UTF-8 и правильно отобразилась в диспетчере PayPal, и правильное значение было возвращено в парах name/value ответа Gateway Gateway. Как вы можете видеть, разница в том, что теги длины BILLTOFIRSTNAME и BILLTOLASTNAME теперь больше и определяют длину в байтах вместо длины в символах. Josè [4 символа, но 5 байт: 4A 6F ​​73 C3 A8] и Elkjærd & Grün [14 символов, но 16 байт: 45 6C 6B 6A C3 A6 72 64 20 26 20 47 72 C3 BC 6E].

POST https://pilot-payflowpro.paypal.com/ HTTP/1.1 
Content-Type: text/namevalue 
Connection: close 
User-Agent: KLMS Payflow for Java/2.0.008 
X-VPS-Request-ID: B8DABD9BDFE246EC909B4CF741030133 
X-VPS-CLIENT-TIMEOUT: 20 
X-VPS-VIT-INTEGRATION-PRODUCT: KLMS Payflow for Java 
X-VPS-VIT-INTEGRATION-VERSION: 2.0.008 
X-VPS-VIT-PROXY: Y 
X-VPS-VIT-RUNTIME-VERSION: 20.45-b01 
X-VPS-VIT-OS-ARCHITECTURE: amd64 
X-VPS-VIT-OS-VERSION: 6.1 
X-VPS-VIT-OS-NAME: Windows 7 
Cache-Control: no-cache 
Pragma: no-cache 
Host: pilot-payflowpro.paypal.com 
Content-Length: 771 

USER[8]=XXXXXXXX&VENDOR[13]=XXXXXXXXXXXXX&PARTNER[6]=PayPal&PWD[8]=XXXXXXXX&VERBOSITY[4]=HIGH&BILLTOEMAIL[28][email protected]&TRXTYPE[1]=A&TENDER[1]=C&ACCT[16]=4111111111111111&EXPDATE[4]=0216&CVV2[3]=123&BILLTOFIRSTNAME[5]=Josè&BILLTOLASTNAME[16]=Elkjærd & Grün&BILLTOSTREET[14]=123 Elm Street&BILLTOSTREET2[10]=Elm & Vine&BILLTOCITY[9]=Elm Creek&BILLTOSTATE[2]=VA&BILLTOZIP[5]=12345&BILLTOCOUNTRY[2]=US&BILLTOPHONENUM[12]=763-221-5593&CUSTBROWSER[108]=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.91 Safari/537.36&CUSTHOSTNAME[12]=192.168.1.10&CUSTIP[12]=192.168.1.10&AMT[6]=600.00&CURRENCY[3]=USD&COMMENT1[45]=Victim Advocate Curriculum (Standard Version)&COMMENT2[36]=Purchased for J.C. Hamlin (jchamlin) 

HTTP/1.1 200 OK 
Connection: close 
Server: VPS-3.033.00 
X-VPS-Request-ID: B8DABD9BDFE246EC909B4CF741030133 
Date: Wed, 28 Jan 2015 01:45:29 GMT 
Content-type: text/namevalue 
Content-length: 209 

RESULT=104&PNREF=B10P7D2F1643&RESPMSG=Timeout waiting for Processor response&TRANSTIME=2015-01-27 17:45:12&BILLTOFIRSTNAME=Josè&BILLTOLASTNAME[16]=Elkjærd & Grün&AMT=600.00&ACCT=1111&EXPDATE=0216&CARDTYPE=0 
+0

В Java значение 'value.length' не указывает количество символов в строке. Он просто сообщает количество 16-разрядных блоков кода, что является очень невыполнимой и низкоуровневой детальностью. Чтобы подсчитать символы, вы должны подсчитывать целые кодовые точки, а не их отдельные компоненты под той или иной кодировкой. – tchrist

+0

String.length() работает, но не совсем точно. Что вводит в заблуждение, так это то, что String.length() - это то, что передает Java-сервер Payflow в payflow.jar на сервер. Также SDK Payflow Java SDK использует кодировку по умолчанию системы, вызывая String.getBytes() и новую строку (байты). Payflow.jar ошибочен в обоих случаях (т. Е. Обе вещи являются реальными ошибками в реализации SDK Payflow Java SDK и несовместимы с сервером шлюза Payflow). –