Ratgeber · Mechanik & Berechnung
Konvertierungs-Engine: wie der Umrechner über SI-Basisgrößen arbeitet
Jede Umrechnung läuft über zwei Schritte: erst in die Basiseinheit (Meter, Kilogramm, Liter, Celsius), dann in die Zieleinheit. Das hält die Engine klein, fehlerarm und nachvollziehbar.
Wer einen Universal-Umrechner bauen will, muss eine zentrale Frage beantworten: wie verbindet man 22 Einheiten ohne 484 einzelne Umrechnungs-Funktionen? Die Antwort lautet Zwei-Schritt-Verfahren über eine Pivot-Einheit. Mein Code in unitConverter.ts setzt das in 261 Zeilen TypeScript um. Hier zeige ich, wie die Engine arbeitet und warum diese Architektur fehlerarm bleibt.
Die vier SI-Basisgrößen als Pivots
Der Umrechner kennt vier Kategorien: Länge, Gewicht, Volumen, Temperatur. Jede Kategorie hat genau eine Pivot-Einheit, in die zuerst konvertiert wird. Für Länge ist das der Meter, für Gewicht das Kilogramm, für Volumen der Liter, für Temperatur Celsius. Drei davon sind echte SI-Basiseinheiten (Meter, Kilogramm, Kelvin), Liter ist eine zugelassene Nicht-SI-Einheit, Celsius eine abgeleitete Temperaturskala mit Offset gegenüber Kelvin.
Der Vorteil der Pivot-Architektur: bei N Einheiten brauche ich nur N Faktoren statt N mal N Umrechnungstabelle. 9 Längen-Einheiten bedeuten 9 Faktoren, nicht 81 Tabelleneinträge. Erweitert sich die Liste um eine neue Einheit (etwa Lichtjahr oder Astronomische Einheit), genügt ein Faktor zur Basis. Alle bestehenden Pfade funktionieren weiter.
Das Zwei-Schritt-Verfahren in Code
Die Hauptfunktion convertFactorBased macht zwei Operationen. Schritt 1 multipliziert den Eingabewert mit dem Faktor der Ausgangseinheit. Schritt 2 teilt das Ergebnis durch den Faktor der Zieleinheit. Vereinfacht:
const baseValue = value * fromDef.factor;
const result = baseValue / toDef.factor;Beispiel Schuhgröße. Eine US-Damengröße 8 entspricht 24,5 Zentimeter Fußlänge. Wer wissen will, wie das in Zoll ist: erst von Zentimeter in Meter (24,5 mal 0,01 = 0,245 m), dann von Meter in Zoll (0,245 geteilt durch 0,0254 = 9,6457). Ergebnis: 24,5 cm = 9,6457 in. Genau so läuft es intern ab, nur dass die Engine den Zwischenwert nicht anzeigt.
Faktor-basiert vs. formel-basiert
Länge, Gewicht und Volumen sind multiplikative Skalen. Null Meter sind null Zoll, doppelte Länge bedeutet doppelter Faktor. Ein einziger Multiplikator reicht zur Umrechnung. Bei Temperatur funktioniert das nicht. Null Grad Celsius sind nicht null Fahrenheit, sondern 32 Fahrenheit. Die Skalen haben unterschiedliche Nullpunkte (Offsets). Das macht eine separate Behandlung nötig.
Die Funktion convertTemperature nutzt deshalb Formeln statt Faktoren. Der Code prüft die Ausgangseinheit und rechnet zuerst in Celsius. Wenn Fahrenheit eingegeben wird, gilt (value - 32) * 5 / 9. Wenn Kelvin eingegeben wird, gilt value - 273,15. Im zweiten Schritt geht es von Celsius in die Zielskala mit der jeweils inversen Formel.
case 'f':
celsius = (value - 32) * 5 / 9;
break;
case 'k':
celsius = value - 273.15;
break;Mehr zum Temperatur-Spezialfall steht im eigenen Ratgeber zur Celsius-Fahrenheit-Kelvin-Umrechnung.
Faktor-Tabelle Länge
Die 9 Längen-Einheiten mit ihren exakten Faktoren zur Basiseinheit Meter, wie sie in LENGTH_UNITS stehen:
| Einheit | Symbol | Faktor zu Meter | Quelle |
|---|---|---|---|
| Millimeter | mm | 0,001 | SI-Vorsilbe milli |
| Zentimeter | cm | 0,01 | SI-Vorsilbe centi |
| Meter | m | 1 | Basiseinheit |
| Kilometer | km | 1.000 | SI-Vorsilbe kilo |
| Zoll | in | 0,0254 | Yard and Pound Agreement 1959 |
| Fuß | ft | 0,3048 | 12 Zoll |
| Yard | yd | 0,9144 | 3 Fuß |
| Meile | mi | 1.609,344 | 1.760 Yard |
| Seemeile | nmi | 1.852 | CGPM 1929 |
Die Imperial-Faktoren sind nicht gerundet. 0,0254 für den Zoll ist exakt, nicht “ungefähr”. Diese Exaktheit kommt aus dem International Yard and Pound Agreement von 1959, das die USA, das Vereinigte Königreich, Kanada, Australien, Neuseeland und Südafrika unterzeichneten. Vorher gab es leicht unterschiedliche nationale Definitionen, der größte Unterschied betraf einige Millionstel pro Yard. Mehr dazu im Ratgeber zum Yard and Pound Agreement.
Faktor-Tabelle Gewicht
Die 8 Gewichts-Einheiten mit Faktor zur Basiseinheit Kilogramm:
| Einheit | Symbol | Faktor zu Kilogramm |
|---|---|---|
| Milligramm | mg | 0,000001 |
| Gramm | g | 0,001 |
| Kilogramm | kg | 1 |
| Tonne | t | 1.000 |
| Unze | oz | 0,028349523125 |
| Pfund | lb | 0,45359237 |
| Stone | st | 6,35029318 |
| US-Tonne | ton | 907,18474 |
Auch hier sind die Imperial-Faktoren exakt, nicht gerundet. 0,45359237 Kilogramm pro Pfund stammt aus dem Yard and Pound Agreement 1959. Stone ist eine britische Einheit (14 Pfund), in den USA praktisch ungenutzt. Die US-Tonne (Short Ton, 2.000 Pfund) ist nicht identisch mit der metrischen Tonne (1.000 kg) und liegt rund 9 Prozent darunter.
Faktor-Tabelle Volumen
Die 10 Volumen-Einheiten mit Faktor zur Basiseinheit Liter:
| Einheit | Symbol | Faktor zu Liter |
|---|---|---|
| Milliliter | ml | 0,001 |
| Zentiliter | cl | 0,01 |
| Deziliter | dl | 0,1 |
| Liter | l | 1 |
| Kubikmeter | m³ | 1.000 |
| Fluid Ounce | fl oz | 0,0295735295625 |
| Cup | cup | 0,2365882365 |
| Pint | pt | 0,473176473 |
| Quart | qt | 0,946352946 |
| Gallone | gal | 3,785411784 |
Wichtig: die Volumen-Imperials sind US-Standard. Britische Pints und Gallonen sind etwa 20 Prozent größer. Wer britische Rezepte umrechnet, muss das wissen. Mein Ratgeber zu US-vs-UK-Imperial erklärt die Unterschiede im Detail.
Beispielrechnung Marathon
Ein Marathon ist 26,2 Meilen lang. Wie viele Kilometer sind das? Schritt 1: 26,2 mal 1.609,344 = 42.164,8128 Meter. Schritt 2: 42.164,8128 geteilt durch 1.000 = 42,1648 Kilometer. Auf sechs signifikante Stellen formatiert zeigt der Umrechner 42,1648 km.
Die offizielle Marathon-Distanz ist 42,195 Kilometer (festgelegt von der IAAF 1921). Die “26,2 Meilen” sind eine gerundete Imperial-Angabe, die nicht ganz präzise dem metrischen Original entspricht. Wer 26,2188 Meilen eingibt, kommt auf 42,195 km, das ist die exakte Umkehrung der metrischen Originaldistanz.
Beispielrechnung Schuhgröße
Eine EU-Schuhgröße ist eine Pariser Stich-Skala, kein direktes Längenmaß. Aber die meisten EU-zu-US-Konvertierungen rechnen über die Fußlänge. Damenschuh EU 39 entspricht etwa 24,8 cm Fußlänge. Wer das in Zoll wissen will: 24,8 mal 0,01 = 0,248 m, dann 0,248 geteilt durch 0,0254 = 9,7638 Zoll. Ergibt rund 9 3/4 Zoll, was Damen-US-Größe 8,5 entspricht.
Schuhgrößen sind kein exaktes Umrechnungs-Thema, weil jede Marke leicht abweicht. Der Umrechner liefert die geometrische Längenbeziehung, das ist die saubere Grundlage. Wer dann eine Marken-Tabelle nutzt, hat zwei verlässliche Schritte: Fußlänge messen, dann in der Marken-Tabelle nachschauen.
Validierung und Edge-Cases
Bevor die Engine rechnet, prüft sie drei Bedingungen. Erstens: ist der Eingabewert eine endliche Zahl? Unendlich oder NaN werden mit einer Fehlermeldung abgefangen. Zweitens: ist der Wert negativ? Bei Länge, Gewicht und Volumen ist negativ nicht erlaubt, weil physikalisch sinnlos. Bei Temperatur ist negativ normal (Celsius kann unter null fallen). Drittens: ist der Wert kleiner als 10 hoch 15? Größere Werte sprengen die Anzeige und die numerische Genauigkeit von JavaScript-Floats.
JavaScript nutzt für Zahlen IEEE-754-Doubles mit 64 Bit. Das gibt rund 15 bis 17 signifikante Dezimalstellen Genauigkeit. Bei sehr großen Werten oder vielen Multiplikationen können Rundungsfehler auftreten. Für die hier verwendeten Faktoren mit maximal 10 Nachkommastellen ist die Genauigkeit unkritisch. 1 Pfund in Milligramm ergibt mit der exakten Definition 453.592,37 mg, die JavaScript-Berechnung liefert genau diesen Wert.
Ausgabe-Formatierung
Die Funktion formatResult rundet auf sechs signifikante Stellen und entfernt trailing Nullen. toPrecision(6) erzeugt aus 67592.448 den String “67592.4” (rundet ab), aus 0.62137 den String “0.621370” (mit Null). Ein anschließendes parseFloat plus toString entfernt die Null und liefert “67592.4” bzw. “0.62137” für die Anzeige.
Sehr kleine oder sehr große Werte würde JavaScript in Exponential-Notation rendern (z.B. 1e-7 für 0,0000001). Das ist mathematisch korrekt, aber für Endnutzer wenig lesbar. Wer möchte, kann die Formatierung erweitern, um Werte zwischen 0,000001 und 1.000.000 immer in Dezimal-Notation darzustellen. Für die hier abgedeckten Einheiten ist der Bereich aber meist gut.
Internes vs. angezeigtes Ergebnis
Die Engine arbeitet intern mit voller Float-Präzision. Erst bei der Ausgabe wird auf sechs Stellen gerundet. Das hat einen Grund: wer das interne Ergebnis weiterverarbeitet (z.B. für ein Diagramm oder eine API-Antwort), bekommt die unverkürzte Zahl. Die formatierte Anzeige ist nur ein String für die UI.
Wer im JavaScript-Code mit der Funktion convertUnit arbeitet, bekommt ein Objekt mit drei Feldern zurück: result (Float), formatted (String mit gerundetem Wert), formula (lesbare Beschreibung). Beispiel-Output für 1 Meile in Kilometer:
{
result: 1.609344,
formatted: "1.60934",
formula: "1 Meile (mi) = 1.60934 Kilometer (km)"
}Was die Zwei-Schritt-Architektur leistet
Vier SI-Basisgrößen, ein generischer Faktor-Multiplikator, eine spezielle Temperatur-Formel. Mehr braucht es nicht, um 22 Einheiten korrekt umzurechnen. Die Engine bleibt in 261 Zeilen TypeScript überschaubar, alle Faktoren sind dokumentiert und auf ISO 80000-1 sowie das International Yard and Pound Agreement 1959 zurückführbar. Erweiterungen um Druck, Energie oder Geschwindigkeit folgen demselben Muster und kosten je 30 Zeilen Code.
Wer eine Bibliothek von 8.000 Zeilen mit 200 Einheiten nutzt, hat mehr Code zu pflegen und mehr potenzielle Fehlerquellen. Wer 22 Einheiten in einer eigenen Engine implementiert, hat die volle Kontrolle und kann jede Umrechnung in zehn Sekunden gegen die offizielle Definition prüfen. Bei einem öffentlichen Tool mit hoher Sichtbarkeit ist das die robustere Wahl.
Wenn dir ein Fehler auffällt oder eine Quelle veraltet ist, schreib an info@akara-solutions.de, bestätigte Korrekturen dokumentieren wir auf /korrekturen/.
FAQ
Häufige Fragen
Warum nutzt der Umrechner nicht eine fertige Bibliothek aus npm?
Fertige Bibliotheken wie convert-units oder js-quantities decken zwar viele Einheiten ab, schleppen aber 50 bis 200 Kilobyte JavaScript mit, das zur Hälfte aus Einheiten besteht, die niemand braucht. Mein Code ist 261 Zeilen TypeScript für 22 Einheiten plus Temperatur-Formeln. Das lädt in unter 4 Kilobyte minified und bleibt vollständig auditierbar. Wenn ein Faktor falsch wäre, sehe ich das in zehn Sekunden, statt durch 8.000 Zeilen Drittcode zu pflügen. Außerdem definiere ich die Faktoren genau so, wie sie im International Yard and Pound Agreement 1959 und in ISO 80000-1 stehen, ohne Zwischenkonvertierung mit Rundungsfehlern.
Was passiert intern, wenn ich Meilen in Kilometer umrechne?
Der erste Schritt nimmt den Eingabewert und multipliziert ihn mit dem Meilen-Faktor 1609,344 zu Metern. Aus 42 Meilen werden so exakt 67592,448 Meter. Der zweite Schritt teilt das Ergebnis durch den Kilometer-Faktor 1000 und liefert 67,592448 Kilometer. Die Ausgabe-Funktion rundet danach auf sechs signifikante Stellen, das ergibt die finale Anzeige 67,5924 km. Diese Zwei-Schritt-Logik wird in der Funktion convertFactorBased für Länge, Gewicht und Volumen gleich verwendet. Nur die Basiseinheit ändert sich (Meter, Kilogramm, Liter). Temperatur läuft über einen eigenen Zweig, weil Offset-Skalen anders funktionieren.
Warum darf der Eingabewert nicht negativ sein, außer bei Temperatur?
Eine negative Länge oder ein negatives Gewicht ergibt physikalisch keinen Sinn. Wer minus 5 Kilogramm sagt, meint entweder eine Differenz oder hat sich vertippt. Der Umrechner fängt das mit einer Validierung ab und gibt eine klare Fehlermeldung. Bei Temperatur ist negativ dagegen normal. Minus 40 Grad Celsius existiert real, das ist der Punkt, an dem Celsius und Fahrenheit denselben Zahlenwert haben. Kelvin liegt als absolute Skala bei null als Untergrenze und kann nie negativ werden. Wenn jemand minus 10 Kelvin eingibt, ist das physikalisch unmöglich, aber die Engine erlaubt es trotzdem und liefert minus 283,15 Celsius. Die Validierung schiebt sich da nicht dazwischen, weil die Rechenformel mathematisch sauber bleibt.
Was bedeutet sechs signifikante Stellen bei der Ausgabe?
Signifikante Stellen sind die mathematisch bedeutsamen Ziffern eines Werts, unabhängig von der Position des Kommas. 67,5924 hat sechs signifikante Stellen, 0,0006759 ebenfalls. Mein Umrechner nutzt das, weil es bei sehr kleinen und sehr großen Werten gleich gute Lesbarkeit liefert. Ein Millimeter in Meilen ergibt 0,000000621371 mi, was nach Rundung auf sechs Stellen als 6,21371 mal 10 hoch minus sieben angezeigt würde. Die toPrecision-Funktion von JavaScript erledigt das und entfernt trailing Nullen. So sieht der Output sauber aus, auch wenn die Skalen 15 Größenordnungen auseinander liegen. ISO 80000-1 empfiehlt drei bis sechs signifikante Stellen für technische Anwendungen, sechs liegt am oberen Ende und reicht für jeden Alltagsfall.
Kann die Engine erweitert werden, etwa um Druckeinheiten oder Energie?
Ja, das Muster lässt sich beliebig erweitern. Druck (Pascal als Basis, bar, psi, mmHg) oder Energie (Joule als Basis, Kalorie, Wattstunde) folgen demselben Schema: eine Array-Konstante mit Faktoren zur Basiseinheit, dann der gemeinsame convertFactorBased-Code. Aufwand pro neue Kategorie etwa 30 Zeilen Code plus drei Tests. Der Grund, warum ich aktuell nur vier Kategorien anbiete: 80 Prozent aller realen Suchanfragen in Deutschland drehen sich um Länge, Gewicht, Volumen und Temperatur. Druck und Energie sind Spezialfälle, die ein dedizierter wissenschaftlicher Rechner besser bedient. Bei Bedarf lege ich aber jederzeit nach.
Quellen