คุณควรระมัดระวังเป็นพิเศษหากคุณใช้คำสั่ง include โดยพื้นฐานแล้วจะเป็นการรวมไฟล์ทั้งหมดและสร้างไฟล์ผลลัพธ์ขึ้นมา และหากคุณรวมส่วนหัวของไซต์ (แถบเลื่อน เมนู ฯลฯ) ไว้ในตอนแรก แล้วลองส่งส่วนหัวในไฟล์หลัก แล้วคุณล่ะ แน่นอน คุณจะได้รับข้อผิดพลาดนี้

นี่คือตัวอย่างของรหัสที่ไม่ถูกต้องดังกล่าว:

ส่งมาโดย เมื่อ พฤหัสบดี 05/04/2017 - 12:55

คำอธิบายของปัญหาเฉพาะ

หลังจากคลิกปุ่มแล้วเกิดข้อผิดพลาด:

คำเตือน: ไม่สามารถแก้ไขข้อมูลส่วนหัว - ส่วนหัวส่งแล้วโดย (เอาต์พุตเริ่มต้นที่ C:\OpenServer\domains\testsite\WEB\5_phpRedirect.php:10) ใน C:\OpenServer\domains\testsite\WEB\5_phpRedirect.php ออนไลน์ 12

รหัสคล้ายกับที่ให้ไว้ในหัวข้อนี้:

เลือกสคริปต์ที่จะดาวน์โหลด

สคริปต์ตัวจัดการ:

สิ่งนี้จะเกิดขึ้นเมื่อใด

ประเภทข้อผิดพลาด (คำเตือน):

คำเตือน: ไม่สามารถแก้ไขข้อมูลส่วนหัวได้ - ส่วนหัวที่ส่งไปแล้ว

เกิดขึ้นหากคุณได้ทำบางสิ่งที่ต้องตั้งค่าส่วนหัวของเบราว์เซอร์แล้ว และตอนนี้คุณต้องการเขียนใหม่ด้วยส่วนหัวใหม่ ตัวอย่างเช่น หากคุณได้แสดงข้อความแล้ว php จะตั้งค่าส่วนหัว (โดยเฉพาะ header ที่ตั้ง-- ซึ่งแสดงว่าจะยังคงอยู่ในหน้าที่ร้องขอหรือไม่ หรือคุณจำเป็นต้องไปที่หน้าอื่นและรับการตอบกลับคำขอที่นั่น) เพื่อแสดงวิธีปฏิบัติตนแก่เบราว์เซอร์ของลูกค้า (ในการตอบสนอง)

ต้นตอของปัญหา

เป็นไปได้มากว่าปัญหาในกรณีของคุณคือคุณกำลังให้บริการเนื้อหาอยู่แล้ว (แท็ก html ที่ปะปนอยู่ในไฟล์พร้อมกับสคริปต์) ถึงคำสั่ง:

ส่วนหัวของ Echo ($ เปลี่ยนเส้นทาง);

โปรดจำไว้ว่าฟังก์ชัน header() สามารถเรียกได้หากไคลเอนต์เท่านั้น ยังไม่มีการถ่ายโอนข้อมูล- นั่นคือควรมาก่อนในเอาต์พุต ไม่ควรมีแท็ก HTML บรรทัดว่าง ฯลฯ ก่อนที่จะเรียกใช้ บ่อยครั้งข้อผิดพลาดเกิดขึ้นเมื่อเมื่ออ่านโค้ดที่มีฟังก์ชันไฟล์ เช่น include หรือ need มีช่องว่างหรือบรรทัดว่างในโค้ดนี้ที่พิมพ์ก่อนที่จะเรียกใช้ header() ปัญหาเดียวกันนี้อาจเกิดขึ้นได้เมื่อใช้ไฟล์ PHP/HTML ไฟล์เดียว

นั่นคือจำเป็นต้องกำจัดตัวจัดการสคริปต์ของ html - ท้ายที่สุดแล้วมันไม่ได้ส่งออกอะไรเลย แต่เพียงโอนไปยังที่อยู่อื่น - นี่เป็นครั้งแรก.

ส่วนหัว($เปลี่ยนเส้นทาง);

