From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1c4b8fdfa762b2bb X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-04-06 11:52:44 PST Path: supernews.google.com!sn-xit-02!supernews.com!nntp-relay.ihug.net!ihug.co.nz!news-hog.berkeley.edu!ucberkeley!newsfeed.stanford.edu!headwall.stanford.edu!unlnews.unl.edu!newsfeed.ksu.edu!nntp.ksu.edu!news.okstate.edu!dvdeug From: dvdeug@x8b4e53cd.dhcp.okstate.edu (David Starner) Newsgroups: comp.lang.ada Subject: Re: Hebrew language character set Date: 5 Apr 2001 20:43:08 GMT Organization: Oklahoma State University Message-ID: <9ailcs$8a22@news.cis.okstate.edu> References: <3ACA11B0.9AAFDDDD@lmco.com> <3ACB85DF.9E6DBD03@lmco.com> <3ACC6E83.5B860AC5@free.fr> <3ACC9597.14D3B23D@lmco.com> <87lmpfz4by.fsf@deneb.enyo.de> <3ACCAA2D.523AA9B6@lmco.com> <3ACCB8F8.C7153457@adapower.net> Reply-To: dstarner98@aasaa.ofe.org NNTP-Posting-Host: x8b4e531b.dhcp.okstate.edu User-Agent: slrn/0.9.6.3 (Linux) Xref: supernews.google.com comp.lang.ada:6586 Date: 2001-04-05T20:43:08+00:00 List-Id: On Thu, 05 Apr 2001 13:27:04 -0500, Britt Snodgrass wrote: >The URL you used points to a very old/obsolete version of the GNAT >reference. See the "Wide Character Encodings" section of a GNAT 3.13p >or 3.14a users manual. [...] >>From the GNAT 3.14a Users Guide: > >Wide Character Encodings > >GNAT allows wide character codes to appear in character and string >literals, and also optionally in identifiers, by means of the following >possible encoding schemes: "in ... literals, and ... in identifiers" clearly shows that this section of the GNAT User Guide is talking about the representation of the source, not I/O. Try Wide_Text_IO ============ `Wide_Text_IO' is similar in most respects to Text_IO, except that both input and output files may contain special sequences that represent wide character values. The encoding scheme for a given file may be specified using a FORM parameter: WCEM=X as part of the FORM string (WCEM = wide character encoding method), where X is one of the following characters `h' Hex ESC encoding `u' Upper half encoding `s' Shift-JIS encoding `e' EUC Encoding `8' UTF-8 encoding `b' Brackets encoding The encoding methods match those that can be used in a source program, but there is no requirement that the encoding method used for the source program be the same as the encoding method used for files, and different files may use different encoding methods. The default encoding method for the standard files, and for opened files for which no WCEM parameter is given in the FORM string matches the wide character encoding specified for the main program (the default being brackets encoding if no coding method was specified with -gnatW). Hex Coding In this encoding, a wide character is represented by a five character sequence: ESC a b c d where A, B, C, D are the four hexadecimal characters (using upper case letters) of the wide character code. For example, ESC A345 is used to represent the wide character with code 16#A345#. This scheme is compatible with use of the full `Wide_Character' set. Upper Half Coding The wide character with encoding 16#abcd#, where the upper bit is on (i.e. a is in the range 8-F) is represented as two bytes 16#ab# and 16#cd#. The second byte may never be a format control character, but is not required to be in the upper half. This method can be also used for shift-JIS or EUC where the internal coding matches the external coding. Shift JIS Coding A wide character is represented by a two character sequence 16#ab# and 16#cd#, with the restrictions described for upper half encoding as described above. The internal character code is the corresponding JIS character according to the standard algorithm for Shift-JIS conversion. Only characters defined in the JIS code set table can be used with this encoding method. EUC Coding A wide character is represented by a two character sequence 16#ab# and 16#cd#, with both characters being in the upper half. The internal character code is the corresponding JIS character according to the EUC encoding algorithm. Only characters defined in the JIS code set table can be used with this encoding method. UTF-8 Coding A wide character is represented using UCS Transformation Format 8 (UTF-8) as defined in Annex R of ISO 10646-1/Am.2. Depending on the character value, the representation is a one, two, or three byte sequence: 16#0000#-16#007f#: 2#0xxxxxxx# 16#0080#-16#07ff#: 2#110xxxxx# 2#10xxxxxx# 16#0800#-16#ffff#: 2#1110xxxx# 2#10xxxxxx# 2#10xxxxxx# where the xxx bits correspond to the left-padded bits of the the 16-bit character value. Note that all lower half ASCII characters are represented as ASCII bytes and all upper half characters and other wide characters are represented as sequences of upper-half (The full UTF-8 scheme allows for encoding 31-bit characters as 6-byte sequences, but in this implementation, all UTF-8 sequences of four or more bytes length will raise a Constraint_Error, as will all illegal UTF-8 sequences.) Brackets Coding In this encoding, a wide character is represented by the following eight character sequence: [ " a b c d " ] Where `a', `b', `c', `d' are the four hexadecimal characters (using uppercase letters) of the wide character code. For example, `["A345"]' is used to represent the wide character with code `16#A345#'. This scheme is compatible with use of the full Wide_Character set. On input, brackets coding can also be used for upper half characters, e.g. `["C1"]' for lower case a. However, on output, brackets notation is only used for wide characters with a code greater than `16#FF#'. For the coding schemes other than Hex and Brackets encoding, not all wide character values can be represented. An attempt to output a character that cannot be represented using the encoding scheme for the file causes Constraint_Error to be raised. An invalid wide character sequence on input also causes Constraint_Error to be raised. [...] ====================================================================== (I must, however, apologize to the person to used -gnatW8 to change the output, and I claimed it only changed source encoding. It's clear I didn't read this section well enough, because, for better or worse, it changes the default encoding. It must get interesting when the program is compiled with different default encodings for each file, though ...) -- David Starner - dstarner98@aasaa.ofe.org Pointless website: http://dvdeug.dhis.org "I don't care if Bill personally has my name and reads my email and laughs at me. In fact, I'd be rather honored." - Joseph_Greg