Connection String Parser: แยก แก้ไข และประกอบ Database Connection String ได้ในคลิกเดียว

ใครที่เคยเจอปัญหา deploy แล้ว connect database ไม่ได้ หลายครั้งต้นตอคือ connection string ยาว ๆ หนึ่งบรรทัดที่กองทั้ง username, password, host, port และ options ไว้รวมกัน แค่มองผ่านตาเดียวไม่มีทางรู้ได้เลยว่า port ผิดหรือเปล่า password ถูก percent-encode แล้วหรือยัง หรือใครบางคนสลับตำแหน่ง database name กับ username ทิ้ง — ความหนาแน่นของมันคือทั้งจุดแข็งและจุดอ่อนในเวลาเดียวกัน

Connection String Parser ตัวนี้แก้ปัญหาตรงจุด โดยรับ connection string ได้แทบทุกชนิด ไม่ว่าจะเป็น PostgreSQL, MySQL, MongoDB (รวมถึง mongodb+srv), Redis, SQL Server, SQLite, AMQP หรือ URL ทั่วไป แล้วแยกออกมาเป็น field ที่มีป้ายกำกับชัดเจน: scheme, username, password, host, port, database และ query parameters ที่สำคัญยังอ่าน libpq keyword/value style และ ODBC style ได้ด้วย ครอบคลุมรูปแบบที่เจอจริงในงาน ไม่ใช่แค่ URL อย่างเดียว

ทั้งหมดนี้ทำงานแบบ client-side 100% ในเบราว์เซอร์ของคุณ ไม่มีการอัปโหลดข้อมูลไปไหน วาง connection string จริงจาก environment ของคุณลงไปได้เลย ตรวจสอบ แก้ค่า แล้ว copy ผลลัพธ์ที่ rebuild แล้วไปใช้ แม้แต่ offline ก็ยังใช้ได้ ในบทความนี้เราจะพาไปดู feature เด่น วิธีใช้งาน และไขความลับโครงสร้าง connection string ในทั้ง 3 รูปแบบหลัก

ทำไมต้องใช้ Connection String Parser?

• อ่านง่ายขึ้นทันที — แทนที่จะหรี่ตาแกะ scheme://user:pass@host:port/db?params ทุก component จะถูกแยกเป็นบรรทัดของตัวเองพร้อมป้ายกำกับ debug เรื่อง connect ไม่ติดเสร็จในไม่กี่วินาที
• รองรับหลาย dialect — tool ตรวจจับอัตโนมัติ 8 dialect: PostgreSQL, MySQL, MongoDB (รวม mongodb+srv), Redis, SQL Server, SQLite, AMQP และ Generic ไม่ต้องบอกมันว่าวางอะไรลงไป
• รับ 3 รูปแบบ input — ทั้ง URL-style, libpq keyword/value (host=localhost port=5432 dbname=mydb) และ ODBC (Driver={...};Server=...;Uid=...;Pwd=...) parse ได้หมด
• ปลอดภัยกับ password จริง — parse ทุกอย่างเกิดขึ้นในเบราว์เซอร์ ไม่มี request ใดพา string ออกไป field password ถูก mask ไว้เป็นค่าเริ่มต้น กด toggle ตาแบบ show/hide ได้เมื่อต้องการ
• Rebuild สด ๆ ระหว่างแก้ — แก้ field ไหนก็ได้ เปลี่ยน host ปรับ port เพิ่ม sslmode=require string ใหม่อัปเดตทันที พอใจแล้วกด copy รับไปใช้ได้เลย
• Edge case จัดการให้หมด — IPv6 ในวงเล็บ, mongodb+srv ที่ไม่มี port, path ไฟล์ของ SQLite อย่าง sqlite:///path.db และ socket form ของ PostgreSQL อย่าง postgresql:///dbname parse ได้ถูกต้องตาม spec

Key Features

จุดที่น่าสนใจเป็นพิเศษมีอยู่ 3 อย่าง:

• WHATWG URL parser คือหัวใจ — เป็น algorithm เดียวกับที่เบราว์เซอร์ใช้จริง percent-encoding, IPv6 ในวงเล็บ และ edge case ของ field ว่าง จัดการตาม spec ไม่ใช่เดาด้วย regex
• Options ไม่ใช่ลูกเล่น — parser จำนวนมากหยุดที่ host กับ port แต่ตัวนี้ทำให้ query parameter เป็น list ที่แก้ไขได้ เพิ่ม sslmode=require สำหรับ managed Postgres ลบ connectTimeout ที่ไม่ต้องการ แล้วดู string ประกอบตัวเองใหม่สด ๆ
• Mask password เป็นค่าเริ่มต้น — connection string จริงมี password จริง การซ่อนไว้หลัง toggle ทำให้ share หน้าจอตอน debug ได้โดยไม่ leak credential

วิธีใช้งาน

1. เปิด Connection String Parser
2. วาง connection string ลงช่อง input — จะเป็น URL-style, libpq keyword/value หรือ ODBC ก็ได้ tool ตรวจจับรูปแบบให้เอง
3. ตรวจสอบผลลัพธ์ที่แยกแล้ว — string จะแตกเป็น scheme, username, password (ถูก mask), host, port, database และรายการ options กด icon ตาเพื่อดู password ได้เมื่อจำเป็น
4. แก้ไขจุดที่ผิด — เปลี่ยน host ไปชี้ staging ปรับ port เปลี่ยนชื่อ database หรือเพิ่ม/แก้/ลบ connection options
5. กด copy string ที่ rebuild แล้ว ไปวางใน env var, config file หรือ deployment dashboard ได้เลย

ทำความเข้าใจโครงสร้าง Connection String

นักพัฒนาส่วนใหญ่ใช้ connection string ทุกวันแต่ไม่เคยนั่งเรียนไวยากรณ์ของมันอย่างจริงจัง มาแกะทีละส่วนกัน

Scheme — คำนำหน้าก่อน :// บอกทั้ง protocol และตระกูลของ database: postgresql://, mysql://, mongodb://, redis://, amqp:// และตัวแปรของมันก็มีความหมาย เช่น sslmode ใน parameter บอกเรื่อง TLS ส่วน mongodb+srv หมายถึง "หา host จาก DNS SRV record" ซึ่งเป็นเหตุผลที่มันไม่มี port ติดมาให้เห็น

Credentials — ระหว่าง :// กับ host คือ username:password@ เครื่องหมาย colon เป็นทางเลือกเมื่อไม่มี password และคู่นี้ตัดทิ้งได้เลยใน database ที่ใช้ trust auth หรือ IP-based auth อักขระพิเศษต้อง percent-encode เสมอ — p@ssword ต้องเขียนเป็น p%40ssword — การลืม encode @ คือสาเหตุคลาสสิกที่ทำให้ host เละ ใน libpq style credentials อยู่ในรูป user=app password=secret ส่วน ODBC เป็น Uid=...;Pwd=...

Host — ที่อยู่ของ server: domain, IP, IPv6 แบบวงเล็บอย่าง [::1] หรือสำหรับ SQLite คือ path ของไฟล์ กรณี PostgreSQL socket form (postgresql:///mydb) จะไม่ใส่ host เลยเพื่อ connect ผ่าน Unix socket ค่าเริ่มต้น ใน ODBC เรียกว่า Server=... ใน libpq เรียกว่า host=...

Port — TCP port หลัง colon: 5432 (PostgreSQL), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis), 1433 (SQL Server) ถ้าไม่ใส่จะใช้ค่า default ของ dialect นั้น ข้อควรระวังคือ mongodb+srv ไม่มี port เสมอ และ : ที่หลุดอยู่ใน password โดยไม่ encode จะทำให้ field นี้เพี้ยนแบบเงียบ ๆ

Database — path segment หลัง / ตัวแรก เช่น postgresql://localhost:5432/appdb สำหรับ SQLite ตรงนี้คือที่อยู่ของไฟล์ (sqlite:///data/app.db) ODBC เรียกว่า Database=... ส่วน libpq เรียกว่า dbname=...

Options (query parameters) — ทุกอย่างหลัง ? คือ list ของ key=value คั่นด้วย & เช่น ?sslmode=require&connect_timeout=10 ใช้ปรับ TLS, timeout, connection pooling และพฤติกรรม replica set parameter ของ Postgres map ตรงกับ libpq keyword ดังนั้น ?sslmode=require ใน URL เท่ากับ sslmode=require ในรูป keyword — มีประโยชน์ตอนแปลงระหว่างรูปแบบ

