33

読みやすい英数字の既存のサブセットはありますか?特に、視覚的に曖昧な文字が少ないサブセットはありますか?特定の文字を削除(または同等化)することで、人的エラーを減らしますか?

「視覚的に曖昧」という表現はやや曖昧ですが、D、O、0がすべて類似しており、1とIも類似していることは明らかです。英数字のセットのサイズを最大にしたいのですが、誤解される可能性のある文字の数を最小にします。

そのようなセットについて私が知っている唯一の先例は、文字D、F、I、O、Q、およびUを削除するカナダの郵便番号システムであり、そのサブセットは郵便システムのOCRプロセスを支援するために作成されました。

私の最初の考えは、次のように大文字と数字のみを使用することです。

A
B = 8
C = G
D = 0 = O = Q
E = F
H
I = J = L = T = 1 = 7
K = X
M
N
P
R
S = 5
U = V = Y
W
Z = 2
3
4
6
9

この問題は、特定の書体から分離するのが難しい場合があります。選択した書体の文字の特徴は、任意の2つの文字の潜在的な視覚的曖昧さに大きく影響する可能性がありますが、ほとんどの現代の書体では、同等の上記の文字は、同等にするのに十分な類似の外観を持つと思います。

上記についての考えに感謝します–上記の方程式は適切ですか、それとも同等化する必要のある文字が他にもありますか?小文字の方が適していますか?

4

10 に答える 10

16

同様の理由 (キーのエンコードなど) で 16 進数 (基数 16) を置き換える必要がありました。

0 1 2 3 4 5 6 7 8 9 A B C D E F     Hexadecimal
H M N 3 4 P 6 7 R 9 T W C X Y F     Replacement

置換セットでは、次のことを考慮します。

使用されているすべての文字には、本当にひどいフォントでのみ省略される主要な特徴があります。

母音 AEIOU は、誤って単語を綴らないように省略されています。

一部のフォントで非常に類似または同一である可能性のある文字セットは完全に回避されます (どのセットの文字もまったく使用されません)。

0 O D Q 
1 I L J
8 B 
5 S
2 Z

これらの文字を完全に回避することで、ユーザーが間違って入力した文字を修正しようとするのではなく、正しい文字を入力することが期待されます。

あまり似ていないが紛らわしい文字のセットについては、各セットで 1 つの文字のみを使用します。できれば最も特徴的なものを使用します。

Y U V 

ここでは Y が使用されます。これは、常に垂直セクションが低く、セリフ フォントのセリフがあるためです。

C G         

ここで C が使用されているのは、C が G として入力される可能性は低いと思われるためです。

X K         

ここでは、ほとんどのフォントでより一貫しているため、X が使用されています。

F E         

ここでは母音ではないのでFが使われています。

これらの類似したセットの場合、セット内の任意の文字のエントリは、実際に使用されるもの (各セットにリストされている最初のもの) に自動的に変換される可能性があります。16 進入力が使用される可能性がある場合は、E を F に自動的に変換してはならないことに注意してください (以下を参照)。

置換セットにはまだ似たような文字が含まれていることに注意してください。これはほとんど避けられません。声に出して読むときは、表音文字を使用する必要があります。

標準の 16 進数にも存在する文字が置換セットで使用されている場合、それらは同じ base-16 値に使用されます。理論的には、E が F に自動的に変換されない限り、16 進数と置換文字の混合入力がサポートされる可能性があります。

これは単なる文字の置換であるため、16 進数との変換は簡単です。

ほとんどのフォントで比較的明確なはずの「h」と「n」を除いて、小文字も適切に見えますが、出力の「正規」形式には大文字が最適のようです。

h m n 3 4 p 6 7 r 9 t w c x y f

もちろん、入力は大文字と小文字を区別しません。

ベース 32 にはいくつかの同様のシステムがあります。http://en.wikipedia.org/wiki/Base32を参照してください。しかし、これらは明らかに、文字ごとにさらに 25% 多い情報と引き換えに、より類似した外観の文字を導入する必要があります。

