unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Kenichi Handa <handa@m17n.org>
Cc: schwab@suse.de, jasonr@gnu.org, emacs-devel@gnu.org
Subject: Re: UCS-2BE
Date: Fri, 01 Sep 2006 10:19:34 +0900	[thread overview]
Message-ID: <E1GIxh0-000751-00@etlken> (raw)
In-Reply-To: <87ac5ko50j.fsf@jurta.org> (message from Juri Linkov on Fri, 01 Sep 2006 02:32:44 +0300)

In article <87ac5ko50j.fsf@jurta.org>, Juri Linkov <juri@jurta.org> writes:

> `UCS-2' is the fixed-length encoding of the BMP.  `UCS-2BE' is
> a big-endian version of the UCS-2 encoding without using a BOM.
> So as actually UCS-2 is a BMP subset of UTF-16, UCS-2BE is a BMP
> subset of UTF-16BE (and UCS-2LE is a BMP subset of UTF-16LE).

Where did you get that info?

The word "encoding" is ambiguous here.  There are "CEF
(Character Encoding Form)" and "CES (Character Encoding
Scheme)".  Unicode says (see Glossary):

Character Encoding Form: Mapping from a character set
definition to the actual code units used to represent the
data.

Character Encoding Scheme: A character encoding form plus
byte serialization. ...

UCS-XXX are CEF, and UTF-XXX are CES.  So, UCS-XXX are not
appropriate lavel names for specifing how to byte-serialize
characters (i.e. on saving characters in a file).  At least,
that is the official definition in Unicode.

And, as you see now, there's is a contradition in the term
"UCS-2BE" because "BE" is information about
byte-serialization.  But the term "UCS-2BE" itself is not
defined in Unicode.  So, there are two possibilities:

(1) It's just a mis-label of something.
(2) It's defined somewhere else.

Which is the case?

> The encodings `UCS-2' and `UCS-2BE' are implemented in iconv
> (http://www.gnu.org/software/libiconv/), so you could look
> at the implementation of UCS-2BE:

Does it mean that it's an invention of iconv to use those
names as CES?

> Does the Emacs implementation of UTF-16 output the BOM?

Yes.

> > (at least, we should not select it by select-safe-coding-system on
> > saving a buffer that contains non-BMP characters).

> What do you think is the right way to deal with non-BMP characters
> when the user will try to save a UTF-16(BE) buffer in the UCS-2(BE)
> encoding?

It depends on how UCS-2BE is defined.  If we follow the
implementation of iconv (and if the buffer contains non-BMP
characters), we should ask the user to select a proper
coding system.

---
Kenichi Handa
handa@m17n.org

  reply	other threads:[~2006-09-01  1:19 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-30 22:54 UCS-2BE Juri Linkov
2006-08-31  9:09 ` UCS-2BE Jason Rumney
2006-08-31 10:23   ` UCS-2BE Kenichi Handa
2006-08-31 10:39     ` UCS-2BE Jason Rumney
2006-08-31 10:55       ` UCS-2BE Kenichi Handa
2006-08-31 11:56         ` UCS-2BE Andreas Schwab
2006-08-31 12:16           ` UCS-2BE Kenichi Handa
2006-08-31 14:33             ` UCS-2BE Andreas Schwab
2006-08-31 22:48               ` UCS-2BE Kenichi Handa
2006-08-31 23:02                 ` UCS-2BE Andreas Schwab
2006-09-01  1:22                   ` UCS-2BE Kenichi Handa
2006-09-01  9:01                     ` UCS-2BE Andreas Schwab
2006-09-01 11:28                       ` UCS-2BE Kenichi Handa
2006-08-31 23:32             ` UCS-2BE Juri Linkov
2006-09-01  1:19               ` Kenichi Handa [this message]
2006-09-01 11:30                 ` UCS-2BE YAMAMOTO Mitsuharu
2006-09-01 12:26                   ` UCS-2BE Kenichi Handa
2006-09-01 12:30                     ` UCS-2BE Andreas Schwab
2006-09-01 12:57                       ` UCS-2BE Kenichi Handa
2006-09-01 17:08                     ` UCS-2BE Stefan Monnier
2006-09-01 23:45                     ` UCS-2BE Juri Linkov
2006-09-02  1:27                       ` UCS-2BE Kenichi Handa
     [not found] <E1GIw3v-00059X-TI@monty-python.gnu.org>
2006-08-31 23:36 ` UCS-2BE Jonathan Yavner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1GIxh0-000751-00@etlken \
    --to=handa@m17n.org \
    --cc=emacs-devel@gnu.org \
    --cc=jasonr@gnu.org \
    --cc=schwab@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).