Matter im Überblick

Im Laufe der letzten Jahre und Jahrzehnte sind einige Smart Home-Standards auf den Markt gekommen. Mit Matter ist nun ein neuer Standard angetreten, welcher den Smart Home-Markt aufrollen möchte.

Doch abseits der für den Endnutzer gedachten Versprechen, welche Vorteile er bringen soll, wird erstaunlich wenig über die technischen Hintergründe gesprochen.

Allerdings helfen diese Hintergründe Matter und seine Möglichkeiten zu verstehen. In diesem Artikel sollen die Hintergründe von Matter beleuchtet und gezeigt werden, wie Matter abseits der Marketingversprechen funktioniert.

Bestehende Standards

Matter ist beileibe nicht der erste Standard, welcher sich mit dem Thema Smart Home beschäftigt. Vor ihm gab und gibt es Standards wie Z-Wave, EnOcean und Zigbee. Letzterer spielt bei Matter organisatorisch eine besondere Rolle.

Je nach Standard werden unterschiedlichste Technologien und Funksysteme genutzt, wie das vermaschte Netzwerk, welches Z-Wave-Geräte untereinander aufbauen.

Das Problem an diesen Systemen ist, dass sie meist zueinander inkompatibel sind. Über Lösungen wie Home Assistant oder Homee können diese unterschiedlichen Systeme zur Zusammenarbeit gebracht werden.

Allerdings wird auch hier in vielen Fällen nur eine begrenzte Anzahl an Hardware unterstützt. Eine allumfassende Lösung stellt dies meist nicht dar.

Auch ins heimische Funknetz eingebundene Geräte werden gerne für die Smart Home-Anwendungen genutzt, welche auch durch ihren günstigen Preis bestechen können.

Aus Sicht von Entwickler sind unterschiedlichste Standards ein Problem. Je nach Firmengröße kann sich nur für einen Standard entschieden werden, da zusätzlich zu unterstützende Standards mehr Entwicklungsaufwand und damit am Ende mehr Kosten bedeuten.

Daneben sind die unterschiedlichen Standards zwar mehr oder weniger gleichwertig, allerdings gibt es eine gewisse Fragmentierung bei den Geräteklassen, so sind Leuchtmittel vorwiegend mit dem Zigbee-Standard verheiratet oder werden über teils obskure Wi-Fi-Lösungen angebunden.

Zwar existieren auch Beleuchtungslösungen für Z-Wave, allerdings sind diese in ihrer Auswahl beschränkt und der Preis ist in vielen Fällen höher als bei den Zigbee-Varianten.

Es gibt es Hersteller, welche mehrere Systeme unterstützen und die gleichen Produkte wie schaltbare Steckdosen in unterschiedlichen Varianten, je nach Smart Home-System, anbieten.

Für den Kunden bedeutet diese Auswahl und die damit verbundenen Probleme wie die Berücksichtigung der Kompatibilität, dass er meist zögerlich zu Smart Home-Produkten greift. Aus Sicht der Hersteller und der Kunden ist dies eine suboptimale Situation: voneinander abgeschirmte Ökosysteme und Geräte, die nur unter Umständen miteinander genutzt werden können.

Smart Home-Markt

Für das Jahr 2022 wird von einem Umsatz im Smart Home-Markt von über einhundert Milliarden Euro ausgegangen.

Allerdings bedingt durch die Fragmentierung des Marktes, entspricht dieser Umsatz nicht dem, der vor einigen Jahren erwartet wurde. So wurde unter anderem von einer höheren Durchdringung des Marktes ausgegangen.

Aktuell nutzen knapp 15 % aller Haushalte, weltweit gesehen, Smart Home-Technik in ihrem Haus oder ihrer Wohnung. Bedingt durch die Vorteile, welche Matter bieten soll und die damit einhergehende Vereinheitlichung, soll dem Smart Home-Markt neues Leben eingehaucht werden.

Das Matter-Versprechen

Matter will die bestehenden Probleme anderer Standards lösen. Der Standard sieht sich als Smart Home-Interoperabilitätsprotokoll und definiert sich als Anwendungsschicht, welche existierende Protokolle wie Thread und Wi-Fi nutzt, um seine Aufgabe, eine Smart Home-Umgebung darzustellen und zu verwalten, zu erfüllen.

Im Grundsatz geht es darum, dass der neue Standard unabhängig von den einzelnen Herstellern sein soll. Auch soll es jedem Hersteller von Hardware möglich sein, den neuen Standard zu implementieren.

Dem Endnutzer wird die Kompatibilität, aller Matter-Geräte untereinander, versprochen. Daneben soll in Zukunft auf proprietäre Bridges und Hubs, welche zur Anbindung bestimmter Systeme genutzt werden, verzichtet werden können.

Eine weitere wichtige Eigenschaft von Matter ist, dass die Steuerung zwar in der Theorie an Cloud-Systeme angebunden werden kann, aber immer lokal funktionieren muss.

Aus Sicht des Datenschutzes und der Betriebssicherheit ist dies eine erfreuliche Entwicklung, da Steuersignale nun nicht mehr die halbe Welt umrunden müssen, bevor sie wieder im eigenen Zuhause ankommen. Auch die Zuverlässigkeit stärkt dies in der Theorie, da auch beim Wegfall der Internetverbindung das eigene Smart Home noch funktioniert.

Für die Einrichtung von Matter-Geräten werden nicht mehr unbedingt die Third-Party-Apps der jeweiligen Hersteller benötigt, sondern diese können zentral über Apps z. B. der Home-App unter iOS hinzugefügt werden.

Connectivity Standards Alliance

Organisatorisch wird der Matter-Standard von der Connectivity Standards Alliance (CSA) betreut. Diese ging aus der Zigbee Alliance, welche 2002 gegründet wurde, hervor, welche sich für den gleichnamigen Zigbee-Standard verantwortlich zeichnet.

Mittlerweile sind über 500 Firmen unter dem Dach der Connectivity Standards Alliance vereint. Dazu gehören Unternehmen wie Amazon, Apple, Comcast, Google, IKEA, Infineon, LG, Nordic Semiconductor und Samsung.

Von der Idee zum Standard

Erste Lebenszeichen des Matter-Standards gab es im Dezember 2019. Damals kündigten unter anderem Amazon, Apple und Samsung sowie die Zigbee Aliance an, dass eine Zusammenarbeit für das Projekt Connected Home over IP beschlossen wurde.

Knapp anderthalb Jahre nach der ersten Ankündigung wurde aus Connected Home over IP schließlich Matter. Im gleichen Zuge wurde durch eine Umbenennung aus der Zigbee Alliance die Connectivity Standards Alliance.

Nach etwa drei Jahren Zeit der Planung und Entwicklung erschien im Oktober 2022 mit der Version 1.0 die erste Iteration des Standards. Hier wurden neben der eigentlichen Standardbeschreibung unterschiedliche Produktkategorien wie Beleuchtungslösungen, Sicherheitssensorik, Thermostate, Türschlösser und einige andere spezifiziert.

Während der Entwicklung gab es bedingt durch Faktoren wie die Coronapandemie und Verzögerungen bei den Gerätetests einige Verschiebungen, welche dann schlussendlich zum Veröffentlichungstermin im Oktober 2022 führten. Im November 2022 wurde Matter offiziell auf einem Launch-Event in Amsterdam vorgestellt.

In der nächsten Iteration des Standards, der Version 2.0, welche im März bzw. April 2024 erscheinen soll, sollen unter anderem die unterstützten Geräte um Klassen wie Staubsauger-Roboter, Rauchmelder, Kameras und einige andere erweitert werden.

Architektur

Aus architektonischer Sicht betrachtet ist Matter ein Applikationsprotokoll, welches auf bestehenden Technologien aufsetzt. Grundlage für das Matter-Protokoll bildet IPv6.

Matter setzt als Applikationsprotokoll auf vorhandenen Technologien auf

Der Matter-Protokollstack selbst besteht aus unterschiedlichsten Schichten, welche jeweils bestimmte fachliche Anforderungen erfüllen.

Die Schichten des Matter-Protokollstack

Die Anwendungsschicht (Application Layer) innerhalb des Matter-Protokollstacks implementiert die dem Gerät eigene Businesslogik. Im Falle einer schaltbaren Steckdose wäre dies die Logik, um das Gerät ein- und auszuschalten. Aktionen in der Anwendungsschicht führen zur Änderung im Datenmodell (Data Model).

