1353

HTTP හි දත්ත තැපැල් කිරීමට ක්‍රම දෙකක් තිබේ: application/x-www-form-urlencodedසහ multipart/form-data. බොහෝ බ්‍රව්සර් වලට ගොනු උඩුගත කළ multipart/form-dataහැක්කේ භාවිතා කරන්නේ නම් පමණක් බව මට වැටහේ . API සන්දර්භයක් තුළ කේතීකරණ වර්ග වලින් එකක් භාවිතා කිරීමට අමතර මග පෙන්වීමක් තිබේද (බ්‍රව්සරයක් සම්බන්ධ නොවේ)? මෙය උදා:

දත්ත ප්‍රමාණය
ASCII නොවන අක්ෂර වල පැවැත්ම
(කේතනය නොකළ) ද්විමය දත්ත මත පැවැත්ම
අතිරේක දත්ත මාරු කිරීමේ අවශ්‍යතාවය (ගොනු නාමය වැනි)

විවිධ අන්තර්ගත වර්ග භාවිතා කිරීම සම්බන්ධයෙන් වෙබයේ විධිමත් මග පෙන්වීමක් මා විසින් මෙතෙක් සොයාගෙන නොමැත.

http post http-headers

— උපරිම
source

79

HTML ආකෘති භාවිතා කරන MIME වර්ග දෙක මේවා බව සඳහන් කළ යුතුය. HTTP තුළම එවැනි සීමාවක් නොමැත ... කෙනෙකුට HTTP හරහා ඔහුට අවශ්‍ය ඕනෑම MIME වර්ගයක් භාවිතා කළ හැකිය.

— tybro0103

2042

ටීඑල්; ඩී.ආර්

සාරාංශය; සම්ප්‍රේෂණය කිරීම සඳහා ඔබට ද්විමය (අක්ෂරාංක නොවන) දත්ත (හෝ සැලකිය යුතු ප්‍රමාණයේ ගෙවීමක්) තිබේ නම්, භාවිතා කරන්න multipart/form-data. එසේ නොමැතිනම් භාවිතා කරන්න application/x-www-form-urlencoded.

ඔබ සඳහන් කළ MIME වර්ග Content-Typeවන්නේ HTTP POST ඉල්ලීම් සඳහා වන ශීර්ෂ දෙකයි . එම ඉල්ලීම් දෙකෙහිම අරමුණ නම් සේවාදායකයාට නම / අගය යුගල ලැයිස්තුවක් යැවීමයි. සම්ප්‍රේෂණය වන දත්ත වර්ගය සහ ප්‍රමාණය අනුව, එක් ක්‍රමයක් අනෙක් ක්‍රමයට වඩා කාර්යක්ෂම වනු ඇත. හේතුව තේරුම් ගැනීමට, ඔබ ආවරණ යටතේ එක් එක් කරන්නේ කුමක්ද යන්න සොයා බැලිය යුතුය.

මක්නිසාද යත් application/x-www-form-urlencoded, සේවාදායකයට යවන ලද HTTP පණිවිඩයේ ශරීරය අත්‍යවශ්‍යයෙන්ම එක් යෝධ විමසුම් නූලකි - නම / අගය යුගල ඇම්පියර්සෑන්ඩ් ( &) මගින් වෙන් කරනු ලැබේ , සහ නම් අගයන්ගෙන් සමාන සංකේතය ( =) මගින් වෙන් කරනු ලැබේ . මේ සඳහා උදාහරණයක් වනුයේ:

MyVariableOne=ValueOne&MyVariableTwo=ValueTwo

පිරිවිතරයන්ට අනුව :

[වෙන් කර ඇති සහ] අක්ෂරාංක නොවන අක්ෂර '% HH' මගින් ප්‍රතිස්ථාපනය වේ, ප්‍රතිශත ලකුණක් සහ අක්ෂරයේ ASCII කේතය නියෝජනය කරන ෂඩාස්රාකාර ඉලක්කම් දෙකක්

