1. Zuhause
  2. Frage und Antwort
  3. Was ist der Unterschied zwischen EM Dash # 151; und # 8212 ;?

Was ist der Unterschied zwischen EM Dash # 151; und # 8212 ;?

2009-03-10 6 views
25

Ich habe eine ASCII-Datei, die ein EM-Dash enthält (- oder — in HTML). Der Hexadezimalwert ist 0x97. Wenn wir diese Datei durch eine Anwendung leiten, kommt sie als UTF-8 an und konvertiert das Zeichen in 0xC297, also — in HTML. Wenn wir diese Datei jedoch an eine andere Anwendung übergeben, wird das Zeichen in 0xE28094 oder — konvertiert.Was ist der Unterschied zwischen EM Dash # 151; und # 8212 ;?

Was würde diese Anwendungen veranlassen, diese Zeichen anders zu konvertieren? Ist es vielleicht eine Codepageeinstellung?

Quelle

2009-03-10 ilitirit

Antwort

34

& # 151; ist falsch. Wenn Sie numerische Zeichenverweise verwenden, bezieht sich die Nummer auf den Unicode-Codepunkt. Für Nummern unter 256 entspricht das dem Codepoint in ISO-8859-1. In 8859-1 gehört das Zeichen 151 zu den "C1-Steuercodes" und nicht zu einem Bindestrich oder einem anderen sichtbaren Zeichen.

Die Verwirrung entsteht, weil Zeichen 151 ein Strich in der Windows-Codepage 1252 (westeuropäisch) ist. Viele Leute denken, cp1252 ist das gleiche wie ISO-8859-1, aber in Wirklichkeit ist es nicht: die Zeichen im C1-Bereich (128 bis 159) sind unterschiedlich.

Die erste Anwendung liest Ihre "ASCII" -Datei * als ISO-8859-1, aber tatsächlich ist es wahrscheinlich cp1252 und Sie müssen einen Weg finden, die App darüber zu informieren, welche Kodierung sie erwarten muss.

(*: "ASCII" ist eine falsche Angabe, wenn in der Datei ein Bit gesetzt ist. Sie meinen wahrscheinlich "ANSI", was eigentlich eine falsche Bezeichnung ist, aber eine, die in der Windows-Welt stecken geblieben ist bedeuten "Text in der aktuellen System-Standard-Codepage codiert".)

Quelle

2009-03-10 17:51:55 bobince

5

Eine ASCII-Datei darf nicht das Zeichen 0x97 enthalten, da der ASCII-Zeichensatz nur von 0x00 bis 0x7F reicht. Daher ist Ihre Datei nicht ASCII, sondern eine andere Einzelbytecodierung. Die Windows-1250-Codierung hat zum Beispiel den em-Strich bei 0x97.

Wenn die Anwendungen die Textdatei mit einer anderen Kodierung als der entschlüsseln, die zum Erstellen der Datei verwendet wurde, ist jedes Zeichen oberhalb von 0x7F falsch.

In Unicode hat der em-Strich den Zeichencode 0x2014 oder 8212 in Dezimal.

Unicode Character 'EM DASH' (U+2014)

In einer Web-Seite, dass zum Beispiel Windows-1250 als Codierung verwendet, wird der Code — als em-dash machen:

<!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>

Quelle

2009-03-10 17:37:47 Guffa

14
  • &#151; is not em dash, wurde Ihr Text aus dem Bindestrich auf diesen Wert falsch übersetzt.
  • &#8212; ist die HTML-Dezimalstelle für em dash. Insbesondere verweist es auf den Unicode-Codepunkt 8212, der einen em-Bindestrich darstellt.
  • Ihre Datei ist kein ASCII, wenn sie einen Bindestrich enthält. ASCII-Zeichen codieren nur in den Dezimalbereich 0 - 127 und em dash ist kein Zeichen, das durch ASCII-Codierung dargestellt werden kann. Wenn Sie einen Strich als 0x97 (151 im Dezimalformat) gespeichert haben, haben Sie wahrscheinlich eine ANSI-Textdatei (alias Windows Codepage 1252 (w-1252)).

Ihre erste App ...
Die Daten wurden als ein in w-1252 codierter em-Strich gestartet. In w-1252 wird der Em-Strich auf den Dezimalwert 151 abgebildet (0x97 in hex oder 10010111 in binär).

Irgendwann wurde der em dash von Code bearbeitet, der dachte, dass die Bytes in Ihrer Datei ISO-8859-1-kodierten Text waren. Wenn dieser Code 0x97 als Zeichenkette interpretierte, mapped 0x97 to a character according to the iso-8859-1 encoding. In iso-8859-1 0x97 wird auf das Zeichen "Ende des geschützten Bereichs" abgebildet.

Als nächstes wurde die Zeichenkette, die der Code als Steuerzeichen "Ende des geschützten Bereichs" betrachtet, als utf-8 codiert. "End of guarded area" encoded in utf-8 is the two-byte sequence: 0xC2 0x97.

Ihre zweite App ...
Die Textdatei korrekt als w-1252 interpretiert wurde, so dass die 0x97 erkannt wird als em dash, die korrekt als em dash in utf-8 codiert wurde: 0xE2 0x80 0x94 .

Was dieses Verhalten beeinflusst
Nicht sicher, ob Sie mit Web-Anwendungen oder das, was es zu tun, aber das Konzept sollte gleich sein, was auch immer es ist. Wir hatten das gleiche 0x97-> 0xC297-Szenario in einer Web-App, in dem Menschen Daten in ein Formular eingeben. Ich fand, dass der Zeichensatz der Webseite als iso8859-1 deklariert wurde, und der beste Weg des Browsers, die w1252-Zeichen zu behandeln, war, sie einfach wie die iso-Bytes zu senden, ohne den Benutzer oder den Server zu alarmieren. Der Server empfängt die Daten als iso und konvertiert in utf-8, was zu 0xC297 führt.

Grundsätzlich jedes Mal, wenn eine App Text berührt, muss es erzählt werden, wie der Text codiert ist, sonst könnte es auf einen Systemstandard zurückfallen. In diesem Fall riskieren Sie eine Datenbeschädigung.

Quelle

2010-01-07 12:36:50

Verwandte Themen

 Verwandte Themen