أنت تطلب x-www-form-urlencoded ، والزاوية لا تقوم بترميز البيانات بهذه الطريقة حاليًا. أفترض أنه يمكننا ذلك ، لكنني لست متأكدًا من أنني أتوقع حدوث ذلك. أعتقد أنه في الوقت الحالي يجب عليك فقط استخدام jQuery عندما تحتاج إلى إرسال طلبات مثل هذه ، وربما إذا كنت ترغب في تنفيذ هذه الميزة ، فيمكننا النظر في إدخالها في الشجرة. سأضع علامة على هذا على أنه ترحيب PRz.

ذات صلة بـ https://github.com/angular/angular.js/issues/1743. أتفق مع caitp على أننا يمكن أن نجعل حياة الناس أسهل قليلاً. أعتقد أننا يمكن أن نحاول القيام به هو:

• الكشف عن رأس x-www-form-urlencoded وتسلسل البيانات وفقًا لذلك
• تحقق مما إذا كانت البيانات من النوع https://developer.mozilla.org/en-US/docs/Web/API/FormData (ولكن هذا يعمل فقط في IE 10+ إذا لم أكن مخطئًا)

هل من المنطقي أن تعيش هذه الوظيفة في وحدة قائمة بذاتها خارج النواة؟ إن وجوده خارج النواة سيجعل من السهل توسيعه ودعم التنسيقات الأخرى بنفس الطريقة.

لقد جمعت دليلًا على المفهوم ، وعرضًا توضيحيًا لـ Plunker . إذا كان هذا يبدو أنه الاتجاه الصحيح ، فسأكون سعيدًا لمواصلة التطوير فيه.

+1

من الملاحظة الشخصية ، كل ما علي فعله لإنجاز هذا العمل هو التفاف الخاصية data مع jQuery's $.param للحصول على نشر للنماذج يعمل كما هو معتاد.

السابق.

$http({
    url: ServerAddress+"/login", method: 'POST',
    data: $.param($scope.loginForm),
    headers : {'Content-Type':'application/x-www-form-urlencoded; charset=UTF-8'}
})

أشعر أنه سيجعل الحياة أسهل إذا تمكنت AngularJS من توفير وظيفة مكافئة لـ jQuery $.param - بشكل مثالي شيء يمكن استخدامه أيضًا مع خاصية transformRequest .

+1. قادمًا من الخيط في # 1743 ، أوافق على أن هذه ميزة مفقودة من Angular. كان فريقي مندهشًا جدًا في الواقع عندما اكتشف أن هناك أطواقًا للقفز من خلالها لإنشاء منشور نموذجي منتظم. في حالتنا لدينا jQuery كعنصر تبعية ، لذلك يمكننا استخدام ذلك حتى يكون لدى Angular حل "أصلي".

تواجه نفس المشكلة أيضًا. بدأت مؤخرًا العمل على تطبيق HTML5 (كوردوفا) الذي يستدعي خلفية PHP لطلبات HTTP. تعمل الواجهة الخلفية لـ PHP على تشغيل عدد من المشاريع المختلفة ، لذا حتى المكالمات البسيطة مثل تسجيل الدخول والمصادقة تتوقع form-data أو application/x-www-form-urlencoded .

لقد أحببت حقًا أجزاء AngularJS التي استخدمتها ولكن هذا كان بمثابة إغفال غريب جدًا. حتى لو لم يكن ترميز عنوان url هو المعيار عند نشر البيانات ، فهذا هو العرف المتوقع من قبل عدد هائل من خدمات الواجهة الخلفية ، ويجب أن يدعم Angular ذلك خارج الصندوق.

متوقع من قبل عدد هائل من الخدمات الخلفية

يتيح تعداد تلك الخدمات ، لا سيما تلك التي يكون فيها هذا هو الحل الوحيد الممكن ومن المستحيل القيام بأي شيء آخر

بعد أن فعلنا ذلك وأثبتنا حجم المشكلة ، لأنه لا يبدو أن معظم الناس يواجهون هذه المشكلة.

