JSON to Swift Converter: แปลง JSON เป็น Swift Codable struct ได้ในไม่กี่วินาที

แอป iOS ยุคนี้ดำรงอยู่ด้วย JSON ไม่ว่าจะเป็น REST endpoint, document ใน Firebase หรือ third-party API ที่แอปคุณเรียกใช้ ล้วนสื่อสารกันด้วย JSON ทั้งสิ้น และสะพานมาตรฐานที่เชื่อม wire format แบบนั้นเข้ากับโค้ด Swift ของคุณก็คือ protocol ที่ชื่อ Codable แต่การพิมพ์ model struct ด้วยมือเองนั้นน่าเบื่อและพลาดง่าย คุณต้องนับปีกกา เดา type ตัดสินใจว่า field ไหนควรเป็น optional แล้วพิมพ์ property name เดิม ๆ ซ้ำไปซ้ำมาจาก API documentation แค่พิมพ์ชื่อ property ผิดตัวเดียว JSONDecoder ก็จะปล่อย decoding failure ให้คุณเจอตอน runtime แบบเงียบ ๆ

JSON to Swift Converter ตัดงานซ้ำซากพวกนี้ทิ้งไป แค่ paste JSON sample ลงไป เครื่องมือจะ generate Swift struct ที่สะอาดพร้อม Codable conformance ขยาย nested type ออกเป็น struct ของตัวเอง และใส่ optional ให้ทุก field ที่หายไปหรือเป็น null โดยรูปแบบการตั้งชื่อ (naming) ปรับได้ ทำให้ wire key ฝั่ง API ยังเป็น snake_case ได้ ขณะที่ property ฝั่ง Swift อ่านเป็น camelCase ตามสไตล์ภาษา Swift ทุกอย่างทำงานแบบ client-side 100% ใน browser ของคุณ — API payload ของคุณไม่ถูกส่งไปที่ server ใด ๆ เลย

ในคู่มือนี้ คุณจะได้เห็นว่าทำไม model ที่ generate จึงเชื่อถือได้กว่าสำหรับการ consume JSON ใน Swift วิธีใช้ converter ทีละขั้น และการทำงานจริงของ Codable ใต้ฝากระโปรง — รวมถึงกับดัก decoding ที่หลอก developer เกือบทุกคนสักครั้งในชีวิต

ทำไมต้องใช้ JSON to Swift Converter?

• ไม่ต้องพิมพ์มือ แต่ความถูกต้องไม่ลดลง การถอด API response ที่มี 40 field ลงเป็น struct ด้วยมือชวนให้สะกด property ผิดและใส่ type ผิด ซึ่ง JSONDecoder จะร้องเรียกก็ตอนที่ข้อมูลจริงชน model ที่พังแล้วเท่านั้น การ generate struct จาก payload จริงการันตีว่ารูปร่างตรงกับที่ server ส่งมาจริง ๆ
• optional มาจากหลักฐาน ไม่ใช่การเดา field ที่หายไปจาก sample หรือมาในรูป null จะกลายเป็น Type? ในผลลัพธ์ ซึ่งเป็นข้อมูลที่ Codable ต้องการพอดี และเครื่องมือใช้กติกานี้สม่ำเสมอทุกระดับความลึก
• nested type เลิกเป็นงานหนัก object ซ้อน object ซ้อน array จะกลายเป็น chain ของ struct เล็ก ๆ แต่ละตัวมี Codable conformance ของตัวเอง payload ที่ซ้อนลึกจนพิมพ์มือต้องใช้เวลายี่สิบนาที ใช้เวลาแค่ไม่กี่วินาที
• ตั้งชื่อได้ตามสไตล์โปรเจกต์ เลือก naming convention ของ property และ type name ได้ ทำให้โค้ดที่ได้วางลงโปรเจกต์เดิมได้ทันทีโดยไม่ต้องไล่เปลี่ยนชื่อ ถ้า sample มั่ว ๆ ลองจัดระเบียบด้วย JSON Formatter ก่อนก็ได้
• เป็นส่วนตัวตั้งแต่สถาปัตยกรรม การแปลงทำงานใน browser ทั้งหมด เวลาคุณ paste payload จริงจาก production, ข้อมูล user หรือ API response ที่ยังไม่เปิดเผย จะไม่มีอะไรถูก upload, log หรือเก็บไว้ที่ไหนเลย
• ฟรีและได้ผลทันที ไม่ต้องสมัคร ไม่ต้อง install ไม่ต้องเปิด Xcode รอ build เพื่อร่าง model เปิด tab, paste, copy แล้วไปต่อ

