অ্যাপ্লিকেশন / এক্স-www-ফর্ম-urlencoded বা মাল্টিপার্ট / ফর্ম-ডেটা?

Question

এইচটিটিপিতে ডেটা পোস্ট করার দুটি উপায় রয়েছে: application/x-www-form-urlencodedএবং multipart/form-data। আমি বুঝতে পারি যে বেশিরভাগ ব্রাউজারগুলি কেবলমাত্র multipart/form-dataব্যবহৃত হলেই ফাইল আপলোড করতে সক্ষম । কোনও API প্রসঙ্গে (কোনও ব্রাউজার জড়িত নেই) কোনও এনকোডিং প্রকারের ব্যবহার করার জন্য কি কোনও অতিরিক্ত নির্দেশিকা রয়েছে? এটি উদাহরণস্বরূপ উপর ভিত্তি করে হতে পারে:

• তথ্য আকার
• অ-এসসিআইআই অক্ষরগুলির অস্তিত্ব
• বাইনারি ডেটা (অচিহ্নবিহীন) অস্তিত্ব
• অতিরিক্ত ডেটা স্থানান্তর করার প্রয়োজন (ফাইলের নামের মতো)

আমি মূলত এখন পর্যন্ত বিভিন্ন সামগ্রী-প্রকারের ব্যবহার সম্পর্কে ওয়েবে কোনও আনুষ্ঠানিক নির্দেশিকা পাইনি।

Comments

এটি উল্লেখ করা উচিত যে এই দুটি মাইম টাইম যা এইচটিএমএল ফর্মগুলি ব্যবহার করে। এইচটিটিপি নিজেই এর কোনও সীমাবদ্ধতা নেই ... এইচটিটিপি এর মাধ্যমে মাই টাইম যা খুশি তা ব্যবহার করতে পারে।

— tybro0103

Answer 1

টি এল; ডিআর

সারসংক্ষেপ; আপনার যদি প্রেরণ করতে বাইনারি (অ-আলফানিউমারিক) ডেটা (বা একটি উল্লেখযোগ্য আকারের পেডলোড) থাকে, ব্যবহার করুন multipart/form-data। অন্যথায়, ব্যবহার করুন application/x-www-form-urlencoded।

---

আপনি যে মাইম টাইমগুলি উল্লেখ করেছেন তা Content-Typeহ'ল এইচটিটিপি পোস্টের অনুরোধের জন্য দুটি শিরোনাম যা ব্যবহারকারী-এজেন্ট (ব্রাউজারগুলি) সমর্থন করে। এই জাতীয় অনুরোধগুলির উভয়ের উদ্দেশ্য হ'ল সার্ভারে নাম / মান জোড়ার একটি তালিকা প্রেরণ করা। তথ্য প্রেরণ ও প্রকারের পরিমাণের উপর নির্ভর করে একটি পদ্ধতি অন্যটির চেয়ে বেশি দক্ষ হবে efficient কেন তা বুঝতে, আপনাকে প্রতিটি কভারের নীচে কী করছে তা দেখতে হবে।

কারণ application/x-www-form-urlencoded, সার্ভারে প্রেরিত HTTP বার্তার মূল অংশটি মূলত একটি দৈত্য কোয়েরি স্ট্রিং - নাম / মান জোড়াটি এম্পারস্যান্ড ( &) দ্বারা পৃথক করা হয় , এবং নামগুলি সমান চিহ্ন ( =) দ্বারা পৃথক করা হয় । এর উদাহরণ হ'ল: 

MyVariableOne=ValueOne&MyVariableTwo=ValueTwo

স্পেসিফিকেশন অনুযায়ী :