สามรูปแบบเมื่อวางเคียงกันจะเห็นชัด: URL style หน้าตาคือ postgresql://app:***@db.example.com:5432/appdb?sslmode=require connection เดียวกันในรูป libpq keyword/value คือ host=db.example.com port=5432 dbname=appdb user=app password=secret sslmode=require และรูป ODBC สำหรับ SQL Server คือ Driver={ODBC Driver 18 for SQL Server};Server=db.example.com;Database=appdb;Uid=app;Pwd=secret ทั้งสามเล่าเรื่องเดียวกัน — มี server, มี database, และมีคนกำลังขอเข้าไป — parser จะ normalize ทั้งหมดเป็นชุด field เดียวกันที่แก้ไขได้

กรณีใช้งานจริง

หมุนเวียน credentials ระหว่าง environment

มี string ของ production, staging และ local ที่ควรต่างกันแค่ host กับ credentials วางทีละตัวเข้า parser แล้วเทียบ field ข้าง ๆ กัน — จุดต่างบรรทัดเดียวที่มองไม่เห็นใน string ยาว 120 ตัวอักษร จะโดดออกมาทันทีเมื่อถูกแยกเป็น label ตอนหมุน password ก็แค่พิมพ์ค่าใหม่ลง field แล้ว copy string ที่ rebuild ไปอัปเดตทุก config

แปลงระหว่างรูปแบบ

