This PDF file is an excerpt from The Unicode Standard, Version 4.0, issued by the Unicode Consor- tium and published by Addison-Wesley. The material has been modified slightly for this online edi- tion, however the PDF files have not been modified to reflect the corrections found on the Updates and Errata page (http://www.unicode.org/errata/). For information on more recent versions of the standard, see http://www.unicode.org/standard/versions/enumeratedversions.html. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and Addison-Wesley was aware of a trademark claim, the designations have been printed in initial capital letters. However, not all words in initial capital letters are trademark designations. The Unicode® Consortium is a registered trademark, and Unicode™ is a trademark of Unicode, Inc. The Unicode logo is a trademark of Unicode, Inc., and may be registered in some jurisdictions. The authors and publisher have taken care in preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. The Unicode Character Database and other files are provided as-is by Unicode®, Inc. No claims are made as to fitness for any particular purpose. No warranties of any kind are expressed or implied. The recipient agrees to determine applicability of information provided. Dai Kan-Wa Jiten used as the source of reference Kanji codes was written by Tetsuji Morohashi and published by Taishukan Shoten. Cover and CD-ROM label design: Steve Mehallo, http://www.mehallo.com The publisher offers discounts on this book when ordered in quantity for bulk purchases and special sales. For more information, customers in the U.S. please contact U.S. Corporate and Government Sales, (800) 382-3419, [email protected]. For sales outside of the U.S., please contact International Sales, +1 317 581 3793, [email protected] Visit Addison-Wesley on the Web: http://www.awprofessional.com Library of Congress Cataloging-in-Publication Data The Unicode Standard, Version 4.0 : the Unicode Consortium /Joan Aliprand... [et al.]. p. cm. Includes bibliographical references and index. ISBN 0-321-18578-1 (alk. paper) 1. Unicode (Computer character set). I. Aliprand, Joan. QA268.U545 2004 005.7’2—dc21 2003052158 Copyright © 1991–2003 by Unicode, Inc. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or other- wise, without the prior written permission of the publisher or Unicode, Inc. Printed in the United States of America. Published simultaneously in Canada. For information on obtaining permission for use of material from this work, please submit a written request to the Unicode Consortium, Post Office Box 39146, Mountain View, CA 94039-1476, USA, Fax +1 650 693 3010 or to Pearson Education, Inc., Rights and Contracts Department, 75 Arlington Street, Suite 300 Boston, MA 02116, USA, Fax: +1 617 848 7047. ISBN 0-321-18578-1 Text printed on recycled paper 1 2 3 4 5 6 7 8 9 10—CRW—0706050403 First printing, August 2003 Chapter 2 General Structure 2 This chapter discusses the fundamental principles governing the design of the Unicode Standard and presents an informal overview of its main features. The chapter starts by placing the Unicode Standard in an architectural context by discussing the nature of text representation and text processing and its bearing on character encoding decisions. Next, the Unicode Design Principles are introduced—ten basic principles that convey the essence of the standard. The Unicode Design Principles serve as a kind of tutorial framework for understanding the Unicode Standard, and they are a useful place from which to start to get a summary of the overall nature of the standard. The chapter then moves on to the Unicode character encoding model, introducing the con- cepts of character, code point, and encoding forms, and diagramming the relationships between them. This provides an explanation of the encoding forms UTF-8, UTF-16, and UTF-32 and some general guidelines regarding the circumstances under which one form would be preferable to another. The section on Unicode allocation then describes the overall structure of the Unicode codespace, showing a summary of the code charts and the locations of blocks of characters associated with different scripts or sets of symbols. Next, the chapter discusses the issue of writing direction and introduces several special types of characters important for understanding the Unicode Standard. In particular, the use of combining characters, the byte order mark, and control characters is explored in some detail. Finally, there is an informal statement of the conformance requirements for the Unicode Standard. This informal statement, with a number of easy-to-understand examples, gives a general sense of what conformance to the Unicode Standard means. The rigorous, formal definition of conformance is given in the subsequent Chapter 3, Conformance. 2.1 Architectural Context A character code standard such as the Unicode Standard enables the implementation of useful processes operating on textual data. The interesting end products are not the charac- ter codes but the text processes, because these directly serve the needs of a system’s users. Character codes are like nuts and bolts—minor, but essential and ubiquitous components used in many different ways in the construction of computer software systems. No single design of a character set can be optimal for all uses, so the architecture of the Unicode Stan- dard strikes a balance among several competing requirements. The Unicode Standard 4.0 8 Aug 03 11 2.1 Architectural Context General Structure Basic Text Processes Most computer systems provide low-level functionality for a small number of basic text processes from which more sophisticated text-processing capabilities are built. The follow- ing text processes are supported by most computer systems to some degree: • Rendering characters visible (including ligatures, contextual forms, and so on) • Breaking lines while rendering (including hyphenation) • Modifying appearance, such as point size, kerning, underlining, slant, and weight (light, demi, bold, and so on) • Determining units such as “word” and “sentence” • Interacting with users in processes such as selecting and highlighting text • Accepting keyboard input and editing stored text through insertion and dele- tion • Comparing text in operations such as determining the sort order of two strings, or filtering or matching strings • Analyzing text content in operations such as spell-checking, hyphenation, and parsing morphology (that is, determining word roots, stems, and affixes) • Treating text as bulk data for operations such as compressing and decompress- ing, truncating, transmitting, and receiving Text Elements, Characters, and Text Processes One of the more profound challenges in designing a worldwide character encoding stems from the fact that, for each text process, written languages differ in what is considered a fundamental unit of text, or a text element. For example, in traditional German orthography, the letter combination “ck” is a text ele- ment for the process of hyphenation (where it appears as “k-k”), but not for the process of sorting; in Spanish, the combination “ll” may be a text element for the traditional process of sorting (where it is sorted between “l” and “m”), but not for the process of rendering; and in English, the letters “A” and “a” are usually distinct text elements for the process of rendering, but generally not distinct for the process of searching text. The text elements in a given language depend upon the specific text process; a text element for spell-checking may have different boundaries from a text element for sorting purposes. For example, in the phrase “the quick brown fox”, the sequence “fox” is a text element for the purpose of spell-checking. However, a character encoding standard provides just the fundamental units of encoding (that is, the abstract characters), which must exist in a unique relationship to the assigned numerical code points. Assigned characters are the smallest interpretable units of stored text. Figure 2-1 illustrates the relationship between several different types of text elements and the characters that are used to represent those text elements. Unicode Standard Annex #29, “Text Boundaries,” provides more details regarding the specifications of boundaries for such text elements as user-perceived characters (called grapheme clusters), words, and sen- tences. The design of the character encoding must provide precisely the set of characters that allows programmers to design applications capable of implementing a variety of text pro- 12 8 Aug 03 The Unicode Standard 4.0 General Structure 2.1 Architectural Context Figure 2-1. Text Elements and Characters Text Elements Characters Ç Composite: Ç C @ ¸ Collation Unit: ch c h (Slovak) Syllable: @ Word: cat c a t cesses in the desired languages. These characters may not map directly to any particular set of text elements that is used by one of these processes. Text Processes and Encoding In the case of English text using an encoding scheme such as ASCII, the relationships between the encoding and the basic text processes built on it are seemingly straightforward: characters are generally rendered visible one by one in distinct rectangles from left to right in linear order. Thus one character code inside the computer corresponds to one logical character in a process such as simple English rendering. When designing an international and multilingual text encoding such as the Unicode Stan- dard, the relationship between the encoding and implementation of basic text processes must be considered explicitly, for several reasons: • Many assumptions about character rendering that hold true for the English alphabet fail for other writing systems.