[সংরক্ষিত এবং] অ-অক্ষরীয় অক্ষরগুলি `% এইচএইচ দ্বারা প্রতিস্থাপিত হয়, একটি শতাংশ চিহ্ন এবং দুটি হেক্সাডেসিমাল অক্ষর অক্ষরের ASCII কোড উপস্থাপন করে

এর অর্থ হ'ল আমাদের মানগুলির মধ্যে একটিতে থাকা প্রতিটি নন-আলফানামুরিক বাইটের জন্য এটি প্রতিনিধিত্ব করতে তিন বাইট লাগবে। বড় বাইনারি ফাইলগুলির জন্য, পেওলডকে তিনগুণ বাড়ানো অত্যন্ত অদক্ষ হতে চলেছে।

যেখানে যে multipart/form-dataআসে। নাম / মান জোড়াগুলি প্রেরণ এই পদ্ধতি দিয়ে, প্রতিটি জোড়া (অন্যান্য উত্তর দ্বারা বর্ণিত) একটি "অংশ" একটি এমআইএমই বার্তায় হিসাবে প্রতিনিধিত্ব করা হয়। অংশগুলি একটি নির্দিষ্ট স্ট্রিংয়ের সীমানা দ্বারা আলাদা করা হয় (বিশেষভাবে চয়ন করা যাতে এই সীমানা স্ট্রিংটি কোনও "মান" পেওলডে না ঘটে)। প্রতিটি অংশের নিজস্ব মাইম হেডারগুলির নিজস্ব সেট রয়েছে Content-Typeএবং বিশেষত Content-Disposition, যা প্রতিটি অংশকে তার "নাম" দিতে পারে। প্রতিটি নাম / মান জোড়ার মান টুকরা হ'ল মাইম মেসেজের প্রতিটি অংশের পেডলোড। মান পেইডকে উপস্থাপন করার সময় মাইমেক স্পেক আমাদের আরও বিকল্প দেয় - আমরা ব্যান্ডউইথকে বাঁচানোর জন্য বাইনারি ডেটার আরও দক্ষ এনকোডিং চয়ন করতে পারি (যেমন বেস 64৪ বা এমনকি কাঁচা বাইনারি)।

কেন multipart/form-dataসব সময় ব্যবহার করবেন না ? সংক্ষিপ্ত আলফানিউমেরিক মানগুলির জন্য (বেশিরভাগ ওয়েব ফর্মের মতো), মাইমির সমস্ত শিরোনাম যুক্ত করার ওভারহেড আরও দক্ষ বাইনারি এনকোডিং থেকে কোনও সঞ্চয়কে উল্লেখযোগ্যভাবে ছাড়িয়ে যাচ্ছে।

Comments

X-www-form-urlencoded এর কি একটি দৈর্ঘ্য সীমা আছে, না এটি সীমাহীন?

— পেসারিয়ার

@ পেসারিয়ার সীমাটি পোস্টের অনুরোধটি প্রাপ্ত সার্ভার দ্বারা প্রয়োগ করা হয়। আরও আলোচনার জন্য এই থ্রেডটি দেখুন: stackoverflow.com/questions/2364840/…

— ম্যাট ব্রিজেস

@ জিগি দ্য হ্যামস্টার জেএসওএন এবং বিএসএন বিভিন্ন ধরণের ডেটার জন্য একে অপরকে দক্ষ। উভয় সিরিয়ালাইজেশন পদ্ধতির জন্য বেস 64 গিজিপের থেকে নিকৃষ্ট। বেস 64 কোনও সুবিধা নিয়ে আসে না, HTTP বাইনারি পাইলোডগুলি সমর্থন করে supports

— টিবেরিউ-আয়নু স্টান

এছাড়াও মনে রাখবেন যে কোনও ফর্মটিতে একটি নামযুক্ত ফাইল আপলোড থাকে তবে আপনার একমাত্র পছন্দ ফর্ম-ডেটা, কারণ urlencoded ফাইলের নাম রাখার উপায় নেই (ফর্ম-ডেটাতে এটি বিষয়বস্তু-অবস্থানের নাম প্যারামিটার)।

— গিডো ভ্যান রসুম

@ ইএমএল আমার প্রথমসূত্রটি দেখুন "(বিশেষভাবে চয়ন করেছেন যাতে এই সীমানা স্ট্রিংটি কোনও" মান "পেলোডের মধ্যে না ঘটে)"

— ম্যাট ব্রিজেস

Answer 2

এখানে প্রথম পারা পড়ুন!

আমি জানি এটি 3 বছর খুব দেরী, কিন্তু ম্যাট এর (স্বীকৃত) উত্তর অসম্পূর্ণ এবং অবশেষে আপনাকে সমস্যার মধ্যে ফেলবে। এখানে কীটি হ'ল, যদি আপনি ব্যবহার করতে চান multipart/form-data, সীমাটি অবশ্যই সার্ভারের প্রাপ্ত ফাইল ফাইলের মধ্যে উপস্থিত হবে না ।

এটি কোনও সমস্যা নয় application/x-www-form-urlencodedকারণ কোনও সীমানা নেই। x-www-form-urlencodedএকটি স্বেচ্ছাসৈনিক বাইটকে তিন 7BITবাইটে রূপান্তর করার সহজ সমীক্ষক দ্বারা বাইনারি ডেটা সর্বদা হ্যান্ডেল করতে পারে । অপর্যাপ্ত, তবে এটি কাজ করে (এবং নোট করুন যে বাইনারি ডেটা পাশাপাশি ফাইলের নাম পাঠাতে না পারার বিষয়ে মন্তব্যটি ভুল; আপনি কেবল এটি অন্য কী / মান জোড় হিসাবে প্রেরণ করেছেন)।

সমস্যাটি multipart/form-dataহ'ল সীমানা বিভাজকটি অবশ্যই ফাইল ডেটাতে উপস্থিত না হওয়া উচিত ( আরএফসি 2388 দেখুন ; বিভাগ 5.2 এও সঠিক এগ্রিগেট এমআইএমআই টাইপ না থাকার জন্য একটি খোঁড়া অজুহাত অন্তর্ভুক্ত রয়েছে যা এই সমস্যাটি এড়ায়)।

সুতরাং, প্রথম দর্শনে, কোনও ফাইল আপলোড, বাইনারি বা অন্যথায় multipart/form-dataযা হয় তার কোনও মূল্য নেই । আপনি সঠিকভাবে আপনার সীমানা চয়ন না থাকে, তাহলে আপনি হবে অবশেষে একটি সমস্যা আছে, আপনি প্লেইন টেক্সট অথবা কাঁচা বাইনারি পাঠাচ্ছি কিনা - সার্ভারের ভুল জায়গায় একটি সীমানা পাবেন, এবং আপনার ফাইল ছেঁটে ফেলা হবে, বা পোস্ট ব্যর্থ হবে.

কীটি কোনও এনকোডিং এবং এমন একটি বাউন্ডারি চয়ন করা উচিত যাতে আপনার নির্বাচিত সীমানা অক্ষরগুলি এনকোডড আউটপুটটিতে উপস্থিত না হয়। একটি সহজ সমাধান হ'ল ব্যবহার করা base64( কাঁচা বাইনারি ব্যবহার করবেন না )। ইন করুন Base64- 3 নির্বিচারে বাইট চার 7-বিট অক্ষর, যেখানে আউটপুট চরিত্র সেট মধ্যে এনকোড করা হয় [A-Za-z0-9+/=](যেমন কারাকাস, + ',' / 'বা' = ')। =এটি একটি বিশেষ কেস এবং এটি কেবলমাত্র একক =বা দ্বৈত হিসাবে এনকোডড আউটপুট শেষে উপস্থিত হতে পারে ==। এখন, আপনার সীমানাটি একটি 7-বিট ASCII স্ট্রিং হিসাবে চয়ন করুন যা base64আউটপুটে প্রদর্শিত হতে পারে না । নেট এ আপনি দেখতে অনেক পছন্দ এই পরীক্ষায় ব্যর্থ হয় - MDN ডক্স গঠন করেউদাহরণস্বরূপ, বাইনারি ডেটা প্রেরণ করার সময় সীমানা হিসাবে "ব্লব" ব্যবহার করুন - ভাল নয়। তবে "! ব্লব!" এর মতো কিছু! base64আউটপুট প্রদর্শিত হবে না ।

Comments

যদিও মাল্টিপার্ট / ফর্ম-ডেটা বিবেচনা হ'ল নিশ্চিত করা হয় যে সীমানাটি ডেটাতে উপস্থিত না হয় এটি যথেষ্ট লম্বা একটি সীমানা বাছাই করে সাধন করা মোটামুটি সহজ। এটি সম্পন্ন করতে দয়া করে আমাদের বেস 64 এনকোডিং করবেন না। একটি সীমানা যা এলোমেলোভাবে উত্পন্ন এবং ইউআইডি হিসাবে একই দৈর্ঘ্য যথেষ্ট হওয়া উচিত: স্ট্যাকওভারফ্লো / প্রশ্নগুলি / ১70০৫০০৮/২ ।

— জোশকোডস

@ ইএমএল, এটি মোটেই বোঝা যায় না। স্পষ্টতই এই সীমানাটি স্বয়ংক্রিয়ভাবে HTTP ক্লায়েন্ট (ব্রাউজার) দ্বারা নির্বাচিত হয় এবং ক্লায়েন্টটি আপনার আপলোডকৃত ফাইলগুলির বিষয়বস্তুর সাথে দ্বন্দ্বপূর্ণ এমন সীমানা ব্যবহার না করার জন্য যথেষ্ট স্মার্ট হবে। এটা সহজ এএ সাবস্ট্রিং ম্যাচ হিসাবে index === -1।

— পেসারিয়ার

@ পেসারিয়র: (এ) প্রশ্নটি পড়ুন: "কোনও ব্রাউজার জড়িত নয়, এপিআই প্রসঙ্গ"। (খ) ব্রাউজারগুলি যাইহোক আপনার জন্য অনুরোধগুলি তৈরি করে না। আপনি নিজে এটি করেন। ব্রাউজারগুলিতে কোনও জাদু নেই।

— ইএমএল

@ বেনিবেলা, তিনি সম্ভবত '()+-./:=তখন ব্যবহার করার পরামর্শ দিচ্ছেন । তা সত্ত্বেও সাবস্ট্রিং চেক দিয়ে র্যান্ডম প্রজন্ম এখনও যেতে পথ এবং এটি এক লাইন সঙ্গে সম্পন্ন করা যেতে পারে: while(true){r = rand(); if(data.indexOf(r) === -1){doStuff();break;}}। ইএমএলের পরামর্শ (কেবলমাত্র সাবস্ট্রিংগুলি মেলে এড়াতে বেস 64 এ রূপান্তর করা) কেবল সরল বিজোড়, উল্লেখ না করেই এটি অনির্ধারিত পারফরম্যান্স অবক্ষয়ের সাথে আসে। এক লাইনের অ্যালগোরিদম যেহেতু কিছুই নয় এবং সমস্ত সমস্যা সমান সোজা এবং সহজ। বেস 64 এইভাবে (আব) ব্যবহৃত হবে না, কারণ এইচটিটিপি বডি সমস্ত 8-বিট অক্টেট গ্রহণ করে ।

— পেসারিয়ার

এই উত্তরটি কেবল আলোচনায় কিছুই জুড়ে না, বরং ভুল পরামর্শও দেয়। প্রথমত, যখনই পৃথক অংশগুলিতে এলোমেলো তথ্য প্রেরণ করা হয়, সর্বদা সম্ভব যে নির্বাচিত সীমানা পে-লোডে উপস্থিত থাকবে। এটি না ঘটে তা নিশ্চিত করার একমাত্র উপায় হ'ল আমরা যে প্রতিটি সীমানা নিয়ে এসেছি তার পুরো পেলোড পরীক্ষা করা। সম্পূর্ণ অবৈধ। আমরা কেবল একটি সংঘর্ষের অসীম সম্ভাবনা স্বীকার করি এবং "--- সীমানা- <ইউইউডি এখানে> - সীমানা ---" - এর মতো যুক্তিসঙ্গত সীমানা নিয়ে আসি। দ্বিতীয়ত, সর্বদা বেস 64 ব্যবহার করা ব্যান্ডউইথকে নষ্ট করবে এবং বিনা কারণে অকারণে বাফারগুলি পূরণ করবে।

— ওয়াগলিস

Answer 3

আমি মনে করি না এইচটিটিপি মাল্টিপার্ট বা এক্স-www-ফর্ম-ইউরেলকোডে পোষ্টের মধ্যে সীমাবদ্ধ। সামগ্রী-প্রকার শিরোলেখ HTTP POST মেথড থেকে লম্ব হয় (আপনি যা আপনি স্যুট পরিহিত MIME প্রকার পূরণ করতে পারেন)। এটি আদর্শ এইচটিএমএল উপস্থাপনা ভিত্তিক ওয়েব অ্যাপসগুলির ক্ষেত্রেও (উদাহরণস্বরূপ, জ্যাকসন পেওলোড আজাক্স অনুরোধের জন্য পেডলোড প্রেরণের জন্য খুব জনপ্রিয় হয়ে উঠেছে)।

এইচটিটিপি-র উপর রিস্টুল এপিআই সম্পর্কে আমি যে অ্যাপ্লিকেশন / এক্সএমএল এবং অ্যাপ্লিকেশন / জেসন এর সংস্পর্শে এসেছি সেগুলির মধ্যে সর্বাধিক জনপ্রিয় কন্টেন্ট-প্রকার রয়েছে।

আবেদন / XML:

• ডেটা-সাইজ: এক্সএমএল খুব ভার্বোজ, তবে সংক্ষেপণ ব্যবহার করার সময় এবং লেখার অ্যাক্সেস কেস (যেমন পোষ্ট বা পুটের মাধ্যমে) পাঠ্য অ্যাক্সেস হিসাবে অনেক বেশি বিরল বলে মনে করে সাধারণত সমস্যা হয় না (অনেক ক্ষেত্রে এটি সমস্ত ট্র্যাফিকের <3% হয়) )। খুব কমই সেখানে যেখানে আমার লেখার পারফরম্যান্সটি অপ্টিমাইজ করতে হয়েছিল cases
• অ-এসকিআই অক্ষরের অস্তিত্ব: আপনি এক্সএমএলে এনকোডিং হিসাবে utf-8 ব্যবহার করতে পারেন
• বাইনারি ডেটার অস্তিত্ব: বেস 64 এনকোডিং ব্যবহার করতে হবে
• ফাইলের নাম ডেটা: আপনি এক্সএমএলে এই অভ্যন্তরীণ ক্ষেত্রটি সজ্জিত করতে পারেন

আবেদন / JSON

• ডেটা-আকার: আরও কমপ্যাক্টের চেয়ে কম যে এক্সএমএল, এখনও পাঠ্য, তবে আপনি সংকোচন করতে পারেন
• অ-এসকি চরগুলি: জসন হ'ল ইউএফ -8
• বাইনারি ডেটা: বেস 64 ( জসন-বাইনারি-প্রশ্নও দেখুন )
• ফাইলের নাম তথ্য: জসনের অভ্যন্তরে নিজস্ব ফিল্ড-বিভাগ হিসাবে এনক্যাপসুলেট

বাইনারি ডেটা নিজস্ব সম্পদ হিসাবে

আমি বাইনারি ডেটাগুলিকে নিজস্ব সম্পদ / সংস্থান হিসাবে উপস্থাপন করার চেষ্টা করব। এটি অন্য কল যুক্ত করে তবে স্টাফটিকে আরও ভালভাবে ডিকোপল করে। উদাহরণ চিত্রসমূহ:

POST /images
Content-type: multipart/mixed; boundary="xxxx" 
... multipart data

201 Created
Location: http://imageserver.org/../foo.jpg  

পরবর্তী সংস্থানগুলিতে আপনি বাইনারি সংস্থানটিকে লিঙ্ক হিসাবে সহজেই ইনলাইন করতে পারেন:

<main-resource>
 ...
 <link href="http://imageserver.org/../foo.jpg"/>
</main-resource>

Comments

মজাদার. তবে কখন অ্যাপ্লিকেশন / এক্স-www-ফর্ম-ইউরেলকোড ব্যবহার করবেন এবং কখন মাল্টিপার্ট / ফর্ম-ডেটা করবেন?

— সর্বাধিক

অ্যাপ্লিকেশন / x-www-form- urlencoded হ'ল আপনার অনুরোধের ডিফল্ট মাইম-টাইপ ( ডাব্লু 3.org/TR/html401/interact/forms.html#h-17.13.4 দেখুন )। আমি এটি "সাধারণ" ওয়েবফর্মের জন্য ব্যবহার করি। এপিআই-এর জন্য আমি অ্যাপ্লিকেশন / এক্সএমএল | জসন ব্যবহার করি। মাল্টিপার্ট / ফর্ম-ডেটা সংযুক্তিগুলির চিন্তাভাবনার একটি ঘণ্টা (প্রতিক্রিয়া সংস্থার অভ্যন্তরে বেশ কয়েকটি ডেটা-বিভাগ একটি সংজ্ঞায়িত সীমানা স্ট্রিংয়ের সাথে সংযুক্ত থাকে)।

— ম্যানুয়েল আলডানা

আমি মনে করি যে ওপি সম্ভবত এইচটিএমএল ফর্মগুলি যে দুটি প্রকারের জন্য ব্যবহার করে সে সম্পর্কে কেবল জিজ্ঞাসা করেছিল, তবে আমি খুশী যে এটি উল্লেখ করা হয়েছিল।

— tybro0103

Answer 4

আমি ম্যানুয়েল যা বলেছি তার সাথে আমি একমত। আসলে, তার মন্তব্যগুলি এই ইউআরএলকে উল্লেখ করে ...

http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4

... কোন প্রদেশ:

"অ্যাপ্লিকেশন / x-www-form-urlencoded" বিষয়বস্তু ধরণের বৃহত পরিমাণে বাইনারি ডেটা বা এসএসআইআই অক্ষরযুক্ত পাঠ্য পাঠানোর জন্য অক্ষম। "মাল্টিপার্ট / ফর্ম-ডেটা" বিষয়বস্তু ফাইলগুলি ফর্ম জমা দেওয়ার জন্য ব্যবহার করা উচিত যা ফাইলগুলি, অ-এএসসিআইআই ডেটা এবং বাইনারি ডেটা ধারণ করে।

যাইহোক, আমার জন্য এটি সরঞ্জাম / কাঠামোর সমর্থনে নেমে আসবে।

• আপনার এপিআই ব্যবহারকারীরা কোন অ্যাপ্লিকেশনগুলি তাদের অ্যাপ্লিকেশনগুলি তৈরি করবেন বলে আপনি কোন সরঞ্জাম এবং ফ্রেমওয়ার্কগুলি প্রত্যাশা করছেন?
• তাদের কি ফ্রেমওয়ার্ক বা উপাদান রয়েছে যা তারা অন্য পদ্ধতির জন্য একটি পদ্ধতির পক্ষপাতী ব্যবহার করতে পারে?

আপনি যদি আপনার ব্যবহারকারীদের এবং আপনি কীভাবে আপনার এপিআই ব্যবহার করবেন সে সম্পর্কে একটি পরিষ্কার ধারণা পেয়ে থাকেন তবে তা আপনাকে সিদ্ধান্ত নিতে সহায়তা করবে। আপনি যদি আপনার এপিআই ব্যবহারকারীদের জন্য ফাইল আপলোডকে শক্ত করে তোলেন তবে সেগুলি সরে যাবে, এর মধ্যে আপনি তাদের সমর্থন করতে অনেক সময় ব্যয় করবেন।

এটির মাধ্যমিকটি হ'ল আপনার এপিআই লেখার জন্য আপনার কাছে থাকা সরঞ্জাম সমর্থন এবং অন্যটির তুলনায় একটি আপলোড প্রক্রিয়া আপনার পক্ষে কতটা সহজ।

Comments

হাই, এর অর্থ কি এই যে প্রতিটি সময় আমরা ওয়েব সার্ভারে কিছু পোস্ট করি, আমাদের ওয়েব সার্ভারকে ডেটা ডিকোড করার সময় জানাতে কন্টেন্টের ধরণটি কী তা উল্লেখ করতে হবে? এমনকি আমরা নিজেরাই HTTP অনুরোধটি তৈরি করি, আমরা কি সামগ্রীর ধরণের উল্লেখ করতে হবে?

— GMsoF

@ জিএমএসএফ, এটি alচ্ছিক। স্ট্যাকওভারফ্লো . com/a/16693884/632951 দেখুন । জেনেরিক ওভারহেডগুলি এড়ানোর জন্য কোনও নির্দিষ্ট সার্ভারের জন্য নির্দিষ্ট অনুরোধটি তৈরি করার সময় আপনি সামগ্রী-প্রকারের ব্যবহার এড়াতে চাইতে পারেন।

— পেসিয়ার

Answer 5

এইচটিএমএল 5 ক্যানভাস চিত্র ডেটা আপলোড করার জন্য আমার পক্ষ থেকে সামান্য ইঙ্গিত:

আমি একটি প্রিন্ট-শপের জন্য একটি প্রকল্পে কাজ করছি এবং এইচটিএমএল 5 canvasউপাদান থেকে আসা সার্ভারে চিত্রগুলি আপলোড করার কারণে কিছু সমস্যা হয়েছিল । আমি কমপক্ষে এক ঘন্টা লড়াই করে যাচ্ছি এবং আমার সার্ভারে চিত্রটি সঠিকভাবে সংরক্ষণ করার জন্য এটি পেলাম না।

একবার আমি contentTypeআমার jQuery এজ্যাক্স কলটির বিকল্পটি সেট করে application/x-www-form-urlencodedসবকিছুতে সঠিক পথে চলে আসলাম এবং বেস 64-এনকোডড ডেটা সঠিকভাবে ব্যাখ্যা করা হয়েছিল এবং সাফল্যের সাথে একটি চিত্র হিসাবে সংরক্ষণ করা হয়েছে।

---

হতে পারে যে কাউকে সাহায্য করে!

Comments

আপনি এটি পরিবর্তন করার আগে এটি কোন ধরণের সামগ্রী প্রেরণ করছিল? আপনি যে সামগ্রী পাঠিয়েছেন তাতে সার্ভারটি সমর্থন না করার কারণে এই সমস্যা হতে পারে।

— Catorda

Answer 6

আপনার যদি সামগ্রী-প্রকার = x-www-urlencoded- ফর্মটি ব্যবহার করতে হয় তবে ফর্ম্যাডাটা সংগ্রহটি প্যারামিটার হিসাবে ব্যবহার করবেন না: এসপিএন কোর 2+ ফর্ম্যাডাটা কালেকশনে কোনও ডিফল্ট কনস্ট্রাক্টর নেই যা ফরমেটারগুলির দ্বারা প্রয়োজনীয়। পরিবর্তে আইফর্ম সংগ্রহ ব্যবহার করুন:

 public IActionResult Search([FromForm]IFormCollection type)
    {
        return Ok();
    }