Utf-8 को JAX-RS (REST) ​​में फ़ॉर्म से स्थानांतरित करने में समस्याएँ

परिचय

वेब एप्लिकेशन इंटरफ़ेस से डेटा स्थानांतरित करने के लिए कई तरीके हैं, लेकिन शायद सबसे आम एक MIME- टाइप application/x-www-form-urlencoded साथ एक फॉर्म भेज रहा है। एक अन्य विकल्प multipart/form-data ।

MVC फ्रेमवर्क में नियंत्रकों को रिसेप्शन के लिए सर्वर तकनीक के रूप में उपयोग किया जा सकता है ( स्प्रिंग एमवीसी , जावा सर्वर पेज , जावा सर्वर फेस को मुख्य जावा प्रौद्योगिकियों से उल्लेख किया जाना चाहिए। लेकिन ये फ्रेमवर्क इंटरफ़ेस डेवलपर के लिए जीवन को काफी कठिन बना देते हैं यदि वह जावा से परिचित नहीं है या जरूरत है। फ्रेमवर्क क्या अनुमति देता है, से एक कदम दूर। आवेदन के बैकएंड में REST इंटरफ़ेस को उजागर करने के मामले में, फ्रंट-एंड डेवलपमेंट को सरल बनाया गया है: एक व्यक्ति जो बुनियादी जावास्क्रिप्ट और jquery जानता है, बैकिंग विकास से स्वतंत्र है, वह कर सकता है, और यहां तक ​​कि जब sc का उपयोग कर रहा हो onizatora विकल्प काफी विस्तार: अपाचे वेग , FreeMarker (यह उल्लेख के लायक है कि Spirng MVC अच्छी तरह से नवीनतम के साथ एकीकृत है), तो सर्वर साइड पर प्रपत्र डेटा बीना, जो देखें / नियंत्रक यह सच है, JSF भी आनुवंशिक समस्या मनाया साथ जुड़ा हुआ है में लिखा है .. एन्कोडिंग के साथ, जिस पर विचार एक अलग लेख के लिए एक विषय है।

पिछले लेख में JAX-RS का एक संक्षिप्त परिचय दिया गया था। और JAX-RS के माध्यम से उजागर किए गए इंटरफ़ेस फॉर्म डेटा के साथ GET और POST अनुरोध स्वीकार कर सकते हैं। गैर latin-1 का उपयोग करते समय इस दृष्टिकोण की समस्याओं पर इस लेख में चर्चा की जाएगी।

JAX-RS में फ़ॉर्म डेटा पुनर्प्राप्त करना

किसी पैरामीटर को किसी फ़ॉर्म से किसी विधि में इंजेक्ट करने के लिए कई एनोटेशन हैं: @Form , @FormParam । एक POST अनुरोध के लिए, @FormParam व्यवहार में GET लिए @QueryParam बराबर है। एक छोटे से अपवाद के साथ: utf-8 का उपयोग करते समय व्यवहार। GET विधि का उपयोग करते समय, urlencoded से एक स्ट्रिंग को डिकोड करना समस्याओं के बिना होता है। POST Content-Type में charset=utf-8 को निर्दिष्ट करना भी आवश्यक है, ताकि जब urlencoded से डीकोड किया जाए, तो बाइट स्ट्रीम UTF-8 में परिवर्तित हो जाएगी, और लैटिन -1 (डिफ़ॉल्ट व्यवहार) नहीं।

ब्राउज़रों

ब्राउज़र्स (या उदाहरण के लिए jquery) एन्कोडिंग निर्दिष्ट नहीं करते हैं, जो प्रपत्र फ़ील्ड के मानों की गलत व्याख्या की ओर ले जाता है यदि उनमें पुराने UTF-8 CPs होते हैं। Content-Type: application/x-www-form-urlencoded; charset=utf-8 हेडर को स्पष्ट रूप से निर्दिष्ट करके jquery का उपयोग करते समय इस समस्या को बाईपास किया जाता है Content-Type: application/x-www-form-urlencoded; charset=utf-8 Content-Type: application/x-www-form-urlencoded; charset=utf-8 । बिना js के एक फॉर्म के लिए, मैं फॉर्म के लिए एक प्रारूप को निर्दिष्ट करके सफल नहीं हो पाया।

Jboss बेचैनी

बेशक, सवाल उठता है: क्या डेटा का उपयोग करना आवश्यक है यदि डेटा अन्य अनुप्रयोगों से आएगा? हमारे मामले में, इसका उपयोग DRY के सिद्धांतों से उचित है: एक ही विधि का उपयोग क्लाइंट फॉर्म और इस एपीआई का उपयोग करके बाहरी अनुप्रयोगों द्वारा दोनों किया जा सकता है।

रेस्टसी क्लाइंट फ्रेमवर्क का उपयोग करते समय, कई विकल्प संभव हैं। उदाहरण के लिए, आप आवश्यक तरीकों से @HeaderParam("Content-Type") जोड़ सकते हैं:

 @Path("/") public interface Rest { @POST @Path("test") public String test(@FormParam("q") String query, @HeaderParam("Content-Type") String contentType); } 

उपयोग इस तरह दिखता है:

 Rest client = ProxyFactory.create(Rest.class, url); client.test(query, "application/x-www-form-urlencode; charset=utf-8"); 

लेकिन क्लाइंट इंटरसेप्टर का उपयोग करने के लिए यह अधिक सही और सुविधाजनक होगा जो Content-Type: application/x-www-form-urlencoded हेडर के लिए charset फ़ील्ड जोड़ता है। इसे निम्नानुसार लागू किया जाता है:

 @ClientInterceptor @HeaderDecoratorPrecedence public class RestInterceptor implements ClientExecutionInterceptor { public static final String FORM_CONTENT_TYPE = "application/x-www-form-urlencoded"; public static final String FORM_CONTENT_TYPE_WITH_CHARSET = "application/x-www-form-urlencoded; charset=utf-8"; @Override public ClientResponse execute(ClientExecutionContext context) throws Exception { String contentType = context.getRequest().getHeaders().getFirst(HttpHeaders.CONTENT_TYPE); if (formWithoutCharset(contentType)) { context.getRequest().header(HttpHeaders.CONTENT_TYPE, FORM_CONTENT_TYPE_WITH_CHARSET); } return context.proceed(); } private boolean formWithoutCharset(String contentType) { return contentType != null && contentType.contains(FORM_CONTENT_TYPE) && ! contentType.contains("charset"); } } 

इंटरसेप्टर का यह संस्करण, ज़ाहिर है, आदर्श नहीं है। यह संभव है कि आप वास्तव में latin-1 में फॉर्म जमा करना चाहते हैं ... लेकिन क्लाइंट कोड को सरल बनाने के लिए यह पहला कदम है।

इसे सक्रिय करने के लिए, आपको रूपरेखा आरंभीकरण प्रक्रिया को थोड़ा ठीक करने की आवश्यकता है:

 public static void initResteasy() { ResteasyProviderFactory factory = ResteasyProviderFactory.getInstance(); RegisterBuiltin.register(factory); InterceptorRegistry<ClientExecutionInterceptor> registry = factory.getClientExecutionInterceptorRegistry(); registry.register(new RestInterceptor()); } 

उसके बाद, ClientRequest का उपयोग करते समय, और अनुरोध भेजने की प्रक्रिया में छद्म वस्तुओं का उपयोग करते समय, यदि application/x-www-form-urlencoded साथ एक Content-Type हेडर है, लेकिन बिना charset , तो वह हेडर चिपका दिया जाता है।