Codierung, der das Fehlreading / FirmyPing / Misspeaking minimiert?

Question

sagen wir sagen, dass Sie ein System haben, in dem ein ziemlich langer Schlüsselwert einem Benutzer auf dem Bildschirm, per E-Mail oder über Papier, mitgeteilt werden kann; Der Benutzer muss jedoch in der Lage sein, den Schlüssel genau an Sie mitzuteilen, indem Sie ihn über das Telefon lesen, oder indem Sie ihn lesen und in eine andere Schnittstelle zurückgeben.

Was ist ein "guter" Weg, um den Schlüssel zu codieren, um das Lesen / Hören / Tippen einfach einfach und genau zu machen?

Dies könnte eine Rechnungsnummer, eine Dokument-ID, eine Transaktions-ID oder einen anderen abstrakten Wert sein. Sagen wir zu diesem Diskussion, dass der zugrunde liegende Schlüsselwert eine große Zahl ist, sagen 40 Ziffern in der Basis 10.

einige Gedanken:

kürzere Tasten sind im Allgemeinen besser

.
• Eine 40-stellige Basis 10-Wert kann nicht in den angegebenen Raum passen und ist leicht, in der Mitte von zu verlieren
• Derselbe Wert könnte in Basis 16 in 33-34 Ziffern dargestellt werden
• der gleiche Wert könnte in der Basis 36 in 26 Ziffern dargestellt werden
• Derselbe Wert könnte in der Basis 64 in 22-23 Ziffern dargestellt werden

  Zeichen, die nicht miteinander visuell verwechselt werden können, sind besser

  .
  • z. Eine Codierung, die sowohl O (OH) als auch 0 (Null) oder S (ESS) und 5 (fünf) enthält, könnte schlecht sein
  • Dieses Problem hängt von dem Schriftart / Gesicht ab, das verwendet wird, um den Schlüssel anzuzeigen, den Sie in einigen Fällen in einigen Fällen kontrollieren können (wie das Drucken auf Papier), aber in anderen nicht kontrollieren können (wie Webseiten und E-Mail).
  • hängt auch davon ab, ob Sie die ausschließliche Verwendung von Groß- und / oder Kleinbuchstaben steuern können - z. Das Kapital d (dee) kann aussehen wie o (oh), aber Kleinbuchstaben d (dee) würde nicht; Während der Kleinbuchstaben l (ell) aussieht, wie ein 1 (eins), während das Kapital L (ell) nicht. (Mit Ausnahmen von vor allem exotischen Schriftarten / Gesichtern).

    Zeichen, die nicht miteinander verbal / ärgerlich verwechselt werden können, sind besser

    .
    • a (ay) 8 (acht)
    • b (Biene) C (CEE) d (dee) e (ee) g (gee) p (pee) t (tee) v (vee) z (zee) 3 (drei)
    • Dieses Problem hängt von der Audioqualität des End-to-End-Kanals ab - größere Herausforderung, wenn die erwartete Benutzerbasis ein Sprachindiment aufweisen kann oder durch eine Gasmaske sprechen muss, oder der Kommunikationskanal könnte CB umfassen Radios oder abgehackte VoIP-Telefonsysteme.

      Hinzufügen einer Überprüfungsstelle oder zwei würden Fehler erkennen, jedoch nicht helfen, Fehler aufzulösen.

      Ein-Alpha-Bravo-Charlie - Delta-Typ-Dialog kann bei Hörgeräten helfen, jedoch nicht gelesene Fehler.

      mögliche Kodierungsmöglichkeiten:

      .
      • Base 64 - kompakt, aber zu viele fleißige Zeichen (Unterstrich, das Dash etc.)
      • Base 34 - 0-9 und A-Z, aber mit O (OH) und I (AYE), die mit den Ziffern mit den Ziffern verbunden sind
      • Base 32 - gleich wie Basis 34, lassen Sie jedoch die 0 (Null) und 1 (eins), auch

        Gibt es eine allgemein anerkannte Kodierung, die eine vernünftige Lösung für dieses Szenario ist?

Answer 1

Wenn ich es zuerst gehört habe, mochte ich den Artikel ein Vorschlag für Perquinter: Kennungen, die lesbar, buchstabierbar und aussprechbar sind.Es codiert Daten als Folge von Konsonanten und Vokalen.Es ist jedoch an die englische Sprache gebunden.(Denn in deutsch, generationspflichtiger Toncode- und f-Klang gleich, so dass sie nicht beide verwendet werden sollten.) Aber ich mag die allgemeine Idee.