ส่วนหัวของ Echo ($ เปลี่ยนเส้นทาง);

การทดลอง

เนื่องจากโดยทั่วไปแล้ว echo() จะเขียนถึง เนื้อหาการตอบสนอง httpและไม่ได้อยู่ในส่วนหัวและส่วนหัวส่งคืนโมฆะ (นั่นคือไม่ส่งคืนค่า) ดังที่ได้กล่าวไว้ข้างต้นจึงไม่มีประโยชน์ในการใช้ echo() แต่
- อย่างไรก็ตาม ฉันเสนอให้ทำการทดลอง:

1. ลบ html
2. อย่าลบเสียงสะท้อน

เนื่องจาก header() ถูกเรียกเป็นหลักก่อน echo() (เนื่องจาก header() เป็นอาร์กิวเมนต์ของ echo()) และดังนั้นจึงส่งคืน - ในเวลาเดียวกันเราจะตรวจสอบว่าฟังก์ชันส่งคืนค่า null หรือไม่ - จะถูกตีความว่าเป็นสตริงว่างหรือ (ซึ่งหรือมากกว่านั้น) echo จะไม่เริ่มทำงานด้วยซ้ำเมื่อการเปลี่ยนเส้นทางเกิดขึ้นแล้ว

มาชี้แจงเหตุผลกันอีกครั้ง

เหล่านั้น. ก่อนที่จะเรียก header() ไม่ควรแสดงเนื้อหา(สิ่งที่เขียนเกี่ยวกับคำอธิบายของฟังก์ชั่น: http://php.net/manual/ru/function.header...)

• 1) ไม่มีเสียงสะท้อน
• 2) ไม่ใช่เพียงการทิ้งข้อความ html ลงในเบราว์เซอร์

ในกรณีของเรา เห็นได้ชัดว่า echo ไม่มีผลกระทบใดๆ แต่ html ในตัวจัดการมีผลจริงๆ

ปัญหาได้รับการแก้ไขแล้ว

ตามคำแนะนำของคุณ พวกเขาถูกลบออก แท็ก HTML- ขณะนี้การเปลี่ยนเส้นทางเกิดขึ้นอย่างถูกต้อง สคริปต์ตัวจัดการจะมีลักษณะดังนี้:

ฟังก์ชัน echo ไม่ส่งผลต่อการทำงานจริงๆ เช่น คุณสามารถปล่อยให้มันเป็นเหมือนใน S. Holzner:

นอกจากนี้ เมื่อเขียนโค้ดสำหรับการเปลี่ยนเส้นทาง คุณควรใส่ใจกับนามสกุลของไฟล์ที่ทำการเปลี่ยนแปลง: ด้วยไวยากรณ์ที่เสนอ จะต้องระบุในอาร์กิวเมนต์ส่วนหัว

• เข้าสู่ระบบเพื่อแสดงความคิดเห็น

แต่คุณสามารถทำให้มันใช้งานได้

แต่คุณยังสามารถทำให้ตัวจัดการก่อนหน้านี้ทำงานได้

หากคุณตั้งค่าตัวเลือกในไฟล์ php.ini

เอาท์พุต_บัฟเฟอร์ = 4096

• เข้าสู่ระบบเพื่อแสดงความคิดเห็น

ห้ามส่งส่วนหัวซ้ำ โปรโตคอล HTTP ใช้งานไม่ได้! แต่เราควรทำอย่างไร? หลังจากแสดงบนเพจแล้ว คุณต้องเริ่มเซสชันและตั้งค่าคุกกี้ด้วยหรือไม่ - มาจำเกี่ยวกับการบัฟเฟอร์เอาต์พุตกันดีกว่า

นั่นคือ เมื่อตั้งค่าขนาดบัฟเฟอร์ที่ไม่เป็นศูนย์ ก็ยังคงสามารถจัดการส่วนหัวได้จนกว่าจะเต็ม หากขนาดบัฟเฟอร์เป็นศูนย์ หลังจากที่เนื้อหาถูกเอาต์พุตแล้ว ก็จะถูกส่งกลับทันที นำหน้าด้วยส่งส่วนหัวการตอบสนอง HTTP ไปยังไคลเอนต์

