perlpodspec - ออนไลน์ในคลาวด์

โครงการ:

ชื่อ

perlpodspec - เอกสารเก่าธรรมดา: ข้อกำหนดรูปแบบและบันทึกย่อ

DESCRIPTION

เอกสารนี้เป็นหมายเหตุโดยละเอียดเกี่ยวกับภาษามาร์กอัปของ Pod คนส่วนใหญ่จะต้อง .เท่านั้น
อ่าน perlpod เพื่อทราบวิธีการเขียนใน Pod แต่เอกสารนี้อาจตอบโดยบังเอิญบ้าง
คำถามเกี่ยวกับการแยกวิเคราะห์และแสดงผล Pod

ในเอกสารนี้ "ต้อง" / "ต้องไม่" "ควร" / "ไม่ควร" และ "อาจ" มี
แบบแผน (cf. RFC 2119) ความหมาย: "X ต้องทำ Y" หมายความว่าถ้า X ไม่ทำ Y มันจะเป็น
ขัดกับข้อกำหนดนี้และควรได้รับการแก้ไขจริงๆ "X ควรทำ Y" หมายความว่า มันคือ
แนะนำ แต่ X อาจล้มเหลวในการทำ Y หากมีเหตุผลที่ดี "X may do Y" เป็นเพียง a
โปรดทราบว่า X สามารถทำ Y ได้ตามต้องการ (แม้ว่าจะขึ้นอยู่กับผู้อ่านที่จะตรวจจับความหมายแฝงของ
"และฉันคิดว่ามันจะเป็น ดี ถ้า X ทำ Y" กับ "มันจะไม่เป็นอย่างนั้นจริงๆ ตื๊อ ฉันถ้า X ไม่
จ")

โดยเฉพาะอย่างยิ่ง เมื่อฉันพูดว่า "parser ควรทำ Y" parser อาจล้มเหลวในการทำ Y หากการเรียก
แอปพลิเคชันร้องขออย่างชัดเจนว่า parser ไม่ ทำ Y. ฉันมักจะวลีนี้ว่า "the
parser ควรทำโดยค่าเริ่มต้น Y" สิ่งนี้ไม่ได้ ต้องการ parser เพื่อให้ตัวเลือก
สำหรับปิดฟีเจอร์ Y อะไรก็ตาม (เช่น การขยายแท็บในย่อหน้าแบบคำต่อคำ)
แม้ว่าจะมีความหมายว่าตัวเลือกดังกล่าว อาจ มีการจัด.

รุน คำจำกัดความ

Pod ถูกฝังอยู่ในไฟล์ โดยทั่วไปแล้วจะเป็นไฟล์ต้นฉบับของ Perl แม้ว่าคุณจะสามารถเขียนไฟล์ได้ก็ตาม
นั่นไม่ใช่อะไรนอกจากพอด

A เส้น ในไฟล์ประกอบด้วยอักขระที่ไม่ใช่บรรทัดใหม่ตั้งแต่ศูนย์ขึ้นไป สิ้นสุดโดย a
ขึ้นบรรทัดใหม่หรือท้ายไฟล์

A ขึ้นบรรทัดใหม่ ลำดับ มักจะเป็นแนวคิดที่ขึ้นกับแพลตฟอร์ม แต่ตัวแยกวิเคราะห์ Pod ควร
เข้าใจว่าหมายถึง CR (ASCII 13), LF (ASCII 10) หรือ CRLF (ASCII 13) ใด ๆ
ทันทีโดย ASCII 10) นอกเหนือจากความหมายเฉพาะระบบอื่นๆ ครั้งแรก
ลำดับ CR/CRLF/LF ในไฟล์อาจใช้เป็นพื้นฐานในการระบุบรรทัดใหม่ได้
ลำดับการแยกวิเคราะห์ส่วนที่เหลือของไฟล์

A ว่างเปล่า เส้น เป็นบรรทัดที่ประกอบด้วยช่องว่างทั้งหมดตั้งแต่ศูนย์ขึ้นไป (ASCII 32) หรือ tabs
(ASCII 9) และสิ้นสุดด้วยการขึ้นบรรทัดใหม่หรือสิ้นสุดไฟล์ อา ไม่ว่าง เส้น เป็นเส้น
มีอักขระตั้งแต่หนึ่งตัวขึ้นไปนอกเหนือจากช่องว่างหรือแท็บ (และสิ้นสุดด้วยการขึ้นบรรทัดใหม่หรือ
ท้ายไฟล์)

(หมายเหตุ ตัวแยกวิเคราะห์ Pod ที่เก่ากว่าจำนวนมากไม่ยอมรับบรรทัดที่ประกอบด้วยช่องว่าง/แท็บ จากนั้น a
ขึ้นบรรทัดใหม่เป็นบรรทัดว่าง บรรทัดเดียวที่พวกเขาถือว่าว่างคือบรรทัดที่ประกอบด้วย ไม่
อักขระ at ทั้งหมดสิ้นสุดด้วยการขึ้นบรรทัดใหม่)

ช่องว่าง ใช้ในเอกสารนี้เป็นคำครอบคลุมสำหรับช่องว่าง แท็บ และขึ้นบรรทัดใหม่
ลำดับ (โดยตัวมันเอง คำนี้มักจะหมายถึงช่องว่างตามตัวอักษร นั่นคือ
ลำดับของอักขระช่องว่างในซอร์ส Pod ซึ่งตรงข้ามกับ "E<32>" ซึ่งก็คือ a
การจัดรูปแบบโค้ดที่ หมายถึง อักขระช่องว่าง)

A รุน parser เป็นโมดูลที่มีไว้สำหรับการแยกวิเคราะห์ Pod (ไม่ว่าจะเกี่ยวข้องกับ
โทรกลับหรือสร้างต้นไม้แยกวิเคราะห์หรือจัดรูปแบบโดยตรง) อา รุน ฟอร์แมตเตอร์
(หรือ รุน นักแปล) เป็นโมดูลหรือโปรแกรมที่แปลง Pod เป็นรูปแบบอื่น (HTML,
ข้อความธรรมดา, TeX, PostScript, RTF) อา รุน หน่วยประมวลผล อาจเป็นตัวจัดรูปแบบหรือนักแปลหรือ
อาจเป็นโปรแกรมที่ทำอย่างอื่นกับ Pod (เช่น การนับคำ การสแกน
สำหรับจุดดัชนี ฯลฯ)

เนื้อหา Pod มีอยู่ใน รุน บล็อก. Pod block เริ่มต้นด้วยบรรทัดที่ตรงกัน
"m/\A=[a-zA-Z]/" และไปต่อในบรรทัดถัดไปที่ตรงกับ "m/\A=cut/" หรือถึง
สิ้นสุดไฟล์หากไม่มีบรรทัด "m/\A=cut/"

ภายในบล็อก Pod มี รุน ย่อหน้า. ย่อหน้า Pod ประกอบด้วยบรรทัดที่ไม่เว้นว่าง
ของข้อความ โดยคั่นด้วยบรรทัดว่างตั้งแต่หนึ่งบรรทัดขึ้นไป

สำหรับวัตถุประสงค์ของการประมวลผล Pod มีย่อหน้าสี่ประเภทในบล็อก Pod:

· ย่อหน้าคำสั่ง (เรียกอีกอย่างว่า "คำสั่ง") บรรทัดแรกของย่อหน้านี้
ต้องตรงกับ "m/\A=[a-zA-Z]/" ย่อหน้าคำสั่งมักจะเป็นหนึ่งบรรทัด เช่นใน:

=head1 หมายเหตุ

=รายการ *

แต่อาจครอบคลุมหลายบรรทัด (ไม่เว้นว่าง):

=สำหรับความคิดเห็น
อืม ฉันสงสัยว่ามันจะเป็นอย่างไรถ้า
คุณพยายามเขียน BNF สำหรับ Pod จากสิ่งนี้

=head3 Dr. Strangelove หรือ: How I Learned to
หยุดกังวลและรักระเบิด

เรื่อง ย่อหน้าคำสั่งอนุญาตให้จัดรูปแบบโค้ดในเนื้อหา (เช่น หลัง part
ที่ตรงกับ "m/\A=[a-zA-Z]\S*\s*/") เช่นใน:

=head1 คุณจำ C . ได้ไหม ?

กล่าวอีกนัยหนึ่ง ตัวจัดการการประมวลผล Pod สำหรับ "head1" จะใช้การประมวลผลแบบเดียวกัน
ถึง "คุณจำ C . ได้ไหม ?" ว่ามันจะเป็นวรรคธรรมดา (เช่น
รหัสการจัดรูปแบบเช่น "C<...>") ถูกแยกวิเคราะห์และน่าจะจัดรูปแบบอย่างเหมาะสม และ
ช่องว่างในรูปแบบของช่องว่างตามตัวอักษรและ/หรือแท็บไม่สำคัญ

·ก คำต่อคำ ย่อหน้า. บรรทัดแรกของย่อหน้านี้ต้องเป็นช่องว่างตามตัวอักษรหรือ
แท็บ และย่อหน้านี้ต้องไม่อยู่ภายใน "=begin ระบุ, ... "=จบ
ระบุ" ลำดับ เว้นแต่ "ระบุ" ขึ้นต้นด้วยเครื่องหมายทวิภาค (":") นั่นคือถ้า a
ย่อหน้าเริ่มต้นด้วยช่องว่างตามตัวอักษรหรือแท็บ แต่ is ภายใน "=begin ระบุ", ...
"=จบ ระบุ" ภูมิภาค แล้วมันเป็นย่อหน้าข้อมูล เว้นแต่ "ระบุ" เริ่มต้นด้วย
ลำไส้ใหญ่

ช่องว่าง is สำคัญในย่อหน้าคำต่อคำ (แม้ว่าในการประมวลผล แท็บจะ
น่าจะขยาย)

· หนึ่ง สามัญ ย่อหน้า. ย่อหน้าเป็นย่อหน้าธรรมดาถ้าบรรทัดแรกตรงกัน
ทั้ง "m/\A=[a-zA-Z]/" หรือ "m/\A[ \t]/", and ถ้ามันไม่ได้อยู่ใน "=begin
ระบุ, ... "=จบ ระบุ" ลำดับ เว้นแต่ "ระบุ" ขึ้นต้นด้วยโคลอน
(":").

