UPC-Aチェックディジット
商品番号01234567890のチェックディジットは5で、完全なUPC-Aは012345678905になります。取引先のファイルやスキャナーから得た12桁のコードを貼り付ければ、最後の桁が正しいか分かります。ブラウザで無料で使えます。
- 無料
- ブラウザで動作
- 登録不要
- データは端末の外に出ません
無料で実行
計算例
- 数
- 01234567890
- 計算モード
- Compute
- 入力
- 01234567890
- チェックディジット
- 5
- チェックディジット付き
- 012345678905
北米の小売商品番号は、ほぼ常にUPC-Aのチェックディジットで終わります。本機能は、12桁のすべてのUPC-Aで使われる標準のGTIN-12 mod-10規則を実装します。左から奇数位は3、偶数位は1で重み付けし、チェックディジットは合計を次の10の倍数に合わせる値です。11桁の商品番号だけをお持ちで、ラベル・データベース・バーコード生成に桁が必要なときはcomputeモードを、パートナー・スキャナ・フォームが12桁の完全なコードを送り、validフラグと期待桁がエラー表示に必要なときはvalidateモードをご利用ください。
UPC-Aチェックディジットの計算方法
UPC-Aコードは常に12桁です。先頭11桁が商品番号(多くはGS1企業プレフィックスと品目参照)で、12桁目がチェックディジットです。同等に、チェックを含む12桁全体は、同じ位置の重みで加重和が10の倍数でなければなりません。
これはGTIN-8、GTIN-12、GTIN-13、GTIN-14で使われるmod-10系の規則と同じで、UPC-Aは米国・カナダの包装で一般的な12桁形式です。アルゴリズムは決定的でローカルであり、カタログ照会・ネットワーク呼び出し・時計は使いません。
本ツールはUPC-Eを展開せず、EAN-13の国プレフィックスを捏造せず、有効なチェックサムが販売認可を意味するとも主張しません。UPC-A規則の下で桁列が整形式であることだけを示します。多種バーコード検証と比べ、ここでの検索意図は狭いです。
実際の業務でのUPC-Aチェックディジットの位置づけ
カタログやPIMのチームは11桁の内部商品番号を受け取り、棚ラベル印刷や無効GTINを拒否するマーケットプレイス掲載の前に、公式のUPC-Aチェックディジットを付けなければなりません。倉庫スキャナと入荷アプリはドックで12桁コードを検証し、1回の転置で幽霊SKUや在庫不一致が生まれないようにします。
データ品質ジョブはCSVエクスポートの各UPC列を歩き、validateモードを呼び、validがfalseの行を隔離し、人手の編集と生成器のオフバイワン双方を捉えます。どの流れでも契約は同じです。通過したUPC-Aチェックをブランド所有やGS1登録の証明と見なさないでください。
活用例
カタログ出力のUPC列を監査する
PIMやパートナーCSVの12桁UPCを一括検証し、チェックディジットが再計算した期待値と一致しない行を隔離します。
よくある質問
UPC-Aチェックディジットとは何ですか?
UPC-Aコードの12桁目で、mod-10の加重和で計算され、入力やスキャンの1桁誤りが保存や印刷の前に多くの場合検出されます。
UPC-Aのチェックディジットはどう計算しますか?
11桁を左から読み、奇数番目の数字に3、偶数番目の数字に1を掛けてすべて足します。チェックディジットは、その合計を次の10の倍数にする数で、すでに倍数なら0です。
12桁のUPC全体を確認するには?
検証を選んで12桁すべてを入力します。有効かどうかがはっきり分かり、あわせて本来あるべきチェックディジットも示されるので、エラーメッセージにそのまま使えます。
UPC-AとEAN-13は同じものですか?
同じ系統の検査規則に属しますが、UPC-Aは米国やカナダの包装でよく使われる12桁の形式で、GTIN-12とも呼ばれます。このツールが扱うのはこの形式だけで、EAN-13やISBNは対象外です。
スペースやハイフン入りのUPCも入力できますか?
いいえ。使えるのは0から9の数字だけで、黙って取り除くことはしないため、中途半端に整えたコードが保存されることはありません。長さが違うときは、11桁か12桁のどちらが必要かを伝えます。
関連ツール
開発者向け — APIアクセス
このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。
エンドポイント
Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。
お使いのスタックから呼び出す
curl -X POST https://api.kit.forhosting.com/enc/upc-check \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"number":"01234567890"}'const res = await fetch("https://api.kit.forhosting.com/enc/upc-check", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"number": "01234567890"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/upc-check",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"number": "01234567890"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/upc-check", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"number":"01234567890"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"number":"01234567890"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/upc-check", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)リクエスト例
{
"number": "01234567890"
}レスポンス例
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.upc_check",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。
料金
単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。
エラー
| HTTP | コード | 意味 |
|---|---|---|
401 | unauthorized | APIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。 |
402 | insufficient_balance | 残高が不足しています。チャージ後に再度お試しください。 |
404 | unknown_type | 指定されたタスクタイプは存在しません。タイプ名を確認してください。 |
429 | rate_limited | リクエストが多すぎます。しばらく待ってから再度お試しください。 |
技術的な注記
製造者と品目を示す11桁のペイロードに加え、1桁の誤入力やスキャン誤りがないことを示す末尾の1桁が続きます。非数値入力や誤った桁数は、黙って切り捨てず invalid_input で失敗するため、中途半端なコードを保存しません。同じ純粋な算術がブラウザ無料版と公開API価格の両方で動作します。
UPC-Aチェックディジットの計算方法
計算では、1始まりの位置で左から11桁のペイロードを辿り、奇数位の各桁に3、偶数位に1を掛け、その積を足し、チェックディジットを(10からその和の10の剰余を引いた値)の10の剰余とします。11桁ペイロード向けのUPC-Aチェックディジット計算機であり、一般的なEANやISBNチェッカーではありません。
入力契約・モード・エラーの振る舞い
computeモードが既定です。桁数の誤りは、モードと送った長さを名指しする明示的エラーです(computeは11、validateは12)。クライアントフォームは推測せず「11桁が必要」と表示できます。空文字・number欠落・無効なmodeは加重和の前に失敗し、課金されません。商品番号を発行・補完するときはcomputeを、利用者やパートナーファイルの完全なコードで照会や取込をゲートするときはvalidateをお勧めします。0から9の文字だけを含むnumberフィールドを送ってください。空白・ハイフン・文字・小数点は非数値入力としてinvalid_inputで拒否され、黙って削られた値が保存に届きません。エンジンはちょうど11桁を要求し、check_digitを1文字の文字列で、with_checkを印刷や永続化できる12桁のUPC-Aとして返します。validateモードはちょうど12桁を要求し、末尾桁が再計算したexpected_check_digitと一致するとvalid trueを報告し、常にpayload(先頭11桁)、check_digit、expected_check_digit、length 12を含みます。digits、upc、codeなどのエイリアスは同じペイロード欄に受け付けるため、「upc」を既に使う連携は改名不要です。経路は時計・乱数源・ネットワークのない純粋なparseなので、同じJSON本体は無料ブラウザツールと成功リクエストあたり$0.002のAPIで常に同じJSON結果になります。
実際の業務でのUPC-Aチェックディジットの位置づけ
ECの登録フォームはexpected_check_digitを再計算し、売主が末尾を誤って貼り付けたときに分かりやすい修正を示せます。結合テストは012345678905のような既知フィクスチャでwith_checkを固定し、バーコードライブラリと本APIがずれないようにします。標準重みの下でmod-10桁がペイロードと一致することだけを示します。
連携の活用例
ラベル用に11桁の商品番号を完成させる
11桁のペイロードでcomputeモードを呼び出し、with_checkを保存し、12桁のUPC-Aをバーコードプリンタやマーケットプレイス掲載に渡します。
入力時にスキャンまたは手入力のUPC-Aを検証する
スキャナやフォームが12桁を送ったらvalidateモードを呼び、validがfalseのとき照会を止め、expected_check_digitを示して1桁の誤りを直します。
技術的な質問
このAPIでUPC-Aチェックディジットをどう計算しますか?
numberをちょうど11桁にし、mode compute(またはmode省略)でPOSTします。応答にcheck_digitとwith_check(12桁の完全なUPC-A)が含まれます。
12桁の完全なUPC-Aをどう検証しますか?
12桁の文字列とmode validateでPOSTします。応答にvalid、check_digit、expected_check_digit、payload(末尾を除く桁)が含まれます。
桁数違い・文字・ハイフンではどうなりますか?
非数値入力と、computeで11以外・validateで12以外の長さはinvalid_inputで拒否されます。失敗した検証タスクは課金されません。
UPC-Aチェックディジットツールは無料ですか?
ブラウザツールは無料でローカル実行です。API呼び出しは公開の基本価格$0.002で前払いKIT残高を使い、無効入力は課金されません。