คุณสมบัติเด่น

มีสองจุดที่ทำให้ผลลัพธ์ใช้งานได้ทันที หนึ่ง generator สะท้อนโครงสร้าง JSON อย่างซื่อสัตย์ — array ของ object จะได้ array ของ struct ที่ตรงกัน ไม่ใช่ dictionary type ที่หลวมกว่า สอง เพราะผลลัพธ์เป็น Swift ล้วน ๆ ไม่มี dependency ตัวโค้ดจึง compile ได้ทุก target ที่รองรับ Codable ไม่ว่าจะ iOS, macOS, watchOS, tvOS หรือ visionOS

วิธีใช้งาน JSON to Swift Converter

แปลง payload หนึ่งชุดใช้เวลาไม่ถึงนาที นี่คือขั้นตอนเต็ม:

ขั้นตอนที่ 1 — เปิดเครื่องมือ

เข้าไปที่ JSON to Swift Converter คุณจะเห็นช่อง input สำหรับ JSON sample และช่อง output สำหรับโค้ด Swift ที่ generate ออกมา

ขั้นตอนที่ 2 — Paste JSON sample

paste JSON ที่เป็น object หรือ array ที่ถูกต้องได้เลย ไม่ว่าจะมาจาก API response ที่แอบจับไว้ด้วย proxy, response body ที่ทีม backend ส่งมาให้ หรือไฟล์ fixture ถ้า sample ถูก minify จนอ่านยาก จัดระเบียบด้วย JSON Formatter ก่อนก็ได้

ขั้นตอนที่ 3 — เลือกรูปแบบการตั้งชื่อ

เลือก naming convention สำหรับ property และ type name ที่ generate ออกมา จุดนี้แหละที่เครื่องมือโชว์คุณค่ากับ API ของโลกจริง คุณเก็บ wire key ไว้เหมือนเดิม ขณะที่ฝั่ง Swift ของคุณยังอ่านเป็นธรรมชาติตามแบบภาษา

ขั้นตอนที่ 4 — ตรวจ struct ที่ได้

ดูช่อง output ให้ครบ field ที่หายไปจาก sample หรือถูกตั้งเป็น null จะโผล่มาเป็น optional, object ที่ซ้อนอยู่จะกลายเป็น struct แยก และ array จะ map เป็น Swift array ของ struct นั้น ๆ

ขั้นตอนที่ 5 — Copy ลง Xcode

copy โค้ดที่ได้ลงไฟล์ใหม่ในโปรเจกต์ Xcode สั่ง build เร็ว ๆ หนึ่งรอบ แล้วเริ่ม decode ได้เลย เอา payload ต้นฉบับไปใส่ unit test แล้วปล่อยให้ JSONDecoder ยืนยันว่า model ใช้ได้ตั้งแต่รันครั้งแรก

Codable แบบไม่ต้องเดา

การจะใช้ผลลัพธ์อย่างมั่นใจ คุณควรเข้าใจก่อนว่า Codable สัญญาอะไรบ้าง type ที่ conform กับ Codable จะ decode จากและ encode ไปยัง external representation ได้ — ในที่นี้คือ JSON — และ compiler จะ synthesize กลไกทั้งหมดนั้นจาก stored properties ให้เอง ในโค้ดที่ generate ออกมาไม่มีอะไรวิเศษณ์ซ่อนอยู่ และนั่นแหละคือจุดขาย คุณอ่านได้ แก้ได้ และเป็นเจ้าของมันได้เต็ม ๆ

ลองดู payload จาก API ตัวอย่างนี้:

{
  "id": 7,
  "first_name": "Ada",
  "email": null,
  "tags": ["ios", "swift"],
  "profile": {
    "bio": "Engineer",
    "website": null
  }
}

JSON to Swift Converter จะแปลงให้เป็น:

struct User: Codable {
    let id: Int
    var firstName: String
    var email: String?
    var tags: [String]
    var profile: Profile
}

struct Profile: Codable {
    var bio: String?
    var website: String?
}

มีสามเรื่องที่ควรสังเกต struct กับ conformance: ทั้ง User และ Profile ที่ซ้อนอยู่ประกาศ Codable ทำให้ compiler generate logic การ decode ให้อัตโนมัติ — ไม่ต้องเขียน init(from:) เอง optional: email และ website เป็น null ใน sample จึงออกมาเป็น String? ในโลกของ Codable property แบบ optional จะใจดีรับทั้งค่า null และ key ที่หายไป แต่ property แบบ non-optional จะไม่ยอมรับทั้งสองกรณี array: tags decode ตรงเข้า [String] และ array ของ object ก็จะ decode เป็น array ของ struct ที่ตรงกันเช่นกัน