Im Datenmodell werden die Daten für das entsprechende Gerät gehalten, z. B. ob das Gerät aktuell angeschaltet ist oder bei einem Leuchtmittel, die aktuell ausgewählte Leuchtfarbe.

Für die Interaktion von Außen werden im Interaction Model bestimmte Interaktionen definiert, welche von Außen geschrieben oder gelesen werden können. Eine solche Interaktion löst dann eine Logik in der Anwendungsschicht des Gerätes aus, um die entsprechenden Aktionen auszulösen.

Über das Interaction Modell kann eine Aktion definiert werden und über die Action Framing-Schicht wird sie schließlich in ein binäres Format serialisiert und dieses an die Security-Schicht übergeben.

In dieser wird die Nachricht verschlüsselt und ein Message Authentication Code angehangen. Damit soll sichergestellt werden, dass die Daten sicher und verschlüsselt zwischen den Instanzen bzw. Geräten übertragen werden.

Damit sind die Daten für die Nachricht serialisiert, verschlüsselt und kryptografisch signiert und werden an die Message Framing-Schicht übergeben, in welcher die endgültige Payload, welche schlussendlich über das Netzwerk verschickt wird, erzeugt wird. In Rahmen dieses Prozesses werden Headerfelder ergänzt, welche unter anderem Routing-Informationen enthalten können.

Anschließend wird das Ganze an die Transportschicht übergeben und findet so seinen Weg durch das Netzwerk, bis es beim definierten Empfänger ankommt. Dort angekommen wird der Matter-Protokollstack in umgekehrter Reihenfolge durchlaufen, bis schlussendlich wieder die eigentliche Nachricht in der Anwendungsschicht verarbeitet werden kann.

Fabric, Nodes und Controller

Im Matter-Standard werden einige Begriffe definiert, deren Wissen um die Bedeutung ein Verständnis des Standards erleichtert.

Ein zentraler Begriff im Matter-Standard ist die Fabric. Bei einer Fabric handelt es sich um einen logischen Verbund von Knoten (Nodes), welche eine gemeinsame Vertrauensbasis (Common Root of Trust) und einen gemeinsamen verteilten Konfigurationsstatus besitzen.

Ein Knoten (Node) ist im Matter-Standard definiert als eine Entität, welche den Matter Protokollstack unterstützt und nach der Kommissionierung über eine Operational Node ID und Node Operational Credentials verfügt.

Eine schaltbare Steckdose

Dabei ist ein Node nicht unbedingt gleichzusetzen mit einem Gerät. Ein Gerät, wie eine schaltbare Steckdose kann in der Theorie mehrere Knoten beinhalten, welche wiederum zu mehreren Fabrics gehören können.

Daneben gibt es im Matter-Standard den Begriff des Controllers. Dieser ist definiert als ein Matter-Knoten, welcher die Berechtigung hat einen oder mehrere Knoten zu kontrollieren. Dies kann z. B. das Smart Home-System sein oder ein iPhone mit der entsprechenden Home-App. Matter unterstützt per Design unterschiedlichste Controller in einem Matter-Netzwerk. Dieses Feature wird als Multi-Admin bezeichnet.

Kerntechnologien

Für Matter-Netzwerke, sind einige Kerntechnologien definiert, welche im Rahmen des Standards genutzt werden.

Für die Kommunikation der Geräte untereinander wird Wi-Fi, Ethernet oder Thread benutzt, für die Kommissionierung Bluetooth LE.

Bluetooth LE

Bluetooth LE wird im Matter-Standard genutzt, allerdings nicht für die Kommunikation der Geräte untereinander. Stattdessen wird Bluetooth LE für Kommissionierung (commission, im Matter-Standard) der Geräte genutzt.

Nach der Definition des Matter-Standards wird bei der Kommissionierung ein Node in die Fabric eingebracht, also das Gerät dem Matter-Netzwerk hinzugefügt.

Im Rahmen dessen werden die Zugangsdaten des Netzwerkes und andere für die Kommissionierung benötigten Informationen auf das Gerät übertragen.

Im Anwendungsfall würde dies so aussehen, dass der Nutzer einen QR-Code scannt, welcher die Informationen über das Gerät enthält und anschließend die Kommissionierung mittels Bluetooth LE durchgeführt wird.

Diese Informationen müssen nicht unbedingt als QR-Code geliefert werden. In der Theorie kann auch NFC als Technologie benutzt werden oder die enthaltenen Informationen einfach als kodierte Zeichenkette auf dem Gerät aufgedruckt sein oder dem Handbuch beiliegen.

Dies ermöglicht eine einfache Konfiguration und Einbindung der Geräte aus Sicht des Endbenutzers. Ist die Kommissionierung abgeschlossen und das Gerät damit in das Matter-Netzwerk eingebunden, nutzt das Gerät Bluetooth LE nicht mehr.

Anbindung der Smart Home-Geräte

In den meisten praxisnahen Fällen wird die Anbindung von Geräten meist auf die Anbindung per Thread und Wi-Fi hinauslaufen. Bei Wi-Fi im Heimbereich sind alle Geräte mehrheitlich mit einem Access Point verbunden. Bei Thread hingegen handelt es sich um ein vermaschtes Netz, welche über Border-Router mit dem Rest des Netzwerkes verbunden ist.

Thread

In einem Smart Home sind eine Reihe von Aktoren, wie schaltbare Steckdosen und Ähnliches verbaut. Daneben gibt es dann noch Sensorik, z. B. in Form von Temperatur- und Bewegungssensoren.

Sensoren, wie Temperatur oder Bewegungssensoren, laufen mehrheitlich mit Batteriestrom und eignen sich damit nicht für energieintensive Techniken wie Wi-Fi, um ihre Daten von A nach B zu transportieren.

Ein batteriebetriebener Sensor

Hier kommt das Protokoll Thread ins Spiel. Dieses ist darauf ausgelegt, Geräte miteinander zu verbinden, welche eine geringe Datenrate benötigen und möglichst wenig Energie verbrauchen sollen. Das Protokoll besticht durch sein simples Design und ermöglicht geringe Latenzen.

Das Netzwerkprotokoll Thread versteht sich als selbstheilendes Mesh-Netzwerk. Ein Designziel war es unter anderem, dass es keinen Single Point of Failure in einem solchen Netzwerk geben soll, die Übertragung zuverlässig und die Reichweite durch das Routing innerhalb des Thread-Netzwerkes gegeben ist.

Im Rahmen von Matter sollen hunderte bis tausende Produkte über Thread in einem Netzwerk unterstützt werden.

Entwickelt wird das Protokoll seit 2014 von der Thread Group welcher unter anderem ARM Limited, Nest Labs, Samsung und Qualcomm angehören. Die Entwicklung ist seit dem nicht stehen geblieben und so wurden mit Thread 1.3 Funktionalitäten wie vollumfängliches IP-Routing und Service-Discovery hinzugefügt. Diese Funktionalitäten werden für die Nutzung von Thread im Zusammenhang mit Matter benötigt.

Thread setzt auf IEEE 802.15.4 auf, bei welchem es sich um ein Standard für kabellose Netzwerke mit geringen Datenraten handelt. In IEEE 802.15.4 ist die Bitübertragungsschicht (Physical Layer) und die Data-Link-Schicht definiert.

Neben Thread setzt unter anderem auch Zigbee auf IEEE 802.15.4 auf, was ein Update solcher Geräte, hin zu Thread, perspektivisch möglich macht.

Das OSI-Modell

Darüberliegende Schichten, welche z. B. das Routing übernehmen können, müssen dann von anderen Protokollen übernommen werden. An dieser Stelle setzt Thread ein.

Per Thread angebundene Geräte können per IPv6 adressiert werden. Wichtig ist es festzuhalten, dass es sich bei Thread nicht um Matter handelt, sondern Thread ein eigenständiges Funkprotokoll ist, welches wie Wi-Fi der Anwendungsschicht agnostisch gegenübersteht.

Rollenspiele

Bei Thread kann jedes Gerät unterschiedliche Rollen annehmen. So gibt es in einem Thread-Netzwerk, einen Leader, einen oder mehrere Router und die Rolle des Endgerätes.

Jedem Gerät wird mindestens die Rolle des Endgeräts zugewiesen. Das sind solche Geräte, welche einen Befehl in Form eines Datenpaketes erhalten, um diesen auszuführen.

Ein Leader ist eine Rolle, welche nur einmal vergeben wird. Dieser koordiniert das Thread-Netzwerk. Fällt ein Leader aus, so wird automatisch ein neuer Leader bestimmt. Dazu ist es notwendig, dass jederzeit andere Geräte für den bestehenden Leader einspringen können. Die Zustandsinformationen müssen also im Netzwerk aktuell gehalten werden.