يتيح تعداد تلك الخدمات ، لا سيما تلك التي يكون فيها هذا هو الحل الوحيد الممكن ومن المستحيل القيام بأي شيء آخر

هناك دائمًا حل بديل للأشياء. لا أعتقد أنك ستحصل على خدمة يستحيل فيها فعليًا إرسال النماذج باستخدام تطبيق Angular الحالي.

كما ذكرت في رسالتي ، في النهاية ، كنت بحاجة فقط لـ jQuery $.param لتغيير بياناتي إلى شيء يمكن لخدمتي (golang backend) أن تستوعبه.

ومع ذلك ، فقد استغرق الأمر وقتًا طويلاً للغاية قبل أن أتمكن من إدراك سبب عدم إرسال النماذج الخاصة بي والعثور على هذا الحل البديل الذي أستخدمه حاليًا. سيكون رائعًا إذا كان بإمكان Angular توفير وظيفة داخلية مشابهة لـ $.param ، أو على الأقل ذكر هذه المشكلة والحلول الممكنة في صفحة مرجع API / wiki.

حل بديل لكل شيء حقًا ، لم أفتح مشكلة مطلقًا لأنني افترضت أن $ .param هو الحل الفعلي.

سيكون التنفيذ المحلي رائعًا.

لدي نفس المشكلة بالضبط ، لا يقبل خادم php طريقة OPTION في الأصل ، لذا أعتقد أن المشكلة كبيرة جدًا.

لقد استخدمت $ http.defaults.headers.post ["Content-Type"] = "application / x-www-form-urlencoded"؛ لتبديل الطلبات إلى application / x-www-form-urlencoded للحصول على الطلب من خلال.

لسوء الحظ ، ليس لدي jQuery كإعالة ، لذا فإن $ .param ليس خيارًا بالنسبة لي ... هل هناك أي حلول أخرى؟

يجب أن تكون هناك بالفعل وظيفة لهذا في الزاوية ، كما تفعل مع مفتاح "params" الذي تم تمريره إلى $ http ... لكن لا يمكن الوصول إليه بشكل عام. أعتقد أن هذا يجب أن يتغير وأن يكون عامًا ، ويجب تغيير convertRequest الافتراضي أيضًا لتسلسل النماذج وفقًا لرأس نوع المحتوى.

في الوقت الحالي ، إذا كنت لا ترغب في إعادة تطبيق العجلة مرارًا وتكرارًا (حتى لو كانت 5 أسطر فقط ، فأنا أوافق على أنه من الأخبار السيئة أن تكتبها بنفسك) ، كانت الحيلة الذكية التي رأيتها مؤخرًا هي تمرير كائن FormData كـ data ، no-op transformRequest بحيث لا يتم ترميزها كـ [object FormData] (offtopic ، html5 spec wtf ، لماذا لا توجد سلسلة مناسبة؟) ، وغير مُعرَّفة كرأس نوع المحتوى ، لذا فإن XHR.send سيضع رؤوسًا متعددة الأجزاء صحيحة. بالنسبة إلى المتصفحات القديمة ، هناك polyfills FormData. لاحظ أن الطلب يصبح متعدد الأجزاء بدلاً من urlencoded بالرغم من ذلك ، غالبًا ما يكون ذلك جيدًا ولكن بالنسبة لبعض الخلفيات الخلفية ، قد لا يزال غير قادر على قطعه.

+1 أنا أيضًا أواجه نفس المشكلة. آمل أن يتم حل هذا من Angular نفسها؟

+1

نفس الشيء هنا .. لا أريد إضافة jQuery كتبعية لهذا الغرض فقط

لا يصدق ، AngularJS رائع للغاية لدرجة أنني لا أستطيع أن أصدق أن هذا الشيء البسيط مفقود. إذن الكل يستخدم jQuery فقط لوظيفة التسلسل هذه؟

+1 إنه أمر مجنون جدًا مثل هذا الإطار المتقدم لا يحتوي على هذا افتراضيًا

