One visible letter, two sequences
Das Wort Café kann ein einzelnes zusammengesetztes é mit dem Codepunkt U+00E9 enthalten oder ein e gefolgt von einem kombinierenden Akutzeichen, U+0065 U+0301. Viele Schriftarten stellen beide Folgen ähnlich dar. In UTF-8 verwendet das zusammengesetzte é die Bytes C3 A9; die zerlegte Schreibweise endet mit 65 CC 81. SHA-256 bildet einen Hash aus den Eingabebytes. Deshalb erhalten die beiden Schreibweisen verschiedene Hashwerte, obwohl Leser dasselbe Wort sehen. Das ist kein Fehler des Hashverfahrens, sondern ein Unterschied zwischen visueller Ähnlichkeit und Bytegleichheit. Bewahren Sie bei der Fehlersuche die ursprüngliche Zeichenfolge auf.
Normalise under an explicit agreement
Unicode NFC setzt geeignete Zeichenfolgen in eine kanonische Form zusammen; NFD zerlegt sie. Wenn zwei Systeme vereinbaren, Text vor der UTF-8-Kodierung und dem Hashen nach NFC zu normalisieren, führen beide Café-Schreibweisen im Beispiel zu derselben kanonischen Bytefolge. Das eingebettete NFC-Werkzeug zeigt die Veränderung an der zerlegten Eingabe. Die Reihenfolge ist entscheidend: zuerst Zeichen normalisieren, dann als UTF-8-Bytes kodieren und schließlich genau diese Bytes hashen. Wer zuerst hasht, kann gleichwertige Schreibweisen danach nicht mehr abgleichen. Halten Sie die vereinbarte Normalisierungsform im Datenvertrag fest.
- Café: zusammengesetztes é oder e plus Akut
- NFC → vereinbarte Zeichenfolge
- UTF-8-Bytes → SHA-256-Hashwert
Do not normalize everything blindly
Durch die Normalisierung kann der genaue Quelltext geändert werden, und die Kompatibilitätsformen NFKC und NFKD ermöglichen umfassendere Ersetzungen als NFC und NFD. Das kann für einen Suchindex nützlich sein, aber ungeeignet für eine juristische Niederschrift, eine digitale Signatur über einem vorhandenen Dokument oder ein System, das eine Byte-für-Byte-Archivierung verspricht. Das Falten von Hüllen, das Beschneiden von Leerzeichen und das Ändern von Zeilenenden sind zusätzliche Optionen und keine automatischen Bestandteile von NFC. Die Spezifikation eines Protokolls erfordert möglicherweise die ursprünglichen Bytes oder definiert ein anderes Kanonisierungsverfahren. Befolgen Sie diese Regel, anstatt die Normalisierung anzuwenden, nachdem Sie eine Nichtübereinstimmung festgestellt haben.
Check the bytes with a controlled test
Erstellen Sie zwei kurze Zeichenfolgen: eine mit zusammengesetztem é und eine mit e plus dem Kombinationszeichen. Führen Sie jeweils den UTF-8-Byte-Viewer durch und notieren Sie am Ende C3 A9 gegenüber 65 CC 81. Hash the raw strings separately; their digests should differ. Wenden Sie dann NFC auf alle an, überprüfen Sie deren Bytes erneut und vergleichen Sie die SHA-256-Digests. Behalten Sie Leerzeichen, Zeilenumbrüche und versteckte Zeichen in kopierten Eingaben im Auge, da diese auch einen Digest verändern können. Der Test sollte identische Algorithmen und Kodierungen vergleichen; Ein SHA-256-Wert kann nicht direkt mit SHA-512 verglichen werden.
Choose the comparison you actually need
Bei einer Dateiintegritätsprüfung kommt es normalerweise darauf an, die ursprünglichen Bytes zu hashen: Jede Byte-Änderung sollte sichtbar sein. Für die Deduplizierung von von Menschen eingegebenen Namen kann eine dokumentierte Textnormalisierungsrichtlinie vor dem Hashing sinnvoll sein, allerdings weisen Namen auch Probleme mit der Groß-/Kleinschreibung und der Sprache auf, die ein einzelnes Unicode-Formular nicht löst. Für Passwörter und Authentifizierung regeln spezielle Sicherheitsdesigns die Normalisierung und das Passwort-Hashing; Ein einfacher SHA-256 eines Passworts reicht nicht aus. Geben Sie an, ob das Ziel Byteidentität, normalisierte Textäquivalenz oder menschliche Ähnlichkeit ist. Das sind unterschiedliche Versprechen, und kein Konverter kann allein aus der Optik auf das Gewollte schließen.