Router, leiten Datenpakete im Thread-Netzwerk weiter. Diese Rolle wird dynamisch von den jeweiligen Geräten aktiviert bzw. wieder deaktiviert, wenn z. B. zu viele Router in der Umgebung unterwegs sind. Daneben bieten die Router Funktionalität, wie Security Services, für andere Geräte, die dem Netzwerk beitreten wollen.

Normalerweise nehmen Thread-Geräte nur die Rolle als Endgerät wahr. Wird mehr Reichweite im Netzwerk benötigt, werden einige dieser Geräte automatisch Router in diesem. Das passiert z. B. dann, wenn ein Endgerät keinen Router findet, aber ein Endgerät in der Theorie eine solche Rolle einnehmen kann.

Auf der anderen Seite funktioniert dies auch, wenn sich zu viele Router in einem Bereich befinden und damit zu viel Redundanz vorhanden ist. In diesem Fall stufen sich Geräte in wieder zurück und geben die Router-Rolle auf. Dies ist z. B. dann der Fall, wenn ein Gerät nur noch mit anderen Geräten verbunden ist, welche ebenfalls die Router-Rolle wahrnehmen.

Damit ist das Routerkonzept, im Gegensatz zu Technologien wie Bluetooth Mesh oder Zigbee dynamisch.

FTDs und MTDs

Thread kennt unterschiedliche Typen von Geräten. Einerseits gibt es sogenannte Full Thread Devices (FTD) und sogenannte Minimal Thread Devices (MTD).

Bei den FTDs handelt es sich um autonome Geräte im Thread-Netzwerk, welche Rollen, jenseits der Endgeräte-Rolle, wahrnehmen. Im Normalfall haben diese Geräte entsprechende Hardwareressourcen, wie genügend Speicher et cetera. Im Gegensatz zu den MTDs sind FTDs immer mit dem Thread-Netzwerk verbunden. Infolgedessen sind FTDs meist solche Geräte, welche direkt am Stromnetz angeschlossen sind.

Ein einfaches Thread-Netzwerk

MTDs hingegen sind für solche Geräte gedacht, welche größtenteils über eine Batterie betrieben werden. In diese Kategorien fallen Geräte wie Sensoren und Ähnliche. Diese müssen mit ihren Ressourcen entsprechend haushalten. Sie treten deswegen nur sporadisch mit dem Thread-Netzwerk in Kontakt und befinden sich den Großteil ihrer Betriebszeit im Schlafmodus.

MTDs senden alle ihre Nachrichten zu einem sogenannten Parent-Device und nehmen nur die Rolle als Endgerät im Thread-Netzwerk wahr.

Border-Router

Da im Rahmen von Matter Informationen aus dem Thread-Netzwerk heraus in den Rest des Netzwerkes gelangen müssen, werden hier wieder Router, sogenannte Border-Router benötigt. Diese routen die Informationen aus und in das Thread-Netzwerk.

Im Gegensatz zu anderen Systemen unterstützt Thread mehrere Border-Router, um auch hier wieder einen Single Point of Failure zu vermeiden. Die Funktionalität solcher Border-Router wird und kann von unterschiedlichsten Geräten wahrgenommen werden. Beispiele für solche Geräte sind z. B. Alexa-Geräte oder der HomePod mini von Apple.

Während bei Bridges eine Übersetzung der jeweiligen Daten vorgenommen wird, damit sie vom anderen System verstanden werden, werden bei den Border-Routern nur die entsprechenden Daten vom Thread-Netzwerk in das andere Netzwerk geroutet. Eine Übersetzung derselben findet nicht statt.

Wi-Fi

Neben Thread können Geräte im Matter-Standard auch über Wi-Fi eingebunden werden. Als Übertragungstechnik bietet sich Wi-Fi für Smart Home-Geräte an, welche eine höhere Bandbreite benötigen und meist auch über ein entsprechendes Energiebudget verfügen und zumeist direkt an das Stromnetz angeschlossen sind.

In diese Kategorie fallen unter anderem Videokameras und Türklingeln mit Videoverbindung. Allerdings ist Wi-Fi bzw. ein einzelner Access Point nicht unbedingt dafür gedacht, eine große Menge an Geräten gleichzeitig zu bedienen.

Mit Wi-Fi 6 sind Verbesserungen eingeflossen, um mehr Geräten in einem Netzwerk entsprechende Daten simultan senden zu können, sodass die Nutzung für Smart Home-Geräte auch hier in Zukunft sinnvoller ist.

Distributed Compliance Ledger

Ein interessantes Detail an Matter ist der Distributed Compliance Ledger. In dieser verteilten Datenbank bzw. Blockchain befinden sich kryptografisch abgesicherte Daten über die Geräteherkunft, den Status der Zertifizierung sowie wichtige Einrichtungs- und Betriebsparameter.

Eingesehen werden kann die Datenbank unter anderem über eine entsprechende Weboberfläche. Die verwendete Software dafür kann auf GitHub ebenfalls eingesehen werden.

Gelesen werden kann die Datenbank von jedermann während Schreibzugriffe nur Herstellern im Rahmen ihrer Produkte gestattet sind.

In dieser Datenbank, können Hersteller von Produkten Informationen über diese hinterlegen, damit sie von jedermann gelesen werden können. Auch die Ergebnisse von Compliance Tests werden in diese Datenbank geschrieben. Dasselbe gilt für die Compliance Confirmation der CSA.

Für den Nutzer wird der Distributed Compliance Ledger interessant, um zu erfahren, ob ein Gerät als mit dem Standard konform zertifiziert wurde oder um Modellinformationen wie Firmware- und Hardware-Versionen auszulesen. Auch Zertifikate können über die Datenbank bezogen werden, um lokale Zertifikate zu überprüfen.

Die Netzwerktopologie des Distributed Compliance Ledger

Im Kontext des Ledgers existieren unterschiedliche Knoten. Einer dieser Knoten sind Validator-Knoten welche eine komplette Kopie der Datenbank vorhalten. Nicht jeder Knoten kann ein Validator-Knoten sein, er benötigt hierfür eine Erlaubnis. Auch die Anzahl der Validator-Knoten sollte beschränkt sein.

Ein weiterer Knoten ist der Observer-Knoten. Auch dieser enthält eine komplette Kopie der Datenbank und jeder darf einen solchen Observer-Knoten aufsetzen. Daneben existieren noch andere Knoten wie Sentry-Knoten, welche vor Validator-Knoten stehen können und ein Weg des DDoS-Schutzes sind.

Der Client kann sich nun mit einem dieser Knoten verbinden und die benötigten Informationen erfragen. Die Responses sind kryptografisch abgesichert, sodass es keine Rolle spielt, ob sie von einem Observer– oder einem Validator-Knoten kommen.

Technisch setzt das System auf Tendermint bzw. dem Cosmos SDK auf, welches ein Framework für Blockchains zur Verfügung stellt.

Unterstützung

Matter an sich ist noch ein relativ junger Standard und im Moment ist es noch schwierig kompatible Geräte zu finden, auch wenn teilweise schon Updates und Geräte ausgeliefert worden sind. Dies betrifft z. B. einige Geräte von Eve Systems oder Produkte von Nanoleaf mit Matter-Unterstützung.

Interessant ist die Unterstützung auch vonseiten der Betriebssystemanbieter für mobile Systeme, wie iOS und Android. Mit iOS 16.1 lieferte Apple die Unterstützung für Matter aus. Bei Android lieferte Android 13 die ersten Integrationen für Matter.

Auch Smart Speaker wie die Alexa-Serie von Amazon unterstützen mittlerweile Matter, so wurden bereits Updates für einige Modelle ausgerollt, weitere Modelle sollen Anfang 2023 folgen. Einige Geräte fungieren dann auch als Thread-Border-Router und ermöglichen so die Integration von Smart Home-Geräten. Das Gleiche gilt für HomePod minis und den Apple TV 4K, welche ebenfalls Thread unterstützten.

Auch auf Produktseite fangen immer mehr Hersteller an Support für Matter in ihre Produkte einzubauen, so können Entwickler z. B. mit den Philips Hue-Hubs und Geräten in Verbindung mit Matter erste Tests durchführen.

Lizenz

Wer sich Matter anschauen möchte, kann sich die Spezifikation herunterladen, nachdem einige Daten bei CSA hinterlegt worden sind. Ein frei verfügbarer Download existiert nicht.

