Quelle est la différence entre EM Dash # 151; et # 8212 ;?

Question

J'ai un fichier ASCII contenant un tableau de bord EM (& # 8212; ou & mdash; en HTML). La valeur hexadécimale est 0x97. Lorsque nous transmettons ce fichier à une application, il se présente sous la forme UTF-8 et convertit le caractère en 0xC297, qui est & amp; # 151; en HTML. Cependant, lorsque nous transmettons ce fichier via une application différente, il convertit le caractère en 0xE28094 ou & amp; # 8212; .

Qu'est-ce qui amènerait ces applications à convertir ces caractères différemment? Est-ce peut-être un paramètre de page de code?

Answer 1

& amp; # 151; est faux. Lorsque vous utilisez des références de caractères numériques, le numéro fait référence au point de code Unicode. Pour les nombres inférieurs à 256, cela correspond au point de code défini dans ISO-8859-1. Dans 8859-1, le caractère 151 fait partie des & # 8220; codes de contrôle C1 & # 8221 ;, et non d'un tiret ou de tout autre caractère visible.

La confusion vient du fait que le caractère 151 est un tiret dans la page de code Windows 1252 (Europe occidentale). Beaucoup de gens pensent que cp1252 est la même chose que ISO-8859-1, mais en réalité, ce n’est pas le cas: les caractères de la plage C1 (128 à 159) sont différents.

La première application lit votre & # 8220; ASCII & # 8221; fichier * en tant que ISO-8859-1, mais en réalité il s’agit probablement de cp1252 et vous aurez besoin d’un moyen de préciser à l’application quel encodage elle doit attendre.

(*: & # 8220; ASCII & # 8221; est impropre si le fichier contient des caractères de jeu de bits supérieurs. Vous voulez probablement dire & # 8220; ANSI & # 8221 ;, ce qui est vraiment aussi un abus de langage, l’un qui est bloqué dans le monde Windows pour signifier le texte codé dans la page de code par défaut du système actuel & # 8221;.)

Answer 2

• & amp; # 151; n'est pas em dash , votre texte a été mal traduit de em dash à cette valeur.
• & amp; # 8212; est l'entité décimale HTML pour em dash. Plus précisément, il fait référence au point de code Unicode 8212 qui représente un tiret instantané.
• Votre fichier n’est pas ASCII s’il contient un tiret em. Les caractères ASCII n'encodent que dans la plage décimale comprise entre 0 et 127 et em dash n'est pas un caractère pouvant être représenté par l'encodage ASCII. Si vous avez un tableau de bord stocké sous la forme 0x97 (151 en décimal), vous avez probablement un fichier texte ANSI (également appelé Windows Codepage 1252 (w-1252)).

Votre première application ...
Les données ont commencé comme un tiret électronique codé en w-1252. Dans w-1252, le tiret em est mappé sur la valeur décimale 151 (0x97 en hexadécimal ou 10010111 en binaire).

À un moment donné, le tiret a été traité par un code qui pensait que les octets de votre fichier étaient du texte codé en iso-8859-1. Lorsque ce code interprétait 0x97 comme une chaîne / un caractère, il a mappé 0x97 sur un caractère selon le codage iso-8859-1 . En iso-8859-1 0x97, le caractère "Fin de la zone gardée" est mappé.

Ensuite, la chaîne qui, selon le code, est la "fin de la zone protégée". contrôle char, a été codé en tant que utf-8. " Fin de la zone surveillée " La séquence à deux octets: 0xC2 0x97 est codée dans utf-8.

Votre deuxième application ...
Le fichier texte a été correctement interprété en tant que w-1252; par conséquent, 0x97 est reconnu comme un tiret, qui a été correctement codé comme tiret dans utf-8: 0xE2 0x80 0x94.

Qu'est-ce qui influence ce comportement
Vous ne savez pas si vous utilisez des applications Web ou quoi, mais le concept devrait être le même quel qu'il soit. Nous avions le même scénario 0x97- > 0xC297 dans une application Web où les utilisateurs entraient des données dans un formulaire. J'ai constaté que le jeu de caractères de la page Web avait été déclaré iso8859-1 et que le meilleur moyen du navigateur de gérer les caractères w1252 consistait simplement à les envoyer comme des octets iso sans alerter l'utilisateur ou le serveur. Le serveur reçoit les données pense qu'il est iso et convertit en utf-8, résultant en 0xC297.

En gros, chaque fois qu'une application touche du texte, il faut lui dire comment le texte est codé, sinon le système pourrait revenir à une valeur par défaut. Si cela se produit, vous risquez la corruption des données.

Answer 3

Conformément à la référence d'entité de caractère de la spécification HTML4 . , l’emdash est & amp; 8212; ( U + 2014 ).

Answer 4

Un fichier ASCII ne peut pas contenir le caractère 0x97, car le jeu de caractères ASCII est uniquement compris entre 0x00 et 0x7F. Par conséquent, votre fichier n’est pas ASCII, mais un autre codage à un octet. Le codage windows-1250, par exemple, a le tiret électronique à 0x97.

Si les applications décodent le fichier texte en utilisant un codage autre que celui utilisé pour créer le fichier, tout caractère supérieur à 0x7F sera erroné.

En unicode, le tiret électronique a le code de caractère 0x2014 ou 8212 en décimal.

Caractère Unicode 'EM DASH' (U + 2014)

Dans une page Web utilisant par exemple Windows-1250 comme encodage, le code & amp; # 151; sera affiché sous forme de tiret:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>em-dash</title>
    <meta http-equiv="content-type" content="text/html; charset=windows-1250"/>
</head>
<body>
    <div>&#151;</div>
</body>
</html>