และปรากฎว่าเราต้องการเปลี่ยนส่วนหัวที่ "บิน" ผ่านเครือข่ายไปยังไคลเอนต์แล้ว (ซึ่งหมายความว่าไม่สามารถแก้ไขได้อีกต่อไป - โดยเฉพาะส่วนหัว ที่ตั้งซึ่งระบุว่าจะอยู่ในหน้าที่ร้องขอหรือขอหน้าอื่น - การตอบสนองของสคริปต์ "ตัวเปลี่ยนเส้นทาง" (สำหรับเรานี่คือตัวจัดการแบบฟอร์ม) เพียงบอกว่าเราต้องขอหน้าอื่น) ซึ่งเป็นสิ่งที่ php เตือนเรา .

แต่:แน่นอนว่าเป็นไปไม่ได้ที่จะแก้ไขปัญหาด้วยวิธีนี้ (ไม่ถูกต้องมากนักและแม่นยำยิ่งขึ้น)

_____________
คณะคณิตศาสตร์ มศว และคณะคลาสสิคอื่นๆ =)

• เข้าสู่ระบบเพื่อแสดงความคิดเห็น

ทำความเข้าใจเกี่ยวกับส่วนหัว HTTP และฟิลด์ส่วนหัว HTTP

ส่วนหัว HTTPให้ข้อมูลสำคัญที่จำเป็นสำหรับธุรกรรม HTTP ที่ส่งผ่าน โปรโตคอล http.

รูปแบบส่วนหัว HTTP ทั่วไปประกอบด้วยคู่ชื่อ - ค่าที่คั่นด้วยโคลอนในฟิลด์ส่วนหัว คู่ชื่อ-ค่าแต่ละคู่ลงท้ายด้วยลำดับอักขระขึ้นบรรทัดใหม่ (CR) และลำดับอักขระป้อนบรรทัด (LF) ช่องว่างที่ส่วนท้ายของแต่ละส่วนหัวจะระบุจุดสิ้นสุดของส่วนหัว

รูปแบบส่วนหัวทั่วไปที่ตามมาด้วยแอปพลิเคชันมีลักษณะดังนี้:

ประเภทของส่วนหัว HTTP

ส่วนหัวข้อความ HTTP มีสี่ประเภท พวกเขาคือ:

• ส่วนหัวทั่วไป
• ขอส่วนหัว
• ส่วนหัวของการตอบกลับ
• ส่วนหัวของเอนทิตี

ส่วนหัวทั่วไป

ฟิลด์ส่วนหัวทั่วไปมีการบังคับใช้ทั่วไปในข้อความคำขอและการตอบกลับ ฟิลด์ส่วนหัวใช้กับข้อความที่ส่งเท่านั้น และไม่ใช้กับเอนทิตีที่ถูกโอน

โครงสร้างของส่วนหัวทั่วไปมีลักษณะดังนี้:

การควบคุมแคชฟิลด์ระบุคำสั่งที่ต้องปฏิบัติตามโดยทุกกลไกการแคชในระบบคำขอและการตอบสนอง

การเชื่อมต่อฟิลด์อนุญาตให้ผู้ส่งระบุตัวเลือกที่จำเป็นสำหรับการเชื่อมต่อ ส่วนหัวของการเชื่อมต่อมีรูปแบบดังต่อไปนี้:

วันที่ฟิลด์แสดงถึงวันที่และเวลาระหว่างการเริ่มต้นข้อความ รูปแบบวันที่ที่ระบุใน HTTP มีลักษณะดังนี้:

แพรมาฟิลด์ช่วยในการรวมคำสั่งเฉพาะในการดำเนินการที่ใช้บังคับกับผู้รับในระบบคำขอและการตอบสนอง

ตัวอย่างค่าของฟิลด์ระบุว่าชุดของฟิลด์ส่วนหัวในตัวอย่างข้อความถูกเข้ารหัสด้วยการเข้ารหัสการโอนแบบก้อนหรือไม่

การโอนการเข้ารหัสฟิลด์ระบุว่ามีการใช้การเปลี่ยนแปลงประเภทใดๆ กับเนื้อหาข้อความหรือไม่