Ähnlich sieht es auch beim Thread-Standard aus. Hier werden auch entsprechende Hinweise in der E-Mail gegeben:

Please also note, as per the Thread 1.1 Specification EULA, you are prohibited from sharing the document.

Grundsätzlich handelt es sich bei Matter um einen proprietären Standard, der genutzt werden kann, nachdem eine Zertifizierung durchgeführt und die Mitgliedsgebühren für die Connectivity Standards Alliance gezahlt wurden. Offizieller Quellcode rund um Matter ist auf GitHub zu finden und unter der Apache-Lizenz lizenziert.

Problematisch wird das Lizenzierungsmodell des Matter-Standards für GPL-Software, bedingt durch die jährlich zu leistenden Zahlungen an die Connectivity Standards Alliance, welche mit der GPL nicht vereinbar sind.

Migration auf Matter

Interessant wird es auch, wenn ein bestehendes Smart Home auf Matter umgerüstet werden soll. In einem solchen Fall sind bereits Systeme wie Zigbee oder Z-Wave installiert und die Frage stellt sich, wie diese Systeme umgestellt werden können.

Der einfachste Weg wäre es natürlich alle bestehenden Altgeräte auszubauen und anschließend neue kompatible Matter-Geräte einzubauen. Dies wird, ist den meisten Fällen aus Kostengründen und mangels fehlender Praktikabilität kein Weg sein, der gegangen werden kann.

Im Matter-Standard selbst sind für diesen Fall Bridges vorgesehen, mit welchen diese „Altsysteme“ angebunden werden können. Ein Bridge definiert sich im Matter-Standard dadurch, dass sie ein Matter-Knoten darstellen, welcher eines oder mehrere Nicht-Matter-Geräte darstellt.

Ein komplexes Matter-Netzwerk

Über solche Bridges können schlussendlich bestehende Netzwerke eingebunden werden. Daneben lassen sich einige Produkte, welche z. B. Hardware nach dem 802.15.4-Standard verbaut haben oder aber bereits Thread unterstützen per Softwareupdate so upgraden, dass sie mit dem Matter-Netzwerk kompatibel werden.

Problematisch an solchen Bridge-Lösungen ist, dass die Geräte nicht direkt integriert sind und somit unter Umständen parallele Mesh-Systeme im Smart Home existieren. Aber über solche Bridge-Lösungen ist möglich, Stück für Stück in die neue Matter-Welt zu migrieren und so den Migrations-Big-Bang zu vermeiden.

Ausblick und Fazit

Matter hat sich als neuer Standard aufgestellt, um den Smart Home-Markt aufzurollen. Dass mit neuen Standards die alten Standards nicht unbedingt obsolet werden, hatte schon XKCD in einem seiner bekannteren Comics gezeigt.

Doch wie könnte die Zukunft von Matter aussehen? Da sich praktisch jeder größere Smart Home-Anbieter und andere Firmen wie Apple, Amazon, Google und Samsung an Matter beteiligen, könnte Matter das Potenzial haben, den Markt aufzurollen.

Schlussendlich stellt sich hier die Frage nach den Produkten, die mit Matter-Unterstützung auf den Markt gebracht werden und ob diese die Kundenwünsche erfüllen können.

Auch muss der Standard, der in der Theorie übergreifend unterstützt wird und dessen Geräte unabhängig vom Hersteller genutzt werden können, dies noch in der Praxis beweisen. Im schlimmsten Fall ist der Kunde hier wieder der Leidtragende, weil er kleine und größere Inkompatibilitäten ertragen muss.

Im besten Fall führt der neue Standard zu einer Migration alter Lösungen in Richtung Matter. Der Zigbee-Standard ist praktisch ein Legacy-Standard geworden und Z-Wave wird im schlimmsten Fall einen langsamen Tod sterben, da viele Nutzer zu Matter abwandern werden und Z-Wave es schwer haben wird, gegen diesen Standard zu bestehen.

Auch wenn Z-Wave aufgrund der genutzten Funkfrequenzen kleinere technische Vorteile hat, sind dies wahrscheinlich keine Faktoren, welche sich auf Kundenseite auswirken werden. Auch wenn dies in der Z-Wave Alliance anders gesehen wird:

Matter is bringing a lot of attention to the smart home. This makes it easy to overlook Z-Wave as the most established, trusted, and secure smart home protocol, that also happens to have the largest certified interoperable ecosystem in the market. We firmly expect that Z-Wave will play a key role in connecting devices and delivering the experience users really want.

Im Rahmen des Artikels wurde einige Hintergründe von Matter erläutert, trotzdem wurde Matter nur angerissen, da der Standard auf über achthundert Seiten, viele Details definiert und unterschiedlichste Verfahren im Detail erläutert.

Wenn Matter seine Versprechen halten kann und die Nutzung für den Kunden einfacher ist, könnte es ein Standard sein, der ein Großteil der Nutzer und Hersteller in Zukunft hinter sich vereinen könnte.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

Formatierung in Ulysses ändert sich nach Aktualisierung

Ulysses ist eine großartige App zum Schreiben größerer Dokumente bis hin zu Büchern. Innerhalb der Applikation wird mit Markdown gearbeitet, welches dann entsprechend dargestellt wird. Dafür sind unter Ulysses sogenannte Themes zuständig. Über diese wird festgelegt wie das Markdown innerhalb der App dargestellt wird.

Die Einstellungen von Ulysses

In neueren Versionen werden Überschriften in unterschiedlichen Größen dargestellt, was ich gelinde gesagt als schrecklich empfinde. Allerdings ist dies kein Problem, da dass entsprechende Theme einfach angepasst werden kann und die Überschriften damit in der gleichen Größe angezeigt werden. Allerdings gibt es bei dieser Möglichkeit ein Problem. Wurde das Standardtheme (aktuell D22) angefasst, so wird dieses bei einer Aktualisierung der Anwendung wieder überschrieben.

‎Ulysses Mobile
Preis: Kostenlos+
‎Ulysses | Schreibprogramm
Preis: Kostenlos+

Die Idee dahinter ist, dass das Standardtheme immer entsprechend aktuell gehalten wird, damit der Nutzer Neuerungen gleich sieht. Gelöst werden kann das Problem dadurch, das eine Kopie vom Standardtheme angelegt wird. Dieses kann dann nach den Wünschen des Nutzers angepasst werden. Die Änderungen werden bei einer Aktualisierung der Applikationen auch nicht mehr überschrieben.

Von Codierungen und Vereinheitlichung

Unicode erblickte vor knapp dreißig Jahren das Licht der Welt und brachte ein wenig Ordnung in die babylonische Vielfalt der Kodierungsstandards. Auch wenn er oft genutzt wird, gibt es doch viel Halbwissen rund um diesen Standard.

Wenn eine Datei mit einem Text eingelesen wird, so besteht diese für den Computer nur aus einer Abfolge von Daten, ohne eine wirkliche Bedeutung. Dass wir am Ende in dieser Datei Eine Geschichte zweier Städte von Charles Dickens finden, ist dem Umstand geschuldet, dass sich auf die Codierung dieser Daten geeinigt wurde.

Für die Codierung von Text wurden viele Codierungen erdacht und in der Praxis eingesetzt, vom Morsecode über den Baudot-Murray-Code, welcher als 5-Bit-Code die Tastenstellung eines Telegrafengerät kodierte, bis zum American Standard Code for Information Interchange, kurz ASCII, der für viele Jahre das Fundament der Textkodierung in der IT darstellte.

Eine Telegraphen-Tastatur

Mit Unicode, welcher vor etwa 30 Jahren das Licht der Welt erblickte, wurde ein wenig Ordnung in die babylonische Vielfalt der Codierungsstandards gebracht, was wegen der Internationalisierung der IT dringend nötig war. Und damit ist dieser Standard aus der Vergangenheit gleichzeitig die Zukunft.

ASCII und EBCDIC

Wie vieles in der IT, baut auch Unicode auf einem historischen Erbe auf, in diesem Fall dem ASCII-Standard. In diesem 1963 verabschiedeten Standard waren in einer 7-Bit-Codierung 128 Zeichen kodiert. Neben dem lateinischen Alphabet, also den Zeichen von A bis Z, jeweils in Groß- und Kleinschreibung, den Ziffern und einigen Sonderzeichen, befanden sich in diesem auch etliche Steuerzeichen.

Zu diesen Steuerzeichen gehören bekannte Zeichen wie der Tabulator oder der Zeilenvorschub, als auch weniger bekannte Zeichen wie die Glocke (Bell). Genutzt wurden diese Zeichen zur Steuerung der Geräte, welche mit dem ASCII-Code umgehen sollten.

