本文へスキップ
OpenQRS
ツール
現在の言語: 日本語
100%プライベート

メール QRコード作成

100%プライベート、ローカル処理 — データがブラウザの外に出ることはありません。これらのQRコードは恒久的で、期限切れになることはありません。

メールの設定

アドレスは1つです。RFC 6068はカンマ区切りで複数を認めていますが、スマートフォンのメールアプリは最初の1つだけを残すのが普通です。

メールの宛先アドレスを入力してください。

任意です。?subject= パラメータに入り、空白はプラス記号ではなく%20としてエンコードされます。

任意です。改行はRFC 6068が求めるとおり%0D%0Aとしてエンコードされます。ここの1文字ごとにシンボルが大きくなります。

デザイン

モジュールの形
プリセット
コーナーの枠
中央にロゴを追加
画像を選択、またはここにドロップPNG, JPEG, WebPまたはGIF、1000 KBまで

画像はこのページ内で読み込まれ、data: URLとしてコードに埋め込まれます。アップロードはされず、ダウンロードするファイルの中に留まります。

その他のデザイン設定

コードの暗いほうの半分です。背景より明度を十分低く保ってください。

モジュール同士の隙間だけでなく、クワイエットゾーンも塗ります。背景を透過にするとファイルから省かれるので、この色では何も描画されません。

モジュールと背景のコントラストは11.5:1です。

プリセット

PNGとWebPはアルファチャンネルを保持し、SVGは背景の矩形をそのまま省きます。コードを置いた面が、コントラストの明るいほうの半分になります。

グラデーション

グラデーションは暗いモジュールだけを塗ります。明るいほうの端がスキャナーの実際に得るコントラストを決めるので、両端とも暗いままにする必要があります。

2色目で、グラデーションを選んでいる間だけ使われます。1色目と並べてコントラストが測定されます。

45°

左から右への向きを起点とした時計回りの角度です。放射グラデーションは中心から外へ広がるため、角度が効くのは線形のときだけです。

モジュールの形

丸い形はセルを覆う面積が小さくなります。デコーダーが標本を取る中心は覆われたままですが、密度の高いコードを小さく印刷する場合は四角のほうが安定して読み取れます。

コーナーの枠

3つの位置検出パターンの外枠です。

コーナーの中心

各位置検出パターンの中にある目にあたる部分です。

4モジュール

コードの周囲の余白で、モジュール単位で測ります。規格上の最小値は4です。

復元レベルが高いほど多くの損傷に耐えられますが容量を消費するため、同じ内容でもシンボルが密になります。

中央にロゴがあり、レベルをHに固定しています。幅の上限はシンボルに応じて変わり、最小のコードで14%、密なコードで30%です。

ライブプレビューと書き出し

書き出し

書き出し

ラスター、画面向け

フォームを入力するとダウンロードが有効になります。

書き出しサイズとエンコードされたテキスト
ペイロード
まだ何もエンコードされていません
シンボル
まだ生成されていません
復元レベル
M

入力待ち

書き出しサイズ

64〜4096ピクセルの範囲。1024 pxで書き出します。

エンコードされたテキスト

mailto:のQRコードは、宛先と件名と本文を書き込んだ状態でスマートフォンのメールアプリを開き、送信者は送信を押すだけの状態にします。本文はシンボルの中に読み取り可能なテキストとして入っているため、これは非公開の連絡経路ではなく、きっかけを渡す仕組みです。

スキャンしたときの動作

スマートフォンが既定のメールアプリで宛先と内容を入力済みの新規下書きを開き、本人が送信をタップするまで何も送信されません。

mailto: URIの組み立て方

ペイロードはRFC 6068で定義されたURIです。スキームの直後にアドレスが続き、それ以外はクエリとして届きます。疑問符のあとに最初のパラメータ、残りはアンパサンドでつなぎます。mailto:hello@example.com?subject=Stand%2014%20enquiry&body=Please%20send%20a%20quote. で完全なペイロードです。

