Насколько UTF-8 безопасен относительно символов ASCII? - PullRequest
Новая
       62

Насколько UTF-8 безопасен относительно символов ASCII?

0 голосов
/ 17 декабря 2018

Я читал в Википедии и обнаружил следующее: 

"Since ASCII bytes do not occur when encoding non-ASCII code points into UTF-8, 
UTF-8 is safe to use within most programming and document languages that 
interpret certain ASCII characters in a special way, such as "/" in filenames, 
"\" in escape sequences, and "%" in printf."

Что я не могу понять, так это то, как это может быть проблемой, даже если это произошло.Если приложение, обрабатывающее байты, поддерживает utf-8, то это простая ситуация, и проблем не возникнет, поскольку она будет знать, как интерпретировать их в контексте других байтов предшественника / преемника.И если этого не произойдет, то, в первую очередь, он не имеет к этому никакого отношения, и тот факт, что он может встретить комбинацию битов, которые представляют собой символ формата, такой как '\', не причинит больше вреда, чем уже обрабатывает его впервое место.

1 Ответ

0 голосов
/ 17 декабря 2018

Взять, к примеру, PHP.В PHP нет родного понимания кодировок (здесь есть несколько звездочек и сносок, но, скажем, нет).Он ищет определенные конкретные байты в исходном коде, которые что-то для него значат, и в основном просто проходит через все остальное, не имеющее для него особого значения.Например: 

$foo = "bar $baz 42";

Это запускает интерполяцию строки;PHP попытается вставить переменную $baz в эту строку.Это делается путем поиска байта 0x24 (ASCII "$") и следующего байта "не слова" в строке, что приводит к поиску имени переменной $baz внутри строки.Что-нибудь еще в строке, через которую он просто проходит, как есть.

Вы можете сделать это на PHP: 

echo "意味分からない";

Все, что PHP видит здесь, это некоторый двоичный двоичный объект, который не представляет для него особого интереса.,Он не поддерживает и не понимает этих персонажей, но и не пытается ничего с ними поделать.Он просто пропускает двоичные данные как есть и, таким образом, выдает желаемое японское предложение.

Теперь, если бы мы написали это предложение в некоторой не ASCII-безопасной кодировке, такой как, скажем, ISO-2022-JP-3, это будет: 

1b24 4230 554c 234a 2c24 2b24 6924 4a24 241b 2842

Вы заметите там 24 байт.Если бы вы могли создать действительный файл PHP, который содержал эти байты между двойными кавычками, PHP попытался бы интерпретировать эти 0x24 байты как $ и попытался бы интерполировать там переменные. 

$ cat /tmp/foo.php 
<?php echo "B0UL#J,$+$i$J$$";
$ xxd /tmp/foo.php 
00000000: 3c3f 7068 7020 6563 686f 2022 1b24 4230  <?php echo ".$B0
00000010: 554c 234a 2c24 2b24 6924 4a24 241b 2842  UL#J,$+$i$J$$.(B
00000020: 223b 0a                                  ";.
$ php /tmp/foo.php 
PHP Notice:  Undefined variable: B0UL in /tmp/foo.php on line 1
PHP Notice:  Undefined variable: i in /tmp/foo.php on line 1
PHP Notice:  Undefined variable: J in /tmp/foo.php on line 1

Это один пример ситуации, когда важна совместимость UTF-8 с ASCII.

...