I want convert U+0780 to UTF-8.
Table:
U+00000000 - U+0000007F 0xxxxxxx
U+00000080 - U+000007FF 110xxxxx 10xxxxxx
U+00000800 - U+0000FFFF 1110xxxx 10xxxxxx 10xxxxxx
U+00010000 - U+001FFFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
Convert 0780 from hex to binary.
00000111 10000000
I choose second line of table
110xxxxx 10xxxxxx
How I fill bits to 00000111 10000000 to template 110xxxxx 10xxxxxx
The template is 110xxxxx 10xxxxxx, so there are 11 bits available.
Take the 11 used bits of the character: 111 10000000, put them in the template in that order, left to right, five leftmost bits 11110 for the first byte and the remaining six bits 000000 for the second byte.
You get: 11011110 10000000.
Related
I am trying to understand the string character encoding of a proprietary file format (fp7-file format from Filemaker Pro).
I found that each character is obfuscated by XOR with 0b01011010 and that the string length is encoded using a single starting byte (max string length in Filemaker is 100 characters).
Encoding is a variable byte encoding, where by default ISO 8859-1 (Western) is used to encode most characters.
If a unicode character outside ISO 8859-1 is to be encoded, some sort of control characters are included into the string that modify the decoding of the next or several following characters. These control characters are using the ASCII control character space (0x01 to 0x1f in particular). This is were I am stuck, as I can't seem to find a pattern to how these control characters work.
Some examples of what I think I have found:
When encountering a control character 0x11 the following characters are created by adding 0x40 to the byte value, e.g. the character Ā (Unicode \U0100) is encoded as 0x11 0xC0 (0xC0 + 0x40 = 0x100).
When encountering the control character 0x10 the previous control character seems to be reset.
When encountering the control character 0x03 the next (only the next!) character is created by adding 0x100 to the byte value. If the control character 0x03 is preceeded by 0x1b then all following characters are created by adding 0x100.
An example string (0_ĀĐĠİŀŐŠŰƀƐƠưǀǐǠǰȀ), its unicode code points and the encoding in Filemaker:
char 0 _ Ā Đ Ġ İ ŀ Ő Š Ű ƀ Ɛ Ơ ư ǀ ǐ Ǡ ǰ Ȁ
unicode 30 5f 100 110 120 130 140 150 160 170 180 190 1a0 1b0 1c0 1d0 1e0 1f0 200
encoded 30 5f 11 c0 d0 e0 f0 3 40 3 50 3 60 3 70 1b 3 80 90 a0 b0 c0 d0 e0 f0 1c 4 80
As you can see the characters 0 and _ are encoded with their direct unicode/ASCII value. The characters ĀĐĠİ are encoded using the 0x11 control byte. Then ŀŐŠŰ are encoded using 0x03 for each character, then 0x1B 0x03 are used to encode the next 8 characters, etc.
Does this encoding scheme look familiar to anybody?
The rules are simple for characters up to 0x200, but then become more and more confusing, even to the point where they seem position dependent.
I can provide more examples for a weekend of puzzles and joy.
When I read The Swift Programming Language Strings and Characters. I don't know how U+203C (means !!) can represented by (226, 128, 188) in utf-8.
How did it happen ?
I hope you already know how UTF-8 reserves certain bits to indicate that the Unicode character occupies several bytes. (This website can help).
First, write 0x203C in binary:
0x230C = 10000000111100
So this character takes 16 bits to represent. Due to the "header bits" in the UTF-8 encoding scheme, it would take 3 bytes to encode it:
0x230C = 10 000000 111100
1st byte 2nd byte 3rd byte
-------- -------- --------
header 1110 10 10
actual data 10 000000 111100
-------------------------------------------
full byte 11100010 10000000 10111100
decimal 226 128 188
Is representing UTF-8 encoding in decimals even possible? I think only values till 255 would be correct, am I right?
As far as I know, we can only represent UTF-8 in hex or binary form.
I think it is possible. Let's look at an example:
The Unicode code point for ∫ is U+222B.
Its UTF-8 encoding is E2 88 AB, in hexadecimal representation. In octal, this would be 342 210 253. In decimal, it would be 226 136 171. That is, if you represent each byte separately.
If you look at the same 3 bytes as a single number, you have E288AB in hexadecimal; 70504253 in octal; and 14846123 in decimal.
I have to represent a character given by the hexadecimal 1D524 in its utf-8 form (11110xxx 10xxxxxx 10xxxxxx 10xxxxxx).
I've already converted the hexadecimal chain to binary, which gives me: 1 1101 0101 0010 0100. But when I try to represent those in utf-8, I get 11110111 10010101 10001001 1000xxxx. Assuming all bytes should have 8 bits, I'm missing 4 bits, so obviously I'm doing something wrong.
Help?
For an input "hello", SHA-1 returns "aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d", which are 40 hex outputs. I know 1 byte can denote as 1 character, so the 160 bits output should be able to converted to 20 characters. But when I look up "aa" in an ASCII table, there are no such hex value, and I'm confused about that. How to map 160 bits SHA-1 string as 20 characters in ANSI?
ASCII only has 128 characters (7 bits), while ANSI has 256 (8 bits). As to the ANSI value of hex value AA (decimal 170), the corresponding ANSI character would be ª (see for example here).
Now, you have to keep in mind that a number of both ASCII and ANSI characters (0-31) are non-printable control characters (system bell, null character, etc.), so turning your hash into a readable 20 character string will be not possible in most cases. For instance, your example contains the hex value 0F, which would translate to a shift-in character.