From 300c5466a7c9cfe3ed22bba2a88ba21058406402 Mon Sep 17 00:00:00 2001
From: Hans Bolinder The Erlang code preprocessor includes functions which are used
by The Erlang source file Handle to the epp server.
+%% coding: utf-8
+%% For this file we have chosen encoding = Latin-1
+%% -*- coding: latin-1 -*-
Returns the default encoding of Erlang source files.
+Returns a string representation of an encoding. The string
+ is recognized by
Read the
The option
Reads the
Returns the read encoding, or
Reads a term
Writes the data with standard syntax in the same way as
5> T = [{attributes,[[{id,age,1.50000},{mode,explicit}, {typename,"INTEGER"}], [{id,cho},{mode,explicit},{typename,'Cho'}]]}, @@ -515,6 +520,19 @@ Here T = [{attributes,[[{id,age,1.5}, {typename,'Person'}, {tag,{'PRIVATE',3}}, {mode,implicit}] +ok+
Binaries that look like UTF-8 encoded strings will be + output with the string syntax if the Unicode translation + modifier is given:
++9> io:fwrite("~p~n",[[1024]]). +[1024] +10> io:fwrite("~tp~n",[[1024]]). +"\x{400}" +11> io:fwrite("~tp~n", [<<128,128>>]). +<<128,128>> +12> io:fwrite("~tp~n", [<<208,128>>]). +<<"\x{400}"/utf8>> ok
Reads data from the standard input (
Reads data from the standard input ( Reads data from the standard input ( Reads data from the standard input
+ ( Reads data from the standard input ( A continuation as returned by
Returns the list of characters needed to print
+
Returns the list of characters needed to print
+
Returns the list of characters needed to print a character + constant in the Unicode character set.
+Returns the list of characters needed to print a character + constant in the Unicode character set. Non-Latin-1 characters + are escaped.
+Returns
Returns
Returns
Implementing support for Unicode character sets is an ongoing process. The Erlang Enhancement Proposal (EEP) 10 outlines the basics of Unicode support and also specifies a default encoding in binaries that all Unicode-aware modules should handle in the future.
-The functionality described in EEP10 is implemented in Erlang/OTP as of R13A, but that's by no means the end of it. More functionality will be needed in the future and more OTP-libraries might need updating to cope with Unicode data. One example of future development is obvious when reading this manual, our documentation format is limited to the ISO-latin-1 character range, why no Unicode characters beyond that range will occur in this document.
+The functionality described in EEP10 is implemented in Erlang/OTP as of R13A, but that's by no means the end of it. More functionality will be needed in the future and more OTP-libraries might need updating to cope with Unicode data.
This guide outlines the current Unicode support and gives a couple of recipes for working with Unicode data.
The standard list encoding for strings is therefore easily extendible to cope with the whole Unicode range: A Unicode string in Erlang is simply a list containing integers, each integer being a valid Unicode codepoint and representing one character in the Unicode character set.
Regular Erlang strings in ISO-latin-1 are a subset of their Unicode strings.
-Binaries on the other hand are more troublesome. For performance reasons, programs often store textual data in binaries instead of lists, mainly because they are more compact (one byte per character instead of two words per character, as is the case with lists). Using erlang:list_to_binary/1, an regular Erlang string can be converted into a binary, effectively using the ISO-latin-1 encoding in the binary - one byte per character. This is very convenient for those regular Erlang strings, but cannot be done for Unicode lists.
+Binaries on the other hand are more troublesome. For performance reasons, programs often store textual data in binaries instead of lists, mainly because they are more compact (one byte per character instead of two words per character, as is the case with lists). Using erlang:list_to_binary/1, a regular Erlang string can be converted into a binary, effectively using the ISO-latin-1 encoding in the binary - one byte per character. This is very convenient for those regular Erlang strings, but cannot be done for Unicode lists.
As the UTF-8 encoding is widely spread and provides the most compact storage, it is selected as the standard encoding of Unicode characters in binaries for Erlang.
The standard binary encoding is used whenever a library function in Erlang should cope with Unicode data in binaries, but is of course not enforced when communicating externally. Functions and bit-syntax exist to encode and decode both UTF-8, UTF-16 and UTF-32 in binaries. Library functions dealing with binaries and Unicode in general, however, only deal with the default encoding.
Character data may be combined from several sources, sometimes available in a mix of strings and binaries. Erlang has for long had the concept of iodata or iolists, where binaries and lists can be combined to represent a sequence of bytes. In the same way, the Unicode aware modules often allow for combinations of binaries and lists where the binaries have characters encoded in UTF-8 and the lists contain such binaries or numbers representing Unicode codepoints:
unicode_binary() = binary() with characters encoded in UTF-8 coding standard
-unicode_char() = integer() representing valid unicode codepoint
+unicode_char() = integer() >= 0 representing valid unicode codepoint
chardata() = charlist() | unicode_binary()
charlist() = [unicode_char() | unicode_binary() | charlist()]
a unicode_binary is allowed as the tail of the list
-The module
The module
external_unicode_binary() = binary() with characters coded in a user specified Unicode
encoding other than UTF-8 (UTF-16 or UTF-32)
@@ -82,12 +82,18 @@ external_unicode_binary() = binary() with characters coded in a user specified U
external_chardata() = external_charlist() | external_unicode_binary()
external_charlist() = [unicode_char() | external_unicode_binary() | external_charlist()]
- an external_unicode_binary is allowed as the tail of the list
+ an external_unicode_binary() is allowed as the tail of the list
First of all, Erlang is still defined to be written in the ISO-latin-1 character set. Functions have to be named in that character set, atoms are restricted to ISO-latin-1 and regular strings are still lists of characters 0..255 in the ISO-latin-1 encoding. This has not (yet) changed, but the language has been slightly extended to cope with Unicode characters and encodings.
- +The bit-syntax contains types for coping with binary data in the three main encodings. The types are named
The literal syntax described here may be subject to change in R13B, it has not yet passed the usual process for language changes approval.
-It is convenient to be able to write a list of Unicode characters in the string syntax. However, the language specifies strings as being in the ISO-latin-1 character set which the compiler tool chain as well as many other tools expect.
-Also the source code is (for now) still expected to be written using the ISO-latin-1 character set, why Unicode characters beyond that range cannot be entered in string literals.
-To make it easier to enter Unicode characters in the shell, it allows strings with Unicode characters on input, immediately converting them to regular lists of integers. They will, by the evaluator etc be viewed as if they were input using the regular list syntax, which is - in the end - how the language actually treats them. They will in the same way not be output as strings by i.e
For source code, there is an extension to the \OOO (backslash followed by three octal numbers) and \xHH (backslash followed by 'x', followed by two hexadecimal characters) syntax, namely \x{H ...} (a backslash followed by an 'x', followed by left curly bracket, any number of hexadecimal digits and a terminating right curly bracket). This allows for entering characters of any codepoint literally in a string. The string is immediately converted into a list by the scanner however, which is obvious when calling it directly:
--1> erl_scan:string("\"X\"."). -{ok,[{string,1,"X"},{dot,1}],1} -2> erl_scan:string("\"\x{400}\"."). -{ok,[{'[',1},{integer,1,1024},{']',1},{dot,1}],1}-
Character literals, or rather integers representing Unicode codepoints can be expressed in a similar way using $\x{H ...}:
--4> $\x{400}. -1024-
This also is a translation by the scanner:
--5> erl_scan:string("$Y."). -{ok,[{char,1,89},{dot,1}],1} -6> erl_scan:string("$\x{400}."). -{ok,[{integer,1,1024},{dot,1}],1}-
In the shell, if using a Unicode input device, '$' can be followed directly by a Unicode character producing an integer. In the following example, let's imagine the character 'c' is actually a Cyrillic 's' (looking fairly similar):
+For source code, there is an extension to the \OOO (backslash +followed by three octal numbers) and \xHH (backslash followed by 'x', +followed by two hexadecimal characters) syntax, namely \x{H ...} (a +backslash followed by an 'x', followed by left curly bracket, any +number of hexadecimal digits and a terminating right curly bracket). +This allows for entering characters of any codepoint literally in a +string even when the encoding is ISO-latin-1.
+In the shell, if using a Unicode input device, '$' can be followed directly by a Unicode character producing an integer. In the following example the codepoint of a Cyrillic 's' is output:
-7> $c. +7> $с. 1089
The literal syntax allowing Unicode characters is to be viewed as "syntactic sugar", but is, as such, fairly useful.
-The interactive Erlang shell, when started towards a terminal or started using the
To investigate what Erlang thinks about the terminal, the
$ LC_CTYPE=en_US.ISO-8859-1 erl -Erlang R13A (erts-5.7) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [kernel-poll:false] +Erlang R13A (erts-5.10) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [kernel-poll:false] -Eshell V5.7 (abort with ^G) +Eshell V5.10 (abort with ^G) 1> lists:keyfind(encoding,1,io:getopts()). {encoding,latin1} 2> q(). ok $ LC_CTYPE=en_US.UTF-8 erl -Erlang R13A (erts-5.7) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [kernel-poll:false] +Erlang R13A (erts-5.10) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [kernel-poll:false] -Eshell V5.7 (abort with ^G) +Eshell V5.10 (abort with ^G) 1> lists:keyfind(encoding,1,io:getopts()). {encoding,unicode} 2>
When (finally?) everything is in order with the locale settings, fonts and the terminal emulator, you probably also have discovered a way to input characters in the script you desire. For testing, the simplest way is to add some keyboard mappings for other languages, usually done with some applet in your desktop environment. In my KDE environment, I start the KDE Control Center (Personal Settings), select "Regional and Accessibility" and then "Keyboard Layout". On Windows XP®, I start Control Panel->Regional and Language Options, select the Language tab and click the Details... button in the square named "Text services and input Languages". Your environment probably provides similar means of changing the keyboard layout. Make sure you have a way to easily switch back and forth between keyboards if you are not used to this, entering commands using a Cyrillic character set is, as an example, not easily done in the Erlang shell.
Now you are set up for some Unicode input and output. The simplest thing to do is of course to enter a string in the shell:
-+$ erl +Eshell V5.10 (abort with ^G) +1> lists:keyfind(encoding, 1, io:getopts()). +{encoding,unicode} +2> "уницоде" +"уницоде" +3> io:format("~ts~n", [v(2)]). +уницоде +ok +4>
While strings can be input as Unicode characters, the language elements are still limited to the ISO-latin-1 character set. Only character constants and strings are allowed to be beyond that range:
-+Eshell V5.10 (abort with ^G) +1> $ξ +958 +2> уницоде. +* 1: illegal character +2>
A raw file name is not a list, but a binary. Many non core applications still do not handle file names given as binaries, why such raw names are avoided by default. This means that systems having implemented Unicode file naming through transparent file systems and an UTF-8 convention, do not by default have Unicode file naming turned on. Explicitly turning Unicode file name handling on for these types of systems is considered experimental.
-The Unicode file naming support was introduced with OTP release R14B01. A VM operating in Unicode file mode can work with files having names in any language or character set (as long as it's supported by the underlying OS and file system). The Unicode character list is used to denote file or directory names and if the file system content is listed, you will also be able to get Unicode lists as return value. The support lies in the kernel and stdlib modules, why most applications (that does not explicitly require the file names to be in the ISO-latin-1 range) will benefit from the Unicode support without change.
+The Unicode file naming support was introduced with OTP release R14B01. A VM operating in Unicode file mode can work with files having names in any language or character set (as long as it's supported by the underlying OS and file system). The Unicode character list is used to denote file or directory names and if the file system content is listed, you will also be able to get Unicode lists as return value. The support lies in the Kernel and STDLIB modules, why most applications (that does not explicitly require the file names to be in the ISO-latin-1 range) will benefit from the Unicode support without change.
On Operating systems with mandatory Unicode file names, this means that you more easily conform to the file names of other (non Erlang) applications, and you can also process file names that, at least on Windows, were completely inaccessible (due to having names that could not be represented in ISO-latin-1). Also you will avoid creating incomprehensible file names on MacOSX as the vfs layer of the OS will accept all your file names as UTF-8 and will not rewrite them.
@@ -197,8 +203,9 @@ Eshell V5.7 (abort with ^G)Raw file names is introduced together with Unicode file name support in erts-5.8.2 (OTP R14B01). The reason "raw file names" is introduced in the system is to be able to consistently represent file names given in different encodings on the same system. Having the VM automatically translate a file name that is not in UTF-8 to a list of Unicode characters might seem practical, but this would open up for both duplicate file names and other inconsistent behavior. Consider a directory containing a file named "bjrn" in ISO-latin-1, while the Erlang VM is operating in Unicode file name mode (and therefore expecting UTF-8 file naming). The ISO-latin-1 name is not valid UTF-8 and one could be tempted to think that automatic conversion in for example
The core system of Erlang (kernel and stdlib) accepts raw file names except for loadable drivers and executables invoked using
Raw file names is introduced together with Unicode file name support in erts-5.8.2 (OTP R14B01). The reason "raw file names" is introduced in the system is to be able to consistently represent file names given in different encodings on the same system. Having the VM automatically translate a file name that is not in UTF-8 to a list of Unicode characters might seem practical, but this would open up for both duplicate file names and other inconsistent behavior. Consider a directory containing a file named "björn" in ISO-latin-1, while the Erlang VM is operating in Unicode file name mode (and therefore expecting UTF-8 file naming). The ISO-latin-1 name is not valid UTF-8 and one could be tempted to think that automatic conversion in for example
The core system of Erlang (Kernel and STDLIB) accepts raw file names except for loadable drivers and executables invoked using
To force Unicode file name translation mode on systems where this is not the default is considered experimental in OTP R14B01 due to the raw file names possibly being a new experience to the programmer and that the non core applications of OTP are not tested for compliance with raw file names yet. Unicode file name translation is expected to be default in future releases.
If working with raw file names, one can still conform to the encoding convention of the Erlang VM by using the
Even if you are operating without Unicode file naming translation automatically done by the VM, you can access and create files with names in UTF-8 encoding by using raw file names encoded as UTF-8. Enforcing the UTF-8 encoding regardless of the mode the Erlang VM is started in might, in some circumstances be a good idea, as the convention of using UTF-8 file names is spreading.
@@ -206,7 +213,7 @@ Eshell V5.7 (abort with ^G)MacOSXs vfs layer enforces UTF-8 file names in a quite aggressive way. Older versions did this by simply refusing to create non UTF-8 conforming file names, while newer versions replace offending bytes with the sequence "%HH", where HH is the original character in hexadecimal notation. As Unicode translation is enabled by default on MacOSX, the only way to come up against this is to either start the VM with the
MacOSX also reorganizes the names of files so that the representation of accents etc is denormalized, i.e. the character
MacOSX also reorganizes the names of files so that the representation of accents etc is denormalized, i.e. the character
When reading and writing to Unicode-aware entities, like the User or a file opened for Unicode translation, you will probably want to format text strings using the functions in
-1> io:format("~ts~n",[<<""/utf8>>]). - -ok -2> io:format("~s~n",[<<""/utf8>>]). +1> io:format("~ts~n",[<<"åäö"/utf8>>]). åäö +ok +2> io:format("~s~n",[<<"åäö"/utf8>>]). +åäö ok
Obviously the second
As long as the data is always lists, the "t" modifier can be used for any string, but when binary data is involved, care must be taken to make the tight choice of formatting characters.
The function
The Unicode string is returned as a Unicode list, why the return value of
+Eshell V5.10 (abort with ^G) +1> io_lib:format("~ts~n", ["θνιψοδε"]). +["θνιψοδε","\n"] +2> io:put_chars(io_lib:format("~ts~n", ["θνιψοδε"])). +θνιψοδε +ok+
The Unicode string is returned as a Unicode list, which is recognized as such since the Erlang shell uses the Unicode encoding. The Unicode list is valid input to the
s%:`=rrJO?rr3#`1]@=S3TL#:!AWs?rrdkBs![O=rrdSCrud="NWn2; -s6k`>JcC<$JcCf2J,~> -!$2%<#+^SDs8S]\rJguSs-AE=rrhICs,N-:rrIh?rr3,O8H4+1rr3#C;#UCo*W?!=Cp
s%:`=rrJO?rr3#`1]@=S3TL#:!AWs?rrdkBs![O=rrdSCrud="NWn2; -s6k`>JcC<$JcCf2J,~> -!$2%<#+^SDs8S]\rJguSs-AE=rrhICs,N-:rrIh?rr3,O8H4+1rr3#C;#UCo*W?!=Cp
s%:`=rrJO?rr3#`1]@=S3TL#:!AWs?rrdkBs![O=rrdSCrud="NWn2;
-s6k`>JcC<$JcCf2J,~>
-!$2%rrJa@qu6\_LAq2Uju<=#NrK%]k^NPcQi@!keO]^gTE"r]6W!a]!$2%rs-/E
-s-JqMX1J3.!EOLFrs;WHs8Ti>s8P^>rr3"eKDtlOkqi;rrfR8s"Wm>rsXFJs![O>s0sGQ
-ruh:9rrKi?JcC<$JcCf2J,~>
-!$2%rrJa@qu6\_LAq2Uju<=#NrK%]k^NPcQi@!keO]^gTE"r]6W!a]!$2%rs-/E
-s-JqMX1J3.!EOLFrs;WHs8Ti>s8P^>rr3"eKDtlOkqi;rrfR8s"Wm>rsXFJs![O>s0sGQ
-ruh:9rrKi?JcC<$JcCf2J,~>
-!$2%rrJa@qu6\_LAq2Uju<=#NrK%]k^NPcQi@!keO]^gTE"r]6W!a]!$2%rs-/E
-s-JqMX1J3.!EOLFrs;WHs8Ti>s8P^>rr3"eKDtlOkqi;rrfR8s"Wm>rsXFJs![O>s0sGQ
-ruh:9rrKi?JcC<$JcCf2J,~>
-!$2%rrMD9r\jsKs8SC>rr3,`2ui#ar\jsPec4`Or\kNefDjlJ2`F*s;#gQC2[23Qs8Qo>
-rr3,5@K5.jr\jgur;Qd"2u`g`g/U'j>EbER9%*_=%%2bJs&:`]2i[k;e49Ks"FB;3dR*pl%"IRB
-cojfgPl?E3K9+!NL>Brs'\0
-[oNJ.@D2[*!M"jps+13$s+14(s*t~>
-!$2%IAqu6]a0CSoAKpVf="P$'CI@pN='[0DRFK#6>hA08oCpfgPl?E3K9+!NL>Brs'\0
-[oNJ.@D2[*!M"jps+13$s+14(s*t~>
-!$2%IAqu6]a0CSoAKpVf="P$'CI@pN='[0DRFK#6>hA08oCpfgPl?E3K9+!NL>Brs'\0
-[oNJ.@D2[*!M"jps+13$s+14(s*t~>
-!$2(=!pX(@qYpTT4R`:NKpVf="P$'CI>RsX'X(@5FK#5r5/^V(CpfgPl?A%DU=!OHM>rs'\E
-aAr9?;m$&R!K28Ts+13$s+14(s*t~>
-!$2(=!pX(@qYpTT4R`:NKpVf="P$'CI>RsX'X(@5FK#5r5/^V(CpfgPl?A%DU=!OHM>rs'\E
-aAr9?;m$&R!K28Ts+13$s+14(s*t~>
-!$2(=!pX(@qYpTT4R`:NKpVf="P$'CI>RsX'X(@5FK#5r5/^V(CpfgPl?A%DU=!OHM>rs'\E
-aAr9?;m$&R!K28Ts+13$s+14(s*t~>
-"WdXCiHE09rrUPJp@&"^KpVf="P$'CI4>.]'JrYdFK!D[s28(?CpfgPl?A%DU=%'s[Js34F>
-aAr9?;`+G=!1\W?JcC<$JcFI(J,~>
-"WdXCiHE09rrUPJp@&"^KpVf="P$'CI4>.]'JrYdFK!D[s28(?CpfgPl?A%DU=%'s[Js34F>
-aAr9?;`+G=!1\W?JcC<$JcFI(J,~>
-"WdXCiHE09rrUPJp@&"^KpVf="P$'CI4>.]'JrYdFK!D[s28(?CpfgPl?A%DU=%'s[Js34F>
-aAr9?;`+G=!1\W?JcC<$JcFI(J,~>
-"