อัพเกรดฟิลด์ช่วยให้ไคลเอ็นต์สามารถระบุโปรโตคอลการสื่อสารที่รองรับเพิ่มเติมได้ นอกจากนี้ยังช่วยให้เซิร์ฟเวอร์สามารถสลับโปรโตคอลด้วยโปรโตคอลเพิ่มเติมได้

ทางฟิลด์เป็นฟิลด์บังคับที่ใช้โดยพรอกซีและเกตเวย์ซึ่งระบุโปรโตคอลระดับกลาง นอกจากนี้ยังระบุผู้รับคำขอระหว่างตัวแทนผู้ใช้และเซิร์ฟเวอร์และการตอบกลับระหว่างเซิร์ฟเวอร์และไคลเอนต์

คำเตือนฟิลด์มีข้อมูลเพิ่มเติมเกี่ยวกับสถานะข้อความและการแปลงข้อความซึ่งไม่ปรากฏในข้อความ

โดยปกติแล้วส่วนหัวคำเตือนจะถูกส่งไปพร้อมกับการตอบกลับ

ฟิลด์ส่วนหัวของคำขออนุญาตให้ไคลเอนต์ส่งข้อมูลคำขอและข้อมูลไคลเอนต์เพิ่มเติมไปยังเซิร์ฟเวอร์

โครงสร้างของส่วนหัวคำขอมีลักษณะดังนี้:

ยอมรับฟิลด์ระบุประเภทสื่อที่ยอมรับได้สำหรับการตอบสนอง

"*" ใช้เพื่อจัดกลุ่มประเภทสื่อในช่วง

"*/*" หมายถึงสื่อทุกประเภท

"type/*" ระบุประเภทย่อยทั้งหมดของประเภท

ยอมรับ Charsetฟิลด์ระบุชุดอักขระที่ยอมรับได้ ทำให้ไคลเอ็นต์สามารถเข้าใจชุดอักขระที่มีวัตถุประสงค์พิเศษเพื่อส่งสัญญาณให้เซิร์ฟเวอร์แสดงเอกสารในชุดอักขระเหล่านี้

ยอมรับการเข้ารหัสฟิลด์จะคล้ายกับยอมรับ จำกัดการตอบสนองการเข้ารหัสเนื้อหาที่ยอมรับได้

ยอมรับภาษาฟิลด์จะคล้ายกับการยอมรับ จำกัดชุดภาษาธรรมชาติที่ต้องการ

การอนุญาตฟิลด์นี้มีไว้สำหรับตัวแทนผู้ใช้ที่ต้องการตรวจสอบสิทธิ์ตนเองกับเซิร์ฟเวอร์

คาดหวังฟิลด์ระบุพฤติกรรมของเซิร์ฟเวอร์ที่ลูกค้าต้องการ

จากมีที่อยู่อีเมลของผู้ใช้ที่ควบคุมตัวแทนผู้ใช้ที่ร้องขอ

เจ้าภาพฟิลด์ระบุโฮสต์อินเทอร์เน็ตและหมายเลขพอร์ตทรัพยากรที่ร้องขอจาก URI ของผู้ใช้

ถ้า-Matchฟิลด์ถูกใช้เพื่อสร้างวิธีการแบบมีเงื่อนไข

ถ้า-แก้ไข-ตั้งแต่ field ใช้เพื่อสร้างเมธอดแบบมีเงื่อนไข หากตัวแปรที่ร้องขอไม่ได้รับการแก้ไขภายในเวลาที่กำหนด เอนทิตีจะไม่ถูกส่งคืนจากเซิร์ฟเวอร์

ถ้า-ไม่มี-ตรงกันฟิลด์ช่วยให้สามารถอัปเดตข้อมูลแคชได้อย่างมีประสิทธิภาพโดยมีค่าใช้จ่ายในการทำธุรกรรมขั้นต่ำ

ถ้า-ช่วงฟิลด์ช่วยให้ลูกค้าได้รับส่วนหนึ่งของเอนทิตีที่หายไป หรือมิฉะนั้น ลูกค้าสามารถขอให้ส่งเอนทิตีใหม่ทั้งหมดได้