Technisch betrachtet wurden im ASCII-Code eigentlich nur 126 Zeichen kodiert. Der Hintergrund hierfür ist historisch begründet. Das Zeichen 0 (kodiert als Bits 0000000) wird genutzt, um die Nichtexistenz von Daten anzuzeigen. Im Kontext einer Lochkarte werden keine Löcher im entsprechenden Bereich gestanzt.

Das Gegenteil hiervon ist das Zeichen 127 (1111111), welches festlegt, dass die Daten auf diesem Feld als gelöscht gelten; auch hier wieder der Lochkarten-Hintergrund, bei welchem im Fehlerfalle bestehende Löcher nicht mehr geschlossen werden können bzw. sollten und somit alle Löcher gelocht werden, um ein gelöschtes Datum zu symbolisieren.

Eine ASCII-Tabelle in einem Drucker von General Electric aus den 70er Jahren

Da sie in dieser Form nicht mehr benötigt wurden, wurden diese Zeichen teilweise anders genutzt. In vielen Programmiersprachen stellt das Zeichen 0 das Ende einer Zeichenkette dar. Somit können in diesen Sprachen, wie z. B. C, Zeichenketten abgespeichert werden, ohne dass die entsprechende Länge bekannt sein muss, im Gegensatz zu Sprachen wie z. B. Pascal.

In seiner heutigen Form wurde der ASCII-Code nach einigen kleineren Änderungen schließlich 1968 verabschiedet. Neben dem ASCII-Code wurde von IBM der Extended Binary Coded Decimal Interchange Code (EBCDIC) entwickelt, welcher vorwiegend auf Großrechnern genutzt wurde. Diese Entwicklung fand zwischen 1963 und 1964 statt und wurde mit dem System/360 der Öffentlichkeit vorgestellt.

Im Westen nichts Neues

Aus Sicht der westlichen Welt war der ASCII-Code für viele Dinge gut genug. So können Umlaute im Deutschen leicht ersetzt werden, z. B. das Zeichen ä durch ae. Allerdings wurde dies nicht immer gemacht und war auch nicht immer gewünscht.

Um andere Zeichen wie Umlaute oder Akzentzeichen abzubilden, entstanden 8-Bit Codes basierend auf dem ASCII-Code, welche somit die doppelte Zeichenanzahl unterbringen konnten.

In Westeuropa hat sich hierbei insbesondere der Standard ISO/IEC 8859-1 etabliert, besser bekannt unter dem Namen Latin-1. Ziel dieses Standards war es, möglichst viele Zeichen westeuropäischer Sprachen abzubilden. Unter Windows wurde eine abgewandelte Form dieses Zeichensatzes unter dem Namen Windows-1252 genutzt.

Durch die ISO standardisiert sind daneben Zeichensätze für weitere europäische Regionen wie Griechisch, aber auch Kyrillisch, Arabisch, Thai und Hebräisch.

Daneben existieren andere 8-Bit-Codierungen, welche teilweise nur mit ihren jeweiligen Anwendungen bzw. Betriebssystemen kompatibel waren und nicht standardisiert sind. Ein Beispiel für eine solche Codierungen ist CBM-ASCII, in welcher unter anderem Zeichen für Blockgrafik enthalten waren und welche bei vielen Heimcomputern von Commodore zum Einsatz kam.

Zeichensalat

Die Nutzung unterschiedlicher Codierungen führt aber auch zu Problemen. Wird ein Dokument z. B. mit der falschen Codierung geöffnet, so erhält der Nutzer in solchen Fällen sogenannten Zeichensalat:

Falsches Üben von Xylophonmusik quält jeden größeren Zwerg.

Auch Texte, in denen mehrere Sprachen vorhanden sind, ließen sich mit diesen bestehenden Codierungen nicht einfach umsetzen.

Noch ein Standard?

Mit der Globalisierung und dem Austausch von Dokumenten über Sprach- und Systemgrenzen hinweg entwickelte sich die Vielfalt an Codierungen zu einem Problem.

Die ISO/IEC 2022 versuchte dieses Problem zu lösen. Bei diesem Standard kann unter Zuhilfenahme verschiedener Escape-Sequenzen zwischen den unterschiedlichen Zeichensätzen umgeschaltet werden. Durchgesetzt hat sich dieser Standard nur in Japan, Korea und China, in erster Linie im Kontext E-Mail; da der Standard auch entsprechende 7-Bit-Codierungen definiert.

Schlussendlich kam es zur Entwicklung von Unicode. Wie so viele Entwicklungen, die die IT weiter brachten, hatten sie etwas mit Xerox zu tun. Vom PARC Universal Packet, welches maßgeblich das Design von TCP/IP beeinflusste, bis zum WIMP-Paradigma (Windows, Icons, Menus, Pointer), dem wir unsere modernen Desktop-Oberflächen und Interface-Konzepte verdanken.

Dort entstand der Xerox Character Code Standard, welcher als inoffizieller Vorgänger des Unicode-Standards betrachtet werden kann. Joseph D. Becker, welcher sich bei Xerox schon länger mit multilingualer Software befasste und unter anderem 1984 das Paper Multilingual Word Processing dazu verfasste, ist einer der Erfinder und Gestalter von Unicode.

Die eigentliche Entwicklung von Unicode begann 1987. Neben Joseph D. Becker arbeiteten Lee Collins und Mark Davis, damals bei Apple angestellt, ebenfalls an dem neuen Standard, welcher ein universelles Set von Zeichen darstellen sollte, in welchem die aktuellen Schriftsysteme der Zeit enthalten sein sollten. In der damaligen Entwurfsphase war es noch nicht das erklärte Ziel historische Schriftsysteme abzubilden:

Unicode gives higher priority to ensuring utility for the future than to preserving past antiquities. Unicode aims in the first instance at the characters published in modern text (e.g. in the union of all newspapers and magazines printed in the world in 1988), whose number is undoubtedly far below 2^14 = 16,384. Beyond those modern-use characters, all others may be defined to be obsolete or rare; these are better candidates for private-use registration than for congesting the public list of generally-useful Unicodes.

Im Laufe des Jahres 1989 stießen zur Gruppe um Becker, Mitarbeiter von Metaphor, RLG und Sun Microsystems hinzu. 1990 wurde das Team um Mitstreiter von Microsoft und NEXT erweitert.

Ende desselben Jahres war der Standard dann so weit gediehen, dass am 3. Januar 1991 das Unicode Consortium gegründet wurde. Dieses setzte einige Monate später im Oktober des Jahres den ersten Unicode-Standard in die Welt.

Allerdings wurde dies nicht überall so verstanden. In der TrueType Spezifikation in Version 1.0 für das entsprechende Font-Format erhielt der Standard die Plattform-ID Apple Unicode, was allerdings ein Irrtum war, welcher mittlerweile korrigiert wurde.

Beim Unicode Consortium selbst handelt es sich um eine gemeinnützige Organisation, mit Sitz in Mountain View in Kalifornien. Sie sorgt für die Weiterentwicklung des Standards und die Aufnahme weiterer Zeichen. Zu den Mitgliedern gehören unter anderem Adobe, Apple, Google und Netflix, aber auch Institutionen wie das Bangladesh Computer Council.

Aufbau

Grundsätzlich definiert der Unicode-Standard einen sogenannten Codespace. Jedem Zeichen wird eine Nummer innerhalb dieses Codespace zugewiesen. Ein vergebener Wert für ein Zeichen innerhalb dieses Codespace wird als Code Point bezeichnet und stellt die Grundlage von Unicode dar. So entspricht z. B. der Code Point 2126 dem Omega-Zeichen (Ω). Der Umfang dieses Codespace erstreckt sich von 0 bis 10FFFF.

Genau betrachtet stellt ein Code Point aber nicht unbedingt ein Zeichen dar, da es Zeichen gibt, welche sich aus mehreren Code Points zusammensetzen. So könnte ein Ä als A mit einem Trema (die Punkte über dem Ä), also mit zwei Code Points, dargestellt werden.

Auch werden keine Repräsentationen der Zeichen durch den Unicode-Standard vorgegeben. Stattdessen handelt es sich um abstrakte Zeichen, welche definiert werden. Ihre jeweilige Ausgestaltung ist z. B. entsprechenden Fonts vorbehalten.