لا ينبغي أن تكون هناك حاجة إلى +1 jQuery لإصلاح هذا ، الوظائف الأساسية جدًا ، إرسال النموذج ...

يجب أن يكون هذا حقًا أولوية لإضافته إلى الإصدار التالي

نعم ، الكثير من واجهات برمجة التطبيقات تتوقع طريقة "jquery" لذلك هذه الوظيفة مطلوبة

+1 للزاوية لدمج هذا

+1
مستخدم آخر هنا ينتظر هذا ...
لا أحتاج إلى تضمين jquery فقط لهذا ... يجب أن تكون هذه المشكلة أولوية!

لأولئك الذين يحاولون إيجاد حل أفضل:
http://victorblog.com/2012/12/20/make-angularjs-http-service-behave-like-jquery-ajax/
(هذا يعمل ، ولست بحاجة إلى استخدام مسج!)

: +1:

شكرا @ rodrigograca31.

هذا سيء. هيا يا رفاق ، الناس يقضون ساعات في هذا.

أراهن أكثر فقط اذهب وأضف JQuery وهو أمر سخيف ، وفي حالتي مستحيل ...

فقط تنبيه ، يعمل هذا الحل بشكل رائع إذا كنت بحاجة إلى هذا فقط للتحدث إلى Spring Security أو أي شيء بطلبات بسيطة
http://stackoverflow.com/a/14868725/564449

+1 إذًا ... ماذا تفعلون لحل هذه المشكلة؟

1+ ربما ليس هو المعيار ولكن x-www-form-urlencoded هو تنسيق البيانات الأكثر استخدامًا لنشر AJAX. أعتقد أن AngularJS على الأقل يجب أن تعطي خيارًا لذلك.

هذا الحل يعمل بالنسبة لي
http://bit.ly/1HE96tC

لكن آمل أن يتمكن Angular من حل هذه المشكلة قريبًا.

هذا الحل يعمل بالنسبة لي
http://bit.ly/1HE96tC

المشكلة هي أن _workaround_ الأكثر شيوعًا لهذا المقترح هو استخدام $.param ، مما يعني وجود jQuery كعنصر تابع. أفضل عدم تضمين jQuery في مشروعي فقط لإجراء تسلسل للبيانات للزاوية.

UzEE بالضبط ، وعلاوة على ذلك ، في كل مكان تبحث فيه عن إجابة ،

هذا شيء لا أستطيع فهمه حقًا ...

أعتقد أنني سأعيد كتابة إصدار مستقل من $ .params ... ولكن سيكون أجمل بكثير إذا لم أضطر إلى :)

UzEE و Avcajaraville لا داعي لإعادة كتابتها ... الحل (الرابط أعلاه) يعمل بدون مسج ...

أنا فقط أتعلم عن الزاوي ، وهذه ميزة لا بد منها!

هذا الآن (منذ 1.4) تافه جدًا مع $httpParamSerializerJQLike :

.controller('myCtrl', function($http, $httpParamSerializerJQLike) {
    $http({
      method: 'POST',
      url: baseUrl,
      data: $httpParamSerializerJQLike({
        "user":{
          "email":"[email protected]",
          "password":"123456"
        }
      }),
      headers:
        'Content-Type': 'application/x-www-form-urlencoded'
    })
})

يمكنك أيضًا نقل هذا المنطق إلى convertRequest الذي يقوم بالتحويل بناءً على الرأس. Imo ، هذا هو الآن التوازن الصحيح بين السهل والمرن.

يمكن أيضًا تعيين $httpParamSerializerJQLike لكل $http باستخدام config.paramSerializer أو تعيينه كإعداد افتراضي $httpProvider.defaults.paramSerializer = $httpParamSerializerJQLike

بالمعلومات الواردة أعلاه ، أعتقد أنه يمكن إغلاق هذا.

lgalfaso لا يتعلق الأمر

كيف يمكنني تحقيق ذلك باستخدام $ Resource على 1.3