ถ้า-ไม่ได้แก้ไข-ตั้งแต่ฟิลด์อนุญาตให้เซิร์ฟเวอร์ดำเนินการตามที่ร้องขอได้หากไม่มีการแก้ไขตั้งแต่เวลาที่ระบุในฟิลด์นี้

แม็กซ์ฟอร์เวิร์ดฟิลด์จัดเตรียมกลไกด้วยเมธอด TRACE และ OPTIONS เพื่อจำกัดพรอกซีหรือเกตเวย์การส่งต่อคำขอ

การอนุญาตพร็อกซีฟิลด์อนุญาตให้ไคลเอนต์ระบุเพื่อรักษาความปลอดภัยพร็อกซี

พิสัยฟิลด์ระบุเอนทิตี HTTP ในข้อความ HTTP ที่แสดงเป็นลำดับไบต์ คำขอดึงข้อมูล HTTP ร้องขอช่วงย่อยของเอนทิตีอย่างน้อยหนึ่งช่วงโดยใช้วิธี GET

ผู้อ้างอิงอนุญาตให้ไคลเอ็นต์ระบุ URI ที่อยู่ของทรัพยากรที่พบ Request-URI

ที.อี.ฟิลด์ระบุการเข้ารหัสการถ่ายโอนส่วนขยายที่สามารถยอมรับในการตอบกลับ นอกจากนี้ยังระบุว่าจะยอมรับช่องตัวอย่างในการเข้ารหัสการโอนแบบก้อนหรือไม่

ผู้ใช้-ตัวแทนฟิลด์มีข้อมูลเกี่ยวกับตัวแทนผู้ใช้ที่ร้องขอ

ส่วนหัวการตอบสนอง HTTP

ฟิลด์ส่วนหัวการตอบกลับอนุญาตให้เซิร์ฟเวอร์ส่งข้อมูลเพิ่มเติมผ่านการตอบกลับนอกเหนือจากการตอบกลับ Status-Line แบบธรรมดา

โครงสร้างของส่วนหัวการตอบกลับมีลักษณะดังนี้:

ยอมรับ-ช่วงฟิลด์ช่วยให้เซิร์ฟเวอร์ระบุการยอมรับคำขอช่วงทรัพยากร

อายุฟิลด์ระบุระยะเวลาโดยประมาณตั้งแต่เซิร์ฟเวอร์ตอบกลับไปยังผู้ส่ง

อีแท็กฟิลด์ระบุค่าปัจจุบันของแท็กเอนทิตีสำหรับคำขอ

ที่ตั้งฟิลด์จะเปลี่ยนเส้นทางผู้รับไปยังตำแหน่งอื่นที่ไม่ใช่ Request-URI เพื่อระบุทรัพยากรใหม่ให้เสร็จสมบูรณ์

พร็อกซี-รับรองความถูกต้องฟิลด์เป็นการรวมที่จำเป็นสำหรับการตอบสนองการรับรองความถูกต้องของพร็อกซี

ลองอีกครั้งหลังจากฟิลด์ถูกใช้เป็นการตอบกลับเมื่อบริการไม่พร้อมใช้งานเพื่อระบุระยะเวลาที่บริการจะยังคงไม่พร้อมใช้งานสำหรับลูกค้า

เซิร์ฟเวอร์ฟิลด์มีข้อมูลเกี่ยวกับซอฟต์แวร์ที่ใช้โดยเซิร์ฟเวอร์เพื่อจัดการคำขอ

ต่างกันไปฟิลด์ ระบุฟิลด์คำขอที่กำหนดว่าแคชมีสิทธิ์ใช้การตอบสนองของคำขอหรือไม่ โดยไม่ต้องตรวจสอบการตอบสนองอีกครั้ง

WWW-รับรองความถูกต้องฟิลด์จะใช้เมื่อข้อความตอบกลับไม่ได้รับอนุญาต

ฟิลด์ส่วนหัวของเอนทิตีกำหนดข้อมูลเมตาเกี่ยวกับเอนทิตี-เนื้อหาหรือทรัพยากรที่ร้องขอ รูปแบบส่วนหัวของเอนทิตีมีลักษณะดังนี้:

อนุญาตฟิลด์แสดงรายการชุดวิธีการที่รองรับโดยทรัพยากรที่ระบุ Request-URI