どうやら次のセットはベース 24 の Windows プロダクト キーにも使用されていたようですが、やはり似たような文字が含まれています。

B C D F G H J K M P Q R T V W X Y 2 3 4 6 7 8 9
于 2014-12-13T13:16:45.657 に答える
14

主に、@rwb によって言及されたこの ux スレッドからインスピレーションを得ています。

  • いくつかの プログラムが同様のものを使用しています。あなたの投稿のリストは、これらのプログラムで使用されているものと非常によく似ているようで、ほとんどの目的にはこれで十分だと思います。小さな間違いを「許す」ために、常に冗長性 (エラー訂正) を追加できます。ただし、これにはコードのスペースを空ける必要があります (ハミング距離を参照)。
  • 人間との試行錯誤を除いて、リストを導出する際に使用される特定の方法についての言及はありません (これは非 ocr に最適です: ユーザー人間です) 。
  • 文字のグループ化 (たとえば、5 つのグループ) を使用してコンテキストを増やすことは理にかなっている場合があります (「5 つのグループの 2 番目の最初の文字」)。
  • あいまいさは、文字の代わりに完全な名詞を使用することで解消できます(類似語がほとんどない辞書から。ここでは word-edit-distance が役立つ場合があります)。「1」と「i」を混同する人がいるかもしれませんが、「one」と「ice」を混同する人はほとんどいません。
  • もう 1 つのオプションは、コードを読み上げられる (偽の) 単語にすることです。そこでマルコフモデルが役に立ちます。
于 2012-09-23T12:03:01.447 に答える
3

あなたが求めているのは、明確で効率的な人間とコンピューターのコードです。私がお勧めするのは、データ全体をリテラル (意味のある)単語、特に名詞でエンコードすることです。

私はまさにそれを行うためのソフトウェアを開発してきました-そして最も効率的に。私はそれをWCodeと呼んでいます。
技術的には、Base-1024 エンコーディング - 記号の代わりに単語を使用します。

リンクは次のとおりです:
プレゼンテーション : https://docs.google.com/presentation/d/1sYiXCWIYAWpKAahrGFZ2p5zJX8uMxPccu-oaGOajrGA/edit /github.com/San13/WCode (アップロード中ですので少々お待ちください...)

于 2012-09-24T20:56:06.830 に答える
2

これは、OCR の一般的な問題です。したがって、OCRエンコーディングが制御されるエンドツーエンドのソリューションでは、あなたが言及した「視覚的なあいまいさ」の問題を解決するために、特殊なフォントが開発されました。参照: http://en.wikipedia.org/wiki/OCR-A_font

追加情報として: Base32 エンコーディングについて知りたい場合があります。数字の「1」の記号は、ユーザーをアルファベットの「l」の記号と「混同」する可能性があるため、使用されません。

于 2012-08-12T09:16:20.760 に答える
1

それは、セットをどれだけ大きくしたいかによって異なります。たとえば、セット {0, 1} だけでもおそらくうまく機能します。同様に、数字のセットのみ。ただし、元の文字セットの約半分のサイズのセットが必要になる場合があります。

私はこれを行っていませんが、ここに提案があります。フォントを選び、最初の文字セットを選び、次のことを行うコードを書きます。n = 1 から (たとえば) 10 の場合、黒と白のピクセルの n 行 n 列の正方形に収まるように各文字を描画します。黒い領域。これにより、各文字の 10 個のコードのリストが得られます。これらのコードの違いの数によって、任意の 2 つの文字間の距離を測定します。アプリケーションに許容できる距離を見積もります。次に、それだけ離れている一連の文字を総当たり検索します。

基本的には、スクリプトを使用してキャラクターに目を細めてシミュレートし、まだ区別できるキャラクターを確認します。

于 2012-09-16T16:59:49.827 に答える
-1

base58:123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz

于 2020-04-23T13:35:01.953 に答える