CSVからSQL INSERTへ
このコンバーターは、ブラウザ内でRFC 4180形式のCSVを読み込み、SQL INSERT文を出力します。各セルは検査によって型付けされます――引用符のない数値は数値のまま、trueとfalseはTRUEとFALSEに変換され、それ以外は引用符で囲まれ、単一引用符がエスケープされた文字列になります。ヘッダー名は二重引用符で囲まれた列識別子になり、何もアップロードされません。
CSVからSQL INSERTへとは
CSVには型がありません。表計算ソフトのエクスポートにはすべてがテキストで、データベースこそが値の意味を決定する場所です。これは、あなたが意図したかどうかにかかわらず、型付けが代行されるCSVからSQLへの変換です。このコンバーターはセルごとに処理し、そのルールを明確に述べています：数値として読み取られるセルは数値になり、trueまたはfalseはTRUEまたはFALSEになり、空のセルはNULLになり、それ以外は文字列になります。
SQL側では標準的な防御策が使用され、特異なものは何もありません：ヘッダー名は二重引用符で囲まれた列識別子になり、文字列値は単一引用符で囲まれ、埋め込み引用符は二重になります――すべてのSQL方言が正しく読み取るO''Brien形式――そして行は複数行のINSERT文として出力されます。パースは厳密なRFC 4180に従い、埋め込みカンマや改行を含む引用フィールドはそのまま保持されます。これは、カンマでの分割による素早いコンバーターがデータを破損する場所です。
変換はこのブラウザタブ内で完全に実行されます。CSVはページ内のコードでパースされ、SQLはメモリ内で組み立てられ、ページからリクエストは送信されません――作業中はDevToolsのネットワークパネルは空のままです。また、サイトのContent-Security-Policyは外部への接続を禁止しています。
もしあなたのレコードがすでに型を持っている場合――APIや型を保持したエクスポートからのものなら――JSONからSQLコンバーターは推論する代わりにその型をそのまま使用し、同じ引用符とNULLのルールを適用します。
データをSQLではなくJSONで必要ですか？CSVからJSONコンバーターは同じRFC 4180パーサーを使用し、文の代わりに型付きのレコードを提供します。
変換の実際の仕組み
エンジンはRFC 4180の実際のルール――レコード、フィールド、引用フィールド内の二重引用符、CRLFまたはLFの終端――に従ってCSVをパースし、最初のレコードをヘッダーとして、それ以降の各レコードをINSERTの1行として扱います。型付けは出力直前の各セルに適用されます：
実際の表計算ソフトのエクスポートから2つの詳細が処理されます：ファイル先頭にあるUTF-8のバイトオーダーマークは、Excelがデフォルトで追加しますが、パース前に削除されます。また、ツールのテーブルフィールドに入力したテーブル名はINSERT内の引用識別子になり、以下の例ではproductsが使用されています。
- 数値：整数または小数のパターンに一致するセルは引用符なしで出力されます――42と24.99は数値になります。先頭にゼロがある場合は disqualified になるため、02134は文字列のままになり、郵便番号が保持されます。
- ブール値：trueまたはfalse（大文字小文字を問わず）はTRUEまたはFALSEになります。
- 空のセル：空のフィールドはNULLになります。存在するが引用符で囲まれた空の値（"")は、RFC 4180とSQLの両方が区別するため、空の文字列のままになります。
- 文字列：それ以外はすべて単一引用符で囲まれ、埋め込み引用符は二重になります――O'Brienは'O''Brien'になります。
- 識別子：ヘッダー名はヘッダーの順序で二重引用符で囲まれた列名として出力されます。
セルからリテラルへのマッピング
ルールごとに1行ずつ説明しているので、実行前に出力を予測できます。空のセルと引用符で囲まれた空のセルは意図的に異なる行であることに注意してください、というのは、これが人々が最も尋ねるペアだからです：
| CSVセル | SQLリテラル | 理由 |
|---|---|---|
| 42 | 42 | 整数パターン |
| 24.99 | 24.99 | 小数パターン |
| true | TRUE | ブール値（大文字小文字を問わず） |
| （空） | NULL | 値が存在しない |
| 02134 | '02134' | 先頭のゼロを保持――郵便番号 |
| O'Brien | 'O''Brien' | 標準に従い引用符を二重に |
出力の見本
以下の作業例は、テーブル名がproductsの場合にコンバーターのサンプル読み込みボタンが生成する正確なペアです。3行あり、各行で1つのルールを試しています：デスクランプの価格は裸の小数で、在庫フラグは裸のTRUEです；テントの行には製品名にカンマが含まれているため、CSVでRFC 4180の引用が必要で、出力されたSQLではそのアポストロフィが二重になります；ランタンの行には2つのセルが空で、両方が空の文字列ではなくNULLになります。出力を.sqlファイルとして保存すると、psql、sqlite3、またはマイグレーションランナーでそのまま実行できます――文は完全でセミコロンで終端されています。
不揃いな行とその他の正直な拒否
RFC 4180では、ヘッダーよりフィールドが少ないまたは多いレコードを技術的に許容していますが、SQLは許容しません――INSERTのタプルは、その文で宣言された列を正確に埋める必要があります。そのため、2つの入力は行番号を示すメッセージ付きで拒否されますが、パディングまたは切り詰めは行いません：
- フィールド数がヘッダーと異なるレコード――NULLでパディングすると、測定していない値を生成し、余分なものを削除すると、提供したデータを破棄することになります。
- 重複するヘッダー名――同じ名前の2つの列は、1つのINSERT内で両方とも引用識別子にできません。そのため、コンバーターは列を報告し、片方をサイレントにリネームする代わりにエラーを出します。
よくある質問
CSVをSQLに変換するとき、ファイルはアップロードされますか？
いいえ。パーサーとSQLライターの両方とも、ページ開時に読み込まれたJavaScript内でこのブラウザタブ内で実行されます。アップロードルートはなく、Content-Security-Policyがページの外部接続を防ぎます。DevToolsで確認してください：変換実行中はネットワークパネルにトラフィックが表示されません。大きなファイルでも同様です。
パーサーはどのCSV方言を受け入れますか？
RFC 4180、標準です：カンマ区切りのフィールド、二重引用符のエスケープ、引用フィールド内の二重引用符、引用フィールド内の埋め込みカンマや改行はすべて正しくパースされます。CRLFと単独のLFの両方のレコード終端が受け入れられます。推測は行いません――セミコロンまたはタブ区切りのファイルはメッセージ付きで拒否されます。なぜなら、サイレントにデリミタを入れ替えるコンバーターは、見えない列を破損するからです。
型推論は、数値、ブール値、文字列のどれにするかどう決定しますか？
厳密なパターンに基づき、セルごとに：フィールドは整数または小数リテラルに正確に一致した場合にのみ数値になり、trueまたはfalse（大文字小文字を問わず）で読み取られた場合にのみブール値になり、フィールドが空の場合にのみNULLになります。それ以外は引用符付きの文字列として出力されます。この厳密さがポイントです――007のような値を積極的に型付けするコンバーターは、データベースに驚きをもたらします。
なぜ郵便番号や製品コードは文字列のままですか？
そうあるべきだからです。02134や007のようなコードは先頭のゼロに情報が含まれており、数値にはそのゼロを保持する場所がありません。推論パターンは意図的に先頭のゼロを拒否するため、そのようなセルは引用符付きの文字列として出力され、列の意味はデータベースへの取り込み時に完全に保持されます。
CSVの日付はどうなりますか？
引用符付きの文字列として到着します、設計上です。SQLの日付リテラルは方言で異なり、2024-01-05を方言固有の形式に書き換えるコンバーターはデータを編集しています。文字列はデータベースにそのまま到達します。DATE列、またはデータベース自身のキャストが挿入時に型を適用します――その決定がなされるべき唯一の場所です。
行ごとに1つのINSERT文を取得できますか？
出力は単一の複数行INSERTです――1回のパース、1つのトランザクションに対応した文、そしてバルクロードのガイドラインが推奨する形式です。VALUESタプルは列リストの下に1行ずつ配置されるため、もしツールが単一行の文を必要とする場合、分割は機械的な編集です：列リストをコピーし、各タプルをセミコロンで終端します。