起因：
前幾天遇到的問題，才有時間記錄，需求：本地生成xml形式的字符串以參數形式用post方法傳送到對方的固定接口；
這個需求寫的時候感覺很容易，本地測試的時候，也覺得很簡單就過了，然后和對方聯調的時候，稀里嘩啦調了N久，
中間對方換了人接手，稀里嘩啦又調了N久，對方改代碼，稀里嘩啦又又調了N久，最后上線了，發現接口對不上，，，
經過：
問題最開始只是亂碼問題，無非就是UTF-8和GBK之間的轉換，我們這邊統一的UTF-8的編碼，對方是GBK。對面改為
了UTF-8，聯調以正確結束；然后對面換人改代碼，說要GBK的，我們發了UTF-8的，他們能解析，然后說頭部編碼格式
要改為GBK，好奇他們居然可以解析的情況下，應要求做出了一個挺low的決定，替換字符串，將UTF-8換為GBK。【其實
這的時候就有點歪了，以至於后面調的比較吃力，當時應該和對方反復確認一下的】。說是沒問題，那就上線了，，，，
然后13call，說亂碼又出現了，，，
前輩們得知有問題后，第一時間支援，開始分析，才發現，最開始的測試是錯的，我用eclipse啟動tomcat服務器，這時候用
的是eclipse的編碼模式，應該生成war包放在tomcat下啟動才能模擬真實的環境，然后我們在不修改環境的情況下各種嘗試
編碼轉換，然后對方說收到了不是亂碼的數據，天真的我以為就可以收尾了
對方馬上提出，收不到參數的那個字段，這里面用的HttpClient的post方法發送，如下↓
CloseableHttpClient client = HttpClients.createDefault();
HttpPost post = new HttpPost("URL");
List<NameValuePair> formparams = new ArrayList<NameValuePair>();
formparams.add(參數);
UrlEncodedFormEntity uefEntity;
uefEntity = new UrlEncodedFormEntity(formparams, "GBK");
post.setEntity(uefEntity);
HttpResponse response2 = client.execute(post);
debug的時候post之前，參數都是有值的，一到post就為null了，濃濃的詭異感飄然而起，前輩當機立斷，換方法
我們換用了HttpURLConnection方法，如下↓
URL postUrl = new URL(URL);
HttpURLConnection connection = (HttpURLConnection) postUrl.openConnection();
connection.setDoOutput(true);
connection.setDoInput(true);
connection.setRequestMethod("POST");
connection.setUseCaches(false);
connection.setInstanceFollowRedirects(true);
connection.setRequestProperty("Content-Type", "application/x-www-form-urlencoded");
connection.connect();
DataOutputStream out = new DataOutputStream(connection.getOutputStream());
String content = "參數=" + URLEncoder.encode(參數, "GBK");
out.writeBytes(content);
收尾了。。。。。
總結：
前輩說，HttpURLConnection是基本的方法，HttpClient是基於HttpURLConnection的封裝，基於“簡單的問題用
復雜的方法，復雜的的問題用簡單的方法”原理，我們回歸原始，，，，
為前輩的機智點贊，記住--生成war包放在tomcat下啟動來模擬真實的環境，好奇為什么定接口的時候不用json，以后
我商討的方案，力爭用json，后期好保養，