Allerdings ist der Adressraum von Unicode nicht flach, sondern in sogenannte Planes unterteilt. Eine Plane entspricht hierbei 2^16, also 65.536 Code Points. Insgesamt sind 17 Planes (Plane 0 bis 16) im Standard definiert. Damit ist das aktuelle Limit an Zeichen in Unicode auf 1.114.112 festgelegt. Nach dem Abzug von Regionen für die private Nutzung bleiben am Ende in etwa 970.000 Code Points für die öffentliche Nutzung übrig.

Die Planes sind nach bestimmten Kriterien unterteilt und definiert. Aktuell genutzt respektive definiert sind sieben dieser Planes, wobei zwei davon für die private Nutzung definiert sind und somit im Unicode-Standard keinerlei Zeichen zugewiesen bekommen.

Die wichtigste und zuerst definierte Plane ist die Basic Multilingual Plane (BMP) mit der ID 0. In dieser sind die Zeichen für die meisten aktuell genutzten Sprachen, definiert. Grundsätzlich sollten in dieser Plane alle Zeichen definiert werden, welche in modernen Schriftsystemen rund um die Welt Verwendung finden. Hier finden sich neben Symbolen und lateinischen Buchstaben hauptsächlich die Zeichen aus der chinesischen, japanischen und koreanischen Sprache.

Die Basic Multilingual Plane

Innerhalb der Planes werden die Code Points in sogenannten Blöcken gruppiert. So existieren in der BMP 164 solcher Blöcke. In diesen Blöcken werden Schriftzeichen thematisch gruppiert, so z. B. der Block für lateinische Buchstaben, für Thai, für mathematische Operatoren oder geometrische Formen. Die Größe eines Blockes hängt von der Anzahl der zu kodierenden Code Points ab, ist aber immer ein Vielfaches von 16.

Neben dieser Plane existieren noch die Supplementary Multilingual Plane mit der ID 1, die Supplementary Ideographic Plane mit der ID 2, die Tertiary Ideographic Plane mit der ID 3 und die Supplementary Special-purpose Plane mit der ID 14.

In der Supplementary Multilingual Plane finden sich weitere Schriftsysteme, auch historischer Natur, wie ägyptische Hieroglyphen oder Zeichen zur Notation von Musik. Auf der Supplementary Ideographic Plane finden sich weitere sogenannte CJK-Zeichen also Schriftzeichen aus dem Chinesischen, Japanischen, Koreanischen und Vietnamesischen. Neben einigem historischen Schriftsystemen wie dem Oracle bone script, einem Vorgänger der chinesischen Schrift, welcher auf Orakelknochen gefunden wurde, ist die Tertiary Ideographic Plane größtenteils leer. Die Supplementary Special-purpose Plane wird für bestimmte Spezialzeichen genutzt, die z. B. im Zusammenhang mit Emojis zum Tragen kommen.

Die Planes 4 bis 13 sind im Moment nicht belegt und somit für zukünftige Erweiterungen verfügbar. Die Planes 15 und 16 sind sogenannte Private Use Area Planes, mit welchen Zeichen kodiert werden können, welche nicht im Unicode-Standard definiert sind. Hierbei müssen sich die Anwendungen über die Bedeutung der einzelnen Zeichen bewusst sein, um diese korrekt darstellen zu können.

Teilweise sind die Zeichen innerhalb einer Plane und entsprechender Blöcke fragmentiert, da Blöcke bereits komplett belegt waren und Zeichen erst später dazukamen.

Altlasten

Neben besagter Fragmentierung befinden sich auch historische Altlasten im Unicode.

Damit bestehende Zeichensätze wie die Latin-Familie, aber auch asiatische Systeme, sinnvoll übernommen werden und einfach konvertiert werden konnten, wurden diese als Ganzes in den Standard übernommen. So entsprechen die ersten 256 Zeichen im Unicode-Standard exakt dem Standard ISO/IEC 8859-1, besser bekannt als Latin-1.

Dies führt stellenweise zu doppelten Zeichen im Unicode-Standard und auch Zeichen wie dem Ä, welches eigentlich ein zusammengesetztes Zeichen ist und als solches nach den heutigen Kriterien wohl nicht im Standard aufgenommen würde. Die meisten dieser Zeichensätze sind in der Basic Multilingual Plane gelandet.

Im Standard selbst mag dies zu einigen Problemen geführt haben und wie ein Makel wirken, aber es war eine pragmatische Entscheidung, welche die Umstellung auf Unicode vereinfachen sollte.

Im Reich der Codierungen

Um ein Unicode-Zeichen zu codieren, existieren unterschiedliche Unicode-Codierungen, sogenannte Unicode Transformation Formats (UTF). Diese unterscheiden sich in grob in Codierungen mit fester Länge wie UTF-32 und Codierungen variabler Länge wie UTF-8.

Im Standard existieren drei Geschmacksrichtungen dieser UTFs: UTF-8, UTF-16 und UTF-32. Die Zahl gibt die Minimalbits an, welche zur Codierung eines Zeichens benötigt werden. Auch wenn dies historisch betrachtet nicht immer der Fall war, da es Codierungen wie UTF-1 oder UTF-7 gab.

Im Falle von Buchstaben aus dem ASCII-Zeichensatz benötigt ein Zeichen in der Codierung UTF-8 ein Byte, kann aber bis zu 4 Byte beanspruchen, je nach dem auf welches Unicode-Zeichen verwiesen werden soll. Somit können alle Zeichen des Unicode-Standards entsprechend kodiert werden. Werden nur ASCII-Zeichen genutzt, so ist diese Codierung kompatibel mit ASCII.

Die Geschichte von UTF-8 ist eng mit der des Betriebsystems Plan-9 verbunden, welches in den 80er-Jahren in den Bell Laboratories entwickelt wurde. Die ursprüngliche Umsetzung sah vor 16-Bit breite Zeichen in Plan 9 zu nutzen. Allerdings waren die Entwickler damit unzufrieden. Ein Anruf von IBM, zu einem bevorstehenden Meeting des X/Open Komitees, führte dazu, dass Rob Pike und Ken Thompson an einem Mittwochabend die UTF-8 Codierung entwickelten und sie Plan 9 von Mittwoch zu Freitag auf UTF-8 umstellten. Ein weiterer Anruf beim X/Open Komitee und dem Eingeständnis, dass der Vorschlag von Pike und Thompson wesentlich besser war als der eigene, begann UTF-8 seinen Siegeszug.

Doch wie wird das Ganze technisch gelöst? Da es sich bei ASCII um eine 7-Bit-Codierung handelt, wird das Bit mit dem Index 7 nicht genutzt. Es ist immer Null. So wäre das Zeichen F wie folgt kodiert:

[0 1 0 0 0 1 1 0]
 7 6 5 4 3 2 1 0

Dieser Umstand wird nun für UTF-8 genutzt. Ist das Bit (Index 7) Null, so handelt es sich um ein ASCII-Zeichen, ist es Eins, so liegt eine UTF-8 Codierung vor. Das Zeichen Ä (196) sähe in der UTF-8-Codierung wie folgt aus:

[11 00 00 11] [10 00 01 00]

Die Bitfolge 11 im ersten Byte zeigt dabei an, dass es sich um das Startbyte des Zeichens handelt. Die Anzahl der Einsen am Anfang gibt hierbei an, in wie vielen Bytes das Zeichen kodiert ist. Das Yen-Zeichen ¥ würde in UTF-8 wie folgt kodiert werden:

[11 10 11 11] [10 11 11 11] [10 10 01 01]

Hier zeigt das Startbyte drei Einsen am Anfang. Damit ist klar, dass dieses Zeichen in drei Byte kodiert wird. Die folgenden Bytes sind die sogenannten Folgebytes und sind an der Bitfolge 10 am Anfang zu erkennen.

Nach den aktuellen Unicode-Regeln darf ein UTF-8-Zeichen maximal 4 Byte in Anspruch nehmen, auch wenn die Art der Codierung in der Theorie mehr Bytes nutzen könnte. Zu den jeweiligen Codierungen zählen weiterhin bestimmte Feinheiten, die im Rahmen dieses Artikels nicht im Detail besprochen werden sollen, da sie für das Grundprinzip der Codierung unerheblich sind. So dürfen unter anderem bestimmte Bitfolgen nicht genutzt werden, da sie im Rahmen der UTF-8 Codierung als ungültig angesehen werden. Ein Vorteil dieser Codierung ist, dass immer klar ist, wo ein neues Zeichen beginnt und daher defekte Daten in der UTF-8-Codierung problemlos übersprungen werden können.