එයින් අදහස් වන්නේ අපගේ එක් අගයක පවතින සෑම අක්ෂරාංක නොවන බයිටයක් සඳහාම, එය නියෝජනය කිරීමට බයිට් තුනක් ගතවනු ඇති බවයි. විශාල ද්විමය ලිපිගොනු සඳහා, ගෙවීම් ප්‍රමාණය තුන් ගුණයකින් වැඩි කිරීම ඉතා අකාර්යක්ෂම වනු ඇත.

ගේ කොහෙද multipart/form-data(වෙනත් පිළිතුරු විසින් විස්තර කර ඇති පරිදි) නම / අගය යුගල සම්ප්රේෂණය මෙම ක්රමය තුළ ය., එක් එක් යුගලය වන MIME පණිවිඩය තුළ "කොටසක්" ලෙස නියෝජනය වේ. අමතර කොටස් මායිමකින් කොටස් වෙන් කරනු ලැබේ (විශේෂයෙන් තෝරාගෙන ඇත්තේ මෙම මායිම් නූල කිසිදු "අගය" ගෙවීම්වල සිදු නොවන ලෙසයි). සෑම කොටසකටම තමන්ගේම MIME ශීර්ෂ කට්ටලයක් ඇත Content-Type, විශේෂයෙන් Content-Disposition, සෑම කොටසකටම එහි "නම" ලබා දිය හැකිය. එක් එක් නම / අගය යුගලයේ අගය කොටස වන්නේ MIME පණිවිඩයේ එක් එක් කොටසෙහි ගෙවීමයි. වටිනාකමේ බර පැටවීම නිරූපණය කිරීමේදී MIME පිරිවිතර අපට තවත් විකල්ප ලබා දෙයි - කලාප පළල සුරැකීම සඳහා අපට වඩාත් කාර්යක්ෂම ද්විමය දත්ත කේතන ක්‍රමයක් තෝරා ගත හැකිය (උදා: පදනම් 64 හෝ අමු ද්විමය).

multipart/form-dataසෑම විටම භාවිතා නොකරන්නේ ඇයි ? කෙටි අක්ෂරාංක අගයන් සඳහා (බොහෝ වෙබ් පෝරම මෙන්), සියලු MIME ශීර්ෂයන් එකතු කිරීමේ පොදු කාර්යය වඩාත් කාර්යක්ෂම ද්විමය කේතීකරණයේ ඉතිරිකිරීම් සැලකිය යුතු ලෙස ඉක්මවා යනු ඇත.

— මැට් පාලම්
source

85

X-www-form-urlencoded හි දිග සීමාවක් තිබේද, නැතහොත් එය අසීමිතද?

— පැසීරියර්

36

AcPacerier POST ඉල්ලීම ලැබෙන සේවාදායකයා විසින් සීමාව බලාත්මක කරයි. වැඩි විස්තර සඳහා මෙම නූල බලන්න: stackoverflow.com/questions/2364840/…

— මැට් බ්‍රිජ්ස්

5

Ig සිගිගි හැම්ස්ටර් JSON සහ BSON එක් එක් විවිධ වර්ගයේ දත්ත සඳහා වඩාත් කාර්යක්ෂම වේ. Base64 අනුක්‍රමිකකරණ ක්‍රම දෙකටම gzip ට වඩා පහත් ය. Base64 කිසිසේත්ම වාසි ගෙන එන්නේ නැත, HTTP ද්විමය පයිලෝඩ් සඳහා සහය දක්වයි.

— Tiberiu-Ionuț Stan

16

පෝරමයක නම් කරන ලද ලිපිගොනු උඩුගත කිරීමක් තිබේ නම්, ඔබේ එකම තේරීම පෝරම-දත්ත බව මතක තබා ගන්න, මන්ද යූරෙන්කෝඩ් කළ ගොනුවේ නම තැබීමට ක්‍රමයක් නොමැති නිසාය (ආකෘති-දත්ත වලදී එය අන්තර්ගත-බැහැර කිරීමේ නම පරාමිතිය වේ).

