調用A系統的時候，發現請求的header的Accept-Charset過長，請求報文如下
既然是Accept-Charset過長，那麼就先了解下什麼是Accept-Charset
Accept-Charset 請求頭用來告知（服務器）客戶端可以處理的字符集類型。 藉助內容協商機制，服務器可以從諸多備選項中選擇一項進行應用， 並使用Content-Type 應答頭通知客戶端它的選擇。瀏覽器通常不會設置此項值，因爲每種內容類型的默認值通常都是正確的，但是發送它會更有利於識別。如果服務器不能提供任何可以匹配的字符集的版本，那麼理論上來說應該返回一個 406 （Not Acceptable，不被接受）的錯誤碼。但是爲了更好的用戶體驗，這種方法很少採用，取而代之的是將其忽略。
既然看了Accept-Charset，不妨再看看相關的參數
Accept-Encoding 首部明確說明了（接收端）可以接受的內容編碼形式（所支持的壓縮算法）。該首部的值是一個Q因子清單（例如 br, gzip;q=0.8），用來提示不同編碼類型值的優先級順序。默認值 identity 則優先級最低（除非聲明爲其他優先級）。將 HTTP 消息進行壓縮是一種最重要的提升 Web 站點性能的方法。該方法會減小所要傳輸的數據量的大小，節省可用帶寬。瀏覽器總是會發送該首部，服務器則應該配置爲接受它，並且採用一定的壓縮方案。
。。。找到一篇很詳細的文章，就不一一粘貼了，https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Content_negotiation
言歸正傳，繼續說header過長的問題
請求是通過RestTemplate發送的，發送之前設置header中的Accept-Charset,發現並沒起作用
這就很奇怪，繼續百度，發現RestTemplate初始化的時候，設置了MessageConverters,其中還有new StringHttpMessageConverter()
原來是需要特殊設置下StringHttpConvertoer,RestTemplate設置如下，然後問題解決了...
RestTemplate很好用，但是很多參數是需要自己設置的，否則就是默認值了...取默認值很可能效果不是最好的...