file_get_contents (“ php: // input”) หรือ $ HTTP_RAW_POST_DATA อันไหนดีกว่าในการรับเนื้อหาของคำขอ JSON


120

file_get_contents("php://input")หรือ$HTTP_RAW_POST_DATA- อันไหนดีกว่าที่จะได้รับเนื้อหาของคำขอ JSON

และประเภทคำขอ ( GETหรือPOST) ผมควรจะใช้ในการส่งข้อมูล JSON เมื่อใช้ฝั่งไคลเอ็นต์XmlHTTPRequest?

คำถามของฉันได้รับแรงบันดาลใจจากคำตอบนี้: วิธีโพสต์ JSON เป็น PHP ด้วย curl

อ้างจากคำตอบนั้น:

จากมุมมองของโปรโตคอลfile_get_contents("php://input")นั้นถูกต้องกว่าเนื่องจากคุณไม่ได้ประมวลผลข้อมูลฟอร์มหลายส่วนของ http จริงๆ

คำตอบ:


196

ที่จริงphp://inputช่วยให้คุณอ่านข้อมูล POST ดิบ

มันเป็นความทรงจำทางเลือกน้อยมากถึง $ HTTP_RAW_POST_DATA และไม่จำเป็นต้องสั่ง

php://inputไม่สามารถใช้ได้กับenctype="multipart/form-data".

อ้างอิง: http://php.net/manual/en/wrappers.php.php


12
นอกจากนี้ใน PHP 5.6 $HTTP_RAW_POST_DATAถือว่าเลิกใช้แล้วและphp://inputสามารถนำกลับมาใช้ใหม่ได้
Chris Forrence

ดูenable_post_data_readingด้วย
Pacerier

json_decode (file_get_contents ('php: // input'), true) สิ่งนี้รองรับใน PHP 7.1 เพื่อรับค่า $ _GET จาก URL หรือไม่
Kailas

$ HTTP_RAW_POST_DATA เลิกใช้แล้วตั้งแต่ PHP 7
Daniel

15

php: // input เป็นสตรีมแบบอ่านอย่างเดียวที่อนุญาตให้คุณอ่านข้อมูลดิบจากเนื้อหาคำขอ ในกรณีของการร้องขอการโพสต์เป็นที่นิยมการใช้ PHP: // ป้อนข้อมูลแทน $ HTTP_RAW_POST_DATA เป็นมันไม่ได้ขึ้นอยู่กับคำสั่ง php.ini พิเศษ ยิ่งไปกว่านั้นสำหรับกรณีที่ไม่มีการเติมข้อมูล $ HTTP_RAW_POST_DATA ตามค่าเริ่มต้นอาจเป็นทางเลือกที่ใช้หน่วยความจำน้อยกว่าในการเปิดใช้งาน always_populate_raw_post_data

ที่มา: http://php.net/manual/en/wrappers.php.php


4
นอกจากนี้ใน PHP 5.6 $HTTP_RAW_POST_DATAถือว่าเลิกใช้แล้วและphp://inputสามารถนำกลับมาใช้ใหม่ได้
Chris Forrence

14

file_get_contents (php: // input) - รับข้อมูลดิบ POST และคุณต้องใช้สิ่งนี้เมื่อคุณเขียน API และต้องการอินพุต XML / JSON / ... ที่ไม่สามารถถอดรหัสเป็น $ _POST โดย PHP ตัวอย่าง:

ส่งทางไปรษณีย์สตริง JSON

<input type="button" value= "click" onclick="fn()">
<script>
 function fn(){


    var js_obj = {plugin: 'jquery-json', version: 2.3};

    var encoded = JSON.stringify( js_obj );

var data= encoded


    $.ajax({
  type: "POST",
  url: '1.php',
  data: data,
  success: function(data){
    console.log(data);
  }

});

    }
</script>

1.php

//print_r($_POST); //empty!!! don't work ... 
var_dump( file_get_contents('php://input'));

3

กฎปกติควรใช้สำหรับวิธีที่คุณส่งคำขอ หากการร้องขอคือการดึงข้อมูล (เช่นผลการค้นหา 'คำใบ้' บางส่วนหรือหน้าใหม่ที่จะแสดง ฯลฯ ... ) คุณสามารถใช้ GET หากข้อมูลที่ส่งเป็นส่วนหนึ่งของคำร้องขอให้เปลี่ยนแปลงบางสิ่งบางอย่าง (อัปเดตฐานข้อมูลลบบันทึก ฯลฯ .. ) จากนั้นใช้ POST

ฝั่งเซิร์ฟเวอร์ไม่มีเหตุผลที่จะใช้อินพุตดิบเว้นแต่คุณต้องการคว้าบล็อกโพสต์ / รับข้อมูลทั้งหมดในครั้งเดียว คุณสามารถดึงข้อมูลเฉพาะที่คุณต้องการผ่านอาร์เรย์ _GET / _POST ได้ตามปกติ ไลบรารี AJAX เช่น MooTools / jQuery จะจัดการส่วนที่ยากของการเรียกใช้ AJAX จริงและการเข้ารหัสข้อมูลในรูปแบบเป็นรูปแบบที่เหมาะสมสำหรับคุณ


นั่นคือประเด็น: ฉันต้องการคว้าบล็อกโพสต์ / รับข้อมูลทั้งหมดในครั้งเดียวเนื่องจาก JSON เป็นรูปแบบที่ไม่แปรผันจึงแสดงเฉพาะข้อมูล
Manuel Bitto

@Kucebe ฉันไม่เห็นว่าทำไมจึงจำเป็นทำไมไม่ใส่ข้อมูล JSON ลงในช่อง POST และดำเนินการกับมัน
Pekka

หากคุณต้องการบล็อก JSON ทั้งหมดทำไมไม่กำหนดบล็อกข้อความ JSON ให้กับฟิลด์แบบฟอร์มและส่งแบบนั้น? <input type="hidden" name="data" value="json data here" />เป็นที่ยอมรับโดยสิ้นเชิงและช่วยให้คุณสามารถเรียกดูได้เล็กน้อยในฝั่งเซิร์ฟเวอร์ด้วย $ _REQUEST ['data']
Marc B

3
การฝัง JSON ในช่อง POST จะเอาชนะวัตถุประสงค์ของแท็กประเภทเนื้อหา HTTP และไม่เหมาะสำหรับการดีบักใน Fiddler และโปรแกรมดีบั๊กของเบราว์เซอร์ (ซึ่งสามารถเข้าใจ JSON ได้) นอกจากนี้ไลบรารี JavaScript ของบุคคลที่สามจำนวนมากโพสต์เพย์โหลด JSON เป็น application / json
CyberMonk

2

สำหรับข้อมูล JSON การโพสต์เป็นประเภทเนื้อหา "application / json" นั้นง่ายกว่ามาก หากคุณใช้ GET คุณต้องเข้ารหัส URL ของ JSON ในพารามิเตอร์และมันก็ยุ่ง นอกจากนี้ยังไม่มีการ จำกัด ขนาดเมื่อคุณทำ POST รับขนาดของถ้า จำกัด มาก (สูงสุด 4K)


2
มักจะมีการ จำกัด ขนาดสำหรับ POST แต่มักจะตั้งไว้ค่อนข้างสูง ตรวจสอบphp.iniไฟล์.
Brad

2

คำถามที่สองของคุณเป็นเรื่องง่าย GET มีข้อ จำกัด ด้านขนาด 1-2 กิโลไบต์ทั้งฝั่งเซิร์ฟเวอร์และเบราว์เซอร์ดังนั้นข้อมูลจำนวนมากที่คุณต้องส่งผ่าน POST

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.