— ගයිඩෝ වැන් රොසුම්

4

@EML මගේ වර්‍ගාත්මක බලන්න (විශේෂයෙන් තෝරාගෙන ඇත්තේ මෙම "මායිම් නූල කිසිදු" වටිනාකමක් සහිත ගෙවීමක් සිදු නොවන පරිදි ")

— මැට් බ්‍රිජ්ස්

153

පළමු පරාසය මෙතැනින් කියවන්න!

මෙය වසර 3 ක් ප්‍රමාද බව මම දනිමි, නමුත් මැට්ගේ (පිළිගත්) පිළිතුර අසම්පූර්ණ වන අතර අවසානයේ ඔබව කරදරයට පත් කරනු ඇත. මෙහි ඇති ප්රධාන ඔබ භාවිතා කිරීමට තෝරා නම්, ය multipart/form-data, මායිම් යුතු නොවේ සේවාදායකය අවසානයේ ලැබෙන බව ගොනුව දත්ත දක්වයි.

සීමාවක් නොමැති නිසා මෙය ගැටළුවක් application/x-www-form-urlencodedනොවේ. x-www-form-urlencodedඑක් අත්තනෝමතික බයිට් එකක් බයිට් තුනකට හැරවීමේ සරල උපයෝගීතාවයෙන් සෑම විටම ද්විමය දත්ත හැසිරවිය හැකිය 7BIT. අකාර්යක්ෂමයි, නමුත් එය ක්‍රියාත්මක වේ (සහ ගොනු නාම සහ ද්විමය දත්ත යැවීමට නොහැකි වීම පිළිබඳ අදහස් දැක්වීම වැරදියි; ඔබ එය වෙනත් යතුරක් / අගය යුගලයක් ලෙස යවන්න).

ගැටළුව multipart/form-dataවන්නේ මායිම් බෙදුම්කරු ලිපිගොනු දත්තවල නොතිබිය යුතුය ( RFC 2388 බලන්න ; 5.2 වගන්තියේ මෙම ගැටළුව මඟහරවා ගත හැකි නිසි MIME වර්ගයක් නොතිබීම සඳහා තරමක් කම්මැලි නිදහසට කරුණක් ඇතුළත් වේ).

එබැවින්, බැලූ බැල්මට, ඕනෑම ගොනුවක් උඩුගත කිරීමේදී, ද්විමය හෝ වෙනත් ආකාරයකින් multipart/form-dataකිසිදු වටිනාකමක් නැත . ඔබ නිවැරදිව ඔබගේ සීමාව තෝරා නැති නම්, ඔබ ඇත අවසානයේ ප්රශ්නයක්, ඔයා තමයි සරල පෙළ හෝ අමු ද්විමය යැවීම යන්න ඇති - සේවාදායකය වැරදි තැනක හතරේ සොයා ඇත, හා ඔබේ ගොනුව ලොප් වේ, හෝ තැපැල් අසමත් වනු ඇත.

ප්රධාන දෙය නම් කේතනය කරන ලද නිමැවුමේ ඔබේ තෝරාගත් මායිම් අක්ෂර දිස්විය නොහැකි වන පරිදි කේතන ක්‍රමයක් සහ මායිමක් තෝරා ගැනීමයි. එක් සරල විසඳුමක් භාවිතා කිරීමයි base64(නෑ නෑ අමු ද්විමය භාවිතා කරන්න). දී base64 ප්රතිදානය චරිත සමූහයක් යනු එහිදී 3 අත්තනෝමතික බයිට්, 7-bit හතර චරිත බවට කේතනය කොට තිබේ [A-Za-z0-9+/=](එනම් අක්ෂර සංඛ්යා, '+', '/' හෝ '='). =විශේෂ අවස්ථාවක් වන අතර එය සංකේතවත් කළ ප්‍රතිදානයේ අවසානයේ තනි =හෝ ද්විත්ව ලෙස පමණක් දිස්විය හැකිය ==. දැන්, ඔබේ සීමාව 7-බිට් ASCII නූලක් ලෙස තෝරන්න base64. ඔබ මෙම පරීක්ෂණය අසමත් ශුද්ධ දකින බොහෝ තෝරා ගැනීම් - මෙම MDN ආකෘති ලේඛන, උදාහරණයක් ලෙස, ද්විමය දත්ත යැවීමේදී මායිමක් ලෙස "blob" භාවිතා කරන්න - හොඳ නැත. කෙසේ වෙතත්, "! බ්ලොබ්!" කිසි විටෙකත් base64ප්‍රතිදානයේ නොපෙන්වයි .

— ඊඑම්එල්
source

52

බහුවිධ / පෝරම-දත්ත සලකා බැලීමේදී දත්තවල මායිම නොපෙන්වන බවට සහතික වීම ප්‍රමාණවත් තරම් දිගු මායිමක් තෝරා ගැනීමෙන් මෙය සාක්ෂාත් කර ගැනීම තරමක් සරල ය. කරුණාකර මෙය සිදු කිරීම සඳහා පදනම් 64 කේතන ක්‍රමයක් නොකරන්න. අහඹු ලෙස ජනනය කරන ලද මායිමක් සහ UUID හා සමාන දිග ප්‍රමාණවත් විය යුතුය: stackoverflow.com/questions/1705008/… .

— ජොෂ්කෝඩ්ස්

21

@EML, මෙය කිසිසේත්ම තේරුමක් නැත. නිසැකවම මායිම http සේවාදායකයා (බ්‍රව්සරය) විසින් ස්වයංක්‍රීයව තෝරා ගනු ලබන අතර ඔබේ උඩුගත කරන ලද ලිපිගොනු වල අන්තර්ගතය සමඟ ගැටෙන සීමාවක් භාවිතා නොකිරීමට සේවාදායකයා බුද්ධිමත් වනු ඇත. එය සරල aa උපස්ථර ගැලපුමකි index === -1.

— පැසීරියර්

13

Ac පැකේරියර්: (අ) ප්‍රශ්නය කියවන්න: "බ්‍රව්සරයක් සම්බන්ධ නැත, API සන්දර්භය". (ආ) බ්‍රව්සර් කෙසේ හෝ ඔබ වෙනුවෙන් ඉල්ලීම් ගොඩනඟන්නේ නැත. ඔබ එය අතින් කරන්න. බ්‍රව්සර්වල මැජික් නැත.

— ඊඑම්එල්

12

En බෙනිබෙලා, ඔහු බොහෝ විට '()+-./:=එවකට භාවිතා කිරීමට යෝජනා කරයි . එහෙත් උපස්ථර චෙක්පත් සමඟ අහඹු ලෙස උත්පාදනය කිරීම තවමත් යා යුතු මාර්ගය වන අතර එය එක් පේළියකින් කළ හැකිය : while(true){r = rand(); if(data.indexOf(r) === -1){doStuff();break;}}. ඊඑම්එල් හි යෝජනාව (ගැලපෙන උපස්ථරයන් වළක්වා ගැනීම සඳහා බේස් 64 වෙත පරිවර්තනය කිරීම) සරල අමුතු දෙයක් වන අතර එය අනවශ්‍ය කාර්ය සාධනය පිරිහීමකින් යුක්ත බව සඳහන් නොකල යුතුය. එක් පේළියේ ඇල්ගොරිතම එක හා සමානව සරල හා සරල බැවින් සියලු කරදර කිසිවක් නැත. Base64 යනු මේ ආකාරයෙන් (ab) භාවිතා කිරීමට අදහස් නොකෙරේ, HTTP ශරීරය සියළුම බිට් 8 අෂ්ටක පිළිගන්නා බැවින් .

— පැසීරියර්

32

මෙම පිළිතුර සාකච්ඡාවට කිසිවක් එකතු කරනවා පමණක් නොව වැරදි උපදෙස් ද ලබා දෙයි. පළමුවෙන්ම, අහඹු දත්ත වෙන් කරන ලද කොටස් වලට සම්ප්‍රේෂණය කරන සෑම විටම, තෝරාගත් සීමාව ගෙවුම් භාරය තුළ තිබිය හැකි ය. මෙය සිදු නොවන බවට වග බලා ගැනීම සඳහා ඇති එකම ක්‍රමය නම් අප ඉදිරිපත් කරන සෑම සීමාවක් සඳහාම සම්පූර්ණ ගෙවීම් පරීක්ෂා කිරීමයි. සම්පූර්ණයෙන්ම ප්‍රායෝගික නැත. අපි ision ට්ටනයක අසීමිත සම්භාවිතාව පිළිගෙන "--- මායිම- <UUID මෙහි>-මායිම ---" වැනි සාධාරණ සීමාවක් සමඟ පැමිණෙමු. දෙවනුව, සෑම විටම Base64 භාවිතා කිරීම කිසිදු හේතුවක් නොමැතිව කලාප පළල නාස්ති කර බෆර් පුරවනු ඇත.

— vagelis

94

HTTP බහුපාර්ශ්වයේ හෝ x-www-form-urlencoded හි POST ට සීමා වී ඇතැයි මම නොසිතමි. මෙම අන්තර්ගත-වර්ගය ශීර්ෂකය ලබාදෙන්න HTTP POST ක්රමය (ඔබ MIME ශෛලිය ඇඳුම් කට්ටල වන පිරවිය හැකි) වෙත ප්රලම්බ වේ. සාමාන්‍ය HTML නිරූපණය පදනම් කරගත් වෙබ් යෙදුම් සඳහාද මෙය වේ (උදා: අජැක්ස් ඉල්ලීම් සඳහා ගෙවීම් සම්ප්‍රේෂණය කිරීම සඳහා ජේසන් ගෙවීම් ඉතා ජනප්‍රිය විය).

HTTP හරහා රෙස්ට්ෆුල් ඒපීඅයි සම්බන්ධයෙන්, මා සම්බන්ධ කර ගත් වඩාත්ම ජනප්‍රිය අන්තර්ගත වර්ග වන්නේ යෙදුම / xml සහ යෙදුම / json ය.

යෙදුම / xml:

දත්ත ප්‍රමාණය: එක්ස්එම්එල් ඉතා වාචික, නමුත් සම්පීඩනය භාවිතා කරන විට සාමාන්‍යයෙන් ගැටළුවක් නොවේ (ලිවීමේ ප්‍රවේශ අවස්ථාව (උදා: POST හෝ PUT හරහා) කියවීමේ ප්‍රවේශය තරම් දුර්ලභ ය (බොහෝ අවස්ථාවන්හි එය <3% සියලු ගමනාගමනයෙන් 3% ). ලිවීමේ කාර්ය සාධනය ප්‍රශස්ත කිරීමට මට සිදු වූ අවස්ථා කලාතුරකිනි
ascii නොවන අක්ෂර වල පැවැත්ම: ඔබට XML හි කේතන ක්‍රමයක් ලෙස utf-8 භාවිතා කළ හැකිය
ද්විමය දත්තවල පැවැත්ම: base64 කේතන ක්‍රමය භාවිතා කිරීමට අවශ්‍ය වනු ඇත
ගොනු නාම දත්ත: ඔබට මෙම අභ්‍යන්තර ක්ෂේත්‍රය XML හි සංයුක්ත කළ හැකිය

application / json

දත්ත ප්‍රමාණය: එක්ස්එම්එල්, තවමත් පෙළ, නමුත් ඔබට සම්පීඩනය කළ හැකි ප්‍රමාණයට වඩා සංයුක්ත වේ
ascii නොවන අක්ෂර: json යනු utf-8 වේ
ද්විමය දත්ත: base64 ( json-binary-question ද බලන්න )
ගොනු නාම දත්ත: json තුළ ක්ෂේත්‍ර ක්ෂේත්‍රයක් ලෙස සංයුක්ත කරන්න

ද්විමය දත්ත තමන්ගේම සම්පතක් ලෙස

ද්විමය දත්ත තමන්ගේම වත්කම් / සම්පතක් ලෙස නිරූපණය කිරීමට මම උත්සාහ කරමි. එය තවත් ඇමතුමක් එක් කරන නමුත් වඩා හොඳ දේ විසන්ධි කරයි. උදාහරණ රූප:

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>

— මැනුවෙල් අල්ඩානා
source

සිත්ගන්නා සුළුය. නමුත් යෙදුම / x-www-form-urlencoded භාවිතා කරන්නේ කවදාද සහ බහුපාර්ශ්වික / පෝරම-දත්ත භාවිතා කරන්නේ කවදාද?

— උපරිම

3

application / x-www-form-urlencoded යනු ඔබගේ ඉල්ලීමේ පෙරනිමි මයිම් වර්ගයයි ( w3.org/TR/html401/interact/forms.html#h-17.13.4 ද බලන්න ). මම එය "සාමාන්‍ය" වෙබ් ආකෘති සඳහා භාවිතා කරමි. API සඳහා මම යෙදුම / xml | json භාවිතා කරමි. බහුපාර්ට් / පෝරම-දත්ත යනු ඇමිණුම් ගැන සිතීමේ සීනුවකි (ප්‍රතිචාර ශරීරය තුළ දත්ත කොටස් කිහිපයක් අර්ථ දක්වා ඇති මායිම් නූලක් සමඟ සංයුක්ත වේ).

— මැනුවෙල් අල්ඩානා

4

මම හිතන්නේ OP බොහෝ විට HTML ආකෘති භාවිතා කරන වර්ග දෙක ගැන විමසනු ඇත, නමුත් මෙය පෙන්වා දීම ගැන මම සතුටු වෙමි.

— tybro0103

30

මැනුවෙල් පැවසූ බොහෝ දේ සමඟ මම එකඟ වෙමි. ඇත්ත වශයෙන්ම, ඔහුගේ අදහස් මෙම url වෙත යොමු වේ ...

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

... එහි සඳහන් වන්නේ:

"යෙදුම / x-www-form-urlencoded" යන අන්තර්ගත වර්ගය ASCII නොවන අක්ෂර අඩංගු ද්විමය දත්ත හෝ පෙළ විශාල ප්‍රමාණයක් යැවීමට අකාර්යක්ෂම වේ. ලිපිගොනු, ASCII නොවන දත්ත සහ ද්විමය දත්ත අඩංගු ආකෘති ඉදිරිපත් කිරීම සඳහා "බහුපාර්ට් / පෝරම-දත්ත" අන්තර්ගත වර්ගය භාවිතා කළ යුතුය.

කෙසේ වෙතත්, මට නම් එය මෙවලම් / රාමු සහාය සඳහා පහළට පැමිණේ.

ඔබගේ API පරිශීලකයින් ඔවුන්ගේ යෙදුම් ගොඩනගනු ඇතැයි ඔබ අපේක්ෂා කරන මෙවලම් සහ රාමු මොනවාද?
එක් ක්‍රමයක් අනෙක් ක්‍රමයට වඩා භාවිතා කළ හැකි රාමු හෝ සංරචක ඔවුන් සතුව තිබේද?

ඔබේ පරිශීලකයින් පිළිබඳ පැහැදිලි අදහසක් සහ ඔවුන් ඔබේ API භාවිතා කරන්නේ කෙසේද යන්න ඔබට ලැබෙන්නේ නම්, එය තීරණය කිරීමට ඔබට උපකාරී වනු ඇත. ඔබගේ API පරිශීලකයින් සඳහා ඔබ ලිපිගොනු උඩුගත කිරීම දුෂ්කර කළහොත් ඔවුන් ඉවත්ව යනු ඇත, ඔබ ඔවුන්ට සහාය දැක්වීමට බොහෝ කාලයක් වැය කරනු ඇත.

මෙයට ද්විතියික වන්නේ ඔබේ API ලිවීම සඳහා ඔබට ඇති මෙවලම් සහාය වන අතර එක් උඩුගත කිරීමේ යාන්ත්‍රණයක් අනෙකට වඩා ඉඩ දීම ඔබට කොතරම් පහසුද.

— මාටින් පෙක්
source

1

හායි, එයින් අදහස් කරන්නේ අප වෙබ් සේවාදායකයට යම් යම් දේ පළ කරන සෑම අවස්ථාවකම, දත්ත විකේතනය කළ යුතු බව වෙබ් සේවාදායකයාට දැනුම් දීම සඳහා අන්තර්ගතයේ වර්ගය කුමක්ද යන්න සඳහන් කළ යුතු බවද? අපි http ඉල්ලීම අප විසින්ම සකස් කළත්, අපි අන්තර්ගත වර්ගය සඳහන් කළ යුතුද?

— GMsoF

2

@GMsoF, එය අත්‍යවශ්‍ය නොවේ. Stackoverflow.com/a/16693884/632951 බලන්න . සාමාන්‍ය සේවාදායකයන් මඟ හැරීම සඳහා නිශ්චිත සේවාදායකයක් සඳහා නිශ්චිත ඉල්ලීමක් සැකසීමේදී අන්තර්ගත-වර්ගය භාවිතා කිරීමෙන් වැළකී සිටීමට ඔබට අවශ්‍ය විය හැකිය.

— පැසීරියර්

2

HTML5 කැන්වස් රූප දත්ත උඩුගත කිරීම සඳහා මගේ පැත්තෙන් කුඩා ඉඟියක්:

මම මුද්‍රණ සාප්පුවක් සඳහා ව්‍යාපෘතියක වැඩ කරමින් සිටින අතර HTML5 canvasමූලද්‍රව්‍යයකින් පැමිණි සේවාදායකයට පින්තූර උඩුගත කිරීම නිසා යම් යම් ගැටලු ඇති විය . මම අවම වශයෙන් පැයක්වත් අරගල කළ අතර මගේ සේවාදායකයේ රූපය නිවැරදිව සුරැකීමට මට එය නොලැබුණි.

contentTypeමගේ jQuery අජැක්ස් ඇමතුමේ විකල්පය සියල්ල සකසා ගත් පසු application/x-www-form-urlencodedනිවැරදි මාර්ගයට ගිය අතර base64- කේතනය කළ දත්ත නිවැරදිව අර්ථ නිරූපණය කර සාර්ථකව රූපයක් ලෙස සුරකිනු ඇත.

සමහර විට එය යමෙකුට උපකාරී වේ!

— ටොරස්ටන් බාර්තෙල්
source

4

ඔබ එය වෙනස් කිරීමට පෙර එය යැවූ අන්තර්ගත වර්ගය කුමක්ද? ඔබ යවන අන්තර්ගත වර්ගයට සේවාදායකය සහාය නොදැක්වීම මෙම ගැටලුවට හේතු විය හැකිය.

— catorda

1

ඔබට Content-Type = x-www-urlencoded-form භාවිතා කිරීමට අවශ්‍ය නම් FormDataCollection පරාමිතිය ලෙස භාවිතා නොකරන්න: asp.net Core 2+ හි FormDataCollection හි පෙරනිමි ඉදිකිරීම්කරුවන් නොමැත. ඒ වෙනුවට IFormCollection භාවිතා කරන්න:

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

— ජහන්ෂා
source

යෙදුම / x-www-form-urlencoded හෝ බහුපාර්ට් / පෝරම-දත්ත?

යෙදුම / xml:

application / json

ද්විමය දත්ත තමන්ගේම සම්පතක් ලෙස

HTML5 කැන්වස් රූප දත්ත උඩුගත කිරීම සඳහා මගේ පැත්තෙන් කුඩා ඉඟියක්: