SQLフォーマッターFor WEB

・SQL整形ツールです。初版は2006年。長くメンテしてきたもんです。

[広告]

カンマ整形:  
AND/OR/ON整形:  
インデント:
JOIN形式:  
予約語:
出力先:  




おまけ:
変換フォーマット: Java Perl
改行コード: なし \n \r\n


[広告]

今まで通りSQLの整形にお役立てください。
バージョンアップした際は本ページでお知らせしたいと思います。

2018/5/14追記
・UNIONはブロック内のベースインデントに強制的に戻すよう対応
・#で括られた文字列が日時っぽかったら整形しないよう対応

2018/3/31追記
・コメントのインデント位置を次のトークンを参照するよう修正
・"["と"]"に囲まれたトークンを整形しないよう対応
・クリップボードにコピーするcopyボタンを追加

2018/1/4追記
・distinctの整形を改善
・select intoの整形を改善
・limit後のselect foo, barの","で改行されない不具合を修正
・バッククォート内に不要な半角空白が含まれる不具合を修正

2017/8/30追記
・SQLを1行に戻す機能を追加

2017/6/14追記
・連結キーワードに「::」,「@>」,「<@」を追加

2017/6/5追記
・整形結果の出力先が選べるように対応

2017/3/20追記
・insert文に暫定対処
・create文に暫定対処
・alter文に暫定対処

2017/3/10追記
・MS-Accessのクエリを考慮し、[xxx - xxx]を[xxx-xxx]となるよう修正
・select for updateのクエリが崩れないよう修正

2017/3/5追記
・":xxx"のバインド変数が":" と"xxx"で別れる不具合を修正
 コア部分に手をいれたため変な動作をしたら教えてください

2017/2/27追記
・":="を1つのキーワードとなるように修正

2017/1/31追記
・"("からはじまるクエリが整形できない問題を修正

2017/1/21追記
・整形後ctrl+cが効かない問題を修正

2017/1/9追記
・色付きクエリはaceエディタに出力するよう変更

2016/11/7追記
・limit付きSQLがうまく整形できない問題を修正

2016/10/14追記
海外版をリリース
日本語版はこのページとして、バグ修正や要望を取り入れながら、海外版も合わせて育てていこうと思います

2016/10/8追記
・色付きのSQLが欲しくなったので簡易版を配置

2016/9/13追記
次の修正を行いました。
・WITHIN GROUPを崩れないよう対応
・その他一部のキーワード追加

2016/9/3追記
次の修正を行いました。
・INNER省略型のJOINキーワードに対応
何か変な動作をしましたら教えてください。

2016/5/5追記
次の修正を行いました
・予約語の一部追加
・カンマ整形を「前」とすると、in(1 ,2)となっていたものをin(1, 2)となるように修正
コア部分に手を入れましたので、変な動作をしましたら教えてください

2015/2/28追記
予約語の大文字、小文字化に対応しました。
紛らわしい予約語は一部除外していますが、うまく変換されないものがあればお知らせください。