·ก ข้อมูล ย่อหน้า. นี้เป็นวรรคที่ is ภายใน "=begin ระบุ" ... "=จบ
ระบุ"ลำดับที่"ระบุ" ทำ ไม่ เริ่มต้นด้วยเครื่องหมายทวิภาค (":") ใน
มีเหตุผลบางอย่าง ย่อหน้าข้อมูลไม่ได้เป็นส่วนหนึ่งของ Pod เลย (กล่าวคือ "ออก-
of-band") เนื่องจากไม่ได้อยู่ภายใต้การแยกวิเคราะห์ Pod ส่วนใหญ่ แต่มีการระบุไว้
ที่นี่เนื่องจาก Pod parsers จำเป็นต้องสามารถเรียกเหตุการณ์สำหรับเหตุการณ์นั้นหรือเก็บไว้ในบางส่วนได้
ก่อตัวในต้นไม้พาร์สหรืออย่างน้อยก็ parse รอบ มัน

ตัวอย่างเช่น พิจารณาย่อหน้าต่อไปนี้:

# <- นั่นคือคอลัมน์ที่ 0

=head1 ฟู

สิ่ง

$foo->bar

=ตัด

ที่นี่ "=head1 Foo" และ "=cut" เป็นย่อหน้าคำสั่งเพราะบรรทัดแรกของแต่ละบรรทัด
ตรงกับ "m/\A=[a-zA-Z]/" "[ช่องว่าง][ช่องว่าง]$foo->bar" เป็นย่อหน้าแบบคำต่อคำเพราะว่า
บรรทัดแรกเริ่มต้นด้วยอักขระช่องว่างตามตัวอักษร (และไม่มี "=begin"..."=end"
บริเวณรอบ ๆ)

The "=เริ่มต้น ระบุ" ... "=จบ ระบุ" คำสั่งหยุดย่อหน้าที่ล้อมรอบ
จากการแยกวิเคราะห์เป็นย่อหน้าธรรมดาหรือย่อหน้าต่อคำ ถ้า ระบุ ไม่ได้ขึ้นต้นด้วย
ลำไส้ใหญ่ นี้จะกล่าวถึงในรายละเอียดในส่วน "เกี่ยวกับย่อหน้าข้อมูลและ
"=begin/=end" ภูมิภาค"

รุน คำสั่ง

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

"=head1", "=head2", "=head3", "=head4"
คำสั่งนี้ระบุว่าข้อความในส่วนที่เหลือของย่อหน้าเป็นหัวเรื่อง
ข้อความนั้นอาจมีรหัสการจัดรูปแบบ ตัวอย่าง:

=head1 คุณสมบัติของออบเจ็กต์

=head3 อะไร B ทำ!

"=พอด"
คำสั่งนี้ระบุว่าย่อหน้านี้เริ่มต้นบล็อกพ็อด (ถ้าเราอยู่ใน .แล้ว
ตรงกลางของ Pod block คำสั่งนี้ไม่มีผลใดๆ ทั้งสิ้น) หากมีข้อความใดๆ
ในย่อหน้าคำสั่งนี้หลัง "=pod" จะต้องละเว้น ตัวอย่าง:

=พอด

นี่เป็นย่อหน้า Pod ธรรมดา

=pod ข้อความนี้ถูกละเว้น

"=ตัด"
คำสั่งนี้ระบุว่าบรรทัดนี้เป็นจุดสิ้นสุดของบล็อก Pod ที่เริ่มก่อนหน้านี้
หากมีข้อความหลัง "=cut" ในบรรทัด จะต้องละเว้นข้อความนั้น ตัวอย่าง:

=ตัด

=cut เอกสารสิ้นสุดที่นี่

=ตัด
# นี่คือบรรทัดแรกของข้อความโปรแกรม
sub foo { # นี่เป็นครั้งที่สอง

มันเป็นข้อผิดพลาดที่จะพยายาม เริ่มต้น Pod block ที่มีคำสั่ง "=cut" ในกรณีนั้น
ตัวประมวลผลพ็อดต้องหยุดการแยกวิเคราะห์ไฟล์อินพุต และต้องส่งคำเตือนโดยค่าเริ่มต้น

"=โอเวอร์"
คำสั่งนี้ระบุว่านี่คือจุดเริ่มต้นของขอบเขตรายการ/เยื้อง ถ้ามี
ข้อความใดๆ ที่ตามหลัง "=over" ต้องประกอบด้วยตัวเลขบวกที่ไม่ใช่ศูนย์เท่านั้น
ความหมายของตัวเลขนี้มีอธิบายไว้ใน "เกี่ยวกับ =over...=back Regions"
ส่วนด้านล่างต่อไป รหัสการจัดรูปแบบจะไม่ถูกขยาย ตัวอย่าง:

=มากกว่า3

=มากกว่า3.5

=เกิน

"=รายการ"
คำสั่งนี้ระบุว่ารายการในรายการเริ่มต้นที่นี่ รหัสการจัดรูปแบบคือ
ประมวลผล ความหมายของข้อความ (ทางเลือก) ในส่วนที่เหลือของย่อหน้านี้
มีการอธิบายในส่วน "เกี่ยวกับ =over...=back Regions" ด้านล่างเพิ่มเติม ตัวอย่าง:

=รายการ

=รายการ *

=รายการ *

=ข้อ 14

=ข้อ 3

=รายการ C<< $thing->stuff(I ) >>

=รายการ สำหรับพาเราข้ามทะเลไปลองแสร้งทำเป็น
ความผิด

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

"=กลับ"
คำสั่งนี้ระบุว่านี่คือจุดสิ้นสุดของภูมิภาคที่เริ่มโดยล่าสุด
คำสั่ง "=over" ไม่อนุญาตให้มีข้อความหลังคำสั่ง "=back"

"=เริ่มต้นชื่อรูปแบบ"
"=เริ่มต้นพารามิเตอร์ชื่อรูปแบบ"
ทำเครื่องหมายย่อหน้าต่อไปนี้ (จนกว่าจะมีการจับคู่ "=end formatname") เป็น
เพื่อการแปรรูปพิเศษบางอย่าง เว้นแต่ "formatname" จะขึ้นต้นด้วยโคลอน
ย่อหน้าที่ไม่ใช่คำสั่งที่มีอยู่คือย่อหน้าข้อมูล แต่ถ้า "ชื่อรูปแบบ" ทำ เริ่ม
ด้วยเครื่องหมายทวิภาค ย่อหน้าที่ไม่ใช่คำสั่งจะเป็นย่อหน้าธรรมดาหรือย่อหน้าข้อมูล
มีการกล่าวถึงรายละเอียดในส่วน "เกี่ยวกับย่อหน้าข้อมูลและ"=เริ่มต้น/=สิ้นสุด"
ภูมิภาค".

ขอแนะนำว่าชื่อรูปแบบตรงกับ regexp "m/\A:?[-a-zA-Z0-9_]+\z/" ทุกอย่าง
ตามช่องว่างหลังชื่อรูปแบบเป็นพารามิเตอร์ที่ . อาจใช้
ตัวจัดรูปแบบเมื่อจัดการกับภูมิภาคนี้ พารามิเตอร์นี้ต้องไม่ซ้ำกันใน
ย่อหน้า "=จบ" ผู้ดำเนินการควรคาดการณ์การขยายตัวในอนาคตในความหมาย
และไวยากรณ์ของพารามิเตอร์แรกเป็น "=begin"/"=end"/"=for"

"=สิ้นสุดชื่อรูปแบบ"
ซึ่งเป็นการสิ้นสุดของขอบเขตที่เปิดโดยภูมิภาค "=begin formatname" ที่ตรงกัน
หาก "formatname" ไม่ใช่ชื่อรูปแบบของไฟล์ที่เปิดล่าสุด "=begin formatname"
ภูมิภาคแล้วนี่คือข้อผิดพลาดและต้องสร้างข้อความแสดงข้อผิดพลาด นี้จะมีการหารือ
ในรายละเอียดในส่วน "เกี่ยวกับย่อหน้าข้อมูลและ "=เริ่มต้น/=สิ้นสุด" ภูมิภาค"

"=สำหรับข้อความชื่อรูปแบบ..."
สิ่งนี้มีความหมายเหมือนกันกับ:

=เริ่มต้นชื่อรูปแบบ

ข้อความ...

=สิ้นสุดชื่อรูปแบบ

นั่นคือมันสร้างภูมิภาคที่ประกอบด้วยย่อหน้าเดียว วรรคนั้นจะเป็น
ถือว่าเป็นย่อหน้าปกติถ้า "ชื่อรูปแบบ" ขึ้นต้นด้วย ":"; ถ้า "ชื่อรูปแบบ"
ไม่ ขึ้นต้นด้วยโคลอน จากนั้น "text..." จะเป็นย่อหน้าข้อมูล มี
ไม่มีทางใช้ "=for formatname text..." เพื่อแสดง "text..." เป็นย่อหน้าแบบคำต่อคำ

"=การเข้ารหัสชื่อการเข้ารหัส"
คำสั่งนี้ ซึ่งควรจะเกิดขึ้นก่อนในเอกสาร (อย่างน้อยก็ก่อนที่ไม่ใช่ของสหรัฐฯ-
ข้อมูล ASCII!) ประกาศว่าเอกสารนี้ถูกเข้ารหัสในการเข้ารหัส ชื่อการเข้ารหัส,
ซึ่งต้องเป็นชื่อเข้ารหัสที่เข้ารหัสรู้จัก (เข้ารหัสรายการรองรับ
การเข้ารหัสใน Encode::Supported มีประโยชน์ที่นี่) หากตัวแยกวิเคราะห์ Pod ไม่สามารถถอดรหัส
ประกาศการเข้ารหัส ควรส่งคำเตือนและอาจยกเลิกการแยกวิเคราะห์เอกสาร
โดยสิ้นเชิง

เอกสารที่มีมากกว่าหนึ่งบรรทัด "=encoding" ควรถือเป็นข้อผิดพลาด Pod
โปรเซสเซอร์อาจทนต่อสิ่งนี้อย่างเงียบ ๆ หากบรรทัด "=encoding" ที่ไม่ใช่บรรทัดแรกเป็นเพียง
ซ้ำกับบรรทัดแรก (เช่น หากมีบรรทัด "=encoding utf8" และต่อมา
อีกบรรทัด "= การเข้ารหัส utf8") แต่โปรเซสเซอร์ Pod ควรบ่นหากมี
บรรทัด "=encoding" ที่ขัดแย้งกันในเอกสารเดียวกัน (เช่น หากมี "=encoding
utf8" ในช่วงต้นของเอกสารและ "=encoding big5" ในภายหลัง) Pod processors that
รู้จัก BOMs อาจบ่นเช่นกันหากพวกเขาเห็นบรรทัด "=encoding" ที่ขัดแย้งกับ
BOM (เช่น หากเอกสารที่มี UTF-16LE BOM มีบรรทัด "=encoding shiftjis")

หากตัวประมวลผล Pod เห็นคำสั่งใด ๆ นอกเหนือจากรายการด้านบน (เช่น "=head" หรือ
"=haed1" หรือ "=stuff" หรือ "=cuttlefish" หรือ "=w123") โปรเซสเซอร์นั้นต้องจัดการโดยปริยาย
นี่เป็นข้อผิดพลาด จะต้องไม่ประมวลผลย่อหน้าที่ขึ้นต้นด้วยคำสั่งนั้นโดย
ค่าเริ่มต้นเตือนว่าเป็นข้อผิดพลาด และอาจยกเลิกการแยกวิเคราะห์ ตัวแยกวิเคราะห์ Pod อาจอนุญาตให้มีทาง
สำหรับแอปพลิเคชันเฉพาะเพื่อเพิ่มในรายการคำสั่งที่รู้จักข้างต้นและกำหนด
สำหรับแต่ละคำสั่งเพิ่มเติม ไม่ว่าโค้ดการจัดรูปแบบควรได้รับการประมวลผลหรือไม่

เวอร์ชันในอนาคตของข้อกำหนดนี้อาจเพิ่มคำสั่งเพิ่มเติม

รุน การจัดรูปแบบ รหัส

(โปรดทราบว่าในฉบับร่างก่อนหน้านี้ของเอกสารนี้และของ perlpod รหัสการจัดรูปแบบคือ
เรียกว่า "ลำดับภายใน" และอาจพบคำนี้ในเอกสารประกอบ
สำหรับตัวแยกวิเคราะห์ Pod และในข้อความแสดงข้อผิดพลาดจากตัวประมวลผล Pod)

มีสองไวยากรณ์สำหรับการจัดรูปแบบโค้ด:

· รหัสการจัดรูปแบบเริ่มต้นด้วยอักษรตัวใหญ่ (แค่ US-ASCII [AZ]) ตามด้วย a
"<" จำนวนอักขระเท่าใดก็ได้ และลงท้ายด้วย ">" ที่ตรงกับตัวแรก ตัวอย่าง:

นั่นคือสิ่งที่ฉัน คิด!

C .คืออะไร สำหรับ?

X และ C ภายใต้ระบบปฏิบัติการที่แตกต่างกัน>

· รหัสการจัดรูปแบบเริ่มต้นด้วยอักษรตัวใหญ่ (แค่ US-ASCII [AZ]) ตามด้วย two
"<" หรือมากกว่า, อักขระช่องว่างอย่างน้อยหนึ่งตัว, จำนวนอักขระเท่าใดก็ได้, หนึ่งหรือ
อักขระช่องว่างเพิ่มเติม และลงท้ายด้วยลำดับที่ตรงกันครั้งแรกตั้งแต่สองตัวขึ้นไป
">" โดยที่จำนวน ">" เท่ากับจำนวน "<" ในการเปิดนี้
รหัสการจัดรูปแบบ ตัวอย่าง:

นั่นคือสิ่งที่ฉัน<< คุณ >> คิด!

C<<< open(X, ">>thing.dat") || ตาย $! >>>

B<< $foo->bar(); >>

ด้วยไวยากรณ์นี้ อักขระช่องว่างหลัง "C<<<" และก่อน ">>>"
(หรืออักษรอะไรก็ตาม) คือ ไม่ แสดงผลได้ ไม่ได้หมายถึงช่องว่าง เป็นเพียง
ส่วนหนึ่งของรหัสการจัดรูปแบบเอง นั่นคือสิ่งเหล่านี้ล้วนมีความหมายเหมือนกัน:

ค
C<< สิ่ง >>
C<< สิ่ง >>
C<<< สิ่ง >>>
ค<<<
สิ่ง
>>>>

เป็นต้น

ในที่สุด รูปแบบวงเล็บหลายมุมก็ไม่ ไม่ เปลี่ยนการตีความของซ้อนกัน
รหัสการจัดรูปแบบ หมายความว่าตัวอย่างสี่บรรทัดต่อไปนี้เหมือนกันใน
ความหมาย:

บี =E $b>>

บี $b >>>

บี =E $b >>>

B<<< ตัวอย่าง: C<< $a E =E $b >> >>>

ในการแยกวิเคราะห์ Pod ส่วนที่ยากเป็นพิเศษคือการแยกวิเคราะห์ที่ถูกต้อง (อาจซ้อนอยู่!)
รหัสการจัดรูปแบบ ผู้ดำเนินการควรศึกษาโค้ดในรูทีน "parse_text" ใน
Pod::Parser เป็นตัวอย่างของการใช้งานที่ถูกต้อง

"ผม " -- ตัวเอียง
ดูการสนทนาสั้น ๆ ใน "การจัดรูปแบบรหัส" ใน perlpod

"NS " -- ข้อความตัวหนา
ดูการสนทนาสั้น ๆ ใน "การจัดรูปแบบรหัส" ใน perlpod

"C " -- code text
ดูการสนทนาสั้น ๆ ใน "การจัดรูปแบบรหัส" ใน perlpod

“ฟ " -- สไตล์สำหรับชื่อไฟล์
ดูการสนทนาสั้น ๆ ใน "การจัดรูปแบบรหัส" ใน perlpod

"NS " -- รายการดัชนี
ดูการสนทนาสั้น ๆ ใน "การจัดรูปแบบรหัส" ใน perlpod

โค้ดนี้ไม่ปกติที่ตัวจัดรูปแบบส่วนใหญ่ละทิ้งโค้ดนี้และ
เนื้อหา. ตัวจัดรูปแบบอื่น ๆ จะแสดงด้วยรหัสที่มองไม่เห็นซึ่งสามารถใช้ได้ใน
การสร้างดัชนีของเอกสารปัจจุบัน

"Z<>" -- โค้ดการจัดรูปแบบ null (zero-effect)
พูดคุยสั้น ๆ ใน "การจัดรูปแบบรหัส" ใน perlpod

รหัสนี้ผิดปกติคือไม่ควรมีเนื้อหา นั่นคือโปรเซสเซอร์อาจ
บ่นถ้ามันเห็น "Z “จะบ่นว่า มันฝรั่ง ข้อความ
ควรละเลย

“หลี่ " -- ไฮเปอร์ลิงก์
ไวยากรณ์ที่ซับซ้อนของรหัสนี้จะกล่าวถึงความยาวใน "การจัดรูปแบบรหัส" ใน
perlpod และรายละเอียดการใช้งานจะกล่าวถึงด้านล่างใน "เกี่ยวกับรหัส L<...>
การแยกวิเคราะห์เนื้อหาของL เป็นเรื่องยุ่งยาก ที่สำคัญต้องตรวจสอบเนื้อหาด้วย
ไม่ว่าจะดูเหมือน URL หรือต้องแยกตามตัวอักษร "|" และ/หรือ
"/" (ในลำดับที่ถูกต้อง!) เป็นต้น ก่อน รหัส E<...> ได้รับการแก้ไขแล้ว

“อี " -- การหลบหนีของตัวละคร
ดู "การจัดรูปแบบรหัส" ใน perlpod และหลายจุดใน "หมายเหตุเกี่ยวกับการใช้ Pod
โปรเซสเซอร์".

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

พิจารณา:

C<$x ? $y : $z>

ส >

ทั้งสองหมายถึงข้อความโมโนสเปซ (สไตล์ c[ode]) ที่ประกอบด้วย "$x" หนึ่งช่องว่าง "?" หนึ่ง
ช่องว่าง, ":", หนึ่งช่องว่าง, "$z" ข้อแตกต่างคืออย่างหลังด้วยรหัส S
ช่องว่างเหล่านั้นไม่ใช่ช่องว่าง "ปกติ" แต่แทนที่จะเป็นช่องว่างที่ไม่แตกหัก

หากตัวประมวลผล Pod เห็นโค้ดการจัดรูปแบบใดๆ นอกเหนือจากที่ระบุไว้ข้างต้น (เช่นใน
"N<...>" หรือ "Q<...>" เป็นต้น) โปรเซสเซอร์นั้นจะต้องถือว่าเป็นข้อผิดพลาดตามค่าเริ่มต้น อา
Pod parser อาจอนุญาตให้แอปพลิเคชันเฉพาะเพิ่มในรายการที่รู้จักด้านบน
รหัสการจัดรูปแบบ; Pod parser อาจอนุญาตให้มีวิธีกำหนด สำหรับแต่ละเพิ่มเติม
คำสั่ง ไม่ว่าจะเป็นรูปแบบการประมวลผลพิเศษบางอย่างตามที่ L<...> ทำ

เวอร์ชันในอนาคตของข้อกำหนดนี้อาจเพิ่มโค้ดการจัดรูปแบบเพิ่มเติม

บันทึกในอดีต: โปรเซสเซอร์ Pod รุ่นเก่าสองสามตัวจะไม่เห็น ">" เป็นการปิดโค้ด "C<"
ถ้า ">" นำหน้าด้วย "-" ทันที นี้เพื่อให้สิ่งนี้:

C<$foo->bar>

จะแยกวิเคราะห์เทียบเท่ากับสิ่งนี้:

C<$foo-E บาร์>

แทนที่จะเทียบเท่ากับโค้ดการจัดรูปแบบ "C" ที่มีเพียง "$foo-" แล้วตามด้วย a
"bar>" นอกโค้ดการจัดรูปแบบ "C" ปัญหานี้ได้รับการแก้ไขแล้วโดย
การเพิ่มไวยากรณ์เช่นนี้:

C<< $foo->บาร์ >>

parsers ที่สอดคล้องต้องไม่ถือว่า "->" เป็นรายการพิเศษ

รหัสการจัดรูปแบบไม่สามารถขยายย่อหน้าได้ หากเปิดรหัสในย่อหน้าเดียว
และไม่พบรหัสปิดท้ายย่อหน้านั้น Pod parser จะต้องปิดสิ่งนั้น
การจัดรูปแบบโค้ดและควรบ่น (เช่นใน "โค้ด Unterminated I ในย่อหน้าเริ่มต้น
ที่บรรทัด 123: 'วัตถุเวลาไม่ใช่...'") ดังนั้นสองย่อหน้านี้:

ผม

อย่าให้ฉันต้องพูดอีก!>

...ต้อง ไม่ แยกวิเคราะห์เป็นสองย่อหน้าเป็นตัวเอียง (โดยรหัส I เริ่มต้นในหนึ่ง
ย่อหน้าแล้วเริ่มในอีก) ย่อหน้าแรกควรสร้าง
คำเตือน แต่นอกเหนือจากนั้น โค้ดด้านบนต้องแยกวิเคราะห์เหมือนกับว่า:

ผม

อย่าให้ฉันต้องพูดอีก!E

(ในศัพท์แสง SGMLish คำสั่ง Pod ทั้งหมดเหมือนกับองค์ประกอบระดับบล็อก ในขณะที่ Pod ทั้งหมด
โค้ดการจัดรูปแบบเหมือนกับองค์ประกอบระดับอินไลน์)

หมายเหตุ : on การดำเนินการ รุน โปรเซสเซอร์

ต่อไปนี้เป็นส่วนยาวของข้อกำหนดและข้อเสนอแนะเบ็ดเตล็ดที่ต้องทำกับ
การประมวลผลพ็อด

· ตัวจัดรูปแบบพ็อดควรทนต่อบรรทัดในกลุ่มคำต่อคำที่มีความยาวเท่าใดก็ได้
ถ้านั่นหมายถึงต้องทุบให้แตก (อาจจะหลายครั้ง สำหรับสายยาวมาก) ถึง
หลีกเลี่ยงข้อความที่วิ่งออกจากด้านข้างของหน้า ตัวจัดรูปแบบพ็อดอาจเตือนสายดังกล่าว-
ทำลาย คำเตือนดังกล่าวเหมาะอย่างยิ่งสำหรับบรรทัดที่เกิน 100
ตัวอักษรยาวซึ่งมักจะไม่ได้ตั้งใจ

· Pod parsers ต้องรู้จัก ทั้งหมด ของรูปแบบบรรทัดใหม่ที่รู้จักกันดีสามรูปแบบ: CR, LF และ
ซีอาร์เอฟ ดูเพิร์ลพอร์ต

· Pod parsers ควรยอมรับบรรทัดอินพุตที่มีความยาวเท่าใดก็ได้

· เนื่องจาก Perl รู้จัก Unicode Byte Order Mark ที่จุดเริ่มต้นของไฟล์เป็นการส่งสัญญาณ
ว่าไฟล์นั้นเข้ารหัส Unicode เช่นเดียวกับใน UTF-16 (ไม่ว่าจะเป็น big-endian หรือ little-endian) หรือ
UTF-8 ตัวแยกวิเคราะห์ Pod ควรทำเช่นเดียวกัน มิฉะนั้น การเข้ารหัสอักขระควรเป็น
เข้าใจว่าเป็น UTF-8 ถ้าลำดับไบต์ไฮบิตแรกในไฟล์ดูเหมือนถูกต้อง
เป็นลำดับ UTF-8 หรืออย่างอื่นเป็น CP-1252 (เวอร์ชันก่อนหน้าของข้อกำหนดนี้
ใช้ Latin-1 แทน CP-1252)

เวอร์ชันในอนาคตของข้อกำหนดนี้อาจระบุวิธีที่ Pod สามารถยอมรับการเข้ารหัสอื่นๆ
สันนิษฐานว่าการรักษาการเข้ารหัสอื่น ๆ ในการแยกวิเคราะห์ Pod จะเหมือนกับการแยกวิเคราะห์ XML:
ไม่ว่าการเข้ารหัสที่ประกาศโดยไฟล์ Pod ใด เนื้อหาจะถูกจัดเก็บใน
หน่วยความจำเป็นอักขระ Unicode

· เครื่องหมายคำสั่ง Unicode Byte ที่รู้จักกันดีมีดังนี้: หากไฟล์ขึ้นต้นด้วย
ค่าไบต์ตามตัวอักษรสองค่า 0xFE 0xFF นี่คือ BOM สำหรับ UTF-16 บิ๊กเอนด์ ถ้าไฟล์
เริ่มต้นด้วยค่าไบต์ตามตัวอักษรสองตัว 0xFF 0xFE นี่คือ BOM สำหรับ little-endian
UTF-16. บนแพลตฟอร์ม ASCII หากไฟล์เริ่มต้นด้วยค่าไบต์ตามตัวอักษรสามค่า
0xEF 0xBB 0xBF นี่คือ BOM สำหรับ UTF-8 กลไกที่สามารถเคลื่อนย้ายไปยังแพลตฟอร์ม ECDIC
คือ:

$utf8_bom ของฉัน = "\x{FEFF}";
utf8::เข้ารหัส($utf8_bom);

· ฮิวริสติกที่ไร้เดียงสา แต่มักจะเพียงพอบนแพลตฟอร์ม ASCII สำหรับการทดสอบครั้งแรก
highbit byte-sequence ในไฟล์ BOM-less (ไม่ว่าจะเป็นในโค้ดหรือใน Pod!) เพื่อดูว่า
ลำดับนั้นถูกต้องตาม UTF-8 (RFC 2279) คือให้ตรวจสอบว่าไบต์แรกเป็น . หรือไม่
ลำดับอยู่ในช่วง 0xC2 - 0xFD and ไม่ว่าไบต์ถัดไปจะอยู่ในช่วงหรือไม่
0x80 - 0xBF. ถ้าเป็นเช่นนั้น parser อาจสรุปว่าไฟล์นี้อยู่ใน UTF-8 และ all
ลำดับไฮบิตในไฟล์ควรถือว่าเป็น UTF-8 มิฉะนั้น parser
ควรถือว่าไฟล์อยู่ใน CP-1252 (การตรวจสอบที่ดีกว่าและใช้งานได้กับEBCDIC
แพลตฟอร์มเช่นกันคือการส่งสำเนาของลำดับไปยัง utf8::ถอดรหัส() ซึ่งดำเนินการ
ตรวจสอบความถูกต้องของลำดับและส่งคืน TRUE หากเป็น UTF-8 ที่ถูกต้อง, FALSE
มิฉะนั้น. ฟังก์ชั่นนี้โหลดไว้ล่วงหน้าเสมอ เร็วเพราะเขียนด้วยภาษา C
และจะถูกเรียกอย่างมากที่สุดเพียงครั้งเดียว คุณจึงไม่จำเป็นต้องหลีกเลี่ยงจาก
ความกังวลด้านประสิทธิภาพ) ในสถานการณ์ที่ไม่น่าจะเป็นไปได้ที่ลำดับไฮบิตแรก
ในไฟล์ที่ไม่ใช่ UTF-8 จริง ๆ แล้วดูเหมือนว่าจะเป็น UTF-8 เราสามารถตอบสนองต่อ
heuristic (เช่นเดียวกับ heuristic ที่ชาญฉลาดกว่า) โดยนำหน้าบรรทัดนั้นด้วย a
บรรทัดความคิดเห็นที่มีลำดับไฮบิตที่ชัดเจน ไม่ ใช้ได้เป็น UTF-8 สาย
ประกอบด้วย "#", e-acute และไบต์ที่ไม่ใช่ highbit ใดๆ ก็เพียงพอแล้ว
สร้างการเข้ารหัสของไฟล์นี้

· ตัวประมวลผลพ็อดต้องถือว่าย่อหน้า "=for [label] [content...]" มีความหมายเหมือนกัน
สิ่งที่เป็น "=begin [label]" ย่อหน้า เนื้อหา และ "=end [label]" ย่อหน้า (ดิ
parser อาจรวมโครงสร้างทั้งสองนี้เข้าด้วยกันหรืออาจปล่อยให้ชัดเจนใน
คาดหวังว่าฟอร์แมตเตอร์จะปฏิบัติต่อพวกเขาเหมือนกัน)

· เมื่อแสดงผล Pod เป็นรูปแบบที่อนุญาตให้แสดงความคิดเห็นได้ (เช่น เกือบทุกรูปแบบอื่นๆ
มากกว่าข้อความธรรมดา) ตัวจัดรูปแบบพ็อดต้องแทรกข้อความความคิดเห็นที่ระบุชื่อและ
หมายเลขเวอร์ชัน และชื่อและหมายเลขเวอร์ชันของโมดูลใดๆ ที่อาจใช้ไปยัง
ประมวลผลพ็อด ตัวอย่างน้อยที่สุด:

%% POD::Pod2PS v3.14159 โดยใช้ POD::Parser v1.92



{\doccomm สร้างโดย Pod::Tree::RTF 3.14159 โดยใช้ Pod::Tree 1.08}

.\" Pod::Man เวอร์ชัน 3.14159 โดยใช้ POD::Parser เวอร์ชัน 1.92

ตัวจัดรูปแบบอาจแทรกความคิดเห็นเพิ่มเติม รวมถึง: วันที่เผยแพร่ของ Pod
โปรแกรมฟอร์แมตเตอร์, ที่อยู่ติดต่อสำหรับผู้เขียนของฟอร์แมตเตอร์, ปัจจุบัน
เวลา, ชื่อของไฟล์อินพุต, ตัวเลือกการจัดรูปแบบที่มีผล, เวอร์ชันของ Perl ที่ใช้,
เป็นต้น

ตัวจัดรูปแบบอาจเลือกที่จะจดบันทึกข้อผิดพลาด/คำเตือนเป็นความคิดเห็น นอกเหนือจากหรือแทน
ปล่อยเป็นอย่างอื่น (เช่นในข้อความถึง STDERR หรือ "ตาย")

· ตัวแยกวิเคราะห์พ็อด อาจ ส่งคำเตือนหรือข้อความแสดงข้อผิดพลาด ("รหัส E ที่ไม่รู้จัก E !") ถึง STDERR
(ไม่ว่าจะผ่านการพิมพ์ไปยัง STDERR หรือ "เตือน"/"ปลาคาร์พ" หรือ "ตาย"/ "บ่น")
แต่ ต้อง อนุญาตให้ระงับเอาต์พุต STDERR ดังกล่าวทั้งหมด และอนุญาตให้ใช้ตัวเลือกสำหรับ . แทน
การรายงานข้อผิดพลาด/คำเตือนด้วยวิธีอื่น ไม่ว่าจะโดยการเรียกกลับ หรือ
สังเกตข้อผิดพลาดในคุณลักษณะบางอย่างของวัตถุเอกสารหรือบางอย่างที่ไม่เป็นการรบกวน
กลไก -- หรือแม้กระทั่งโดยการผนวกส่วน "ข้อผิดพลาดของพ็อด" ต่อท้ายแบบฟอร์มแยกวิเคราะห์
ของเอกสาร

· ในกรณีของเอกสารที่ผิดปกติเป็นพิเศษ Pod parsers อาจยกเลิกการแยกวิเคราะห์ สม่ำเสมอ
ดังนั้นควรหลีกเลี่ยงการใช้ "die"ing/"croak"ing ถ้าเป็นไปได้ ห้องสมุด parser
อาจเพียงแค่ปิดไฟล์อินพุตและเพิ่มข้อความเช่น "*** การจัดรูปแบบถูกยกเลิก ***" ไปที่
สิ้นสุดเอกสารในหน่วยความจำ (บางส่วน)

· ในย่อหน้าที่เข้าใจรหัสการจัดรูปแบบ (เช่น E<...>, B<...>) (เช่น ไม่
วรรคคำต่อคำ แต่ รวมทั้ง วรรคธรรมดาและวรรคคำสั่งที่
สร้างข้อความที่แสดงผลได้ เช่น "=head1") โดยทั่วไปช่องว่างตามตัวอักษรควรเป็น
ถือว่า "ไม่มีนัยสำคัญ" โดยปริยายบทหนึ่งมีความหมายเหมือนกันทุกประการ
(ไม่ใช่ศูนย์) จำนวนช่องว่างตามตัวอักษร การขึ้นบรรทัดใหม่ตามตัวอักษร และแท็บตามตัวอักษร (ตราบเท่าที่
สิ่งนี้จะไม่สร้างบรรทัดว่าง เนื่องจากจะเป็นการสิ้นสุดย่อหน้า) ตัวแยกวิเคราะห์พ็อด
ควรเว้นวรรคตามตัวอักษรอย่างย่อในแต่ละย่อหน้าที่ประมวลผล แต่อาจให้
ตัวเลือกสำหรับการเอาชนะสิ่งนี้ (เนื่องจากงานการประมวลผลบางอย่างไม่ต้องการมัน) หรืออาจ
ปฏิบัติตามกฎพิเศษเพิ่มเติม
คาบ-ขึ้นบรรทัดใหม่)

· ตามค่าเริ่มต้น Pod parsers ไม่ควรพยายามบังคับเครื่องหมายอะพอสทรอฟี (') และอ้าง (") ลงใน
คำพูดที่ฉลาด (9's, 66's, 99's, ฯลฯ ) หรือพยายามเปลี่ยน backtick (`) เป็นอะไรก็ได้
อื่นนอกจากอักขระ backtick เดียว (แตกต่างจากอักขระอัญประกาศเปิด!) หรือ
"--" เป็นอะไรก็ได้ยกเว้นเครื่องหมายลบสองอัน พวกเขา ต้อง ไม่เคย ทำสิ่งเหล่านั้นเพื่อ
ข้อความในรหัสการจัดรูปแบบ C<...> และไม่เคย เคย เป็นข้อความในย่อหน้าต่อคำ

· เมื่อแสดงผล Pod เป็นรูปแบบที่มีเครื่องหมายยัติภังค์ (-) สองชนิด ชนิดหนึ่งที่ไม่ใช่-
ยัติภังค์หัก และอีกอันที่เป็นยัติภังค์ที่แตกได้ (เช่นใน "เชิงวัตถุ" ซึ่ง
สามารถแบ่งบรรทัดเป็น "object-", newline, "Oriented"), formatters are
แนะนำให้แปล "-" เป็นยัติภังค์ที่ไม่แยกส่วน แต่อาจใช้การวิเคราะห์พฤติกรรม
เพื่อแปลงบางส่วนเหล่านี้เป็นยัติภังค์แยก

· ตัวจัดรูปแบบ Pod ควรใช้ความพยายามอย่างเหมาะสมเพื่อป้องกันไม่ให้คำของรหัส Perl เป็น
แตกข้ามเส้น ตัวอย่างเช่น "Foo::Bar" ในบางระบบการจัดรูปแบบจะถูกมองว่าเป็น
มีสิทธิ์ถูกแบ่งบรรทัดเป็น "Foo::" ขึ้นบรรทัดใหม่ "Bar" หรือแม้แต่ "Foo::-"
ขึ้นบรรทัดใหม่ "บาร์" ควรหลีกเลี่ยงสิ่งนี้หากเป็นไปได้ โดยการปิดการใช้งานทุกบรรทัด-
แบ่งคำกลางหรือตัดคำบางคำด้วยเครื่องหมายวรรคตอนภายใน
รหัส "อย่าทำลายสิ่งนี้ข้ามบรรทัด" (ซึ่งในบางรูปแบบอาจไม่ใช่รหัสเดียว
แต่อาจเป็นเรื่องของการแทรกช่องว่าง zero-width ที่ไม่ทำลายระหว่างทุกคู่
ของตัวอักษรในคำ)

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

· ตามค่าเริ่มต้น Pod parsers ควรลบการขึ้นบรรทัดใหม่จากจุดสิ้นสุดของสามัญและคำต่อคำ
ย่อหน้าก่อนส่งต่อไปยังฟอร์แมตเตอร์ ตัวอย่างเช่นในขณะที่วรรค
ที่คุณกำลังอ่านอยู่ตอนนี้สามารถพิจารณาในแหล่ง Pod เพื่อลงท้ายด้วย (และมี) the
ขึ้นบรรทัดใหม่ ที่ลงท้ายมัน ควรประมวลผลว่าลงท้ายด้วย (และมี) the
อักขระจุดที่ลงท้ายประโยคนี้

· Pod parsers เมื่อรายงานข้อผิดพลาด ควรพยายามรายงานค่าโดยประมาณ
หมายเลขบรรทัด ("E ซ้อนกัน <> ในวรรค #52 ใกล้บรรทัด 633 ของ Thing/Foo.pm!") แทน
ของการสังเกตหมายเลขย่อหน้าเท่านั้น ("E ซ้อนกัน <> ในย่อหน้า #52 ของ
Thing/Foo.pm!") ในกรณีที่เป็นปัญหา อย่างน้อย เลขย่อหน้าควรเป็น
พร้อมด้วยข้อความที่ตัดตอนมาจากย่อหน้า ("ซ้อน E<> ในย่อหน้า #52 ของ
Thing/Foo.pm ซึ่งเริ่มต้น 'อ่าน/เขียน accessor สำหรับ C
คุณลักษณะ...'").

· Pod parsers เมื่อประมวลผลชุดของย่อหน้าต่อคำทีละย่อหน้าควร
พิจารณาว่าเป็นย่อหน้าขนาดใหญ่หนึ่งย่อหน้าที่มีบรรทัดว่าง
นั่นคือ สองบรรทัดนี้ซึ่งมีบรรทัดว่างระหว่างพวกเขา:

ใช้ฟู;

พิมพ์ Foo->VERSION

ควรรวมเป็นหนึ่งย่อหน้า ("\tuse Foo;\n\n\tprint Foo->VERSION") ก่อน
ถูกส่งไปยังฟอร์แมตเตอร์หรือโปรเซสเซอร์อื่น Parsers อาจอนุญาตให้ใช้ตัวเลือก
เพื่อเอาชนะสิ่งนี้

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

· ตัวจัดรูปแบบพ็อด หากเป็นไปได้ ขอแนะนำให้หลีกเลี่ยงการแยกคำต่อคำแบบสั้น
ย่อหน้า (ใต้สิบสองบรรทัด พูด) ข้ามหน้า

· ตัวแยกวิเคราะห์พ็อดต้องปฏิบัติต่อบรรทัดที่มีเพียงช่องว่างและ/หรือแท็บเป็น "บรรทัดว่าง"
เช่น แยกย่อหน้า ( parsers ที่เก่ากว่าบางคนรู้จักเพียงสองตัวที่อยู่ติดกัน
การขึ้นบรรทัดใหม่เป็น "บรรทัดว่าง" แต่จะไม่รู้จักการขึ้นบรรทัดใหม่ การเว้นวรรค และการขึ้นบรรทัดใหม่
เป็นบรรทัดว่าง นี่เป็นพฤติกรรมที่ไม่เป็นไปตามข้อกำหนด)

· ผู้เขียนฟอร์แมตเตอร์/โปรเซสเซอร์ Pod ควรพยายามอย่างเต็มที่ที่จะหลีกเลี่ยงการเขียน
Pod parser ของตัวเอง CPAN มีอยู่แล้วหลายตัวพร้อมอินเทอร์เฟซที่หลากหลาย
สไตล์ -- และหนึ่งในนั้นคือ Pod::Parser ที่มาพร้อมกับ Perl เวอร์ชันทันสมัย

· อักขระในเอกสาร Pod อาจถ่ายทอดเป็นตัวอักษรหรือตามตัวเลขใน E
รหัสหรือโดยเทียบเท่าช่วยในการจำเช่นในE ซึ่งเทียบเท่ากับ
อี<233>. ตัวเลขเป็นค่า Latin1/Unicode แม้กระทั่งบนแพลตฟอร์ม EBCDIC

เมื่อพูดถึงตัวอักษรโดยใช้ E รหัสตัวเลข ตัวเลขในช่วง 32-126
อ้างถึงอักขระ US-ASCII ที่รู้จักกันดี (ซึ่งกำหนดโดย Unicode ด้วย
ความหมายเดียวกัน) ซึ่งตัวจัดรูปแบบ Pod ทั้งหมดต้องแสดงตามความเป็นจริง ตัวละครที่มี E<>
ตัวเลขอยู่ในช่วง 0-31 และไม่ควรใช้ 127-159 (ไม่ใช่ตัวอักษร
หรือเป็น E รหัส) ยกเว้นลำดับไบต์ตามตัวอักษรสำหรับการขึ้นบรรทัดใหม่ (ASCII 13
ASCII 13 10 หรือ ASCII 10) และแท็บ (ASCII 9)

ตัวเลขในช่วง 160-255 หมายถึงอักขระละติน-1 (ยังกำหนดไว้โดย
Unicode ที่มีความหมายเหมือนกัน) ตัวเลขที่สูงกว่า 255 ควรเข้าใจเพื่ออ้างถึง
อักขระ Unicode

· ขอเตือนว่าตัวจัดรูปแบบบางตัวไม่สามารถแสดงอักขระภายนอก 32-126 ได้อย่างน่าเชื่อถือ และ
หลายคนสามารถรองรับ 32-126 และ 160-255 แต่ไม่มีอะไรเกิน 255

· นอกจากคำว่า "E ." ที่รู้จักกันดี " และ "เ " รหัสสำหรับน้อยกว่าและมากกว่า Pod
parsers ต้องเข้าใจ "E " สำหรับ "/" (โซลิดัส สแลช) และ "E " สำหรับ "|"
(แถบแนวตั้ง, ท่อ). Pod parsers ควรเข้าใจ "E " และ
“อี " เป็นรหัสดั้งเดิมสำหรับอักขระ 171 และ 187 กล่าวคือ "ชี้ไปทางซ้ายสองครั้ง
เครื่องหมายคำพูดมุม" = "กิลเลเมตชี้ซ้าย" และ "มุมคู่ชี้ขวา
เครื่องหมายคำพูด" = "กิลล์ชี้ขวา" (สิ่งเหล่านี้ดูเหมือน "<<" และ ">>" เล็กน้อย
และควรแสดงด้วยโค้ด HTML/XHTML "E " และ
“อี ".)

· Pod parsers ควรเข้าใจ "E ." ทั้งหมด " รหัสตามที่กำหนดไว้ในเอนทิตี
ประกาศในข้อกำหนด XHTML ล่าสุดที่ "www.W3.org" Pod parsers ต้อง
เข้าใจอย่างน้อยเอนทิตีที่กำหนดอักขระในช่วง 160-255
(ละติน-1). Pod parsers เมื่อต้องเผชิญกับ "E ." ที่ไม่รู้จักระบุ>" รหัสไม่ควร
เพียงแค่แทนที่ด้วย nullstring (โดยค่าเริ่มต้น อย่างน้อย) แต่อาจส่งผ่านเป็น a
สตริงที่ประกอบด้วยตัวอักษร E น้อยกว่า ระบุ, มากกว่า.
หรือผู้แยกวิเคราะห์ Pod อาจเสนอทางเลือกอื่นในการประมวลผลที่ไม่รู้จัก
“อีระบุ>" โดยการเริ่มเหตุการณ์โดยเฉพาะอย่างยิ่งสำหรับรหัสดังกล่าว หรือโดยการเพิ่ม a
ชนิดโหนดพิเศษในแผนผังเอกสารในหน่วยความจำ เช่น "Eระบุ>" อาจมี
ความหมายพิเศษของโปรเซสเซอร์บางตัวหรือโปรเซสเซอร์บางตัวอาจเลือกที่จะเพิ่มลงใน a
รายงานข้อผิดพลาดพิเศษ

· Pod parsers จะต้องรองรับโค้ด XHTML "E " สำหรับอักขระ 34 (เครื่องหมายคำพูดคู่
"), "เ " สำหรับอักขระ 38 (เครื่องหมาย & &) และ "E " สำหรับอักขระ 39
(เครื่องหมายอัญประกาศเดี่ยว, ').

· โปรดทราบว่าในทุกกรณีของ "E ", อะไรก็ตาม (ไม่ว่าจะเป็น htmlname หรือตัวเลขใน
ฐานใดๆ) ต้องประกอบด้วยอักขระที่เป็นตัวอักษรและตัวเลขเท่านั้น นั่นคือ อะไรก็ตาม ต้องดู
"ม/\A\w+\z/". ดังนั้น "E< 0 1 2 3 >" ไม่ถูกต้อง เนื่องจากมีช่องว่างซึ่งไม่ใช่
ตัวอักษรและตัวเลข นี้น่าจะไม่ได้ จำเป็นต้อง การดูแลเป็นพิเศษโดย Pod
โปรเซสเซอร์; " 0 1 2 3 " ดูไม่เหมือนตัวเลขในฐานใดๆ ก็น่าจะประมาณนี้
ให้ค้นหาในตารางชื่อเหมือน HTML เนื่องจากไม่มี (และไม่สามารถ) ได้
เอนทิตีคล้าย HTML ที่เรียกว่า " 0 1 2 3 " จะถือเป็นข้อผิดพลาด อย่างไรก็ตาม Pod
โปรเซสเซอร์อาจใช้ "E< 0 1 2 3 >" หรือ "E " เช่น วากยสัมพันธ์ ไม่ถูกต้อง,
อาจได้รับข้อความแสดงข้อผิดพลาดที่แตกต่างจากข้อความแสดงข้อผิดพลาด (หรือคำเตือน หรือ
เหตุการณ์) ที่สร้างขึ้นโดยชื่อ html ที่ไม่รู้จัก (แต่ถูกต้องตามหลักวิชา) เช่นเดียวกับใน
“อี " [sic] อย่างไรก็ตาม ตัวแยกวิเคราะห์ Pod ไม่จำเป็นต้องสร้างความแตกต่างนี้

· โปรดทราบว่า E ต้อง ไม่ ถูกตีความว่าเป็นเพียงแค่ "codepoint จำนวน ใน
ชุดอักขระปัจจุบัน/ดั้งเดิม" มักจะหมายถึง "อักขระที่แสดงโดย
โค้ดพอยท์ จำนวน ใน Unicode" (นี่เหมือนกับความหมายของ &#จำนวน, ใน
XML)

ซึ่งอาจต้องใช้ตัวจัดรูปแบบจำนวนมากเพื่อให้มีการแมปตารางจาก Unicode ที่รักษาได้
codepoints (เช่น "\xE9" สำหรับอักขระ e-acute) ไปยังลำดับหลีกหรือ
รหัสที่จำเป็นสำหรับการถ่ายทอดลำดับดังกล่าวในรูปแบบผลลัพธ์เป้าหมาย ตัวแปลง
ถึง *roff จะ เช่น รู้ว่า "\xE9" (ไม่ว่าจะถ่ายทอดตามตัวอักษรหรือผ่าน a
ลำดับ E<...>) ให้แสดงเป็น "e\\*'" ในทำนองเดียวกันโปรแกรมแสดง Pod in
หน้าต่างแอปพลิเคชัน Mac OS คงจะจำเป็นต้องรู้ว่า "\xE9" จับคู่กับ
codepoint 142 ในการเข้ารหัส MacRoman ซึ่ง (ในขณะที่เขียน) เป็นโปรแกรมดั้งเดิมสำหรับ Mac OS
Unicode2 นั้นการแมปแบบใดก็ตามสันนิษฐานว่าสามารถใช้ได้ทั่วไปแล้ว
รูปแบบเอาต์พุต (การแมปดังกล่าวอาจไม่สมบูรณ์! ไม่คาดว่าจะเป็นผู้ดำเนินการ
โน้มตัวไปข้างหลังเพื่อพยายามแสดงพยางค์ของเชอโรกี อักษรรูนอีทรัสคัน
สัญลักษณ์ดนตรีไบแซนไทน์ หรือสิ่งแปลกประหลาดอื่นๆ ที่ Unicode สามารถเข้ารหัสได้)
และหากเอกสาร Pod ใช้อักขระที่ไม่พบในการแมปดังกล่าว ตัวจัดรูปแบบ
ควรพิจารณาว่าเป็นอักขระที่ไม่สามารถแสดงผลได้

· น่าแปลกที่ผู้ดำเนินการของ Pod formatter ไม่สามารถหา pre-
การแมปตารางที่มีอยู่จากอักขระ Unicode เพื่อหลีกหนีในรูปแบบเป้าหมาย (เช่น
ตารางที่เหมาะสมของอักขระ Unicode เพื่อ *roff หนี) จำเป็นต้องสร้าง
ตารางดังกล่าว หากคุณอยู่ในสถานการณ์นี้คุณควรเริ่มด้วยตัวอักษร
ในช่วง 0x00A0 - 0x00FF ซึ่งส่วนใหญ่เป็นอักขระเน้นเสียงที่ใช้อย่างหนัก
จากนั้นดำเนินการ (ตามที่ความอดทนอนุญาตและความพิถีพิถันบังคับ) ผ่านตัวอักษร
ที่กลุ่มมาตรฐาน (X)HTML เห็นว่ามีความสำคัญมากพอที่จะช่วยในการจำ
มีประกาศไว้ในข้อกำหนด (X)HTML ที่เว็บไซต์ www.W3.org ณ เวลาที่
การเขียน (กันยายน 2001) ไฟล์ประกาศเอนทิตีล่าสุดคือ:

http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent
http://www.w3.org/TR/xhtml1/DTD/xhtml-special.ent
http://www.w3.org/TR/xhtml1/DTD/xhtml-symbol.ent

จากนั้นคุณสามารถดำเนินการผ่านอักขระ Unicode ที่โดดเด่นที่เหลืออยู่ในช่วง
0x2000-0x204D (ดูตารางอักขระได้ที่ www.unicode.org) และอื่นๆ
โดนใจคุณ ตัวอย่างเช่น ใน xhtml- symbol.ent, มีรายการ:



ในขณะที่การทำแผนที่ "infin" กับตัวละคร "\x{221E}" จะเป็น (หวังว่า)
จัดการโดย Pod parser แล้ว การมีอักขระในไฟล์นี้หมายถึง
ที่มีความสำคัญพอสมควรที่จะรวมไว้ในตารางของตัวจัดรูปแบบที่แมปจาก
อักขระ Unicode ที่โดดเด่นสำหรับรหัสที่จำเป็นสำหรับการแสดงผล ดังนั้นสำหรับ
ตัวอย่างเช่น การแมป Unicode-to-*roff สิ่งนี้ควรค่าแก่รายการ:

"\x{221E}" => '\(ใน',

หวังเป็นอย่างยิ่งว่าในอนาคตจะเพิ่มจำนวนรูปแบบ (และตัวจัดรูปแบบ)
จะสนับสนุนอักขระ Unicode โดยตรง (ตามที่ (X)HTML ทำกับ "∞", "∞",
หรือ "∞") ลดความจำเป็นในการแมป Unicode-to-my_escapes.

· ขึ้นอยู่กับตัวจัดรูปแบบ Pod แต่ละคนในการแสดงวิจารณญาณที่ดีเมื่อเผชิญหน้ากับ
อักขระที่ไม่สามารถแสดงผลได้ (ซึ่งแตกต่างจาก E . ที่ไม่รู้จัก ลำดับที่
parser ไม่สามารถแก้ไขอะไรได้ แสดงผลได้หรือไม่) เป็นแนวปฏิบัติที่ดีในการทำแผนที่
ตัวอักษรละตินที่มีเครื่องหมายกำกับเสียง (เช่น "E "/"E<233>") ไปยังที่สอดคล้องกัน
ตัวอักษร US-ASCII ที่ไม่เน้นเสียง (เช่น อักขระธรรมดา 101, "e") แต่ชัดเจนว่านี่คือ
มักไม่สามารถทำได้ และอักขระที่ไม่สามารถแสดงผลได้อาจแสดงเป็น "?" หรือ
ชอบ. ในการพยายามใช้ทางเลือกที่สมเหตุสมผล (ตั้งแต่ E<233> ถึง "e") ตัวจัดรูปแบบพ็อดอาจใช้
ตาราง %Latin1Code_to_fallback ใน Pod::Escapes หรือ Text::Unidecode หากมี

ตัวอย่างเช่น ข้อความพ็อดนี้:

เวทมนตร์จะเปิดใช้งานหากคุณตั้งค่า C<$Currency> เป็น 'E '.

อาจแสดงผลเป็น: "เวทมนตร์จะเปิดใช้งานหากคุณตั้งค่า $Currency เป็น '?'" หรือว่า "เวทมนตร์คือ
เปิดใช้งานหากคุณตั้งค่า $Currency เป็น '[ยูโร]'" หรือเป็น "เวทมนตร์จะเปิดใช้งานหากคุณตั้งค่า
$Currency เป็น '[x20AC]' เป็นต้น

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

· E<...> อาจปรากฏขึ้นอย่างอิสระในโค้ดการจัดรูปแบบใดๆ (นอกเหนือจากใน E<...> อื่นหรือใน an
ซี<>). นั่นคือ “X 1,000,000 Solution>" ถูกต้อง เช่นเดียวกับ "L
อี 1,000,000 โซลูชั่น|ล้าน::ยูโร>".

· ตัวจัดรูปแบบพ็อดบางตัวส่งออกไปยังรูปแบบที่ใช้ช่องว่างที่ไม่แตกเป็น an
อักขระแต่ละตัว (ซึ่งฉันจะเรียกว่า "NBSP") และตัวอื่น ๆ ที่ส่งออกไปยังรูปแบบนั้น
ใช้ช่องว่างที่ไม่ทำลายเช่นเดียวกับช่องว่างที่ห่อหุ้มด้วย "อย่าทำลายสิ่งนี้
บรรทัด" โปรดทราบว่าที่ระดับของ Pod รหัสทั้งสองแบบสามารถเกิดขึ้นได้: Pod can
มีอักขระ NBSP (ไม่ว่าจะเป็นตัวอักษรหรือเป็น "E<160>" หรือ "E " รหัส);
และ Pod สามารถมี "S baz>" รหัสโดยที่ "ช่องว่างเพียง" (อักขระ 32) ใน
รหัสดังกล่าวถูกนำมาใช้เพื่อแสดงช่องว่างที่ไม่แตกหัก Pod parsers ควรพิจารณา
สนับสนุนการแยกวิเคราะห์ทางเลือกของ "S baz>" ราวกับว่ามันเป็น
"ฟูกบรผมกบรbaz" และไปอีกทางหนึ่ง การแยกวิเคราะห์กลุ่มของ
คำที่เชื่อมต่อโดย NBSP ราวกับว่าแต่ละกลุ่มอยู่ในรหัส S<...> ดังนั้นตัวจัดรูปแบบอาจ
ใช้การแสดงที่แมปกับสิ่งที่รูปแบบเอาต์พุตต้องการได้ดีที่สุด

· โปรเซสเซอร์บางตัวอาจพบว่าโค้ด "S<...>" นั้นง่ายต่อการติดตั้งโดยการแทนที่
แต่ละช่องว่างใน parse tree ใต้เนื้อหาของ S โดยมี NBSP แต่หมายเหตุ: the
ควรใช้ทดแทน ไม่ ไปยังช่องว่างใน ทั้งหมด ข้อความ แต่ เพียง ไปยังช่องว่างใน พิมพ์ได้
ข้อความ. (ความแตกต่างนี้อาจเห็นหรือไม่ปรากฏชัดในแบบจำลองต้นไม้/เหตุการณ์โดยเฉพาะ
ดำเนินการโดย Pod parser) ตัวอย่างเช่น พิจารณากรณีที่ผิดปกตินี้:

ส >

ซึ่งหมายความว่าต้องไม่เว้นวรรคตรงกลางข้อความลิงก์ที่มองเห็นได้
ข้ามบรรทัด กล่าวอีกนัยหนึ่งก็เหมือนกับสิ่งนี้:

L<"AutoloadedE<160>Functions"/Autoloaded Functions>

อย่างไรก็ตาม การแทนที่ space-to-NBSP ที่ไม่ถูกต้องอาจสร้างบางสิ่งได้ (อย่างไม่ถูกต้อง)
เทียบเท่ากับสิ่งนี้:

L<"AutoloadedE<160>Functions"/AutoloadedE<160>Functions>

...ซึ่งแทบจะใช้ไม่ได้กับไฮเปอร์ลิงก์อย่างแน่นอน (สมมติว่า
ตัวจัดรูปแบบส่งออกรูปแบบที่สนับสนุนไฮเปอร์เท็กซ์)

ตัวจัดรูปแบบอาจเลือกที่จะไม่สนับสนุนโค้ดรูปแบบ S โดยเฉพาะในกรณีที่
รูปแบบเอาต์พุตไม่มีอักขระ / รหัส NBSP และไม่มีรหัสสำหรับ "อย่าทำลายสิ่งนี้
สิ่งของข้ามเส้น".

· นอกจากอักขระ NBSP ที่กล่าวถึงข้างต้นแล้ว ผู้ดำเนินการยังได้รับการเตือนถึงการมีอยู่
ของอักขระ "พิเศษ" อื่น ๆ ในภาษาละติน-1 อักขระ "ยัติภังค์อ่อน" หรือที่รู้จัก
เป็น "ยัติภังค์ตามดุลยพินิจ" เช่น "E<173>" = "E<0xAD>" = "E "). อักขระนี้
แสดงจุดยัติภังค์ทางเลือก กล่าวคือ ปกติจะแสดงเป็นไม่มีอะไร แต่
อาจแสดงผลเป็น "-" หากตัวจัดรูปแบบแบ่งคำ ณ จุดนั้น ตัวจัดรูปแบบพ็อด
ควรทำอย่างใดอย่างหนึ่งต่อไปนี้ตามความเหมาะสม 1) แสดงผลด้วยรหัสด้วย
ความหมายเดียวกัน (เช่น "\-" ใน RTF) 2) ส่งผ่านโดยคาดหวังว่า
ตัวจัดรูปแบบเข้าใจอักขระนี้เช่นนั้น หรือ 3) ลบออก

ตัวอย่างเช่น:

ซิกอี หนังบู๊
manuE สคริปต์
จาร์คอี โก เฮียอี แท nieE มิ

สิ่งเหล่านี้ส่งสัญญาณไปยังฟอร์แมตเตอร์ว่าหากเป็นการใส่ยัติภังค์ "sigaction" หรือ "manuscript"
ก็ควรทำเป็น “ซิก-[การแบ่งบรรทัด]การกระทำ" หรือ "แมนยู-[การแบ่งบรรทัด]สคริปต์" (และ if
มันไม่ใส่ยัติภังค์ แล้ว "E " ไม่ปรากฏขึ้นเลย) และถ้าเป็นเพื่อ
ยัติภังค์ "Jarkko" และ/หรือ "Hietaniemi" ทำได้เฉพาะจุดที่มี
เอ "เ "รหัส

ในทางปฏิบัติคาดว่าตัวละครนี้จะไม่ได้ใช้บ่อยแต่
ตัวจัดรูปแบบควรสนับสนุนหรือลบออก

· หากคุณคิดว่าคุณต้องการเพิ่มคำสั่งใหม่ให้กับ Pod (เช่น พูดว่า "=biblio"
คำสั่ง) พิจารณาว่าคุณจะได้รับผลเช่นเดียวกันกับ a for หรือ start/end
ลำดับ: "=for biblio ... " หรือ "=begin biblio" ... "=end biblio" โปรเซสเซอร์ Pod ที่
ไม่เข้าใจ "=for biblio" ฯลฯ จะเพิกเฉย ในขณะที่พวกเขาอาจบ่น
เสียงดังหากพวกเขาเห็น "=biblio"

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

เกี่ยวกับเรา ล<...> รหัส

อย่างที่คุณบอกได้จากการชำเลืองมองที่ perlpod รหัส L<...> นั้นซับซ้อนที่สุดของ Pod
รหัสการจัดรูปแบบ ประเด็นด้านล่างหวังว่าจะชี้แจงความหมายและวิธี
โปรเซสเซอร์ควรจัดการกับมัน

· ในการแยกวิเคราะห์โค้ด L<...> ตัวแยกวิเคราะห์ Pod ต้องแยกแยะแอตทริบิวต์อย่างน้อยสี่อย่าง:

ครั้งแรก:
ลิงค์-ข้อความ. หากไม่มี ต้องเป็น "undef" (เช่น ใน "L
Functions|perlfunc>" ข้อความลิงก์คือ "ฟังก์ชัน Perl" ใน "L " และ
แม้แต่ "L<|Time::HiRes>" ก็ไม่มีข้อความลิงก์ โปรดทราบว่าข้อความลิงก์อาจมี
การจัดรูปแบบ)

ประการที่สอง:
ข้อความลิงก์ที่อนุมานได้ กล่าวคือ หากไม่มีข้อความลิงก์จริง นี่
เป็นข้อความที่เราจะอนุมานแทน (เช่น สำหรับ "L ", ที่
ข้อความลิงก์ที่อนุมานคือ "Getopt::Std")

ที่สาม:
ชื่อหรือ URL หรือ "undef" ถ้าไม่มี (เช่น ใน "L ", ที่
ชื่อ (บางครั้งเรียกว่าหน้า) คือ "perlfunc" ใน "หลี่ ", ชื่อ
คือ "undef")

ที่สี่:
ส่วน (AKA "รายการ" ใน perlpods ที่เก่ากว่า) หรือ "undef" หากไม่มี เช่น ใน
“หลี่ , "DESCRIPTION" คือส่วน (โปรดทราบว่านี่คือ
ไม่เหมือนกับส่วน manpage เช่น "5" ใน "man 5 crontab" "มาตราฟู"
ในความหมาย Pod หมายถึงส่วนของข้อความที่นำโดยหัวเรื่องหรือ
รายการที่มีข้อความ "Foo")

Pod parsers อาจทราบคุณลักษณะเพิ่มเติม ได้แก่ :

ห้า:
แฟล็กสำหรับว่าข้อ 3 (ถ้ามี) เป็น URL หรือไม่ (เช่น "http://lists.perl.org" เป็น),
ในกรณีนี้ไม่ควรมีแอตทริบิวต์ของส่วน ชื่อพ็อด (เช่น "perldoc" และ
"Getopt::Std" คือ); หรืออาจเป็นชื่อหน้าคน (เช่น "crontab(5)") คือ)

หก:
เนื้อหาดิบดั้งเดิมของ L<...> ก่อนที่ข้อความจะแบ่งออกเป็น "|", "/" ฯลฯ และก่อนหน้านั้น
รหัส E<...> ถูกขยาย

(ด้านบนมีหมายเลขสำหรับการอ้างอิงที่กระชับด้านล่างเท่านั้น ไม่ใช่ข้อกำหนด
ว่าสิ่งเหล่านี้ถูกส่งผ่านเป็นรายการหรืออาร์เรย์จริง)

ตัวอย่างเช่น:

หลี่
=> undef, # ข้อความลิงก์
"Foo::Bar", # อาจเป็นข้อความลิงก์ที่อนุมานได้
"ฟู::บาร์", #ชื่อ
undef, # ส่วน
'พ็อด' #ลิงก์ประเภทไหน
"Foo::Bar" # เนื้อหาต้นฉบับ

หลี่
=> "ส่วนของ Perlport ใน NL", # ลิงก์ข้อความ
"ส่วนของ Perlport ใน NL", # อาจเป็นข้อความลิงก์ที่อนุมานได้
"perlport", # ชื่อ
"ขึ้นบรรทัดใหม่", # ส่วน
'พ็อด' #ลิงก์ประเภทไหน
"ส่วนของ Perlport ใน NL's | perlport/Newlines"
# เนื้อหาต้นฉบับ

หลี่
=> undef, # ข้อความลิงก์
'"Newlines" ใน perlport', # อาจเป็นข้อความลิงก์ที่อนุมานได้
"perlport", # ชื่อ
"ขึ้นบรรทัดใหม่", # ส่วน
'พ็อด' #ลิงก์ประเภทไหน
"perlport/Newlines" # เนื้อหาต้นฉบับ

L<crontab(5)/"คำอธิบาย">
=> undef, # ข้อความลิงก์
'"คำอธิบาย" ใน crontab(5)', # อาจเป็นข้อความลิงก์ที่อนุมานได้
"crontab(5)", # ชื่อ
"คำอธิบาย", # ส่วน
'ผู้ชาย' #ลิงก์ประเภทไหน
'crontab(5)/"DESCRIPTION"' # เนื้อหาต้นฉบับ

หลี่
=> undef, # ข้อความลิงก์
'"แอตทริบิวต์ของวัตถุ"', # ข้อความลิงก์ที่อนุมานได้
undef #ชื่อ
"แอตทริบิวต์ของวัตถุ", # ส่วน
'พ็อด' #ลิงก์ประเภทไหน
"/Object Attributes" # เนื้อหาต้นฉบับ

L<http://www.perl.org/>
=> undef, # ข้อความลิงก์
"http://www.perl.org/", # อาจเป็นข้อความลิงก์ที่อนุมานได้
"http://www.perl.org/", # ชื่อ
undef, # ส่วน
'url', # ลิงค์ประเภทไหน
"http://www.perl.org/" # เนื้อหาต้นฉบับ

หลี่http://www.perl.org/>
=> "Perl.org", # ข้อความลิงก์
"http://www.perl.org/", # อาจเป็นข้อความลิงก์ที่อนุมานได้
"http://www.perl.org/", # ชื่อ
undef, # ส่วน
'url', # ลิงค์ประเภทไหน
"Perl.org|http://www.perl.org/" # เนื้อหาต้นฉบับ

โปรดทราบว่าคุณสามารถแยกความแตกต่างระหว่างลิงก์ URL กับสิ่งอื่นด้วยข้อเท็จจริงที่ว่ามันตรงกัน
"m/\A\w+:[^:\s]\S*\z/". ดังนั้น "หลี่http://www.perl.com>" เป็น URL แต่ "L "
ไม่ใช่

· ในกรณีของรหัส L<...> ที่ไม่มี "text|" ส่วนหนึ่งในพวกเขา ฟอร์แมตเตอร์ที่เก่ากว่าได้แสดง
รูปแบบที่ดีในการแสดงลิงก์หรือการอ้างอิงโยงจริงๆ ตัวอย่างเช่น,
L<crontab(5)> จะแสดงเป็น "the crontab(5) manpage" หรือ "ใน crontab(5) หน้าจัดการ"
หรือเพียงแค่ "crontab(พ.ศ. 5) ".

ตัวประมวลผล Pod ต้องปฏิบัติต่อ "text|"-less links ดังนี้:

หลี่ => หลี่
หลี่ => L<"section"|/section>
หลี่ => L<"section" ในชื่อ|ชื่อ/ส่วน>

· โปรดทราบว่าชื่อส่วนอาจมีมาร์กอัป กล่าวคือถ้าส่วนเริ่มต้นด้วย:

=head2 เกี่ยวกับตัวดำเนินการ C<-M>

หรือด้วย:

=รายการ เกี่ยวกับตัวดำเนินการ C<-M>

จากนั้นลิงก์ไปยังมันจะมีลักษณะดังนี้:

หลี่ โอเปอเรเตอร์>

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

เกี่ยวกับ -M
โอเปอเรเตอร์

...

เกี่ยวกับ -M
โอเปอเรเตอร์" ใน somedoc

· perlpod รุ่นก่อนหน้าโดดเด่น "L " ลิงก์จาก
“หลี่ " ลิงก์ (และเป้าหมาย) สิ่งเหล่านี้ถูกรวมเข้าด้วยกันทางวากยสัมพันธ์และ
ความหมายในข้อกำหนดปัจจุบันและ ส่วน สามารถอ้างถึง "= headn
คำสั่งหัวข้อเนื้อหา" หรือคำสั่ง "=เนื้อหารายการ" ข้อกำหนดนี้
ไม่ได้ระบุพฤติกรรมที่ควรจะเป็นในกรณีที่เอกสารที่กำหนดมี
หลายอย่างก็ดูจะเหมือนกันหมด ส่วน ตัวระบุ (เช่น ใน HTML
หลายสิ่งหลายอย่างเหมือนกันหมด ชื่อผู้ประกาศข่าว ในชื่อผู้ประกาศข่าว">...
องค์ประกอบ) ที่ซึ่งโปรเซสเซอร์ Pod สามารถควบคุมพฤติกรรมนี้ได้ พวกเขาควรใช้ตัวแรก
สมอดังกล่าว นั่นก็คือ “หลี่ " หมายถึง เป็นครั้งแรก ส่วน "บาร์" ใน Foo

แต่สำหรับโปรเซสเซอร์/รูปแบบบางตัว สิ่งนี้ไม่สามารถควบคุมได้ง่าย เช่นเดียวกับ HTML
ตัวอย่าง พฤติกรรมของพหุความคลุมเครือชื่อผู้ประกาศข่าว">...คือที่สุด
เหลือเพียงเบราว์เซอร์ที่จะตัดสินใจได้อย่างง่ายดาย

·ใน "L " รหัสข้อความอาจมีรหัสการจัดรูปแบบสำหรับการจัดรูปแบบหรือสำหรับ
E<...> หนีเช่นใน:

หลี่ ของ>|...>

สำหรับโค้ด "L<...>" ที่ไม่มี "name|" อาจมีเฉพาะรหัส "E<...>" และ "Z<>" เท่านั้น
นั่นคือผู้เขียนไม่ควรใช้ ""L >"".

อย่างไรก็ตาม โปรดทราบว่าโค้ดการจัดรูปแบบและ Z<> สามารถเกิดขึ้นได้ในทุกส่วนของ an
L<...> (เช่น ใน ชื่อ, ส่วน, ข้อความและ URL).

ผู้เขียนต้องไม่ซ้อนรหัส L<...> ตัวอย่างเช่น "L หน้าคน>" ควร
ถือเป็นข้อผิดพลาด

· โปรดทราบว่าผู้เขียน Pod อาจใช้รหัสการจัดรูปแบบภายในส่วน "ข้อความ" ของ
“หลี่ " (และอื่นๆ สำหรับ L ).

กล่าวอีกนัยหนึ่งสิ่งนี้ถูกต้อง:

ไปอ่าน L |perlvar/"$.">

รูปแบบเอาต์พุตบางรูปแบบที่อนุญาตให้แสดงโค้ด "L<...>" เป็นไฮเปอร์เท็กซ์ อาจไม่
อนุญาตให้จัดรูปแบบข้อความลิงก์ ในกรณีนี้ ตัวจัดรูปแบบจะต้องเพิกเฉย
การจัดรูปแบบนั้น

· ในขณะที่เขียน "L " ค่าเป็นสองประเภท: ชื่อของหน้า Pod อย่างใดอย่างหนึ่ง
เช่น "หลิว " (ซึ่งอาจเป็นโมดูลหรือโปรแกรม Perl จริงใน @INC / PATH
ไดเร็กทอรีหรือไฟล์ .pod ในตำแหน่งเหล่านั้น); หรือชื่อหน้าคนยูนิกซ์เช่น
“หลี่crontab(5)>" ตามทฤษฎีแล้ว "หลี่" " ไม่ชัดเจนระหว่างหน้า Pod ที่เรียกว่า
"chmod" หรือหน้า man ของ Unix "chmod" (ในส่วน man-section) อย่างไรก็ตาม
การปรากฏตัวของสตริงในวงเล็บเช่นเดียวกับใน "crontab(5)" ก็เพียงพอแล้วที่จะส่งสัญญาณว่า
กำลังถูกกล่าวถึงไม่ใช่หน้า Pod และน่าจะเป็นหน้า man ของ Unix ดิ
ความแตกต่างไม่มีความสำคัญต่อโปรเซสเซอร์ Pod หลายตัว แต่โปรเซสเซอร์บางตัวนั้น
การเรนเดอร์เป็นรูปแบบไฮเปอร์เท็กซ์อาจจำเป็นต้องแยกความแตกต่างเพื่อให้ทราบวิธีการ
ทำให้ "L "รหัส

· perlpod เวอร์ชันก่อนหน้าอนุญาตสำหรับ "L ไวยากรณ์ " (เช่นใน "L
คุณลักษณะ>") ซึ่งแยกความแตกต่างจาก "L . ได้ไม่ยาก" " ไวยากรณ์และสำหรับ
"L<"section">" ซึ่งคลุมเครือเพียงเล็กน้อยเท่านั้น ไวยากรณ์นี้ไม่อยู่ใน .แล้ว
ข้อมูลจำเพาะและถูกแทนที่ด้วย "L " ไวยากรณ์ (โดยที่เครื่องหมายทับ
เดิมเป็นทางเลือก) ตัวแยกวิเคราะห์พ็อดควรทนต่อไวยากรณ์ "L<"section">" สำหรับ a
ในขณะที่อย่างน้อย ฮิวริสติกที่แนะนำสำหรับการแยกแยะ "L " จาก
“หลี่ " คือถ้ามันมีช่องว่างใด ๆ ก็คือ a ส่วน. โปรเซสเซอร์ Pod
ควรเตือนเกี่ยวกับไวยากรณ์ที่เลิกใช้แล้ว

เกี่ยวกับเรา =over...=กลับ ภูมิภาค

ขอบเขต "=over"..."=back" ใช้สำหรับโครงสร้างที่เหมือนรายการประเภทต่างๆ (ฉันใช้
คำว่า "ภูมิภาค" ในที่นี้เป็นเพียงคำศัพท์รวมสำหรับทุกอย่างตั้งแต่ "=มากกว่า" ถึง
ตรงกัน "=กลับ")

· ตัวเลขที่ไม่ใช่ศูนย์ เยื้องระดับ ใน "=มากกว่า เยื้องระดับ" ... "=back" ใช้สำหรับ
ให้คำใบ้แก่ผู้จัดรูปแบบว่ามี "ช่องว่าง" จำนวนเท่าใด (ems หรือหน่วยเทียบเท่าโดยประมาณ)
มันควรจะแท็บแม้ว่าตัวจัดรูปแบบจำนวนมากจะต้องแปลงสิ่งนี้เป็นแบบสัมบูรณ์
การวัดที่อาจไม่ตรงกับขนาดของช่องว่าง (หรือ M) ใน
แบบอักษรพื้นฐานของเอกสาร ตัวจัดรูปแบบอื่นๆ อาจต้องละเลยตัวเลขโดยสิ้นเชิง ดิ
ขาดความชัดเจนใดๆ เยื้องระดับ พารามิเตอร์เทียบเท่ากับ an เยื้องระดับ มูลค่า 4.
โปรเซสเซอร์ Pod อาจบ่นถ้า เยื้องระดับ มีอยู่แต่ไม่เป็นจำนวนบวก
ตรงกับ "m/\A(\d*\.)?\d+\z/"

· ผู้เขียนฟอร์แมตเตอร์ Pod ได้รับการเตือนว่า "=over" ... "=back" อาจจับคู่กับหลาย ๆ
โครงสร้างต่างๆ ในรูปแบบเอาต์พุตของคุณ ตัวอย่างเช่น ในการแปลง Pod เป็น
(X)HTML มันสามารถแมปกับใด ๆ ของ ... , ... , ... , หรือ
... . ในทำนองเดียวกัน "=item" สามารถจับคู่กับ หรือ .

· แต่ละภูมิภาค "=over" ... "=back" ควรเป็นหนึ่งในส่วนต่อไปนี้:

· พื้นที่ "=over" ... "=back" ที่มีเฉพาะคำสั่ง "=item *" แต่ละรายการตามด้วย
จำนวนย่อหน้าธรรมดา/คำต่อคำบางย่อหน้า อื่นๆ ที่ซ้อนกัน "=over" ... "=back"
ภูมิภาค ย่อหน้า "=for..." และภูมิภาค "=begin"..."=end"

(ตัวประมวลผลพ็อดต้องทนต่อ "=รายการ" เปล่าราวกับว่าเป็น "=รายการ *")
"*" จะแสดงเป็นเครื่องหมายดอกจันตามตัวอักษร, "o" หรือเป็นสัญลักษณ์แสดงหัวข้อย่อยจริงบางประเภท
อักขระถูกปล่อยไว้สำหรับฟอร์แมตเตอร์ Pod และอาจขึ้นอยู่กับระดับของ
การทำรัง

· พื้นที่ "=over" ... "=back" ที่มีเฉพาะ "m/\A=item\s+\d+\.?\s*\z/"
ย่อหน้าแต่ละย่อหน้า (หรือแต่ละกลุ่ม) ตามด้วย
ย่อหน้าธรรมดา/คำต่อคำ ภูมิภาค "=over" ... "=back" ที่ซ้อนกันอยู่ "=for..."
ย่อหน้า และ/หรือรหัส "=begin"..."=end" โปรดทราบว่าตัวเลขต้องเริ่มต้นที่1
ในแต่ละส่วนและต้องดำเนินการตามลำดับโดยไม่ข้ามหมายเลข

(ตัวประมวลผล Pod ต้องทนต่อบรรทัดเช่น "=item 1" ราวกับว่าเป็น "=item 1",
กับระยะเวลา)

· พื้นที่ "=over" ... "=back" ที่มีเฉพาะคำสั่ง "=item [text]" แต่ละรายการ
(หรือแต่ละกลุ่ม) ตามด้วยวรรคธรรมดา/คำต่อคำบางย่อหน้า
"=over" ... "=back" ที่ซ้อนกันอื่น ๆ หรือย่อหน้า "=for..." และ
ภูมิภาค "=เริ่มต้น"..."=สิ้นสุด"

ย่อหน้า "=item [text]" ไม่ควรตรงกับ "m/\A=item\s+\d+\.?\s*\z/" หรือ
"m/\A=item\s+\*\s*\z/" และไม่ควรตรงกับ "m/\A=item\s*\z/"

· พื้นที่ "=over" ... "=back" ที่ไม่มีย่อหน้า "=item" เลย และ
ที่มีเพียงบางย่อหน้าธรรมดา/ต่อคำเท่านั้นและอาจด้วย
"=over" ... "=back" ที่ซ้อนกันบางส่วน "=for..." ย่อหน้าและ
ภูมิภาค "=begin"..."=สิ้นสุด" ภูมิภาค "=over" ... "=back" ที่ไม่มีรายการดังกล่าวใน Pod is
เทียบเท่าในความหมายกับ " ... " องค์ประกอบใน HTML

โปรดทราบว่าด้วยกรณีทั้งหมดข้างต้น คุณสามารถระบุได้ว่า "=โอเวอร์" ประเภทใด ...
"=back" ที่คุณมี โดยตรวจสอบย่อหน้าพ็อดแรก (ไม่ใช่-"=ตัด" ไม่ใช่-"=พ็อด")
คำสั่ง "=over"

· ตัวจัดรูปแบบพ็อด ต้อง ยอมรับข้อความจำนวนมากตามอำเภอใจใน "=item ข้อความ..."
วรรค ในทางปฏิบัติ ย่อหน้าดังกล่าวส่วนใหญ่จะสั้น เช่น:

=รายการ สำหรับการตัดการค้าของเรากับทุกส่วนของโลก

แต่อาจยาวโดยพลการ:

=รายการ สำหรับพาเราข้ามทะเลไปลองแสร้งทำเป็น
ความผิด

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

· ตัวประมวลผลพ็อดควรทนต่อ "=item *" / "=item จำนวน" คำสั่งที่ไม่มี
ย่อหน้าประกอบ รายการกลางคือตัวอย่าง:

=เกิน

=ข้อ 1

รับซักแห้ง.

=ข้อ 2

=ข้อ 3

หยุดที่ร้านค้า รับ Abba Zabas, Stoli และเก้าอี้สนามหญ้าราคาถูก

=กลับ

· ไม่มีพื้นที่ "=over" ... "=back" สามารถมีหัวเรื่องได้ โปรเซสเซอร์อาจปฏิบัติต่อ a . ดังกล่าว
มุ่งหน้าไปเป็นข้อผิดพลาด

· โปรดทราบว่าขอบเขต "=over" ... "=back" ควรมีเนื้อหาบางส่วน กล่าวคือ ผู้เขียน
ไม่ควรมีพื้นที่ว่างดังนี้:

=เกิน

=กลับ

ตัวประมวลผล Pod เห็นพื้นที่ "=over" ... "=back" ที่ไม่มีเนื้อหา อาจเพิกเฉยหรือ
อาจแจ้งว่าเป็นข้อผิดพลาด

· ผู้ประมวลผลต้องทนต่อรายการ "=โอเวอร์" ที่ไปจากส่วนท้ายของเอกสาร (เช่น
ซึ่งไม่มี "=back") ที่ตรงกัน แต่พวกเขาอาจเตือนเกี่ยวกับรายการดังกล่าว

· ผู้เขียนฟอร์แมตเตอร์ Pod ควรสังเกตว่าโครงสร้างนี้:

=รายการ Neque

=รายการ Porro

=ไอเทม Quisquam Est

Qui dolorem ipsum quia dolor sit amet, คอนเซกเตอร์, อะดิปิสชี
velit, sed quia ไม่ใช่ numquam eius modi tempora incidunt ut
labore และ dolore magnam aliquam quaerat voluptatem.

=ไอเทม Ut Enim

มีความคลุมเครือในลักษณะที่ทำให้การตัดสินใจจัดรูปแบบยากขึ้นเล็กน้อย
ด้านหนึ่งอาจกล่าวถึงสิ่งของ "เนค" กล่าวถึงสิ่งของอื่น
“พอโร” และกล่าวถึงอีกรายการหนึ่ง “ควิสควอมเอส” โดยมีเพียงอันสุดท้ายที่ต้องการ
วรรคอธิบาย "Qui dolorem ipsum quia dolor..."; แล้วตามด้วยรายการ "อุต
Enim" ในกรณีนี้ คุณต้องการจัดรูปแบบดังนี้:

เนเก

ร่วมกัน

ควิสควอม เอส
Qui dolorem ipsum quia dolor sit amet, คอนเซกเตอร์, อะดิปิสชี
velit, sed quia ไม่ใช่ numquam eius modi tempora incidunt ut
labore และ dolore magnam aliquam quaerat voluptatem.

อุตเอนิม

แต่ก็สามารถเป็นการอภิปรายกันในสามรายการ (ที่เกี่ยวข้องหรือเทียบเท่า) ได้
"Neque", "Porro" และ "Quisquam Est" ตามด้วยย่อหน้าที่อธิบายทั้งหมด และ
แล้วรายการใหม่ "Ut Enim" ในกรณีนั้น คุณอาจต้องการจัดรูปแบบดังนี้:

เนเก
ร่วมกัน
ควิสควอม เอส
Qui dolorem ipsum quia dolor sit amet, คอนเซกเตอร์, อะดิปิสชี
velit, sed quia ไม่ใช่ numquam eius modi tempora incidunt ut
labore และ dolore magnam aliquam quaerat voluptatem.

อุตเอนิม

แต่ (สำหรับอนาคตอันใกล้) Pod ไม่ได้ให้วิธีการใดๆ แก่ผู้เขียน Pod เลย
แยกแยะความแตกต่างระหว่างโครงสร้างคลัสเตอร์ "=item" -cluster ด้านบน ดังนั้น
ตัวจัดรูปแบบควรจัดรูปแบบดังนี้:

เนเก

ร่วมกัน

ควิสควอม เอส

Qui dolorem ipsum quia dolor sit amet, คอนเซกเตอร์, อะดิปิสชี
velit, sed quia ไม่ใช่ numquam eius modi tempora incidunt ut
labore และ dolore magnam aliquam quaerat voluptatem.

อุตเอนิม

นั่นคือควรมีระยะห่างระหว่างรายการเท่ากัน (อย่างน้อยประมาณ) ระหว่าง
ย่อหน้า (แม้ว่าระยะห่างนั้นอาจน้อยกว่าความสูงเต็มของบรรทัดของ
ข้อความ). สิ่งนี้ปล่อยให้ผู้อ่านใช้ (บริบท) ตัวชี้นำข้อความเพื่อค้นหาว่า
ย่อหน้า "Qui dolorem ipsum..." ใช้กับรายการ "Quisquam Est" หรือกับทั้งหมด
สามรายการ "Neque", "Porro" และ "Quisquam Est" แม้ว่าจะไม่ใช่สถานการณ์ในอุดมคติ แต่สิ่งนี้
ดีกว่าที่จะให้ตัวชี้นำการจัดรูปแบบที่อาจขัดกับ
ความตั้งใจของผู้เขียน

เกี่ยวกับเรา ข้อมูล ย่อหน้า and "=เริ่มต้น/=สิ้นสุด" ภูมิภาค

โดยทั่วไป ย่อหน้าข้อมูลจะใช้สำหรับการฝังข้อมูลที่ไม่ใช่ Pod ที่จะนำไปใช้ (โดยทั่วไป
ผ่าน) เมื่อแสดงเอกสารในรูปแบบเฉพาะ:

=เริ่ม rtf

\par{\pard\qr\sa4500{\i พิมพ์\~\chdate\~\chtime}\par}

=สิ้นสุด rtf

ผลลัพธ์เดียวกันแน่นอนสามารถทำได้โดยบังเอิญด้วยย่อหน้า "=for" เดียว:

=สำหรับ rtf \par{\pard\qr\sa4500{\i Printed\~\chdate\~\chtime}\par}

(แม้ว่าจะไม่ใช่ย่อหน้าข้อมูลอย่างเป็นทางการ แต่ก็มีความหมายเดียวกับย่อหน้าหนึ่ง และ Pod
parsers อาจแยกวิเคราะห์เป็นหนึ่ง)

อีกตัวอย่างหนึ่งของย่อหน้าข้อมูล:

= เริ่ม html

ฉันชอบ พาย !

โดยเฉพาะพายพีแคน!

=สิ้นสุด html

หากเป็นย่อหน้าธรรมดา Pod parser จะพยายามขยาย "E" (ใน
ย่อหน้าแรก) เป็นโค้ดการจัดรูปแบบ เช่นเดียวกับ "E " หรือ "เ "แต่ตั้งแต่นี้เป็นต้นไป
อยู่ใน "=begin ระบุ"..."=จบ ระบุ" ภูมิภาค and ตัวระบุ "html" ไม่
เริ่มมีคำนำหน้า ":" เนื้อหาของภูมิภาคนี้จะถูกจัดเก็บเป็นย่อหน้าข้อมูล
แทนที่จะประมวลผลเป็นย่อหน้าธรรมดา (หรือถ้าขึ้นต้นด้วยการเว้นวรรคและ/หรือ
แท็บเป็นย่อหน้าต่อคำ)

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

=เริ่มต้น :biblio

เวิร์ธ, นิคลอส. พ.ศ. 1976 ฉัน
โปรแกรม> Prentice-Hall, Englewood Cliffs, NJ.

=จบ :biblio

สิ่งนี้จะส่งสัญญาณไปยัง parser ว่าย่อหน้าในส่วนเริ่มต้นนี้...ส่วนท้ายอยู่ภายใต้
การจัดการตามปกติเป็นย่อหน้าธรรมดา/ต่อคำต่อคำ (ในขณะที่ยังคงติดแท็กว่ามีความหมายสำหรับ .เท่านั้น
โปรเซสเซอร์ที่เข้าใจตัวระบุ "บรรณานุกรม") อาจมีผลเช่นเดียวกันกับ:

=สำหรับ :biblio
เวิร์ธ, นิคลอส. พ.ศ. 1976 ฉัน
โปรแกรม> Prentice-Hall, Englewood Cliffs, NJ.

":" บนตัวระบุเหล่านี้หมายถึงเพียงแค่ "ประมวลผลสิ่งนี้ตามปกติ แม้ว่า
ผลลัพธ์จะเป็นเป้าหมายพิเศษ" ฉันขอแนะนำให้ parser APIs รายงาน "biblio" เป็น
ตัวระบุเป้าหมาย แต่ยังรายงานว่ามีคำนำหน้า ":" (และในทำนองเดียวกันกับ
เหนือ "html" ให้รายงาน "html" เป็นตัวระบุเป้าหมาย และสังเกต ไม่มี ของ ":" คำนำหน้า)

โปรดทราบว่า a "=begin ระบุ"..."=จบ ระบุ" ภูมิภาคที่ ระบุ เริ่มต้นด้วย
ลำไส้ใหญ่ สามารถ มีคำสั่ง ตัวอย่างเช่น:

=เริ่มต้น :biblio

คลาสสิกของ Wirth มีให้เลือกหลายรุ่น ได้แก่ :

=สำหรับความคิดเห็น
อืม ตรวจสอบ abebooks.com ว่าสำเนาที่ใช้แล้วราคาเท่าไหร่

=เกิน

=รายการ

เวิร์ธ, นิคลอส. 1975 ฉัน
ทึบเนอร์, สตุ๊ตการ์ท. [ใช่ มันเป็นภาษาเยอรมัน]

=รายการ

เวิร์ธ, นิคลอส. พ.ศ. 1976 ฉัน
โปรแกรม> Prentice-Hall, Englewood Cliffs, NJ.

=กลับ

=จบ :biblio

อย่างไรก็ตาม หมายเหตุ a "=begin ระบุ"..."=จบ ระบุ" ภูมิภาคที่ ระบุ ทำ ไม่
ขึ้นต้นด้วยโคลอน ไม่ควรมีคำสั่ง "=head1" ... "=head4" โดยตรง หรือ
"=over" หรือ "=back" หรือ "=item" ตัวอย่างเช่น อาจถือว่าไม่ถูกต้อง:

=เริ่มต้นข้อมูลบางส่วน

นี่คือย่อหน้าข้อมูล

=head1 อย่าทำแบบนี้!

นี่เป็นย่อหน้าข้อมูลด้วย

= สิ้นสุดข้อมูลบางส่วน

โปรเซสเซอร์ Pod อาจส่งสัญญาณว่าข้อความข้างต้น (โดยเฉพาะย่อหน้า "=head1") เป็น
ข้อผิดพลาด. อย่างไรก็ตาม โปรดทราบว่าสิ่งต่อไปนี้ควร ไม่ ถือเป็นข้อผิดพลาด:

=เริ่มต้นข้อมูลบางส่วน

นี่คือย่อหน้าข้อมูล

=ตัด

# ใช่ นี่ไม่ใช่ Pod อีกต่อไป
ไม่รวมย่อย { (rand() > .5) ? "ฮู้!" : "ฮะ!" }

=พอด

นี่เป็นย่อหน้าข้อมูลด้วย

= สิ้นสุดข้อมูลบางส่วน

และสิ่งนี้ก็ถูกต้องเช่นกัน:

=เริ่มรูปแบบใดรูปแบบหนึ่ง

นี่คือย่อหน้าข้อมูล

และนี่คือย่อหน้าข้อมูล

=เริ่มรูปแบบอื่น

นี่เป็นย่อหน้าข้อมูลด้วย

และนี่คือย่อหน้าข้อมูลด้วย

=begin :yetanรูปแบบอื่น

=head2 นี่คือย่อหน้าคำสั่ง!

นี่เป็นวรรคธรรมดา!

และนี่คือย่อหน้าต่อคำ!

= สิ้นสุด : ยังอีกรูปแบบหนึ่ง

=สิ้นสุดรูปแบบอื่น

ย่อหน้าข้อมูลอื่น!

=จบบางรูปแบบ

เนื้อหาของภูมิภาค "=begin :yetanotherformat" ... "=end :yetanotherformat" ด้านบน
ไม่ใช่ ย่อหน้าข้อมูลเพราะทันทีที่มีตัวระบุภูมิภาค
(":yetanotherformat") เริ่มต้นด้วยเครื่องหมายทวิภาค ในทางปฏิบัติ ภูมิภาคส่วนใหญ่ที่มีข้อมูล
ย่อหน้าจะประกอบด้วย เพียง ย่อหน้าข้อมูล อย่างไรก็ตาม การทำรังข้างต้นเป็นวากยสัมพันธ์
ใช้ได้เหมือน Pod แม้ว่าจะหายากก็ตาม อย่างไรก็ตาม ตัวจัดการสำหรับบางรูปแบบ เช่น "html"
จะยอมรับเฉพาะย่อหน้าข้อมูลเท่านั้น ไม่รวมขอบเขตที่ซ้อนกัน และพวกเขาอาจจะบ่นถ้าเห็น
(กำหนดเป้าหมายสำหรับพวกเขา) ภูมิภาคที่ซ้อนกันหรือคำสั่งอื่นที่ไม่ใช่ "=end", "=pod" และ "=cut"

พิจารณาโครงสร้างที่ถูกต้องนี้ด้วย:

=เริ่มต้น :biblio

คลาสสิกของ Wirth มีให้เลือกหลายรุ่น ได้แก่ :

=เกิน

=รายการ

เวิร์ธ, นิคลอส. 1975 ฉัน
ทึบเนอร์, สตุ๊ตการ์ท. [ใช่ มันเป็นภาษาเยอรมัน]

=รายการ

เวิร์ธ, นิคลอส. พ.ศ. 1976 ฉัน
โปรแกรม> Prentice-Hall, Englewood Cliffs, NJ.

=กลับ

ซื้อซื้อซื้อ!

= เริ่ม html





=สิ้นสุด html

ตอนนี้ เดี๋ยวนี้ เดี๋ยวนี้!

=จบ :biblio

ที่นั่น ภูมิภาค "=begin html"..."=end html" ซ้อนอยู่ภายใน "=begin" ที่ใหญ่ขึ้น
:biblio"..."=end :biblio" ภูมิภาค โปรดทราบว่าเนื้อหาของ "=begin html"..."=end
html" เป็นย่อหน้าข้อมูล เพราะทันทีที่มีตัวระบุภูมิภาค
("html") ไม่ เริ่มต้นด้วยเครื่องหมายทวิภาค

Pod parsers เมื่อประมวลผลชุดของย่อหน้าข้อมูลทีละย่อหน้า (ภายใน a
ภูมิภาคเดียว) ควรพิจารณาให้เป็นย่อหน้าข้อมูลขนาดใหญ่หนึ่งย่อหน้าที่เกิดขึ้นกับ
มีบรรทัดว่าง ดังนั้นเนื้อหาข้างต้น "=begin html"..."=end html" อาจ be
จัดเก็บเป็นสองย่อหน้าข้อมูล (หนึ่งประกอบด้วย "
src='wirth_spokesmodeling_book.png'>\n" และอีกอันประกอบด้วย " \n"), แต่ น่า be
จัดเก็บเป็นย่อหน้าข้อมูลเดียว (ประกอบด้วย "
src='wirth_spokesmodeling_book.png'>\n\n \n")

ตัวประมวลผลพ็อดควรทนต่อความว่างเปล่า "=begin บางสิ่งบางอย่าง"..."=จบ บางสิ่งบางอย่าง" ภูมิภาค ว่างเปล่า
"=เริ่มต้น :บางสิ่งบางอย่าง"..."=จบ :บางสิ่งบางอย่าง" ภูมิภาคและไร้เนื้อหา "=for บางสิ่งบางอย่าง"และ
"=สำหรับ:บางสิ่งบางอย่าง" ย่อหน้า กล่าวคือควรยอมรับสิ่งเหล่านี้:

=สำหรับ html

= เริ่ม html

=สิ้นสุด html

=เริ่มต้น :biblio

=จบ :biblio

อนึ่ง โปรดทราบว่าไม่มีวิธีง่ายๆ ในการแสดงย่อหน้าข้อมูลที่ขึ้นต้นด้วย
สิ่งที่ดูเหมือนคำสั่ง พิจารณา:

=เริ่มของ

=ชาซบอท

=จบเรื่อง

ที่นั่น "=shazbot" จะถูกแยกวิเคราะห์เป็นคำสั่ง Pod "shazbot" ไม่ใช่ย่อหน้าข้อมูล
"=shazbot\n". อย่างไรก็ตาม คุณสามารถแสดงย่อหน้าข้อมูลที่ประกอบด้วย "=shazbot\n" โดยใช้
รหัสนี้:

=สำหรับสิ่งของ =shazbot

สถานการณ์ที่จำเป็นนี้น่าจะหายากมาก

โปรดทราบว่าคำสั่ง =end ต้องตรงกับคำสั่งที่เปิดอยู่ =begin นั่นคือพวกเขาต้อง
รังอย่างถูกต้อง ตัวอย่างเช่น สิ่งนี้ถูกต้อง:

=เริ่มต้นภายนอก

X

=เริ่มต้นภายใน

Y

=สิ้นสุดภายใน

Z

=จบนอก

ในขณะที่สิ่งนี้ไม่ถูกต้อง:

=เริ่มต้นภายนอก

X

=เริ่มต้นภายใน

Y

=จบนอก

Z

=สิ้นสุดภายใน

อันหลังนี้ไม่เหมาะสมเพราะเมื่อเห็นคำสั่ง "=end outer" แสดงว่ากำลังเปิดอยู่
ภูมิภาคมีชื่อรูปแบบ "ภายใน" ไม่ใช่ "ภายนอก" (มันเพิ่งเกิดขึ้นที่ "นอก" คือ
ชื่อรูปแบบของภูมิภาคที่สูงกว่า) นี่เป็นข้อผิดพลาด โปรเซสเซอร์จะต้องรายงานโดยปริยาย
นี่เป็นข้อผิดพลาด และอาจหยุดการประมวลผลเอกสารที่มีข้อผิดพลาดนั้น ผลพวง
ของสิ่งนี้คือภูมิภาคไม่สามารถ "ทับซ้อนกัน" นั่นคือบล็อกหลังด้านบนไม่
เป็นตัวแทนของภูมิภาคที่เรียกว่า "นอก" ซึ่งมี X และ Y ซ้อนทับกับภูมิภาคที่เรียกว่า
"inner" ซึ่งมี Y และ Z แต่เนื่องจากไม่ถูกต้อง
ภูมิภาคจะเป็น) มันไม่ได้เป็นตัวแทนของสิ่งนั้นหรืออะไรเลย

ในทำนองเดียวกัน สิ่งนี้ไม่ถูกต้อง:

= เริ่มต้นสิ่ง

=สิ้นสุด hting

นี่เป็นข้อผิดพลาดเนื่องจากพื้นที่เปิดโดย "สิ่ง" และ "=end" พยายามปิด
"ถิง" [sic].

สิ่งนี้ไม่ถูกต้องเช่นกัน:

= เริ่มต้นสิ่ง

=สิ้นสุด

สิ่งนี้ไม่ถูกต้องเนื่องจากทุกคำสั่ง "=end" ต้องมีพารามิเตอร์ formatname

ใช้ perlpodspec ออนไลน์โดยใช้บริการ onworks.net