परिचय

मैंने यह टूल एक बहुत सरल कारण से बनाया। हर बार इसे हाथ से संभालना थका देने वाला था।

आंतरिक सिस्टम से आने वाली CSV, Excel से बनाई गई CSV, और Linux/Windows/DB से निकली configuration files—इनका स्रोत बदलते ही encoding, line ending और BOM भी बदल जाते हैं।

  • UTF-8 समझा, निकला Shift_JIS
  • LF समझा, निकला CRLF
  • कुछ सिस्टम BOM के साथ स्थिर, कुछ BOM से ही टूट जाते हैं

यह काम हर बार आँख और अनुमान से करना स्केल नहीं होता। इसलिए ऐसा टूल बनाया जो किसी भी स्रोत की फ़ाइल ले और target import requirement के अनुसार output normalize करे।

असली समस्या एक बार की garbled text नहीं है

एक फ़ाइल खराब हो जाए तो अक्सर ठीक हो जाती है। कठिन स्थिति तब होती है जब 10 या 100 फ़ाइलें अलग-अलग स्रोतों से एक साथ आती हैं।

और मुश्किल यह कि हर destination system की “सही” परिभाषा अलग होती है।

  • System A: केवल UTF-8 (बिना BOM)
  • System B: UTF-8 (BOM के साथ) पर स्थिर
  • System C: Shift_JIS आधारित; UTF-8 दिख तो जाता है पर import fail होता है

ऐसे में “सबको UTF-8 कर दो” जैसी सामान्य सलाह बेकार है। ज़रूरत है उपयोग-आधारित, सुरक्षित और repeatable प्रक्रिया की।

इस टूल से मेरा लक्ष्य

सिर्फ तीन सिद्धांत:

  1. किसी भी स्रोत की फ़ाइल स्वीकार करना
  2. destination requirement के अनुसार convert करना
  3. bulk processing में भी incidents न बढ़ाना

यह conversion का प्रदर्शन नहीं, operational friction कम करने का साधन है।

मेरी वास्तविक प्रक्रिया

1. पहले output specification तय करें

शुरुआत input से नहीं, output से करें। इन तीन चीज़ों को लॉक करें:

  • Encoding (UTF-8 / Shift_JIS आदि)
  • Line ending (LF / CRLF)
  • BOM (with / without)

यह अस्पष्ट रहा तो operator बदलते ही परिणाम बदल जाएगा।

2. conversion targets को छोटे समूहों में बाँटें

सारा डेटा एक साथ न चलाएँ। System, period, file type के आधार पर छोटे batch से शुरू करें।

कारण स्पष्ट है: failure पर rollback संभव रहता है। Full-volume one-shot सफल हो तो तेज है, असफल हो तो बहुत महँगा पड़ता है।

3. conditions fix करके bulk conversion चलाएँ

Character Encoding Converter में destination के अनुसार conditions lock करें। बीच में setting न बदलें। हर बार वही condition दोहराई जा सके, यही महत्वपूर्ण है।

4. सफलता का निर्णय सिर्फ देखकर न करें

“फ़ाइल खुल गई, मतलब ठीक है” — यही कई दुर्घटनाओं की शुरुआत है। कम से कम यह जाँचें:

  • पहले और बाद में row count समान है या नहीं
  • CSV/TSV column count टूटा तो नहीं
  • � (replacement character) बढ़ा तो नहीं
  • key columns (ID/code) की लंबाई और character type कायम है या नहीं

जाँच पास न हो तो import मत करें।

BOM विचारधारा नहीं, counterpart requirement है

BOM होना चाहिए या नहीं—मैदान में यह बहस अक्सर अर्थहीन है। महत्वपूर्ण केवल यह है कि सामने वाला सिस्टम कैसे consume करता है।

  • counterpart BOM के साथ stable है तो BOM के साथ output दें
  • counterpart BOM से टूटता है तो BOM हटाकर दें

“सैद्धांतिक रूप से सही format” से पहले “जो सामने वाले को न तोड़े” को प्राथमिकता दें। यही व्यावहारिक operations है।

इस टूल का मूल्य conversion से आगे है

असली मूल्य दो हैं:

  • निर्णय व्यक्ति-निर्भर नहीं रहता
  • बार-बार verification की लागत घटती है

Encoding incidents को शून्य करना संभव नहीं। लेकिन वही गलती बार-बार होने से रोकी जा सकती है। इसीलिए मैंने ऐसा टूल तैयार किया जो कुछ भी स्वीकार करे और उपयोग के अनुसार स्थिर output लौटाए।

निष्कर्ष

यह टूल आदर्शवादी सिद्धांत से नहीं बना। यह वास्तविक काम में बार-बार होने वाले थकाऊ encoding adjustment को खत्म करने के लिए बना।

अलग स्रोतों की फ़ाइल लें, destination requirement के अनुसार encoding/line ending/BOM मिलाएँ, और consistent output दें। सिर्फ इस flow को automate करने से operations काफी आसान हो जाते हैं।

Mojibake संभालना इच्छाशक्ति का काम नहीं है। इसे reproducible procedure बनाना होगा ताकि कोई भी व्यक्ति वही परिणाम दे सके। तभी हम कह सकते हैं कि bulk recovery सुरक्षित है।