Տվյալների փոխարկիչներ

Տվյալների տեղափոխում CSV, JSON, YAML և XML միջև

Տվյալները հազվադեպ են մնում մեկ ֆորմատում։ Հաշվետվությունը գալիս է որպես աղյուսակ, API-ն ուզում է JSON, deployment pipeline-ը ակնկալում է YAML, և ինչ-որ տեղ նկուղում legacy ծառայությունը դեռ խոսում է XML-ով։ Տվյալների հետ աշխատանքի ամենօրյա շփման մեծ մասը ոչ թե տվյալներն իրենք են, այլ դրանք ձեզ ունեցած ձևից ինչ-որ այլ բանի պահանջած ձևի բերելը։ Հենց դա է տվյալների փոխարկիչի ամբողջ աշխատանքը. վերցնել կառուցվածքային տեքստ մեկ notation-ով և վերարտադրել այն մեկ ուրիշում՝ չկորցնելով իմաստը ճանապարհին։

Speedor-ի փոխարկիչներն ամբողջովին աշխատում են ձեր բրաուզերում։ Դուք տեղադրում եք, սեղմում եք, պատճենում արդյունքը։ Ոչինչ չի վերբեռնվում, ոչինչ չի գրանցվում, և ոչինչ չի հեռանում ձեր սարքից։ Ցանկացած մեկի համար, ով երբևէ երկմտել է, նախքան հաճախորդի export-ը պատահական կայքում տեղադրելը, հենց այս լոկալ-միայն դիզայնն է իմաստը։

Ինչում է իրականում լավն յուրաքանչյուր ֆորմատ

Օգտակար է իմանալ, թե ինչու են այս ֆորմատները գոյություն ունեն, նախքան դրանց միջև խառնուփառնուր անելը սկսելը, քանի որ յուրաքանչյուրը կառուցվել է տարբեր աշխատանքի համար։

CSV-ն հարթ, ստորակետով բաժանված ցանցն է, որը սիրում են աղյուսակները։ Այն բնությամբ աղյուսակային է. տողեր և սյուներ, ոչինչ ներդրված չէ։ Բացեք այն Excel-ում, Google Sheets-ում կամ Numbers-ում, և այն պարզապես աշխատում է։ Խնդիրն այն է, որ CSV-ն տեսակների հասկացություն չունի։ 007 արժեքը կարող է լինել string, number կամ zip code, և CSV-ն ձեզ չի ասի, թե որն է։

JSON-ը ժամանակակից վեբի ընդհանուր լեզուն է։ Գրեթե ամեն API, որին երբևէ կդիմեք, խոսում է դրանով։ JSON-ը մշակում է nesting, array-ներ և մի քանի իրական տեսակներ (string-ներ, number-ներ, boolean-ներ, null), ինչը այն շատ ավելի արտահայտիչ է դարձնում, քան հարթ աղյուսակը։ Այն կոմպակտ է, մեքենային-հարմար, և աջակցվում է ամենուր։

YAML-ը JSON-ի ավելի ընթեռնելի զարմիկն է։ Այն օգտագործում է ինդենտացիա փակագծերի փոխարեն, աջակցում է comment-ներ, և հակված է լինել կոնֆիգուրացիայի ֆայլերի, Docker Compose-ի, Kubernetes manifest-ների և CI pipeline-ների ընտրյալ ֆորմատը։ Երբ մարդը պետք է ձեռքով ինչ-որ բան խմբագրի, YAML-ը սովորաբար ավելի բարեհամբույր է աչքի համար։

XML-ը ավագ պետական գործիչն է։ Verbose, tag-ալի, և դեռ խորապես ներդրված է ձեռնարկատիրական համակարգերում, SOAP ծառայություններում, ֆինանսական հաղորդագրություններում և փաստաթղթային ստանդարտներում, ինչպիսին է RSS-ը։ Դուք ավելի հազվադեպ եք հանդիպելու դրան greenfield նախագծերում, բայց երբ իսկապես դա անհրաժեշտ է, դա իսկապես անհրաժեշտ է։

Որտեղ իրականում տեղի են ունենում փոխարկումները

Սցենարներն ամբողջովին կոնկրետ են, երբ սկսում եք նայել։ Ասենք մարքեթինգը ձեզ տալիս է 4000 կոնտակտների աղյուսակ, և գրանցման API-ն ընդունում է միայն JSON array։ Դուք export եք անում աղյուսակը CSV-ի, գործարկում այն CSV to JSON-ի միջով, և ունեք payload պատրաստ POST անելու։ Ոչ մի glue script, ոչ մի pandas, ոչ մի ինժեների սպասում։

