From cffcb7e445d6fdc8dc5e65a43ee04d5b7cb59c00 Mon Sep 17 00:00:00 2001
From: Hans Bolinder
The functionality described in EEP10 was implemented in Erlang/OTP - as of R13A, but that was by no means the end of it. In R14B01 support + R13A, but that was by no means the end of it. In Erlang/OTP R14B01 support for Unicode file names was added, although it was in no way complete and was by default disabled on platforms where no guarantee was given - for the file name encoding. With R16A came support for UTF-8 encoded + for the file name encoding. With Erlang/OTP R16A came support for UTF-8 encoded source code, among with enhancements to many of the applications to support both Unicode encoded file names as well as support for UTF-8 encoded files in several circumstances. Most notable is the support @@ -52,8 +52,8 @@ for UTF-8 and more support for Unicode character sets in the I/O-system.
-In 17.0, the encoding default for Erlang source files was - switched to UTF-8 and in 18.0 Erlang will support atoms in the full +
In Erlang/OTP 17.0, the encoding default for Erlang source files was + switched to UTF-8 and in Erlang/OTP 18.0 Erlang will support atoms in the full Unicode range, meaning full Unicode function and module names
@@ -222,7 +222,7 @@
%% -*- coding: utf-8 -*-
@@ -290,7 +290,7 @@
In Erlang, strings are actually lists of integers. A string was - up until R13 defined to be encoded in the ISO-latin-1 (ISO8859-1) + up until Erlang/OTP R13 defined to be encoded in the ISO-latin-1 (ISO8859-1) character set, which is, code point by code point, a sub-range of the Unicode character set.
The standard list encoding for strings was therefore easily
@@ -321,7 +321,7 @@
encoding has to be decided upon and the string should be converted
to a binary in the preferred encoding using
The Unicode file naming support was introduced with OTP release +
The Unicode file naming support was introduced with Erlang/OTP
R14B01. A VM operating in Unicode file name translation mode can
work with files having names in any language or character set (as
long as it is supported by the underlying OS and file system). The
@@ -709,7 +709,7 @@ Eshell V5.10.1 (abort with ^G)
problem even if it uses transparent file naming. Very few systems
have mixed file name encodings. A consistent UTF-8 named system will
work perfectly in Unicode file name mode. It was still however
- considered experimental in R14B01 and is still not the default on
+ considered experimental in Erlang/OTP R14B01 and is still not the default on
such systems. Unicode file name translation is turned on with the
Raw file names were introduced together with Unicode file name - support in erts-5.8.2 (OTP R14B01). The reason "raw file + support in erts-5.8.2 (Erlang/OTP R14B01). The reason "raw file names" was introduced in the system was to be able to consistently represent file names given in different encodings on the same system. Having the VM automatically translate a file name @@ -798,10 +798,10 @@ Eshell V5.10.1 (abort with ^G) the argument as a binary.
To force Unicode file name translation mode on systems where this
- is not the default was considered experimental in OTP R14B01 due to
+ is not the default was considered experimental in Erlang/OTP R14B01 due to
the fact that the initial implementation did not ignore wrongly
encoded file names, so that raw file names could spread unexpectedly
- throughout the system. Beginning with R16B, the wrongly encoded file
+ throughout the system. Beginning with Erlang/OTP R16B, the wrongly encoded file
names are only retrieved by special functions
(e.g.
You can check this option by calling io:printable_range/0,
- which in R16B will return This function returns the default encoding for Erlang source
files (if no encoding comment is present) in the currently
- running release. For R16 this returns The encoding of each file can be specified using comments as
described in
--
cgit v1.2.3