手作りのmailto:コードが壊れるのはエンコードのところです。予約文字はパーセントエンコードしなければならず、非ASCIIのテキストはまずUTF-8に変換してから1バイトずつパーセントエンコードする必要があります。RFC 6068は、空白をプラス記号ではなく%20と書くべきだと明示しています。プラス記号は、アドレスの中の本物のプラス記号と区別できないからです。

本文中の改行は%0D%0Aとしてエンコードしなければなりません。ペイロードに生の改行が入ると、本文がその位置で切れるか、メールアプリがまったく解釈できないURIになります。

メールアプリが実際に尊重するもの

RFC 6068が読み取り側に課す基準は、意図的に低く設定されています。mailto: URIを解決するクライアントはsubjectヘッダーとbodyを扱えなければならず、それ以上は何も保証されません。実際にはccとbccはほとんどのデスクトップクライアントが尊重し、モバイルのかなりの数が無視します。だからこのページには、黙って消えることになる項目を用意していません。

スキャンすると、端末が既定に設定しているメールアプリが開きます。標準のメールアプリを削除したまま代わりのアプリにサインインしていない人の場合、タップしても目に見える反応がありませんが、これはコードの不具合ではなく端末側の設定です。

もう1つのゆるい上限は本文の長さです。事前入力された本文を切り詰めるクライアントがありますし、どの文字もシンボルを大きくします。そのためmailto:コードは、件名に加えて、その人が今どこに立っているかが分かる1〜2文を入れる使い方が最も向いています。

送信ではなく下書き、そして秘密でもない

スキャンしても何も送信されません。メールアプリは送信者自身のアカウントで、その人自身のアドレスから、内容が入った下書きを開き、送る前にどの部分も編集できます。つまりそのメッセージは、普通のReply-Toを持つ普通のメールとしてあなたに届きます。

コードの中身はすべて読み取れます。ポスターを撮影した人は誰でも、どんなスキャナーでもアドレス、件名、本文を復号できるので、本文に入れた整理番号や割引の合言葉は、印刷した瞬間から公開されています。

印刷されたアドレスは、Webページ上のmailto:リンクと同じように機械可読なので、収集される可能性があります。info@やbooth14@のような役割ごとのアドレスにしておけば、印刷物から個人のメールボックスを外しておけますし、ほかの印刷物を刷り直さずに廃止できます。

よくある質問

スキャンするとメールは自動で送信されますか?

いいえ。mailto:スキームにできるのは下書きを開くことだけです。宛先、件名、本文が本人のメールアプリに表示され、どこでも変更でき、送信は自分で押す必要があります。どのプラットフォームのどのメールアプリも、その操作なしにmailto:のメッセージを送ることはありません。

ccやbccのアドレスを追加できますか?

RFC 6068はccとbccをクエリ文字列の中のヘッダーフィールドとして定義していますが、クライアントに義務づけているのはsubjectとbodyを理解することだけです。モバイルのメールアプリは残りを頻繁に捨てるので、動くように見えてから消えるくらいなら、と、ここでは用意していません。

なぜ空白はプラス記号ではなく%20なのですか?

RFC 6068がそう定めているからです。mailto: URIでは、name+tag@example.com のようにプラス記号がアドレスの中の本物の文字になりえます。そのため、空白を表すプラス記号は本来そこにあるプラス記号と区別できません。%20ならその曖昧さがなくなります。

このように印刷すると、アドレスが収集されませんか?

その可能性はあります。mailto:のペイロードはWebページ上のmailto:リンクと同じくらい機械可読で、撮影されたコードは誰でも復号できます。廃止できる役割用のアドレスを使い、公開されたアドレスと同じだけ迷惑メールを集めるものと考えてください。

静的QRコードの仕組み

このサイトのコードはすべて静的です。ペイロードは白黒のモジュールそのものに書き込まれています。読み取り時に何かを参照することはなく、当サイトのサーバーが関与することもなく、印刷されたコードをサブスクリプションが支えているわけでもありません。同じ性質が限界でもあります。一度印刷すると、中身は変更できません。

印刷したコードが読めるかどうかを決めるのは3つです。ペイロードが何バイトになったか、どの復元レベルが損傷を吸収するか、そして紙の上で1モジュールがどれだけの幅になるか。以下のガイドは、そのそれぞれを数字とともに扱います。