เพราะ wire key เป็น snake_case ขณะที่ property เป็น camelCase โค้ด production จึงต้องมี enum CodingKeys คอยแปลงระหว่างสองฝั่ง และการ generate mapping นี้ให้ถูกทุก field คืองานซ้ำ ๆ ที่คนพลาดบ่อยแต่ generator ไม่มีวันพลาด:

extension User {
    enum CodingKeys: String, CodingKey {
        case id
        case firstName = "first_name"
        case email
        case tags
        case profile
    }
}

และนี่คือกับดัก decoding ที่ developer Swift ทุกคนต้องเจอสักวันหนึ่ง: field ที่เป็น non-optional หายไปแม้แต่ตัวเดียว ก็จะ throw ทันที ถ้า server ส่ง payload มาโดยไม่มี id JSONDecoder จะ raise keyNotFound แล้วการ decode ทั้งก้อนล้มเหลว ทั้งที่ object มาครบเกือบเก้าสิบเปอร์เซ็นต์ก็ตาม นี่คือดีไซน์ที่ตั้งใจ Codable ปฏิเสธที่จะมั่ว default value ที่คุณไม่เคยระบุ ผลที่ตามมาในทางปฏิบัติก็ตรงไปตรงมา field ที่ API อาจไม่ส่งมาหรือส่ง null จริง ๆ ควรเป็น optional ซึ่ง converter จะ mark ให้อัตโนมัติจาก sample ของคุณ ส่วน field ที่ต้องมีเสมอควรคงเป็น non-optional เพื่อให้ payload ที่ผิดปกติระเบิดให้เห็นตอน development แทนที่จะส่ง model ครึ่ง ๆ กลาง ๆ ผ่านไปเงียบ ๆ ลองเก็บ payload จริงมาสักสองสามชุด แปลง แล้วเทียบผลลัพธ์ — จุดที่ผลไม่ตรงกันคือคำตอบว่า field ไหนเชื่อถือไม่ได้

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

ชั้น networking ของแอป iOS

กรณีคลาสสิกที่สุด เมื่อแอป consume REST API ให้ generate struct หนึ่งตัวต่อ response ของแต่ละ endpoint แล้ววางไว้ใน folder Models เคียงข้าง networking code พอ backend ส่ง field ใหม่มา ก็แค่จับ response ใหม่หนึ่งชุด reconvert แล้ว diff กับ model เดิม การ review การเปลี่ยนแปลงใช้เวลาไม่กี่นาทีแทนที่จะเป็นหลายชั่วโมง

watchOS และ widget extension ที่แชร์ model เดียวกัน

model ที่เป็น Swift ล้วนพร้อม Codable conformance compile ได้ทุก platform ของ Apple struct ที่ generate มาชุดเดียวจึงวางใน shared framework ที่ทั้งแอป iOS, แอปคู่แฝงบน watchOS และ widget หน้า home screen ใช้ร่วมกันได้ แปลงครั้งเดียวได้ model สำหรับทุก target โดยไม่มี third-party dependency ตามมาให้ต้องจัดการข้าม platform

Payload จาก App Store server

ถ้าคุณ verify การแจ้งเตือนจาก App Store Server API หรือ signed transaction payload เหล่านั้นจะซ้อนลึก เป็น snake_case key และเปลี่ยนรูปร่างข้ามแต่ละเวอร์ชันของ API การเอา notification จริงมาแปลงเป็น struct — พร้อม CodingKeys ที่จัดการ mapping ให้เรียบร้อย — ปลอดภัยกว่าการร่าง hierarchy จาก documentation เพียงอย่างเดียว โดยเฉพาะ field ที่ Apple เพิ่มเข้ามาในแต่ละเวอร์ชัน

จาก prototype สู่ production model

ช่วง hackathon หรือ spike เอา payload จริงมา generate struct แล้วส่ง feature ออกได้ภายในวันเดียว พอ prototype ได้เลื่อนขั้นเป็น production model ก็มีอยู่แล้ว decode ข้อมูลจริงได้อยู่แล้ว และไม่มีกระเปาะ framework ติดมาให้ต้องรื้อ — refactor ได้อิสระ เพราะมันคือ Swift ธรรมดาที่คุณเป็นเจ้าของ

แนวทางปฏิบัติที่ดี

• mark field ที่ truly optional ให้เป็น optional จริง ๆ ถ้า field ไหนบางครั้งหายไปใน production ให้ยืนยันใช้ Type? ดีกว่าเอา default value มาอุดรูรั่วของการ decode converter จะอนุมานเรื่องนี้จาก sample ดังนั้นเลือก payload ที่สะท้อนความจริงให้มัน
• เพิ่ม CodingKeys ทุกครั้งที่รูปแบบชื่อไม่ตรงกัน อย่าเปลี่ยนชื่อ wire key ใน model แล้วหวังว่าจะไปได้สวย ให้ map แบบชัดเจน เพื่อให้ decoding เชื่อถือได้แน่นอนไม่ว่า naming convention จะเป็นแบบไหน
• ทดสอบ decode ด้วย payload จริงใน unit test เก็บ API response ที่ capture มาเป็น test fixture แล้ว assert ว่า decode สำเร็จ วิธีนี้จับ schema drift ได้ตั้งแต่วินาทีแรก ก่อนที่ crash report จะจับแทนคุณ
• generate ใหม่เมื่อ API เปลี่ยน ถือว่า output ของ converter คือ baseline ใหม่ทุกครั้งที่ endpoint พัฒนา แล้ว diff กับ model ที่ commit ไว้ ดีกว่าแก้ตามความจำ
• ตรวจ sample ก่อนแปลงเสมอ paste ที่ผิดรูปหรือถูกตัดครึ่งจะให้ struct ที่หลอกคุณ ผ่าน JSON Formatter เร็ว ๆ หนึ่งรอบเพื่อยืนยันว่า sample สมบูรณ์ก่อน
• ให้มี source of truth เดียวต่อหนึ่ง platform ทีมข้าม platform ควรใช้คู่กับ JSON to Kotlin Converter เพื่อให้ model ฝั่ง iOS และ Android generate จาก payload เดียวกัน และเบี่ยงเบนจากกันไม่ได้

เริ่มแปลง JSON เป็น Swift ได้เลยวันนี้

Codable ทำให้การจัดการ JSON ใน Swift ดีขึ้นอย่างก้าวกระโดด แต่มันไม่เคยแก้ปัญหาการพิมพ์เอง JSON to Swift Converter ปิดช่องว่างสุดท้ายนั้น: paste payload แล้วรับ struct ที่ถูกต้องพร้อม optional, nested type และชื่อที่เข้ากับโปรเจกต์ของคุณ — เป็นส่วนตัว รวดเร็ว และอยู่ใน browser ของคุณทั้งหมด หยิบ API response จริงมาหนึ่งชุดแล้วจะรู้ว่าต่างกันแค่ไหนภายในไม่ถึงนาที

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

• JSON Formatter — validate, pretty-print และจัดระเบียบ JSON sample ก่อนแปลง
• JSON to Kotlin Converter — workflow generate จาก payload แบบเดียวกันสำหรับ data class บน Android
• OpenAPI to TypeScript Converter — แปลง API specification ทั้งชุดเป็น typed model สำหรับ web stack ของคุณ

ขอให้สนุกกับการ decode!

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

ถ: ตอนแปลง JSON ของฉันถูกส่งไปที่ server หรือเปล่า?

ตอบ: ไม่ครับ converter ทำงานใน browser ของคุณทั้งหมด การ parse และ generate โค้ดเกิดขึ้นในเครื่อง และไม่มี payload, sample หรือโค้ดที่ generate แล้วถูก upload, เก็บหรือ log ไว้ที่ใดเลย

ถ: เครื่องมือตัดสินใจว่า property ไหนควรเป็น optional อย่างไร?

ตอบ: field ใดก็ตามที่หายไปจาก sample หรือปรากฏด้วยค่า null จะออกมาเป็น Type? ส่วน field ที่ปรากฏพร้อมค่าจริงจะออกมาเป็น non-optional ดังนั้นควรให้ converter กิน payload ที่สะท้อนพฤติกรรมจริงของ API รวมถึง field ที่บางครั้งหายไปด้วย

ถ: รองรับ JSON ที่ซ้อนลึกพร้อม array ของ object ไหม?

ตอบ: รองรับครับ object ที่ซ้อนกันจะกลายเป็น struct แยกกัน และ array ของ object จะกลายเป็น Swift array ของ struct type ที่ตรงกัน ลึกแค่ไหนก็ได้ โดย struct ที่ generate ออกมาทุกตัวมี Codable conformance ของตัวเอง