cerc-io/solidity
16
0
Fork 0
mirror of https://github.com/ethereum/solidity synced 2023-10-03 13:03:40 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Correct all UTF-8 spellings

Browse Source
This commit is contained in:
Denton Liu 2016-08-10 14:52:11 -04:00
parent 2a492f59c9
commit 1634a79bd8
2 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
docs/frequently-asked-questions.rst
View File

@ -399,7 +399,7 @@ What character set does Solidity use?
===================================== =====================================
Solidity is character set agnostic concerning strings in the source code, although Solidity is character set agnostic concerning strings in the source code, although
utf-8 is recommended. Identifiers (variables, functions, ...) can only use UTF-8 is recommended. Identifiers (variables, functions, ...) can only use
ASCII. ASCII.
What are some examples of basic string manipulation (``substring``, ``indexOf``, ``charAt``, etc)? What are some examples of basic string manipulation (``substring``, ``indexOf``, ``charAt``, etc)?
@ -741,15 +741,15 @@ see a 32-byte hex value, this is just ``"stringliteral"`` in hex.
The type ``bytes`` is similar, only that it can change its length. The type ``bytes`` is similar, only that it can change its length.
Finally, ``string`` is basically identical to ``bytes`` only that it is assumed Finally, ``string`` is basically identical to ``bytes`` only that it is assumed
to hold the utf-8 encoding of a real string. Since ``string`` stores the to hold the UTF-8 encoding of a real string. Since ``string`` stores the
data in utf-8 encoding it is quite expensive to compute the number of data in UTF-8 encoding it is quite expensive to compute the number of
characters in the string (the encoding of some characters takes more characters in the string (the encoding of some characters takes more
than a single byte). Because of that, ``string s; s.length`` is not yet than a single byte). Because of that, ``string s; s.length`` is not yet
supported and not even index access ``s[2]``. But if you want to access supported and not even index access ``s[2]``. But if you want to access
the low-level byte encoding of the string, you can use the low-level byte encoding of the string, you can use
``bytes(s).length`` and ``bytes(s)[2]`` which will result in the number ``bytes(s).length`` and ``bytes(s)[2]`` which will result in the number
of bytes in the utf-8 encoding of the string (not the number of of bytes in the UTF-8 encoding of the string (not the number of
characters) and the second byte (not character) of the utf-8 encoded characters) and the second byte (not character) of the UTF-8 encoded
string, respectively. string, respectively.

2
docs/types.rst
View File

@ -147,7 +147,7 @@ Dynamically-sized byte array
``bytes``: ``bytes``:
Dynamically-sized byte array, see :ref:`arrays`. Not a value-type! Dynamically-sized byte array, see :ref:`arrays`. Not a value-type!
``string``: ``string``:
Dynamically-sized UTF8-encoded string, see :ref:`arrays`. Not a value-type! Dynamically-sized UTF-8-encoded string, see :ref:`arrays`. Not a value-type!
As a rule of thumb, use ``bytes`` for arbitrary-length raw byte data and ``string`` As a rule of thumb, use ``bytes`` for arbitrary-length raw byte data and ``string``
for arbitrary-length string (UTF-8) data. If you can limit the length to a certain for arbitrary-length string (UTF-8) data. If you can limit the length to a certain