Bei UTF-16 wird ein Zeichen durch 16 Bit abgebildet, wenn es sich um ein Zeichen aus der Basic Multilingual Plane handelt. Bei Codierungen außerhalb der BMP werden jeweils zwei 16-Bit-Pärchen genutzt. Dies sollte allerdings nicht mit der UTF-32 Codierung verwechselt werden, da es sich trotzdem um zwei UTF-16 codierte Entitäten handelt.

UTF-32 kodiert jeden Code Point immer in vier Byte und stellt damit die speicherintensivste Codierung dar. Im gewissen Rahmen, mit Ausnahme zusammengesetzter Zeichen, bietet sie einen wahlfreien Zugriff auf die Zeichen einer Zeichenkette an. Damit kann auf Zeichen innerhalb der Zeichenkette zugegriffen werden, indem ihre Position berechnet wird, anstatt die komplette Zeichenkette von Anfang an decodieren zu müssen.

Im Zusammenhang mit den Codierungen fallen gelegentlich auch die Begriffe UCS-2 und UCS-4. Bei UCS-2 handelt es sich um eine obsolete Codierung, welche nur die Code Points der Basic Multilingual Plane codieren konnte. UCS-4 hingegen ist gleichbedeutend mit UTF-32. Die Begrifflichkeit UCS kommt vom Universal Coded Character Set aus der Norm ISO/IEC 10646.

Daneben gibt es Codierungen wie UTF-EBCDIC, welche dafür gedacht waren, Unicode auf entsprechende Mainframe-Rechnern, welche mit der EBCDIC-Codierung arbeiten, zu bringen. In der Praxis wird auf solchen Systemen, wie z/OS, aber meist UTF-16 genutzt.

Der Unterschied zwischen Codierungen fester Breite gegenüber denen variabler Breite liegt im Aufwand, die entsprechende Codierung auszuwerten. Bei den Codierungen variabler Breiten, muss ein entsprechender Rechenaufwand in das Lesen der Codierungen gesteckt werden. Dieser entfällt bei Codierungen fester Breite, allerdings ist hier der Speicherbedarf höher als bei den Codierungen variabler Breite.

Byte Order Mark

Doch wie wird erkannt, in welcher Codierung ein Dokument vorliegt? Dafür existiert das Byte Order Mark, kurz BOM. Dieses steht am Anfang einer Datei und teilt die genutzte Codierung mit.

Für UTF-8 haben viele ein solches BOM sicherlich schon einmal gesehen:



Als hexadezimale Repräsentation sieht dieses dann wie folgt aus:

EF BB BF

Bei den UTF-16 und UTF-32 Codierungen muss die Endianness, also die Reihenfolge der Bytes berücksichtigt werden. Dies wird mit dem Byte Order Mark, wie der Name es andeutet, bewerkstelligt. Ein Beispiel eines UTF-16 BOM:

 FE FF (Big Endian)
 FF FE (Little Endian)

Die Nutzung des Byte Order Mark ist optional. Ist keines gesetzt, so wird automatisch davon ausgegangen, dass die Byte-Reihenfolge Big-Endian ist.

ISO und Unicode

Mit dem Standard ISO/IEC 10646, dem Universal Coded Character Set sind die Zeichen des Unicodes auch in einem ISO-Standard verewigt. Mittlerweile werden der ISO-Standard und Unicode synchronisiert; das bedeutet, sie definieren die gleichen Zeichen.

Allerdings existieren Unterschiede zwischen diesem Standard und Unicode. Während die Namen und Code Points in beiden Standards gleich sind, spezifiziert der Unicode Standard Regeln zur Interoperabilität und liefert weitere Dinge wie entsprechende Algorithmen mit. Im Vergleich dazu stellt der ISO-Standard nur eine Zeichentabelle dar.

Im Laufe der Zeit

Während im Oktober 1991 die Unicode-Version 1.0.0, mit 7129 Code Points, veröffentlicht wurde, ist die aktuelle Version 14.0 im September 2021 erschienen und definiert ein Vielfaches an Code Points im Standard.

Dabei sind von Version zu Version immer wieder neue Zeichen hinzugekommen. Der Unicode-Standard legt fest, dass einmal eingebrachte Zeichen nie wieder aus dem Standard entfernt werden dürfen. Das bedeutet, dass sich gut überlegt werden muss, ob ein Zeichen wirklich dem Standard zugeschlagen wird.

Allerdings ist dies nicht immer so gewesen. In der Frühzeit des Standards bis einschließlich Version 2.0, welche im Juli 1996 erschien, wurden unter anderem das koreanische Alphabet in Version 2.0 entfernt und durch neue Zeichen an einer anderen Stelle in der Codeplane ersetzt. Auch in den vorherigen Versionen 1.1 und 1.0.1 wurden Zeichen entfernt.

Ab der Version 2.1 des Standards wurde sich von dieser Praxis gelöst und seitdem wird der Standard nur noch erweitert. Wird nun von der Nutzung eines Zeichens abgeraten, so wird dieses im Unicode-Standard als deprecated gekennzeichnet.

Im Oktober 2010 wurden mit dem Unicode-Standard 5.2 nicht nur Symbole für Spielkarten und weitere Schriftsysteme hinzugefügt, sondern auch Emojis feierten ihr Debüt in dieser Version. Gab es ursprünglich 722 definierte Emojis, sind diese mittlerweile angewachsen und verfügen auch über die Unterstützung unterschiedliche Hautfarben anzeigen zu können.

Mit Version 1.40 sind 144.697 Code Points definiert. Damit ist in etwa ein Siebtel des Codespace belegt. Dass das klingonische Schriftsystem darunter ist, ist im Übrigen ein Gerücht. Allerdings werden klingonische Zeichen über die privaten Bereiche des Unicode-Codespaces genutzt. Für diese privaten Bereiche innerhalb des Codespace gibt es mit der Under-ConScript Unicode Registry eine Art informelle Registry für diese.

Umsetzung in der IT

Standards und damit auch der Unicode-Standard sind nur dann sinnvoll, wenn sie umgesetzt und genutzt werden. Aktuelle Windows-Versionen und macOS-Versionen nutzen für die interne Repräsentation von Unicode UTF-16, bei Linux ist es UTF-8. Damit ist die grundlegende Nutzung in den entsprechenden Betriebssystemen gegeben.

In den Betriebssystemen selbst gibt es für den Nutzer unterschiedliche Möglichkeiten Unicode-Zeichen einzusetzen. Viele Varianten arbeiten mit der Eingabe der entsprechenden ID des Code Points in dezimaler oder hexadezimaler Repräsentation in Verbindung mit einer Taste. Unter Windows kann die Alt-Taste in Verbindung mit der entsprechenden ID zur Eingabe genutzt werden. Auch unter Linux und macOS sind solche Eingaben möglich, wobei diese unter macOS explizit aktiviert werden müssen.

Die Zeichentabelle unter Windows 10

Daneben existieren in den Betriebssystemen auch entsprechende Applikationen, wie die Zeichentabelle unter Windows, mit der Unicode-Zeichen über ein entsprechendes Interface herausgesucht und genutzt werden können.

Bei Programmiersprachen wie Java oder den auf .NET basierenden Sprachen wird intern ebenfalls mit UTF-16 gearbeitet. Unter Rust kann der primitive Typ einen sogenannten Unicode scalar value speichern. Dieser entspricht einem Code Point; allerdings sind die sogenannten Low- und High-Surrogate, welche für UTF-16 benötigt werden, hier nicht mit eingeschlossen.

Interessant ist auch die Betrachtung von Fonts in Bezug auf Unicode. Die erste Frage, die sich hier vielleicht stellt, ist ob ein Font existiert, welcher alle Unicode-Zeichen unterstützt.

Aus technischen Gründen ist dies schon nicht möglich. So kann eine TrueType-Schriftart maximal 65.535 Glyphen enthalten. Auch im OpenType-Format ist eine solche Beschränkung enthalten.

Einer der Fonts aus der Noto-Familie

Allerdings gibt es Font-Familien wie Noto, welche von Google beauftragt wurde und mittlerweile über 77.000 Code Points des Unicodes-Standards abdeckt. Daneben gibt es eine Reihe weiterer Fonts wie GNU Unifont oder WenQuanYi, welche ebenfalls eine Vielzahl an Zeichen aus dem Unicode-Zeichensatz unterstützen.