Կամ դուք հանում եք JSON-ի կտոր նույն API-ից և ցանկանում եք տեղադրել այն կոնֆիգուրացիայի ֆայլում, որը ձեր ծառայությունը կարդում է գործարկման ժամանակ։ Փոխարկեք այն JSON to YAML-ով, և կստանաք ինչ-որ մաքուր և comment-ելի բան, որը ճիշտ տեղավորվում է ձեր repo-ում։ Հակառակ ուղղությունն էլ է աշխատում, երբ գործիքն ընդունում է միայն JSON, բայց ձեր կոնֆիգուրացիան YAML-ում է ապրում։

Եվ հետո կա ինտեգրումը, որը ոչ ոք չի սիրում. գործընկեր համակարգ, որն ընդունում է միայն XML։ Դուք կառուցում եք ձեր payload-ը JSON-ով, քանի որ հենց այդպես է մտածում ձեր հավելվածը, ապա փոխարկում XML-ի սահմանագծում։ Ձևը մնում է նույնը, միայն սինտաքսն է փոխվում։

Ինչին արժե ուշադրություն դարձնել

Ֆորմատի փոխարկումը միշտ չէ, որ lossless է, և հակառակը ձևացնելը հանգեցնում է bug-երի։ Մի քանի բան, որ արժե հիշել.

CSV-ն մոռանում է տեսակները։ Քանի որ ամեն cell-ը պարզապես տեքստ է, թվերը, boolean-ները և ամսաթվերը բոլորը դուրս են գալիս որպես string-ներ, եթե փոխարկիչը ձեզ համար չի գուշակում։ Եթե true-ն պետք է լինի boolean, ոչ թե «true» բառը, ստուգեք արդյունքը, նախքան այն առաքելը։

YAML-ը հոգում է բացատների մասին։ Ինդենտացիան YAML-ում կոսմետիկ չէ, այն կառուցվածքային է։ Մեկ պատահական բացատը կարող է փոխել, թե որ բանալուն է պատկանում արժեքը, և tab-երն ամբողջովին արգելված են։ Ցանկացած JSON to YAML round-trip-ից հետո արժե արագ նայել, կամ արդյունքը կրկին անցկացնել JSON ֆորմատավորիչի միջով՝ հաստատելու, որ կառուցվածքը ողջ է մնացել։

XML-ը և JSON-ը մաքուր չեն համապատասխանում։ JSON-ը ունի array-ներ. XML-ը ունի կրկնվող element-ներ։ JSON-ը ոչ մի տեղ attribute-ներ չունի. XML-ը դրանք ունի ամենուր։ Փոխարկիչների մեծ մասն ընտրում է ողջամիտ conventions, բայց եթե ձեր XML-ը ինտենսիվ օգտագործում է attribute-ներ, արտադրված JSON-ը մի փոքր տարբեր տեսք կունենա, քան ձեռքով գրված JSON-ը։ Դա ակնկալվող է, ոչ թե թերություն։

Nesting-ի խորությունը կարևոր է։ CSV-ն հարթ է, ուստի խորապես nested JSON-ը միշտ չէ, որ կարող է սեղմվել սյուների մեջ՝ առանց բանալիների հարթեցման (մտածեք address.city)։ Հակառակ ուղղությամբ գնալիս, հարթ CSV-ն դառնում է հարթ array, երբեք ծառ։

Ինչու է կարևոր լոկալ-միայն մոտեցումն այստեղ

Շատ տվյալներ, որոնք ցանկանում եք փոխարկել, ձերը չեն կիսվելու համար։ Օգտատերերի գրառումներ, ներքին կոնֆիգուրացիաներ, պատասխանում թաղված API բանալիներ, ֆինանսական տողեր։ Բազմաթիվ օնլայն փոխարկիչներ լուռ ուղարկում են ձեր տեղադրածը սերվեր՝ աշխատանքն անելու համար։ Speedor-ը դա չի անում։ Փոխարկման տրամաբանությունն աշխատում է ձեր բրաուզերի tab-ում, տվյալները երբեք չեն անցնում ցանցով, և tab-ը փակելը ողջ մաքրումն է, որն անհրաժեշտ է։ Այն նաև ավելի արագ է, քանի որ չկա վերբեռնման round-trip, և այն աշխատում է offline, հենց էջը բեռնվում է։ Անվճար, առանց գրանցման, առանց quota-ի։

Հաճախ տրվող հարցեր