การเข้ารหัสเนื้อหาฟิลด์ถูกใช้เป็นตัวแก้ไขประเภทสื่อ

เนื้อหา-ภาษาฟิลด์อธิบายภาษาธรรมชาติสำหรับลูกค้าของเอนทิตี

ความยาวของเนื้อหาฟิลด์ระบุขนาดของเอนทิตีที่แสดงเป็นเลขทศนิยม

เนื้อหา-ตำแหน่งฟิลด์ระบุตำแหน่งทรัพยากรสำหรับเอนทิตีเมื่อสามารถเข้าถึงได้จากตำแหน่งอื่นที่ไม่ใช่ URI ที่ร้องขอ

เนื้อหา-MD5ฟิลด์จัดเตรียมการตรวจสอบความสมบูรณ์ของข้อความ (MIC) โดยใช้การสรุป MD5 บนเนื้อหาเอนทิตี

เนื้อหา-ช่วงฟิลด์ระบุตำแหน่งที่ควรใช้บางส่วนของเนื้อหาเอนทิตีแบบเต็ม

ประเภทเนื้อหาฟิลด์ระบุว่าประเภทสื่อของเนื้อหาเอนทิตีถูกส่งไปยังผู้รับหรือใช้วิธีการ GET เพื่อส่งคำขอ

หมดอายุฟิลด์ระบุวันที่/เวลาที่การตอบกลับกลายเป็นข้อมูลเก่า

แก้ไขครั้งล่าสุดฟิลด์ระบุวันที่และเวลาของการแก้ไขตัวแปรครั้งล่าสุด

ลำดับที่ชื่อฟิลด์ปรากฏในส่วนหัวเมื่อได้รับไม่มีนัยสำคัญ ส่วนหัวทั่วไปตามอัตภาพจะถูกวางไว้ก่อน ตามด้วยส่วนหัวคำขอหรือการตอบกลับโดยมีส่วนหัวของเอนทิตีที่ส่วนท้าย

ประกาศเกี่ยวกับลิขสิทธิ์: โปรดอย่าคัดลอกหรือแปลบทความนี้โดยไม่ได้รับอนุญาตเป็นลายลักษณ์อักษรล่วงหน้าจากไซต์

HTTP Debugger เป็นตัววิเคราะห์ HTTP ที่ไม่ต้องใช้พร็อกซีสำหรับนักพัฒนาที่ให้ความสามารถในการจับภาพและวิเคราะห์ส่วนหัว HTTP, คุกกี้, พารามิเตอร์ POST, เนื้อหา HTTP และส่วนหัว CORS จากเบราว์เซอร์หรือแอปพลิเคชันเดสก์ท็อปใด ๆ

UI ที่ยอดเยี่ยมและใช้งานง่ายมาก ไม่ใช่พรอกซี ไม่มีปัญหาเครือข่าย!

วันหนึ่ง เมื่อฉันไปที่บล็อก ฉันรู้สึกประหลาดใจที่พบข้อผิดพลาดที่ไม่สามารถเข้าใจได้ เช่น:

คำเตือน: ไม่สามารถแก้ไขข้อมูลส่วนหัว — ส่วนหัวที่ส่งไปแล้ว (เอาต์พุตเริ่มต้นที่ /xxxxxxxx/wp-config.php:1)

ยิ่งกว่านั้นไม่มีวิธีเข้าสู่แผงผู้ดูแลระบบ ฉันไปตรวจสอบทันทีว่ามีอะไรผิดปกติกับไฟล์ wp-config.php ทุกอย่างเรียบร้อยดี รหัสผ่านฐานข้อมูลถูกต้อง ฉันคิดว่ามันถูกแฮ็กอีกครั้ง)) แต่ขอย้ำอีกครั้งว่า FTP ไม่มีสัญญาณของการก่อกวน สิ่งที่แปลกประหลาดที่สุด (ซึ่งท้ายที่สุดแล้วฉันก็สับสนไปหมด) ก็คือ มีเพียงลิงก์ไปยังเว็บไซต์ที่ไม่มี www เท่านั้นที่ใช้งานไม่ได้ หรือในทางกลับกัน (ฉันจำไม่ได้แน่ชัด) ฉันเริ่มติดต่อโฮสต์โดยดูการตั้งค่าในแผงผู้ดูแลระบบโดเมน โดยทั่วไปแล้วมีหลายสิ่งหลายอย่าง แต่มันกลับกลายเป็นว่าง่ายกว่ามาก -ที่จุดเริ่มต้นของไฟล์ปรับแต่งมี BOM บางอย่าง