Der Name der Schriftartfamilie Noto steht für No Tofu und spielt auf das Kästchen an, welches angezeigt wird, wenn ein Font ein entsprechendes Unicode-Zeichen nicht enthält. Früher wurde hierbei häufig der Replacement Character, welcher sich in der Basic Multilingual Plane befindet, genutzt. Dieser zeigt eigentlich an, dass ein Zeichen nicht als valides Unicode-Zeichen erkannt werden konnte, also ein Kodierungsfehler vorliegt. Heutzutage wird für den Fall, dass ein valides Unicode-Zeichen vom Font nicht dargestellt werden kann, die .notdef Glyphe des entsprechenden Fonts angezeigt.

Auch bei der softwareseitigen Unterstützung von Unicode gibt es hier und da Probleme. So wurden bis in die 2000er-Jahre hauptsächlich die Code Points aus der Basic Multilingual Plane unterstützt. Andere Planes waren nicht wirklich zugänglich.

Auch die Zusammensetzung von Zeichen aus mehreren Code Points wird von vielen Anwendungen nicht richtig beherrscht. Gebessert hat sich dies unter anderem durch den Standard GB 18030 der chinesischen Regierung, welcher ebenfalls die entsprechenden Zeichen aus der Codeplane unterstützt und damit ein Unicode Transformation Format darstellt.

Dieser Standard definiert, welche Zeichen zwingend in entsprechenden Betriebssystemen und Anwendungen unterstützt werden müssen und brachte damit die Unicode-Unterstützung jenseits der Basic Multilingual Plane voran.

Auch in anderen Anwendungen, wie E-Mail kann Unicode dank des MIME-Standards seit vielen Jahren genutzt werden. Für die Codierungen von Domainnamen, mit Nicht-ASCII-Zeichen, waren ebenfalls Unicode Transformation Formate in der Entwicklung (UTF-5, UTF-6), allerdings hat sich hier Punnycode durchgesetzt.

Trotz der Durchdringung der Unicode-Standards, kommt es immer wieder zu kleineren und größeren Problemen mit ihm. So akzeptierte Outlook 2016 keine Passwörter mit Unicode-Zeichen und ein Schriftzeichen der Sprache Telugu führte zu Problemen unter iOS und macOS.

Kritik

Der Unicode-Standard ist nicht perfekt und so gab und gibt es immer wieder Kritik an diesem. Einer dieser Punkte ist die Han-Vereinheitlichung. Bei dieser ging und geht es darum, die Zeichen aus den unterschiedlichen ostasiatischen Sprachen auf ihre Grundformen zurückzuführen und diese entsprechend im Unicode-Standard abzubilden. Dies führte zu einiger Kritik, obwohl hierbei möglichst alle betroffenen Sprachgruppen eingebunden wurden, da teilweise Zeichen vereinheitlicht wurden, welche nicht unbedingt dieselbe Bedeutung hatten.

Auch das besagte Mapping bestehender Zeichensätze in den Unicode-Standard, wie im Abschnitt über die Altlasten beschrieben, war ein solcher Kritikpunkt.

Aus der Sicht der IT-Sicherheit wird manchmal die Nutzung von Homoglyphen kritisiert, da dort bestimmte Zeichen durch andere, ähnliche aussehende Zeichen ausgetauscht werden, um z. B. eine Domain einer Bank zu imitieren und den Kunden so um seine Zugangsdaten zu bringen. Ein bekanntes Beispiel hier ist der Austausch des Buchstabens O durch eine 0, welches schon beim ASCII-Standard funktionierte. Mit dem Unicode-Standard sind viele weitere Möglichkeiten für solche Homoglyphen dazugekommen.

Auch die Sortierung und Groß- und Kleinschreibung kann sich im Codespace von Unicode und entsprechender lokaler Regelungen manchmal als schwierig erweisen, da sich z. B. die Sortierreihenfolge nicht unbedingt aus der Anordnung der Zeichen innerhalb des Codespace ergibt.

Die Zukunft

Unicode ist bisher nicht überall angekommen. So wird der Standard ISO/IEC 8859-15 respektive Latin-9 als 8-Bit-Code weiterhin verwendet. Genutzt wird diese Codierung unter anderem bei amtlichen Werken wie der elektronischen Gesundheitskarte.

Im Internet sind mittlerweile über 97,6 % aller Webseiten als UTF-8 kodiert, 1,1 % als ISO-8859-1 und noch mal knapp ein Prozent entfallen auf die Codierungen Windows-1251 und Windows-1252.

Alte Zeichensätze und Codierungen werden über kurz oder lang ein Nischendasein führen und zum Großteil durch Unicode ersetzt werden, zumindest was moderne System angeht.

Im Rahmen der Script Encoding Initiative von Deborah Anderson, welche sie seit 2002 an der University of California in Berkeley betreibt, werden neue Schriftsysteme für den Standard vorgeschlagen, sodass auch in Zukunft weitere Zeichen in den Standard aufgenommen werden.

So zog 2016, mit Adlam, ein ungewöhnliches Schriftsystem in den Standard ein. Ungewöhnlich deshalb, weil dieses System erst seit 1989 existiert. Zwei Brüder entwickelten dieses System, um ihre Sprache, Fulani, phonetisch in einem Schriftsystem abbilden zu können. Etliche Jahre später wurde das System dank der Unterstützung der Script Encoding Initiative schließlich in den Unicode-Standard übernommen und wird mittlerweile unter Windows, Chrome OS sowie Android unterstützt.

Dieses Beispiel zeigt, wie Unicode eine Grundlage für die Nutzung und Überführung von Schriftsystemen in die digitale Welt ist. Noch einige Jahrzehnte zuvor war ein Großteil des Internets und der IT auf einige lateinische Buchstaben reduziert. Dank Unicode ist es möglich in seiner jeweiligen Muttersprache und in seinem angestammten Schriftsystem digital zu kommunizieren, sich zu informieren und teilzuhaben.

Das Unicode Consortium wird seine Arbeit fortsetzen und sich dabei auch in einem teilweise politischen Spannungsfeld bewegen. Wie Randall Munroe, Autor des xkcd-Comics, dazu einmal sagte:

I am endlessly delighted by the hopeless task that the Unicode Consortium has created for themselves. […] They started out just trying to unify a couple different character sets. And before they quite realized what was happening, they were grappling with decisions at the heart of how we use language, no matter how hard they tried to create policies to avoid these problems. It’s just a fun example of how weird language is and how hard human communication is and how you really can’t really get around those problems.

So bietet uns Unicode lateinische Schrift, Spielkarten, Operatoren, Emojis, Schriftzeichen aus vielen menschlichen Kulturen und mehr. Und da sich Schrift und Sprache im Laufe der Zeit verändern, wird der Unicode-Standard wohl nie fertiggestellt, sondern ein lebendiger und sich weiterentwickelnder Standard sein.

Mit seinen 144.697 Zeichen und der Abbildung von über 150 Schriftsystemen liefert er einen Beitrag zur Erhaltung der Schriftkultur und der Daten über die Jahrzehnte. In Zeiten von Globalisierung und weltweit miteinander interagierenden Systemen ist ein gemeinsamer Zeichensatz sicherlich nicht die schlechteste Idee gewesen.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

Standardeditor im Terminal unter macOS Big Sur ändern

Der Standardeditor im Terminal unter macOS Big Sur, welches die Z shell nutzt, ist vim. Soll dieser Standard geändert werden, muss die Profildatei der Z shell angepasst werden:

nano ~/.zshrc

Dort wird nun folgende Zeile hinzugefügt:

export EDITOR=nano

Nachdem dem Speichern der Änderung, sowie einem Neustart der Terminal-App ist der neue Editor als Standard gesetzt.

Referenz für Markdown

Markdown ist eine Auszeichnungssprache für Text mit vielen Vorteilen. Da Markdown an sich kein festgeschriebener Standard ist, gibt es unterschiedlichste Varianten bzw. Ausprägungen von Markdown. In der Vergangenheit waren entsprechende vollständige und aktuelle Referenzen für Markdown Mangelware. Deshalb begann der technische Redakteur Matt Cone damit selbst eine solche Referenz zu entwickeln.

Der Markdown Guide liefert eine Referenz für Markdown

In dieser Referenz ist das ursprüngliche Markdown ebenso aufgeführt wie die erweiterten Markdown-Stile. Auch entsprechendes Tooling rund um Markdown wird in der Referenz beleuchtet. Zu finden ist die Referenz unter markdownguide.org. Der Quelltext der Webseite ist auf GitHub zu finden. Er ist unter der MIT-Lizenz lizenziert und damit freie Software. Der eigentliche Inhalt der Referenz ist unter der Creative Commons-Lizenz CC-BY-SA lizenziert.