ย้าย app จาก driver ที่ใช้ URL ไปเป็นตัวที่ใช้ libpq (หรือกรอก ODBC DSN) มักต้องคัดลอกทุก component ด้วยมือ — และทุกครั้งที่คัดคือโอกาสพิมพ์ port ผิด วาง source string เข้า parser อ่านค่าจาก field แล้ว rebuild เป็นรูปแบบปลายทางได้มั่นใจกว่า โดยเฉพาะ SQL Server URL style ของ tedious/mssql (sqlserver://host;database=db;user=...;password=...) ที่พิมพ์มือแล้วเละง่ายมาก

Debug "connection refused" และ "authentication failed"

ครึ่งหนึ่งของปัญหา connection เป็นเรื่องโครงสร้าง: @ ใน password ที่ไม่ได้ encode กลืน host หายไป, port หายไปเลย fallback ไป default ที่ผิด หรือ ? หลุดตัดชื่อ database ขาด การ parse string ที่กำลังล้มเหลวจริง ๆ — ไม่ใช่ string ที่คิดว่า deploy ไป — จะเห็นว่า driver เห็นอะไร บ่อยครั้งทางแก้ชัดขึ้นทันทีเมื่อทุก component มีป้ายกำกับ

สร้าง connection string จากศูนย์

แทนที่จะประกอบ string ทีละตัวอักษรแล้วสวดมนต์ ให้ทำสลับทาง: พิมพ์ host, port และ database ลง editor เพิ่ม options ที่ต้องการ (อย่าง sslmode=require สำหรับ managed database) แล้วให้ tool ประกอบ string ที่ถูกไวยากรณ์ให้เอง copy ตรงเข้าไปวางในไฟล์ .env ได้เลย

Best Practices

• อย่าเก็บ password แบบ plain ไว้ใน connection string ใน source control — ใช้ env var หรือ secrets manager และถือว่า string ที่วางเข้า parser เป็นข้อมูลลับเสมอ tool เป็น client-side แต่ประวัติ clipboard ของคุณเป็นเรื่องที่ต้องจัดการเอง
• Percent-encode อักขระพิเศษใน credentials เสมอ — @, :, / หรือ # ใน username/password จะจัดโครงสร้าง string ใหม่แบบเงียบ ๆ ไม่แน่ใจก็ encode ไว้ก่อน
• เขียน options แบบชัดเจนดีกว่าพึ่ง default แฝง — ใส่ port=5432 แบบเต็ม ๆ ไม่ได้แพงขึ้นเลย แต่ทำให้ string อธิบายตัวเองได้เมื่อมีคนมา parse อีกทีในหกเดือนถัดมา
• เก็บ canonical string แค่หนึ่งอันต่อหนึ่ง environment — ดีกว่าสำเนาที่ต่างกันเล็กน้อยกระจัดกระจายตาม config ต่าง ๆ เพราะ drift ระหว่างสำเนาคือแหล่งกำเนิด outage
• ใส่ sslmode=require (หรือเทียบเท่า TLS ของ dialect นั้น) ทุกอย่างที่ข้าม internet สาธารณะ — managed provider ส่วนใหญ่ปฏิเสธหรือเตือน connection แบบ plaintext อยู่แล้ว
• Parse ก่อนเอาไปวางใน ticket — เวลาขอความช่วยเหลือ การ share component ที่แยกแล้ว (โดย mask password ไว้ตามค่าเริ่มต้นของ tool) สื่อสารได้ดีกว่า string ดิบ ๆ เสมอ

พร้อมจัดการ Connection String ของคุณหรือยัง?

คราวหน้าที่ connection string เริ่มดื้อ — ไม่ว่าจะเป็นปริศนา percent-encoding, การแปลงรูปแบบ หรือ host ที่ดูถูกแต่กลับ connect ไม่ได้ — อย่าเดาด้วยตาเปล่า วางมันลง Connection String Parser ดูมันแตกเป็น component พร้อมป้ายกำกับ แก้ field เดียวที่ผิด แล้ว copy string ใหม่ที่เชื่อถือได้ ฟรี ใช้ offline ได้ และไม่ส่งข้อมูลคุณไปที่ไหน credential ของ database มันซับซ้อนพออยู่แล้ว การ debug มันไม่ควรต้องส่งมันขึ้น server ไปด้วยอีก

เครื่องมือที่เกี่ยวข้อง ที่คุณอาจสนใจ:

• SQL Formatter
• URL Encoder
• Base64 Tool

Happy parsing!

คำถามที่พบบ่อย

ถ: Connection string ของฉันถูกส่งไป server ไหม?

ตอบ: ไม่ การ parse, แก้ไข และ rebuild ทั้งหมดเกิดขึ้นในเบราว์เซอร์ด้วย JavaScript ไม่มี network request ใดพา string ออกไป และ tool ยังใช้งานได้แม้ปิด internet — ลองดูได้

ถ: รองรับ connection string รูปแบบไหนบ้าง?

ตอบ: URL-style (scheme://user:pass@host:port/db?params) สำหรับ PostgreSQL, MySQL, MongoDB และ MongoDB+SRV, Redis, SQL Server (รวมรูปแบบ tedious/mssql sqlserver://host;database=...), SQLite และ AMQP บวก libpq keyword/value และ ODBC keyword string scheme ที่ไม่รู้จักจะ fallback ไป parse แบบ Generic

ถ: แก้ไข field ที่ parse แล้วได้หรือแค่ดูอย่างเดียว?

ตอบ: แก้ไขได้ ทั้ง username, host, port และ database พร้อมเพิ่ม แก้ หรือลบ connection options string จะ rebuild ใหม่ทันทีระหว่างพิมพ์ และมีปุ่ม copy ให้ย้ายผลลัพธ์ไปใช้ต่อ

ถ: ระบบจัดการ password ในหน้า UI อย่างไร?

ตอบ: field password จะถูก mask ไว้เป็นค่าเริ่มต้น พร้อม toggle รูปตาไว้กดเปิด/ปิด ทำให้ใช้ tool ระหว่าง share หน้าจอหรือถ่าย screenshot ได้อย่างปลอดภัย — การเปิดดูเป็นการกระทำที่ตั้งใจเท่านั้น

ถ: IPv6 และ edge case อื่น ๆ ล่ะ?

ตอบ: tool ใช้ WHATWG URL parser ตัวเดียวกับที่เบราว์เซอร์ใช้ ทำให้ IPv6 แบบวงเล็บอย่าง [::1], mongodb+srv ที่ไม่มี port, path ไฟล์ของ SQLite อย่าง sqlite:///path.db และ socket form ของ PostgreSQL อย่าง postgresql:///dbname ถูก parse ตาม spec ทั้งหมด