ในโปรแกรมแก้ไขข้อความบางตัว คุณอาจพบ "รวม Unicode Signature (BOM)", "เพิ่ม Byte Order Mark" หรือช่องทำเครื่องหมายที่คล้ายกันในการตั้งค่า มิฉะนั้นหากไม่สามารถปิดการใช้งานตัวเลือกที่ไม่จำเป็นในโปรแกรมใดโปรแกรมหนึ่งได้ก็ไม่แนะนำให้ใช้ ในฟอรั่มเฉพาะคุณสามารถค้นหารายการที่ดีได้ โปรแกรมแก้ไขข้อความ, นี้ - Notepad2, PSPad, UnicEdit, Notepad++- โดยทั่วไปแล้ว มีการเขียนมากมายเกี่ยวกับเรื่องหลังนี้ มันเป็นเครื่องมือที่ทรงพลังมาก บังเอิญฉันมีมันอยู่ในคอมพิวเตอร์ของฉัน บรรณาธิการสำรอง — อาเคลแพด— ฉันใช้มันสำหรับงานที่คล้ายกัน

อีกประเด็นที่ควรสังเกตก็คือ ข้อผิดพลาดกับ BOM สามารถเกิดขึ้นได้ไม่เพียงแต่ในไฟล์ wp-config.php เท่านั้น นอกจากนี้ หากปิดใช้งานตัวเลือกในการแสดงคำเตือน คุณจะไม่เห็นว่าปัญหาคืบคลานไปที่ใดเลย ในกรณีเช่นนี้ (และอื่นๆ ทั้งหมด) ฉันขอแนะนำให้ใช้วิธีง่ายๆ สคริปต์สำหรับค้นหาไฟล์ด้วย BOM- ต้องขอบคุณ Yuri Belotitsky สำหรับการพัฒนา

การใช้สคริปต์นั้นง่ายมาก

1. ไฟล์ที่ต้องการ
2. คุณเทมันลงไป เซิร์ฟเวอร์เอฟทีพีไปยังไดเร็กทอรีราก หากไม่ได้ติดตั้ง WordPress ในรูทของไซต์ (แต่ในโฟลเดอร์บล็อก เป็นต้น) จะต้องวางสคริปต์ในไดเร็กทอรีที่ WordPress ตั้งอยู่ และเรียกใช้จากที่นั่น
3. การเปิดตัวนั้นง่ายมาก - เพียงพิมพ์เข้าไป แถบที่อยู่ลิงค์เบราว์เซอร์ http://your.site/find_bom.php

เป็นผลให้คุณได้รับรายการไฟล์ที่ผิดพลาด อย่างไรก็ตาม เพื่อเพิ่มความเร็วในการทำงาน สคริปต์จะตรวจสอบเฉพาะไดเร็กทอรีที่ผู้ใช้มักจะอัปโหลดไฟล์ - รูท /wp-content/themes และ /wp-content/plugins

นั่นคือทั้งหมด มันยากแค่ไหนที่จะแก้ไขปัญหาง่ายๆ เช่นนี้ ฉันหวังว่าฉันจะช่วยคุณได้เล็กน้อยจากประสบการณ์ของฉัน และตอนนี้เมื่อมีคำเตือนที่เกี่ยวข้องปรากฏขึ้น คุณจะรู้ว่าต้องทำอย่างไร :) หากคุณไม่สามารถแก้ไขไฟล์หนึ่งหรือไฟล์อื่นจาก BOM คุณสามารถอัปโหลดไฟล์ใหม่จากการกระจาย WordPress .

ป.ล. สถานที่ที่เหมาะสมสำหรับคู่บ่าวสาวคือการจัดงานเลี้ยงและแก้ไขปัญหาทั้งหมดที่เกี่ยวข้องกับงานแต่งงาน