2

エンコードする文字、必要なマージン、およびECレベルを指定して、標準に準拠したQRコードに対応するために必要な最小ピクセル数を出力するコードをいくつか作成しました。ただし、有効なQRコードではなく、Googleから空白の画像応答が返されます。

可能な最小のQRコードは、29x29ピクセルのバージョン1 QRコードです（21個のコード化モジュール+各側に4個のモジュールマージン）。 例

1文字のQRコード

Google ChartsのQRコードのドキュメントによると、ECレベルHのバージョン1 QRコードで使用できる0〜9桁の最大数は17です。ただし、そのようにパラメータを指定すると、空白の画像になります。choeパラメータが何に設定されていても、収容できるよりも多くのデータがエンコードされているためです。

有効である必要がありますが空白

文字数を14文字に減らすと、有効なQRコードになります。

動作するには桁数を減らす必要があります

では、特定のバージョンとECレベルごとにGoogle Charts APIでエンコードできるデータの量を知っている人はいますか？文字バイトに依存しますか？私のコードはJavaで書かれていますが、必要に応じて、任意のプログラミング言語でのソリューションで十分です。

うまくいけば、私は何か間違ったことをしたか、QRコードの「十分な」実装ではなく、従うことができるいくつかのロジックがあります。

4

2 に答える 2

1

これに対する公式の答えはありません。APIは非推奨になったため、回答が表示されたり、バグが修正されたりする可能性はほとんどありません。zxingはまだ開発されており、前述の問題に悩まされていないため、代わりにzxingを使用することをお勧めします。

于 2012-09-08T20:00:33.023 に答える
0

生成された画像のピクセル単位のサイズは、ここでは関係ありません。表示および生成しているQRコードはすべて有効です。

数値モードを使用すると、バージョン1のQRコードは17桁に収まります。

ここでは、ChartServerの実装が単に間違っていると思います。数値モードを使用していますが、必要以上にパディングバイトを入れているため、バージョン2が使用されています。

zxingに表示されるバージョンは、実際には同じベースエンコーダーコードですが、実際には、2006年に開始されたこの実装よりも最新で、おそらく修正されていると思います。そこの中に。）

ECIセグメントを使用してバイトモードでUTF-8エンコーディングを指定する場合、UTF-8は有効です。しかし、それが正しく行われることはめったにありません。zxingはそれをサポートしています。

実際には、バイトモードでQRコードに入れられるあらゆる種類のもの（Shift_JIS、UTF-8など）があります。zxing（およびその他）は、多くの場合、それを正しく推測します。チャートサーバーであるAFAIKは、デフォルトのISO-8859-1で合法的にエンコードできないため、必要に応じてUTF-8を使用します。しかし、それはここでは問題ではありません。

チャートサーバーは、仕様が示す制限から数バイト離れていると思います。仕様はISO18004：2006です。それはあなたにすべてのバージョン、モードとECレベルのためのすべての正しい制限を与えます。

AFAIK zxingはそれを正しく行い、それはJavaです。

于 2012-05-27T19:02:28.257 に答える