وصلت للتو إلى هذه المناقشة ، لكنني لا أعتقد أنه يكفي توفير $ httpParamSerializerJQLike. ما هو مطلوب هنا هو أن تفهم آلية POST أنه إذا قلت أن المحتوى هو "application / x-www-form-urlencoded" من أجل تطبيق التحويل على البيانات تلقائيًا.

كنت أحاول استخدام $httpParamSerializerJQLike كحل للمشكلة مثل:

angular.module('myApp', [])
   .factory('myFactory', ['$http', $httpParamSerializerJQLike,
      function($http , $httpParamSerializerJQLike ) {

         var location = 'https://somelocation.com';
         return {
            check: function(user) {
                return $http({
                    method: 'POST',
                    url: location,
                    data: $httpParamSerializerJQLike(user),
                    headers: {'Content-Type': 'application/x-www-form-urlencoded'}
                });
            }
         };
      }
   ]);

ويظهر لي هذا الخطأ $httpParamSerializerJQLike is not defined ، ربما هناك شيء مفقود.

باستخدام Angular 1.4.4

gillchristian : أنت بحاجة إلى اقتباسات من أول $ httpParamSerializerJQLike لذلك:
.factory ('myFactory'، ['$ http'، '$ httpParamSerializerJQLike'،

تضمين التغريدة فاتني أن: ابتسامة:

يعمل الرمز التالي مثل السحر للإصدار الأقدم

    $httpProvider.defaults.headers.post['Content-Type'] = 'application/x-www-form-urlencoded';
    $httpProvider.defaults.transformRequest.unshift(function(data, headersGetter) {
        var key, result = [],
            response;
        if (typeof data == 'string') {
            response = data;
        } else {
            for (key in data) {
                if (data.hasOwnProperty(key)) {
                    result.push(encodeURIComponent(key) + '=' + encodeURIComponent(data[key]));
                }
            }
            response = result.join('&');
        }
        return response;
    });

awebdeveloper "يعمل مثل السحر" للحالات البسيطة ، نعم.
إنه بعيد كل البعد عن برنامج jquery serializer الذي يعمل مع الهياكل المتداخلة أيضًا.
وهي تندرج تحت فئة "إعادة اختراع العجلة" التي أتعامل معها.

georgir The paramSerializer متاح منذ 1.4. هل لاحظت أي أخطاء بها؟

Narretz كان ردي السابق موجهًا على وجه التحديد إلى awebdeveloper وشفرته فيما يتعلق بالإصدارات الأقدم ، آسف لم أوضح ذلك وربما تركت انطباعًا بأنني أنتقد الإصدار الحالي من Angular أو شيء من هذا القبيل.

لكن للإجابة عليك على أي حال ، لم أستخدم 1.4 ولكن من النظر إلى الكود يبدو الأمر جيدًا. بالضبط ما أردت في رسالتي الأولى حول هذه المسألة بالضبط - كشف الوظيفة التي يستخدمها خيار تهيئة "params" $ http ليكون متاحًا بشكل عام. الآن يمكن للمستخدمين الاتصال به للحصول على بياناتهم.

ميزات إضافية مثل محول الطلب الافتراضي الذي يستخدم هذا المسلسل لبيانات الطلب بناءً على رأس نوع المحتوى كما اقترحه الآخرون في هذا الموضوع ربما لا تزال تندرج تحت هذه المشكلة.

[بخصوص البارامترات على وجه التحديد - ميزة "JQLike" المفقودة لمسلسل "JQLike" هي القدرة على التعامل مع مصفوفة من كائنات {name ، value} ، لدعم نفس المفتاح الذي يظهر عدة مرات في البيانات ، أي لحالات مثل a[]=1&a[]=2&a[]=3 . ليست ميزة مهمة ، ولست متأكدًا مما إذا كانت هذه المشكلة هي المكان المناسب لمناقشة ذلك.]

/ سي سيNarretz
أنا أستخدم AngularJS 1.4.6.
لدي الكود التالي في قسم التكوين الخاص بالوحدة الخاصة بي ولكنه لا يعمل:

$httpProvider.defaults.headers.post['Content-Type'] = 'application/x-www-form-urlencoded;charset=utf-8';
$httpProvider.defaults.paramSerializer = '$httpParamSerializerJQLike';

يوجد أيضًا سؤال SO لم تتم الإجابة عليه هنا.

armanforghani لا يمكنني الاختبار الآن ، لكن هذا يجب أن ينجح. هل يمكنك إعداد plnkr الذي يوضح المشكلة؟

Narretz الرجاء انظر هنا

armanforghani ، فإن paramSerializers مخصصة لتسلسل معلمات استعلام URL ، وليست الحمولة النافعة / بيانات الطلب.
في plnkr الخاص بك ، لا توجد معلمات لإجراء تسلسل.

كيف يمكنني إجراء تسلسل للبيانات لطلب آخر؟ حاليا أنا أستخدم هذه الطريقة . هل يمكنك أن تنصحني بخيار أفضل؟

يمكنني حقًا أن أوصي بخيار أفضل ، لأنني لا أحتاج مطلقًا إلى إجراء تسلسل للحمولة ala jQuery.
إذا اضطررت إلى ذلك ، فسأحاول https://github.com/angular/angular.js/issues/6039#issuecomment -113502695 كخيار أول.

armanforghani يوجد أيضًا مثال في المستندات: https://docs.angularjs.org/api/ng/service/ $ httpParamSerializerJQLike أخبرني إذا كان هذا لا يعمل

يجب أن يكون من الممكن أن يكون لديك هذا السلوك افتراضيًا لجميع طلبات _post_ ، ما عليك القيام به

// Warning, untested code
module.run(function($http, $httpParamSerializerJQLike) {
  $http.defaults.transformRequest.unshift($httpParamSerializerJQLike);
});

Narretz أنا أبحث عن طريقة
lgalfaso شكرا لك. مثير للاهتمام ، سأحاول ذلك.

armanforghani ، يرجى المشاركة إذا

لقد اختبرته للتو وهو يعمل بشكل مثالي. lgalfaso شكرا جزيلا لك.

نظرًا لوجود آلية لتحقيق السلوك المطلوب ، فيجب أن يكون إغلاق هذه المشكلة آمنًا. إذا كانت هناك مصلحة مكانية لجعل تسلسل بيانات نص طلب http قابلاً للتكوين بطريقة أسهل ، فافتح مشكلة تربط هذه المناقشة.

lgalfaso أنا أختلف حقًا في أن هذا يحل المشكلة. لا يوجد سوى مجموعة فرعية صغيرة من طلبات POST التي يكون هذا هو المُسلسل الصحيح لها ، لذا فإن إضافتها لجميع الطلبات ليست حلاً جيدًا للحالة العامة. يجب تغيير إطار العمل لاستخدام هذا المسلسل في أي وقت يكون "application / x-www-form-urlencoded" هو نوع البيانات. وإلا فإن إطار العمل يرسل بيانات سيئة

AdamMcCormick أعتقد أنه من الجيد تمامًا متابعة المناقشة حول تسلسل البيانات لطلبات _POST_. يتضمن ذلك ما يجب أن يكون قابلاً للتكوين ، وما إذا كان هذا التكوين يجب أن يكون جزءًا من النواة أو وحدة تابعة لجهة خارجية.
الآن ، لا توجد مواصفات حول كيفية إجراء تسلسل لبيانات JSON. http://www.w3.org/TR/html401/interact/forms.html#h -17.13.4.1 يشير هذا إلى عدم وجود طريقة صحيحة أو خاطئة لإجراء تسلسل لها. ما تعتقد أنه _حسب_الطريقة_ ستكون طريقة خاطئة لشخص آخر.

طريقة تسلسل البيانات قابلة للتكوين كما هو موضح من قبل ، وكيفية القيام بذلك موثقة https://docs.angularjs.org/api/ng/service/ $ http # تحويل الطلبات والاستجابات وهناك بعض الأدوات لمختلف آليات التسلسل.
تتيح الآلية الحالية إمكانية إنشاء تحويل يعمل بشكل مختلف عندما يكون وقت البيانات هو "application / x-www-form-urlencoded" أو أي شيء آخر ، حيث يمكنك الوصول إلى عنوان الطلب.

سيكون تغيير السلوك الافتراضي بمثابة تغيير جذري وشيء نحاول تجنبه. هذا هو السبب في وجود العديد من نقاط التكوين التي نأمل أن تساعد المطورين على جعل الأشياء تعمل بالطريقة التي يحتاجونها مع الحد الأدنى من التعليمات البرمجية.

مع كل هذه المعلومات ، ليس من الواضح لي ما الذي يجب تغييره. هل يمكنك تقديم مثال على شيء غير ممكن ، أو قد يحتاج إلى عدد كبير من LOC لتحقيقه؟

@ pkozlowski- مفتوح المصدر لديك خطة لهذا ، أليس كذلك؟ ربما يمكنك تحديد الخطوط العريضة لما كنت ستفعله ، ويمكنني أنا أو أي شخص آخر القيام بذلك؟

Narretzlgalfaso ما كنت أفكر به هو تغيير الإعدادات الافتراضية حتى إذا مجموعات شخص 'application/x-www-form-urlencoded' باعتباره رأس كنا تسلسل مختلف (لا تستخدم JSON لكن لك شيء أن "معظم الناس يتوقعون"). من الواضح أن هذا سيكون بمثابة تغيير جذري ، لذا لا يمكن إجراؤه إلا في 1.5.x أو 1.6.x

lgalfaso عندما أقول أنني أريد بيانات "application / x-www-form-urlencoded" (بإخبار الزاوي بنوع المحتوى) ، لا يجب إرسال JSON على الإطلاق! يجب أن يرسل كائن البيانات الذي أقدمه كما لو كان نموذج WWW (كما تحدده المواصفات بوضوح) ، مثلما أخبرته بذلك. لست متأكدًا من سبب صعوبة فهم ذلك. السلوك الحالي ليس متوافقًا مع المواصفات وبالتالي فهو خاطئ ، لذا يجب تغيير التغيير أو عدمه. لا يتعلق الأمر بما أعتقده ، ولا يهم إذا كان هناك حل بديل. لقد أوضح @ pkozlowski-openource عدة مرات كيف يمكن تنفيذ حل ، وأنا أقول أنه ينبغي أن يكون كذلك.

AdamMcCormick ، هل سيكون من الممكن معرفة المعيار الذي تتحدث عنه؟
https://xhr.spec.whatwg.org/#the -send () - الطريقة هي المعيار لـ _xhr_ وهذا هو ما $http الملخصات. هنا ، يتم تحديد كيفية إجراء تسلسل للجسم لحالتين فقط ؛ مستند HTML أو سلسلة.

lgalfaso لقد ربطت مواصفات "application / x-www-form-urlencoded" أعلاه وهي واضحة جدًا فيما يتعلق بكيفية تسلسل أزواج المفاتيح / القيم وإرسالها. عندما يكون نوع المحتوى هو "application / x-www-form-urlencoded" ، فإن بيت القصيد هو محاكاة الطريقة التي سيبدو بها نموذج HTML إذا كان لديك POST. إنه ليس "جسمًا" إنه نموذج WWW مشفر بعنوان URL ، يجب أن يتصرف مثله.

AdamMcCormick المواصفات الموجودة على http://www.w3.org/TR/html401/interact/forms.html#h -17.13.4.1 تنطبق فقط على <form> وسيكون من المعقول الاعتقاد بأن هذا يجب أيضًا تنطبق على كائنات FormData ، لكن لا يوجد شيء ينطبق على كائنات JSON. على الأقل لم أجد أي شيء. إذا كانت هناك مواصفات تحدد هذا ، يرجى نشره هنا لأنه سيكون سببًا مقنعًا لتبرير تغيير التعطيل. إذا لم يكن الأمر كذلك ، فمن الأفضل أن يكون لديك خيار قابل للتكوين للمسلسل ، مع الاحتفاظ بالمسلسل الحالي كخيار افتراضي.

lgalfaso إنه ليس http://www.w3.org/TR/html401/interact/forms.html#h -17.13.4.1 ما يجب أن تلتزم به أية بيانات يتم إرسالها بنوع محتوى "application / x-www-form-urlencoded". هذا "سبب مقنع لتبرير تغيير جذري". ما هو الشيء الأكثر إقناعًا من كون الوضع الحالي للعملية خاطئًا بشكل واضح؟

TL ، DR:
يجب أن توضح المستندات سلوك $http عند إجراء تسلسل للبيانات الثنائية ، وما هو التسلسل الافتراضي وما هي التسلسلات المتوفرة ، إن وجدت ، بخلاف الإعداد الافتراضي.
أفضل سلوك في رأيي هو أن الطرق الزاوية التي ينتج عنها طلب HTTP يجب أن تستخدم _configuration_ أو رأس _content-type_ لتحديد الخوارزمية التي ستستخدمها لتسلسل البيانات الثنائية. بالإضافة إلى ذلك ، في حالة اتباع مسار التكوين ، يجب على Angular تعيين نوع المحتوى الصحيح للتسلسل المختار.

الآن ، لا توجد مواصفات حول كيفية إجراء تسلسل لبيانات JSON.

JSON هو التسلسل ، فلا داعي لإجراء تسلسل مرة أخرى. :ابتسامة:
تم تحديده في RFC @ IETF وعلى json.org .

application / x-www-form-urlencoded هو تسلسل آخر محدد كجزء من مواصفات HTML.

من المتوقع أن تتلقى المعلمة data من الدالة $http أيًا من نوعي البيانات:
String : بيانات بتنسيق نصي ، يمكن أن تكون سلسلة نصية أو نوع بيانات آخر يتم تسلسله إذا لزم الأمر
Object : كائن ثنائي سيتم إجراء تسلسل له إما بواسطة Angular أو وكيل المستخدم قبل إرساله عبر HTTP. نحن نعلم بالفعل أن Angular تسلسلها كـ JSON افتراضيًا وتتجاهل رأس نوع المحتوى ، إذا تم تعيينها.

لماذا هذا يبدو وكأنه حشرة؟
$ http. [post | get | put | ...] لا تشير الوثائق إلى طريقة التسلسل الافتراضية التي تستخدمها Angular عندما تكون معلمة "data" كائن جافا سكريبت ولا تتصرف مثل أطر عمل جافا سكريبت الأكثر شيوعًا (jQuery و Mootools و ...). ولا يتصرف مثل ما هو الافتراضي المتوقع من قبل تقنيات جانب الخادم الأكثر شيوعًا (PHP ، Java ، ASP.net ، ...)

للإضافة ، لا تذكر الوثائق أيضًا أن $ http سيتجاهل "نوع المحتوى" وأي رأس معلمة أخرى لتحديد طريقة التسلسل التي سيستخدمها.

هذه حالة استخدام واحدة تقود الأشخاص إلى مشكلة github هذه
باستخدام خادم PHP و Angular بدون jQuery (وهو غير مفيد لتطبيق Angular) لأول مرة (مثلي) ، ستحاول دائمًا:
$http.post(url, jsObject).then(...)
هذا وسوف تفشل، PHP افتراضيا deserializes x-www-form-urlencoded البيانات في $_POST متغير، وليس json البيانات.
عند مراجعة مفتش الشبكة في Firebug أو chrome أو dragonfly ، قد تلاحظ أنه تم تسلسل البيانات إلى JSON. ليس مهما:
راجع التعليمات البرمجية الخاصة بك ، اقرأ مستندات Angular. لا تجد أي خطأ.
من المتوقع أن تسلسل البيانات الثنائية تلقائيًا إلى التسلسل الأكثر شيوعًا في HTTP ، ستتذكر العديد من الحالات الأخرى التي تحتاج فيها إلى تعيين نوع البيانات بشكل صريح على أنه x-www-form-urlencoded ، حاول تعيين رأس http وتأمل أن يكرم إطار العمل هو - هي:
$http.post(url, jsObject, {headers: {'Content-Type': 'application/x-www-form-urlencoded'}}).then(...)

عندما يفشل هذا ، ستعتقد أنك أو إطار العمل قد ارتكبت شيئًا خاطئًا وسوف تقرأ المستندات مرة أخرى ، وتسأل ، وتبحث في الويب ، ...

في مكان ما بالقرب من هذه النقطة ، ستتعرف على $httpParamSerializer وربما تستخدمه ، انتقل إلى صفحة المشكلات @ أو كليهما.

ribeirobreno أوافق تمامًا. كانت هذه مشكلتي عند العمل مع angular 1 وبعد المرور بهذه الخطوات بالضبط واضطررت إلى استخدام $ .param لأنني لم أعرف عن $ httpParamSerializer. بعد كل هذا جئت إلى نفس المشكلة مع Angular 2 والآن ، مرة أخرى ، يمر يومي بينما أحاول معرفة كيفية القيام بذلك دون استخدام jquery مرة أخرى لأنني لم أتمكن من العثور على $ httpParamSerializer. ما يهمني أكثر هو الإطار الخلفي الذي يستخدمه الرجال الزاويون لعدم الوصول إلى هذه المشكلة على الفور منذ أن واجهت هذه المشكلة مع كل من Flask و ASP.Net وعلى كل من الأشخاص الذين يعملون في الخلفية ، قالوا إنها مشكلتي

DominikDitoIvosevic لقد بحثت في المستندات اليوم ووجدت هذا: https://docs.angularjs.org/api/ng/service/ $ http # default-transformations

لا أعرف ما إذا كنت قد فاتني ذلك من قبل أو إذا تمت إضافته ... في كلتا الحالتين أعتقد أنه سيكون من الجيد حقًا وجود مرجع إلى "التحويلات الافتراضية" بجوار معلمات البيانات ، هنا: https: // docs. angularjs.org/api/ng/service/ $ http # استخدام

أدرك أنني أتيت إلى هذا متأخرًا جدًا (جدًا) ، ولكن بصفتي شخصًا جديدًا في Angular ، أشعر بالدهشة من أنه من المحرج جدًا الحصول على هيئة نشر www-form-urlencoded . لقد فوجئت جدًا بأنه _لم يكن _ الخيار الافتراضي ، نظرًا (كما قال ribeirobreno ، ببراعة) إنه ما يتم استخدامه _ في أي مكان آخر_. ما زلت لا أفهم سبب عدم ذكر هذا الاختلاف صراحةً في الوثائق. مثل الكثيرين في هذا الموضوع ، أنا أستخدم PHP كخلفية. من الأسهل بالنسبة لي أن أجعل جانب خادم التحويل من جانب Angular ، ويرجع ذلك جزئيًا إلى أنه حتى مع التحولات في Angular ، فإن الحصول على نصوص منشورات ورؤوس محتوى "عادية" لا يزال يتطلب الكثير من العمل في Angular. سواء أجريت التعديل في Angular أو PHP ، لا يزال يتعين علي شرح شيء آخر لطلابي المبتدئين.

هذه إحدى المشكلات العديدة المغلقة التي وجدتها في هذا الموضوع. لن أعلق عليها جميعًا ، لكنني آمل أن تجلب الأصوات الكافية بعض الوضوح للمشكلة وتجعل استخدام Angular أسهل في الاستخدام.

كمبتدئ في Angular! لقد ساعدني في عام 2017 :)

واجهت هذه المشكلة في angular2
لذلك استخدمت هذا الرمز هنا
http://stackoverflow.com/questions/35212341/angular2-http-post-request-parameters