仕組み

report.pdf という名前のファイルが必ずしも PDF とは限らず、拡張子のまったくないファイルでもたいていは判別できます。そこで最初に行うのは、アップロードの先頭バイトを読み、既知の形式シグネチャと照合することです。

これは見た目以上に重要です。拡張子を信用すると、名前を変えただけのファイルが分かりにくいエラーで失敗するか、さらに悪ければ誤ったツールに渡されます。バイト列を読めば、ラベルの誤ったファイルもそのまま正しく変換でき、本当に名乗りどおりでないファイルは明確に拒否できます。

対応するすべての変換は 2 つの形式を結ぶ辺であり、各辺は忠実度、おおよそのコスト、受け入れ可能な最大入力サイズを保持しています。形式ページはこのグラフから生成され、その全体が API を通じて公開されています。

指定された 2 つの形式の間に辺が存在しない場合は、アップロード後ではなくその場でお知らせします。変換が動いているように見せるために、劣化を伴う中間形式へ黙って迂回させることはありません。

画像の拡大縮小は 1 秒を大きく下回るため、リクエストの中で実行され、応答にはすでに結果が含まれます。長い文書のレンダリングや動画のトランスコードはそうではないため、キューに入り、別のワーカー群が処理します。

どちらになったかを推測する必要はありません。完了したジョブは結果とともに返り、キューに入ったジョブはジョブ ID・待ち順・所要時間の見込みとともに返ります。照会するか、メールを待ってください。

ウェブサイト、API、メール変換は、ひとつのパイプラインへの 3 つの入口です。異なるのは呼び出し元の識別方法だけ — セッション Cookie、ベアラートークン、あるいはメールの送信者 — で、その後はまったく同じコードを実行します。

これは実装上の都合ではなく意図的な制約です。「使用量を確認し、バイト列を判定し、アーカイブを保護する」を 2 通り実装すれば、いずれ一方が、最も気づかれにくい利用者に対してだけ手順を省くようになります。