perlpodspec: Finish EBCDIC updates

This is a follow up to bd940430ebc41b7b346cc761cc46be9674f34111

diff --git a/pod/perlpodspec.pod b/pod/perlpodspec.pod
index 36a655b..20a9195 100644 (file)
--- a/pod/perlpodspec.pod
+++ b/pod/perlpodspec.pod
@@ -622,8 +622,13 @@ The well known Unicode Byte Order Marks are as follows:  if the
 file begins with the two literal byte values 0xFE 0xFF, this is
 the BOM for big-endian UTF-16.  If the file begins with the two
 literal byte value 0xFF 0xFE, this is the BOM for little-endian
-UTF-16.  If the file begins with the three literal byte values
+UTF-16.  On an ASCII platform, if the file begins with the three literal
+byte values
 0xEF 0xBB 0xBF, this is the BOM for UTF-8.
+(A mechanism portable to EBCDIC platforms is to:
+
+  my $utf8_bom = "\x{FEFF}";
+  utf8::encode($utf8_bom);
 
 =for comment
  use bytes; print map sprintf(" 0x%02X", ord $_), split '', "\x{feff}";
@@ -634,7 +639,8 @@ UTF-16.  If the file begins with the three literal byte values
 
 =item *
 
-A naive but often sufficient heuristic for testing the first highbit
+A naive, but often sufficient heuristic on ASCII platforms, for testing
+the first highbit
 byte-sequence in a BOM-less file (whether in code or in Pod!), to see
 whether that sequence is valid as UTF-8 (RFC 2279) is to check whether
 that the first byte in the sequence is in the range 0xC2 - 0xFD
@@ -642,7 +648,8 @@ I<and> whether the next byte is in the range
 0x80 - 0xBF.  If so, the parser may conclude that this file is in
 UTF-8, and all highbit sequences in the file should be assumed to
 be UTF-8.  Otherwise the parser should treat the file as being
-in CP-1252.  (A better check is to pass a copy of the sequence to
+in CP-1252.  (A better check, and which works on EBCDIC platforms as
+well, is to pass a copy of the sequence to
 L<utf8::decode()|utf8> which performs a full validity check on the
 sequence and returns TRUE if it is valid UTF-8, FALSE otherwise.  This
 function is always pre-loaded, is fast because it is written in C, and
@@ -671,12 +678,6 @@ is sufficient to establish this file's encoding.
 
 =item *
 
-This document's requirements and suggestions about encodings
-do not apply to Pod processors running on non-ASCII platforms,
-notably EBCDIC platforms.
-
-=item *
-
 Pod processors must treat a "=for [label] [content...]" paragraph as
 meaning the same thing as a "=begin [label]" paragraph, content, and
 an "=end [label]" paragraph.  (The parser may conflate these two
@@ -848,10 +849,11 @@ are the Latin1/Unicode values, even on EBCDIC platforms.
 When referring to characters by using a EE<lt>n> numeric code, numbers
 in the range 32-126 refer to those well known US-ASCII characters (also
 defined there by Unicode, with the same meaning), which all Pod
-formatters must render faithfully.  Numbers in the ranges 0-31 and
-127-159 should not be used (neither as literals, nor as EE<lt>number>
-codes), except for the literal byte-sequences for newline (13, 13 10, or
-10), and tab (9).
+formatters must render faithfully.  Characters whose EE<lt>E<gt> numbers
+are in the ranges 0-31 and 127-159 should not be used (neither as
+literals,
+nor as EE<lt>number> codes), except for the literal byte-sequences for
+newline (ASCII 13, ASCII 13 10, or ASCII 10), and tab (ASCII 9).
 
 Numbers in the range 160-255 refer to Latin-1 characters (also
 defined there by Unicode, with the same meaning).  Numbers above