43件のコメント

  1. 便利なサービスの提供ありがとうございます。

    1点お願いがあるのですが、サイトのfaviconを設定していただくことは可能でしょうか。

    というのも、自分がブックマークバーに登録する際、スペース節約のためにブックマークに名前を設定せず、faviconのみ表示させるような使い方をしているため、faviconが設定されていると見分けがつきやすくなるためです。

    わがままなお願いですが、是非ご検討のほどよろしくお願いいたします。

    1. faviconを設定してみました。
      移転前だとfaviconもままならなかったので、移転してよかったですー

  2. 変換前
    –コメント1
    SELECT * FROM A
    –コメント2
    UNION
    SELECT * FROM B

    変換後
    –コメント1
    SELECT
    *
    FROM
    A
    –コメント2
    UNION
    SELECT
    *
    FROM
    B

    この際のコメント2のインデントは無しにできないでしょうか。
    コメントだけの行は整形無しでも良いかと。

    1. >sapさん
      要望ありがとうございます。
      たしかにこの例だと、unionの前なのでコメント2のインデントは無いほうが見やすいですね。

      コメントは直後のトークンのインデントと同じにするように検討したいと思います。

    2. >sapさん
      コメント位置を修正してみました。お試しください。
      うまくいかない場合は、キャッシュの可能性があるため、再読み込みをしてお試しくださいm(_ _)m

  3. 便利なツールをありがとうございます。
    MS-Access / SQL Server を使用しているのですが、[](角括弧)は文字列リテラルとして扱ってもらえれば(整形対象から外してもらえれば)ありがたいです。

    1. >denchi さん
      コメントありがとうございます。
      Accessの[](角括弧)内はカラム名に特殊文字などを使っているときに利用するんですね。Accessは不勉強でしりませんでした。
      たしかにそれであれば、文字列リテラルとして扱うほうが問題なさそうなので、修正を検討いたします。

  4. 返信ありがとうございます。
    検討よろしくお願いします。

    余談ですけど、Access SQLの角括弧は、カラム名やテーブル名だけではなくて、たとえば

    SELECT * FROM [Excel 12.0 Xml;database=D:\Book1.xlsx].[Sheet1$]

    なんて書くとExcelのシートをテーブルとして開けたり、

    SELECT * FROM table1 IN “” [ODBC;Driver={SQL Server};SERVER=servername;Database=dbname;]

    みたいな感じでODBCデータソースを開けたりするのです。

    1. さすがAccessといったところですね。
      勉強不足でした。自由度がたかい。。。

      情報ありがとうございます。
      修正まで今しばらくお待ちくださいませ。

      1. ありがとうございます。修正お待ちしています。
        様々なSQLの方言に対応するのは大変でしょう(スミマセン)。

        また余談で、これは特に対応していただく必要はないと思いますが、
        SQL Serverではカラム名やテーブル名に
        角括弧やピリオドなども使えてしまい、その場合、
        角括弧の中の閉じ角括弧は2つ重ねてエスケープします。
        (開き角括弧はそのまま記載します)

        SELECT * FROM [[table]].[1]]]

        これは”[table].[1]”という名前のテーブルを使った例です。
        実際にそんな名前を使う人はいないと思いますが。

        あと前回返信するべきところを新規のコメントにしてしまってすみません。

        1. >denchiさん
          コメントありがとうございます。

          >SELECT * FROM [[table]].[1]]]
          これはすごい^^;
          こういった名前形式が流行っていったら(フレームワークとかで?)検討ですかねぇ。

    2. >denchi さん
      角括弧の対応を行ってみました。お試しください。
      うまくいかない場合は、キャッシュの可能性があるため、再読み込みをしてお試しくださいm(_ _)m

      1. 対応どうもありがとうございます。
        いい感じに整形できているようで、いろいろ捗りそうです。
        今後もSQLフォーマッターにはお世話になります。

  5. 便利に使わせてもらっています。

    お願いがあるのです。
    整形済みSQLを表示する場所の右端の方に
    クリップボードにコピーの機能を付けられませんか?
    よくブログなどでハイライトされたソースコードの横にうっすらとある機能のことです。

    イメージ
    http://xn--hhro09bn9j8uh.com/blog/post-1670/

    ぜひご検討をよろしくお願いいたします。

    1. >もちもちさん
      要望ありがとうございます。
      なるほど、クリップボードですね。
      検討しますのでしばらくお待ちください。

    2. >もちもち さん
      クリップボードへコピーするcopyボタンをつけてみました。お試しください。
      うまくいかない場合は、キャッシュの可能性があるため、再読み込みをしてお試しくださいm(_ _)m

  6. 失礼します。
    いつも利用させていただいております!
    ありがとうございます!!
    失礼しました。

    1. いつも利用していただいてありがとうございます。
      これからもよろしくお願いしますー!

  7. お世話になっております。
    JOINの後にUNIONがあるとちょっとおかしいみたいです。

    SELECT * FROM t1 INNER JOIN t2 ON t1.f1 = t2.f1 UNION SELECT * FROM t3;
    — ↓WHEREがあれば正常。
    SELECT * FROM t1 INNER JOIN t2 ON t1.f1 = t2.f1 WHERE 1=1 UNION SELECT * FROM t3;
    — ↓JOINがなければ正常。
    SELECT * FROM t1 UNION SELECT * FROM t3;

    1. >denchiさん
      報告ありがとうございます。
      確かにUNIONのインデントが変ですね。。
      調査してみます。

    2. >denchiさん
      UNIONの整形見直しましたので、ご確認ください。
      うまくいかない場合は、キャッシュの可能性があるため、再読み込みをしてお試しくださいm(_ _)m

  8. 続けて要望すみません。
    Access SQLなんですが、日付/時刻のリテラルの書式がありまして、「#」で囲むのです。

    SELECT * FROM t WHERE dtm1 #01/01/2017#;

    といった具合です。
    ついては、「#」で囲まれた部分も整形対象外にしていただけたらありがたいです。
    優先度は低めです。

    1. >denchiさん
      要望ありがとうございます。

      Accessは#で括るんですね。。
      他のRDBとの兼ね合いを調査しつつ検討してみます。

      1. そうですね、他のRDBで「#」を別な意味で使っていたら悪影響が出そうですね。
        軽くお願いしてしまってすみません。

        ところで、前回の私のコメントのSQL文がおかしいですね。
        確か「<=」とか「>」というのを(半角で)入れたと思いますので、
        それがHTMLタグと判定されて削除されちゃった感じでしょうか……。

        「#04/19/2018#」とか「#04/19/2018 15:00:00#」とか、
        そういう書き方があります、というのを示したSQL文でした。

        1. >denchiさん
          コメントありがとうございます。

          SQLの件、了解です。
          整形ツールの向上にもなりますので、要望は気楽に上げて貰うほうが実は助かってます^^

          1. そう言っていただけるとありがたいです。

            では、えー、さらに優先順位の低い話で、
            もし直ったらうれしいなあ程度のことなんですが、
            符号の(つもりの)マイナスが数字から離れてしまうのが
            ちょっとだけ気になっています。
            「UPDATE t SET a = -1」みたいなのですね。

            また、試しに「SELECT -1 * -2 – -3 – 4, -5」とか入れてみたら
            途中の「- -」が「–」で独立した行になってしまい、なんかおかしいですね。
            普通こんな(意地悪な)感じの式は書かないと思いますが。

          2. >denchiさん
            コメントありがとうございます。そして回答が遅くなり申し訳ないです。。

            なるほど、たしかに「a = -1」と入力した場合は、想定外ですね。
            管理人がカラム価にマイナスを入れる案件を携わったことがないのが原因ですかね^^;
            でもこれはあり得そうなので、修正を検討します。

            もう一つの「- -」は意図してませんでした。
            こういった演算子は、プログラムではよくありますが、SQLでもあるんですかね?
            であれば対応せねば。。ヽ(゚Д゚)ノ

          3. 検討ありがとうございます。
            すぐにご回答いただかなくても全く問題ありませんのでお気になさらず。

            ところで、また書き込んだテキストがちょっと変化しているかな?
            件のSELECT文はぜんぶ半角のマイナスで入れたつもりだったんですが、
            式の中の演算子に相当する部分がなぜかenダッシュ(U+2013)になっていますね。

            > 途中の「- -」が「–」で独立した行になってしまい
            ここも、後ろのかぎかっこの中はマイナス2文字です。
            マイナス2文字をコメント欄に書くと変換されちゃうのでしょうか。
            あああ、今見ると4/11の私の書き込みのマイナス2文字(コメント行)も
            emダッシュ(U+2014)に変わってますね。
            <>もそうですが、SQL文をここのコメントに貼り付けるのはちょっと厳しいですね……。

            要は、マイナスがスペースを挟んで2つ続いたときに、
            間のスペースが削除されて、でもコメントとして解釈されているわけでもなくて
            独立した行になってしまうなー、おかしいなー、という話です。

            自分が普通に書くならマイナスマイナスはプラスにしちゃいますので
            こういう文になることは多分ないです。かけるマイナスならたまにありますが。

            件の文は、符号のマイナスが出現するパターンとして、
            SELECT直後、演算子の後、コンマの後、あたりかなー、
            といったことを考えて書いてみたもので、
            そしたらたまたま「- -」の整形が妙だったので
            一応ご報告しておこうかな、といったようなわけです。

          4. 符号については離れてもそれほど見づらいわけではないので、
            優先順位は低いということで……。

            一応、思いついたほかのパターンを書いておきます。
            SELECT -f1, -.1, -(-0.2) FROM t WHERE f2 > -.3
            このマイナスはぜんぶ符号ですね。

          5. >denchiさん
            詳細なコメントありがとうございます。
            そしてコメントの自動変換でご不便かけます^^;
            これはサイトの仕様ですかね。。

            マイナス記号は細々と対応していこうと思います!

          6. 返信のネストも4段までなんですかね~。
            自分のコメントがどう表示されるのかすぐにはわかりませんし、
            なんとも厳しい仕様ですね……。

            今後もよろしくお願いします。

    2. >denchiさん
      #で囲まれたトークンが日時の場合、整形対象外にしましたので、ご確認ください。

      ただし現状では日時を正確にパースしてないので、いまいちの場合はコメントくださいm(_ _)m

      1. なるほど、日付っぽかったらですか。
        個人的には「#MM/dd/yyyy#」か「#MM/dd/yyyy hh:mm:nn#」しか使わないため問題なさそうです。
        どうもありがとうございます。

        一応、情報として、判定に失敗しそうなものを挙げておくと、

        ・年月日の区切りには「/」だけではなく、「-」や「 」(スペース)も使える
        ・月の表記には数字だけではなく「Jan」や「January」なども使える
        ・時刻は末尾に「AM」「PM」をつけることができる

        といったあたりでしょうか。資料が見当たらず、網羅しているかどうかは自信がないですが……。

        例)
        SELECT TOP 1 #2018-05-15 10:15:20#, #Jan 18 2018 10:15 AM#, #18-January-2018 10:15AM#, #10AM# FROM T

        まともに判定するのは大変そうですね。

        1. >denchi さん
          コメントありがとうございます。
          #は他のRDSでも使うので、とりあえずの対応です^^;
          こちらも正確な資料が見つからなかったので、コメント頂けて幸いです。
          それにしてもAccessの日時型は自由度が広い。。
          日付っぽさを拡張して
          #[0-9a-zA-Z\-\/: ]+#
          の正規表現で判定にするかも^^;

          1. 正規表現だけで正確に判定するのは大変そうですが、とは言え、
            そんなに広げてしまって大丈夫でしょうか。
            Accessユーザーとしては広くても全く困らないのですが、
            全然日付っぽくなくてもマッチしちゃいますよね。
            (整形しないだけだから結果的にそんなに問題ないのかな?)

            他のRDBではどう使われているんでしょ。

            追加で、AM/PMはA/Pでも行けました。#1A#で午前1時とか。
            おまけに、アルファベットの月表記を使うと
            年月日の順番は問わないみたいです。ひええ。

          2. >denchi さん
            コメントありがとうございます。

            他のRDSだとシャープを単独で使うのはあるみたいですが、
            #で括る仕様は、なかなか出てこないですねぇ。
            Accessの日付パースはとてもシンドソウなので、何とかお手軽に逃げたいですねぇ

            「#[0-9a-zA-Z\-\/: ]+#」だと、
            select #hoge from #foo
            とかだと破綻するので、
            「#を括る」というオプションのほうがいいかもしれませんねぇ。
            うーん、悩ましい。

          3. 私もちょいちょい検索してみましたが、
            OracleやSQL Serverでは「#」はそのまま表名/列名に使える記号らしいですね。
            (アンダースコアと同様のイメージ)
            それと、MySQLでは「#」以降行末までがコメントになるんだとか。
            (こっちはハイフンx2と同様)

            これ、MySQLが強力すぎて、Access抜きにしても破綻しますねえ……。

            オプションで対応するとしたら
            「#: 通常の文字とみなす / 行末までコメントとする / 括った文字列を整形しない」
            みたいな感じでしょうか……。

          4. でも、MySQLの#コメントには対応しないということであれば、
            「#と#の間の文字列が **偶然** 日付っぽくなる可能性を無視する」のはアリかもしれませんねー。

            拙いですしまだちょっと緩いかもですけど、とりあえず

            /# *((\d{1,4}|Jan(uary)?|Feb(ruary)?|Mar(ch)?|Apr(il)?|May|June?|July?|Aug(ust)?|Sep(tember)?|Oct(ober)?|(Nov|Dec)(ember)?)(([\-/]| +)(\d{1,4}|Jan(uary)?|Feb(ruary)?|Mar(ch)?|Apr(il)?|May|June?|July?|Aug(ust)?|Sep(tember)?|Oct(ober)?|(Nov|Dec)(ember)?)){1,2}( +\d{1,2}(( *(AM|PM|A|P))|((:\d{1,2}){1,2}( *(AM|PM|A|P))?)))?|(\d{1,2}(( *(AM|PM|A|P))|((:\d{1,2}){1,2}( *(AM|PM|A|P))?)))) *#/i

            という感じならどうでしょうか。
            (ちゃんと表示されるかな?)

          5. >denchi さん
            コメントありがとうございます。

            MySQLは行コメントかー。
            やっぱりオプション選択を検討ですかね^^;
            そして素敵な正規表現ありがとうございます!
            参考にさせていただきますー

          6. はい、ご参考ということで……(ちゃんと表示されているようです)。

            それで、「偶然」はあり得なさそうだなーと思いつつ考えたのですが、
            SELECT MAY#05-APR#04 FROM T
            というのを思いつきました。
            (’MAY#05′ と ‘APR#04’ がフィールド名で、引き算)

            まあ、あり得ないわけではない、ということですかね💦

          7. どうもですー
            もの凄いカラム名ですね^^;

            こういったものは、専用のRDMSでのパースとなりそうですねー。うーん、悩ましい。
            RDMSの方言にも困ったものです。。

          8. というか、現状でSELECT MAY#05-APR#04 FROM Tは正しく整形できているようですので、
            ・MySQLの人には「#」ではなく標準的なハイフンx2を使ってもらう。
            ・Accessの人には日付リテラルのハイフン区切りと月名表記を諦めてもらう。
            というのが最もお手軽な対応でしょうねー。

            ちなみに上記SQLはAccessではカラム名を[]で括らないとエラーが出ます。

            また、現バージョンでの「偶然」も考えてみたんですが
            SELECT COLUMN#05/10 #ALIAS FROM T
            とか……(’COLUMN#05′ 割る 10 を ‘#ALIAS’ という別名で返す)。
            あり得ないわけではないですねえ💦
            なお「#05/10 #」はAccessの日付リテラルとして正しいので、日付っぽさ判定を厳しくするというアプローチでは解決しません。
            でもぶっちゃけ、そんな「偶然」まで対応する必要はないんじゃないかとは思いますー。

コメントを残す

メールアドレスが公開されることはありません。