Zum Hauptinhalt springen

6. Byte-Reihenfolgezeichen (Byte order mark - BOM)

Definition​

Das UCS-Zeichen U+FEFF „ZERO WIDTH NO-BREAK SPACE" ist auch informell als „BYTE ORDER MARK" (abgekürzt „BOM") bekannt. Dieses Zeichen kann als echtes „ZERO WIDTH NO-BREAK SPACE" im Text verwendet werden, aber der Name BOM deutet eine zweite mögliche Verwendung des Zeichens an: das Voranstellen eines Zeichens U+FEFF vor einen UCS-Zeichenstrom als „Signatur".

Verwendung als Signatur​

Ein Empfänger eines solchen serialisierten Stroms kann dann das initiale Zeichen als Hinweis verwenden, dass:

  • Der Strom aus UCS-Zeichen besteht
  • Zur Erkennung, welche UCS-Kodierung beteiligt ist
  • Bei Kodierungen mit einer Mehrbyte-Kodierungseinheit als Mittel zur Erkennung der Byte-Serialisierungsreihenfolge

UTF-8 und BOM​

Da UTF-8 eine Ein-Byte-Kodierungseinheit hat, ist diese letztere Funktion nutzlos, und das BOM wird immer als Byte-Sequenz EF BB BF erscheinen.

Interpretationsregeln​

Position ist wichtig​

Es ist wichtig zu verstehen, dass das Zeichen U+FEFF, das an einer anderen Position als am Anfang eines Stroms erscheint, mit der Semantik eines geschützten Leerzeichens ohne Breite interpretiert werden MUSS (MUST) und NICHT (MUST NOT) als Signatur interpretiert werden darf.

Überlegungen zur Entfernung​

Wenn es als Signatur interpretiert wird, schlägt der Unicode-Standard vor, dass ein initiales U+FEFF-Zeichen vor der Textverarbeitung entfernt werden kann. Eine solche Entfernung ist in einigen Fällen notwendig (z. B. beim Konkatenieren zweier Zeichenketten, da sonst die resultierende Zeichenkette ein unbeabsichtigtes „ZERO WIDTH NO-BREAK SPACE" am Verbindungspunkt enthalten könnte), könnte aber einen Prozess in einer anderen Schicht beeinflussen (wie eine digitale Signatur oder eine Zeichenzählung), der sich auf das Vorhandensein aller Zeichen im Strom verlässt.

Empfehlung​

Es wird daher EMPFOHLEN (RECOMMENDED):

  • Ein als Signatur interpretiertes initiales U+FEFF ohne guten Grund nicht zu entfernen
  • Es zu ignorieren, anstatt es zu entfernen, wenn dies angemessen ist (wie bei der Anzeige)
  • Es nur dann zu entfernen, wenn es wirklich notwendig ist

Mehrdeutigkeitsprobleme​

U+FEFF an der ersten Position eines Stroms KANN (MAY) als geschütztes Leerzeichen ohne Breite interpretiert werden und ist nicht immer eine Signatur.

Unicode 3.2-Ergänzung​

In einem Versuch, diese Unsicherheit zu verringern, fügt Unicode 3.2 ein neues Zeichen hinzu, U+2060 „WORD JOINER", mit genau derselben Semantik und Verwendung wie U+FEFF, außer der Signaturfunktion, und empfiehlt nachdrücklich dessen ausschließliche Verwendung zur Ausdrückung der Wortverbindungssemantik.

Zukünftige Klarheit​

Letztendlich wird die Befolgung dieser Empfehlung es fast sicher machen, dass jedes initiale U+FEFF eine Signatur ist und kein beabsichtigtes „ZERO WIDTH NO-BREAK SPACE".

Richtlinien für Protokolle​

In der Zwischenzeit bleibt die Unsicherheit leider bestehen und kann Internetprotokolle beeinflussen. Protokollspezifikationen KÖNNEN (MAY) die Verwendung von U+FEFF als Signatur einschränken, um die potenziellen negativen Auswirkungen dieser Unsicherheit zu reduzieren oder zu beseitigen.

Im Interesse eines Gleichgewichts zwischen den Vorteilen (Reduzierung der Unsicherheit) und den Nachteilen (Verlust der Signaturfunktion) solcher Einschränkungen ist es nützlich, einige Fälle zu unterscheiden:

Fall 1: Obligatorisches UTF-8​

Ein Protokoll SOLLTE (SHOULD) die Verwendung von U+FEFF als Signatur für textuelle Protokollelemente verbieten, die das Protokoll immer in UTF-8 vorschreibt, da die Signaturfunktion in diesen Fällen völlig nutzlos ist.

Fall 2: Zuverlässige Identifikationsmechanismen​

Ein Protokoll SOLLTE (SHOULD) auch die Verwendung von U+FEFF als Signatur für textuelle Protokollelemente verbieten, für die das Protokoll Mechanismen zur Identifikation der Zeichenkodierung bereitstellt, wenn erwartet wird, dass Protokollimplementierungen in der Lage sind, die Mechanismen immer korrekt zu verwenden.

Dies ist der Fall, wenn die Protokollelemente eng unter der Kontrolle der Implementierung vom Zeitpunkt ihrer Erstellung bis zum Zeitpunkt ihrer Übertragung (korrekt gekennzeichnet) gehalten werden.

Fall 3: Keine Identifikationsmechanismen​

Ein Protokoll SOLLTE NICHT (SHOULD NOT) die Verwendung von U+FEFF als Signatur für textuelle Protokollelemente verbieten, für die das Protokoll keine Mechanismen zur Identifikation der Zeichenkodierung bereitstellt, wenn:

  • Ein Verbot nicht durchsetzbar wäre, oder
  • Es erwartet wird, dass Protokollimplementierungen nicht in der Lage sind, die Mechanismen immer korrekt zu verwenden

Diese letzten beiden Fälle treten wahrscheinlich bei größeren Protokollelementen wie MIME-Entitäten auf, insbesondere wenn Protokollimplementierungen solche Entitäten erhalten von:

  • Dateisystemen
  • Protokollen, die keine Kodierungsidentifikationsmechanismen für Nutzdaten haben (wie FTP)
  • Anderen Protokollen, die keine korrekte Identifikation der Zeichenkodierung garantieren (wie HTTP)

Implementierungshinweise​

Wenn verboten​

Wenn ein Protokoll die Verwendung von U+FEFF als Signatur für ein bestimmtes Protokollelement verbietet, dann MUSS (MUST) jedes initiale U+FEFF in diesem Protokollelement als „ZERO WIDTH NO-BREAK SPACE" interpretiert werden.

Wenn nicht verboten​

Wenn ein Protokoll die Verwendung von U+FEFF als Signatur für ein bestimmtes Protokollelement nicht verbietet, dann SOLLTEN (SHOULD) Implementierungen darauf vorbereitet sein:

  • Eine Signatur in diesem Element zu handhaben
  • Angemessen zu reagieren: die Signatur zur Identifikation der Zeichenkodierung zu verwenden, falls erforderlich
  • Die Signatur angemessen zu entfernen oder zu ignorieren
Letztes Update am