সিরিয়ালাইজেশন বোঝা যাচ্ছে

Question

আমি একজন সফটওয়্যার ইঞ্জিনিয়ার এবং কিছু সহকর্মীর সাথে আলোচনার পরে বুঝতে পেরেছিলাম ধারণাটি সিরিয়ালায়নের সম্পর্কে আমার খুব বেশি উপলব্ধি নেই। আমি যেমন বুঝতে পেরেছি, সিরিয়ালাইজেশন হ'ল কিছু সত্তা যেমন ওওপি-তে কোনও অবজেক্টকে বাইটের অনুক্রমে রূপান্তর করার প্রক্রিয়া, যাতে উল্লিখিত সত্তা পরবর্তী অ্যাক্সেসের জন্য সংরক্ষণ করা যায় বা প্রেরণ করা যায় ("deserialization" প্রক্রিয়া)।

আমার যে সমস্যাটি হচ্ছে তা হ'ল: সমস্ত ভেরিয়েবল নয় (এটি আদিম পছন্দ হোক) int বা যৌগিক বস্তুর মতো হওয়া) ইতিমধ্যে বাইটের ক্রম দ্বারা প্রতিনিধিত্ব করা হয় না? (অবশ্যই তারা, কারণ তারা রেজিস্টার, মেমরি, ডিস্ক ইত্যাদিতে সঞ্চিত থাকে)

সুতরাং সিরিয়ালাইজেশন এত গভীর বিষয় কি করে? একটি ভেরিয়েবল সিরিয়ালাইজ করতে, আমরা কি কেবল এই বাইটগুলি মেমরির মধ্যে নিতে পারি না এবং সেগুলি একটি ফাইলে লিখতে পারি না? আমি কোন জটিলতা মিস করেছি?

Comments

ধারাবাহিক বস্তুগুলির জন্য ক্রমিকায়ন তুচ্ছ হতে পারে । যখন বস্তুর মানটিকে পয়েন্টার গ্রাফ হিসাবে উপস্থাপন করা হয় , জিনিসগুলি আরও জটিল হয়ে ওঠে, বিশেষত যদি বলা হয় গ্রাফের লুপ থাকে।

— চি ২

@ চি: আপনার প্রথম বাক্যটি সামান্য বিভ্রান্তিকর দেওয়া দ্বন্দ্বটি অপ্রাসঙ্গিক। আপনার কাছে এমন একটি গ্রাফ থাকতে পারে যা স্মৃতিতে অবিচ্ছিন্ন হতে থাকে এবং এটি আপনাকে ক্রমিকায়িত করতে সাহায্য করে না কারণ এখনও আপনাকে (ক) সনাক্ত করতে হবে যে এটি সত্যিকারের মতোই সংঘটিত হয়েছে এবং (খ) অভ্যন্তরের পয়েন্টারগুলি ঠিক করে ফেলতে পারে। আপনি যা বলেছিলেন তার দ্বিতীয় ভাগটিই আমি বলতে চাই।

— মেহরদাদ

@ মেহরদাদ আমি সম্মত হলাম আমার মন্তব্য সম্পূর্ণ সুনির্দিষ্ট নয়, আপনি যে কারণে উল্লেখ করেছেন। সম্ভবত পয়েন্টারবিহীন / পয়েন্টার-ব্যবহার আরও ভাল পার্থক্য (এমনকি পুরোপুরি সঠিক না হলেও)

— চি ২

আপনাকে হার্ডওয়্যারে উপস্থাপনের বিষয়েও চিন্তা করতে হবে। যদি আমি 4 bytesআমার পিডিপি -11 এ কোন ইন্টারটি সিরিয়াল করি এবং তারপরে আমার ম্যাকবুকটিতে সেই চারটি বাইট স্মৃতিতে পড়তে চেষ্টা করি তবে সেগুলি একই নম্বর নয় (এন্ডিয়ানেসের কারণে)। সুতরাং আপনাকে ডে-কোডটি উপস্থাপন করতে হবে যা আপনি উপ-কোড করতে পারেন (এটি ক্রমিকায়ন) serial আপনি কীভাবে ডেটাটিকে সিরিয়ালাইজ করেছেন তাতে ট্রেড অফসের গতি / নমনীয়তা মানব / মেশিন পঠনযোগ্যও রয়েছে।

— মার্টিন ইয়র্ক

আপনি যদি অনেক গভীরভাবে সংযুক্ত নেভিগেশন বৈশিষ্ট্যগুলির সাথে সত্ত্বা ফ্রেমওয়ার্ক ব্যবহার করেন তবে কী হবে? একটি ক্ষেত্রে, আপনি একটি নেভিগেশন সম্পত্তিকে সিরিয়াল করতে চাইতে পারেন, তবে অন্যটিতে এটি বাতিল করে দিন (কারণ আপনি আপনার সিরিয়ালাইজড প্যারেন্ট অবজেক্টে থাকা আইডির উপর ভিত্তি করে ডাটাবেস থেকে সেই প্রকৃত অবজেক্টটি পুনরায় লোড করবেন)। এটি কেবল একটি উদাহরণ। এখানে অনেক.

— এরিক

Answer 1

আপনার যদি কোনও জটিল ডেটা কাঠামো থাকে তবে মেমরিতে এটির উপস্থাপনা সাধারণত মেমরি জুড়ে ছড়িয়ে ছিটিয়ে থাকে। (উদাহরণস্বরূপ, বাইনারি গাছের কথা চিন্তা করুন))

বিপরীতে, আপনি যখন এটি ডিস্কে লিখতে চান, আপনি সম্ভবত একটি সংক্ষিপ্ত বাইটের (আশা করি সংক্ষিপ্ত) ক্রম হিসাবে একটি উপস্থাপনা পেতে চান। সিরিয়ালাইজেশন আপনার জন্য এটি করে।

Answer 2

আমার যে সমস্যাটি হচ্ছে তা হ'ল: কি সমস্ত ভেরিয়েবল (ইন্ট বা কমপোজেট অবজেক্টের মতো আদিম) ইতিমধ্যে বাইটের ক্রম দ্বারা উপস্থাপিত হয় না? (অবশ্যই তারা, কারণ তারা রেজিস্টার, মেমরি, ডিস্ক ইত্যাদিতে সঞ্চিত থাকে)

সুতরাং সিরিয়ালাইজেশন এত গভীর বিষয় কি করে? একটি ভেরিয়েবল সিরিয়ালাইজ করতে, আমরা কি কেবল এই বাইটগুলি মেমরির মধ্যে নিতে পারি না এবং সেগুলি একটি ফাইলে লিখতে পারি না? আমি কোন জটিলতা মিস করেছি?

নোড সহ সি হিসাবে একটি অবজেক্ট গ্রাফটি বিবেচনা করুন:

struct Node {
    struct Node* parent;
    struct Node* someChild;
    struct Node* anotherLink;

    int value;
    char* label;
};

//

struct Node nodes[10] = {0};
nodes[5].parent = nodes[0];
nodes[0].someChild = calloc( 1, sizeof(struct Node) );
nodes[5].anotherLink = nodes[3];
for( size_t i = 3; i < 7; i++ ) {
    nodes[i].anotherLink = calloc( 1, sizeof(struct Node) );
}

রানটাইমের সময় পুরো অবজেক্ট Nodeগ্রাফটি মেমরির জায়গার চারদিকে ছড়িয়ে পড়ে এবং একই নোডটি বিভিন্ন নোড থেকে পয়েন্ট-টু করা যেতে পারে।

আপনি কেবল কোনও ফাইল / স্ট্রিম / ডিস্কে মেমরি ডাম্প করতে পারেন এবং এটিকে সিরিয়ালাইজড কল করতে পারবেন না কারণ পয়েন্টার মানগুলি (যা মেমরি ঠিকানাগুলি) ডি-সিরিয়ালাইজ করা যায়নি (কারণ আপনি যখন ডাম্প ফেরত লোড করবেন তখন সেই মেমরির অবস্থানগুলি ইতিমধ্যে দখল করা যেতে পারে because স্মৃতিতে) কেবল ডেম্পিং মেমরির সাথে আরেকটি সমস্যা হ'ল আপনি সব ধরণের অপ্রাসঙ্গিক ডেটা এবং অব্যবহৃত স্থান সংরক্ষণ করবেন - x86 এ কোনও প্রক্রিয়াতে 4GiB মেমরির স্থান থাকে এবং কোনও ওএস বা এমএমইউতে কেবল মেমরিটি আসলে কী তা সম্পর্কে একটি সাধারণ ধারণা থাকে অর্থপূর্ণ বা না (কোনও প্রক্রিয়াতে নির্ধারিত মেমোরি পৃষ্ঠাগুলির উপর ভিত্তি করে), সুতরাং Notepad.exeযখনই আমি একটি পাঠ্য ফাইল সংরক্ষণ করতে চাই তখন আমার ডিস্কে 4 গিগাবাইট কাঁচা বাইট ফেলে দেওয়া কিছুটা অপ্রয়োজনীয় বলে মনে হয়।

সংস্করণে আরেকটি সমস্যা রয়েছে: আপনি যদি প্রথম Nodeদিনটিতে নিজের গ্রাফটি সিরিয়ালায়িত করেন , তবে দ্বিতীয় দিনে আপনি অন্য ক্ষেত্রটি যুক্ত করেন Node(যেমন অন্য পয়েন্টার মান, বা একটি আদিম মান), তারপরে ৩ য় দিনে আপনি নিজের ফাইলটি ডি-সিরিয়াল করেন দিন 1?

আপনাকে অন্যান্য বিষয়গুলিও বিবেচনা করতে হবে, যেমন আধ্যাত্মিকতা। 1980 এবং 1990 এর দশকে ম্যাকোস এবং আইবিএম / উইন্ডোজ / পিসি ফাইলগুলি একে অপরের সাথে সামঞ্জস্যপূর্ণ না হওয়ার একটি প্রধান কারণ হ'ল x86 / পিসি মাল্টি-বাইট পূর্ণসংখ্যার মানগুলির কারণে স্বল্প-এডিয়ান অর্ডারে সংরক্ষণ করা হয়েছিল, তবে ম্যাকের উপর বিগ-এন্ডিয়ান অর্ডার - এবং সফ্টওয়্যারটি ক্রস প্ল্যাটফর্মের বহনযোগ্যতার কথা মাথায় রেখে তৈরি করা হয়নি। আজকাল বিষয়গুলি উন্নত বিকাশকারী শিক্ষা এবং আমাদের ক্রমবর্ধমান বিজাতীয় কম্পিউটিং জগতের জন্য আরও ভাল ধন্যবাদ।

Comments

প্রক্রিয়াটির মেমরির সমস্ত জায়গাকে ডাম্পিং করা সুরক্ষা কারণেও ভয়াবহ হতে পারে। একটি প্রোগ্রাম নাইট স্মৃতিতে থাকে 1) কিছু প্রকাশ্য ডেটা এবং 2) পাসওয়ার্ড, গোপন নন বা ব্যক্তিগত কী। প্রাক্তনকে সিরিয়ালকরণ করার সময়, কেউ পরবর্তীকালের কোনও তথ্য প্রকাশ করতে চায় না।

— চি ২

এই বিষয়ে একটি খুব আকর্ষণীয় নোট: মাইক্রোসফ্ট অফিস ফাইল ফর্ম্যাটগুলি এত জটিল কেন?

— আঘাত করা

Answer 3

ছদ্মবেশটি আসলে ইতিমধ্যে শব্দটিতে বর্ণিত: " সিরিয়াল আইজেশন"।

প্রশ্নটি মূলত: আমি কীভাবে একটি স্বেচ্ছাসেবী জটিল আন্তঃসংযুক্ত চক্রাকার নির্দেশিত গ্রাফকে বিন্যাসের রৈখিক ক্রম হিসাবে নির্বিচারে জটিল বস্তুর প্রতিনিধিত্ব করতে পারি?

এটি সম্পর্কে চিন্তা করুন: একটি লিনিয়ার সিকোয়েন্সটি হ'ল ডিজেনারেটেড ডিরেক্টর্ট গ্রাফের মতো যেখানে প্রতিটি শীর্ষবিন্দুতে একেবারে একটি আগমনকারী এবং বহির্গামী প্রান্ত থাকে ("প্রথম প্রান্তি" বাদে যার কোনও আগত প্রান্ত থাকে না এবং "শেষ প্রান্ত" থাকে না যার বাইরে কোন প্রান্ত থাকে না) । এবং একটি বাইট সম্ভবত একটি বস্তুর চেয়ে কম জটিল ।

সুতরাং, এটি যুক্তিসঙ্গত বলে মনে হচ্ছে যেহেতু আমরা একটি নির্বিচারে জটিল গ্রাফ থেকে অনেক বেশি সীমাবদ্ধ "গ্রাফ" (আসলে কেবল একটি তালিকা) এবং নির্বিচারে জটিল বস্তুগুলি থেকে সাধারণ বাইটগুলিতে যাব , তথ্য হারাবে, যদি আমরা এই কাজটি অনড়ভাবে করি এবং ডন ' t "বহিরাগত" তথ্য কোনওভাবে এনকোড করুন। সিরিয়ালাইজেশন হ'ল: জটিল তথ্যটি একটি সাধারণ রৈখিক বিন্যাসে এনকোড করে।

আপনি যদি ওয়াইএএমএলের সাথে পরিচিত হন তবে আপনার অ্যাঙ্কর এবং উরফের বৈশিষ্ট্যগুলির দিকে নজর রাখতে পারে যা আপনাকে সিরিয়ালায়িতকরণে "একই জিনিস বিভিন্ন জায়গায় উপস্থিত হতে পারে" এই ধারণার প্রতিনিধিত্ব করতে দেয়।

যেমন নীচের গ্রাফটি থাকলে:

A → B → D
↓       ↑
C ––––––+

আপনি YAML এ লিনিয়ার পাথের তালিকা হিসাবে এটি উপস্থাপন করতে পারেন:

- [&A A, B, &D D]
- [*A, C, *D]

আপনি এটিকে সংলগ্ন তালিকা, বা সংলগ্ন ম্যাট্রিক্স হিসাবে বা এমন একটি জোড় হিসাবে প্রতিনিধিত্ব করতে পারেন যার প্রথম উপাদানটি নোডের সমষ্টি এবং যার দ্বিতীয় উপাদানটি নোডের জোড়া রয়েছে, তবে এই সমস্ত উপস্থাপনায় আপনার থাকা দরকার বিদ্যমান নোডগুলিতে পিছনে এবং ফরোয়ার্ডগুলি উল্লেখ করার একটি উপায় , অর্থাৎ পয়েন্টারগুলি , যা আপনার সাধারণত কোনও ফাইল বা কোনও নেটওয়ার্ক স্ট্রিমে নেই। আপনার সমস্ত কিছু শেষ পর্যন্ত বাইট।

(কোন বিটিডব্লিউর অর্থ হ'ল উপরের ওয়াইএএমএল পাঠ্য ফাইলটি নিজেই "সিরিয়ালাইজড" হওয়া দরকার, বিভিন্ন চরিত্রের এনকোডিংস এবং ইউনিকোড স্থানান্তর ফর্ম্যাটগুলির জন্য এটি… এটি কঠোরভাবে "সিরিয়ালাইজেশন" নয়, কেবল এনকোডিং রয়েছে, কারণ পাঠ্য ফাইলটি ইতিমধ্যে একটি সিরিয়াল রয়েছে / কোডেপয়েন্টের রৈখিক তালিকা, তবে আপনি কিছু মিল দেখতে পারেন))

Answer 4

অন্যান্য উত্তরগুলি ইতিমধ্যে জটিল অবজেক্টের গ্রাফগুলিকে সম্বোধন করে, তবে এটি উল্লেখ করার মতো যে আদিমগুলি ক্রমিক করাও ক্ষুদ্র নয়।

সংক্ষিপ্ততার জন্য সি আদিম ধরণের নাম ব্যবহার করে বিবেচনা করুন:

1. আমি সিরিয়াল করি a long। এর কিছুদিন পরে আমি ডি ধারাবাহিকভাবে এটা, কিন্তু ... একটি ভিন্ন প্ল্যাটফর্মের উপর, এবং এখন longহয় int64_tবদলে int32_tআমি সংরক্ষণ করা হয়। সুতরাং, আমি হয় আমার সংরক্ষণ করা প্রতিটি ধরণের সঠিক আকার সম্পর্কে খুব সাবধানতা অবলম্বন করা দরকার, বা প্রতিটি ক্ষেত্রের ধরণ এবং আকার বর্ণনা করে কিছু মেটাডেটা সঞ্চয় করতে হবে।

   নোট করুন যে এই ভিন্ন প্ল্যাটফর্মটি ভবিষ্যতের পুনরায় সংকলনের পরে ঠিক একই প্ল্যাটফর্ম হতে পারে।

2. আমি একজন ধারাবাহিকভাবে int32_t। কিছু সময় পরে আমি এটি ডি-সিরিয়াল করি, তবে ... ভিন্ন প্ল্যাটফর্মে, এবং এখন মানটি দুর্নীতিগ্রস্থ। দুঃখের সাথে আমি মানটি একটি বড়-এন্ডিয়ান প্ল্যাটফর্মে সংরক্ষণ করেছি এবং এটি একটি সামান্য এন্ডিয়ান প্লেতে লোড করেছি। এখন আমার ফর্ম্যাটটির জন্য আমার একটি কনভেনশন স্থাপন করা প্রয়োজন, বা প্রতিটি ফাইল / স্ট্রিম / যা-ই হোক না কেন অন্তর্নিহিততা বর্ণনা করে আরও মেটাডেটা যুক্ত করা দরকার । এবং অবশ্যই, যথাযথ রূপান্তরগুলি সম্পাদন করুন।

3. আমি একটি স্ট্রিং সিরিয়াল। এবার একটি প্ল্যাটফর্ম ব্যবহার করে charএবং ইউটিএফ -8, এবং একটি wchar_tএবং ইউটিএফ -16 ব্যবহার করে।

সুতরাং, আমি দাবি করেছি যে যুক্তিসঙ্গত মানের সিরিয়ালাইজেশন সামঞ্জস্যপূর্ণ স্মৃতিতে এমনকি আদিমদের জন্যও তুচ্ছ নয়। আপনার ডকুমেন্ট করতে হবে বা ইনলাইন মেটাডেটা দিয়ে বর্ণনা করতে হবে এমন প্রচুর এনকোডিং সিদ্ধান্ত রয়েছে।

অবজেক্ট গ্রাফগুলি তার ওপরে জটিলতার আরও একটি স্তর যুক্ত করে।

Answer 5

একাধিক দিক রয়েছে:

একই প্রোগ্রাম দ্বারা পঠনযোগ্যতা

আপনার প্রোগ্রামটি কোনওভাবে মেমরিতে বাইট হিসাবে আপনার ডেটা সংরক্ষণ করেছে। তবে এটি নির্ধারিতভাবে বিভিন্ন রেজিস্টারে ছড়িয়ে ছিটিয়ে থাকতে পারে, পয়েন্টারগুলি এর ছোট ছোট টুকরাগুলির মধ্যে পিছনে এবং পিছনে যায় [সম্পাদনা করুন: মন্তব্য করা হয়েছে, শারীরিকভাবে ডেটা রেজিস্ট্রারের চেয়ে মূল মেমরিতে ডেটা বেশি থাকে তবে এটি পয়েন্টারের সমস্যাটি সরিয়ে দেয় না] । কেবল একটি সংযুক্ত পূর্ণসংখ্যার তালিকার কথা ভাবেন। প্রতিটি তালিকার উপাদানগুলি সম্পূর্ণ আলাদা জায়গায় সংরক্ষণ করা হতে পারে এবং তালিকাটি একসাথে রাখা সমস্তগুলিই এক উপাদান থেকে পরের দিকে নির্দেশক। আপনি যদি সেই ডেটাটি যেমনটি গ্রহণ করেন এবং একই প্রোগ্রামটি চালাচ্ছেন এমন অন্য কোনও মেশিনে অনুলিপি করার চেষ্টা করেছিলেন, আপনি সমস্যার মধ্যে পড়ে যাবেন:

1. প্রথম এবং সর্বাগ্রে, নিবন্ধগুলি অ্যাড্রেস করে আপনার ডেটা একটি মেশিনে সঞ্চিত রয়েছে অন্য মেশিনে সম্পূর্ণ আলাদা কোনও কিছুর জন্য ইতিমধ্যে ব্যবহার করা যেতে পারে (কেউ স্ট্যাক এক্সচেঞ্জ ব্রাউজ করছে এবং ব্রাউজারটি ইতিমধ্যে সমস্ত স্মৃতি খেয়ে ফেলেছে)। সুতরাং আপনি যদি এই রেজিস্ট্রে ওভাররাইড করে থাকেন তবে ভাল বাই ব্রাউজার। সুতরাং, দ্বিতীয় মেশিনে আপনার ফ্রি ঠিকানাগুলি ফিট করার জন্য আপনার কাঠামোর পয়েন্টারগুলিকে পুনরায় ব্যবস্থা করতে হবে। আপনি যখন পরে একই কম্পিউটারে ডেটা পুনরায় লোড করার চেষ্টা করবেন তখন একই সমস্যা দেখা দেয়।
2. যদি কোনও বাহ্যিক উপাদান আপনার কাঠামোতে নির্দেশ করে বা আপনার কাঠামোর বাহ্যিক ডেটারে পয়েন্টার রয়েছে, আপনি সঞ্চারিত করেন নি? সব জায়গায় সেগফাল্টস! এটি একটি ডিবাগিং দুঃস্বপ্ন হয়ে উঠবে।

অন্য প্রোগ্রামের পাঠযোগ্যতা

আপনার ডেটা ফিট করার জন্য আপনি অন্য মেশিনে ঠিক সঠিক ঠিকানা বরাদ্দ করতে পরিচালিত হন। যদি আপনার ডেটা সেই মেশিনে (আলাদা ভাষা) একটি পৃথক প্রোগ্রাম দ্বারা প্রক্রিয়া করা হয়, তবে সেই প্রোগ্রামটির ডেটা সম্পর্কে সম্পূর্ণ আলাদা বেসিক বোঝাপড়া থাকতে পারে। বলুন যে আপনার পয়েন্টার সহ সি ++ অবজেক্ট রয়েছে তবে আপনার লক্ষ্য ভাষাটি সেই স্তরের পয়েন্টারগুলিকে সমর্থনও করে না। আবার, আপনি দ্বিতীয় প্রোগ্রামটিতে সেই ডেটা সম্বোধনের কোনও পরিষ্কার উপায় ছাড়াই শেষ করেছেন। আপনি মেমরির কিছু বাইনারি ডেটা দিয়ে শেষ করেছেন, তবে তারপরে আপনাকে অতিরিক্ত কোড লিখতে হবে যা তথ্যকে ঘিরে রেখেছে এবং কোনওরকমভাবে এটি অনুবাদ করে যা আপনার টার্গেট ল্যাঙ্গুয়েজ দিয়ে কাজ করতে পারে। Deserialization এর মত শোনাচ্ছে, আপনার প্রারম্ভিক বিন্দুটি এখন আপনার প্রধান স্মৃতিতে ছড়িয়ে ছিটিয়ে থাকা অদ্ভুত জিনিস, এটি বিভিন্ন উত্স ভাষার জন্য আলাদা, পরিবর্তে একটি সংজ্ঞায়িত কাঠামোযুক্ত ফাইলের পরিবর্তে। একই জিনিসটি অবশ্যই, আপনি যদি বাইনারি ফাইলটিতে সরাসরি পয়েন্টারগুলির সাথে ব্যাখ্যা করার চেষ্টা করেন - আপনার প্রতিটি সম্ভাব্য উপায়ে পার্সার লিখতে হবে অন্য কোনও ভাষা মেমোরির মধ্যে ডেটা উপস্থাপন করতে পারে।

একজন মানুষের দ্বারা পঠনযোগ্যতা

ওয়েব ভিত্তিক সিরিয়ালাইজেশনের জন্য সর্বাধিক বিশিষ্ট দুটি আধুনিক সিরিয়ালাইজেশন ভাষা (এক্সএমএল, জসন) কোনও মানুষ সহজেই বোধগম্য হয়। গু'র বাইনারি স্তূপের পরিবর্তে, ডেটা পড়ার প্রোগ্রাম ছাড়াই তথ্যের প্রকৃত কাঠামো এবং বিষয়বস্তু স্পষ্ট। এর একাধিক সুবিধা রয়েছে:

• সহজ ডিবাগিং -> যদি আপনার পরিষেবা পাইপলাইনে কোনও সমস্যা হয় তবে আপনি কেবল একটি পরিষেবা থেকে বেরিয়ে আসা ডেটাটি দেখুন এবং এটি পরীক্ষা করে দেখুন (এটি প্রথম পদক্ষেপ হিসাবে); আপনি যখন প্রথমে আপনার রফতানি ইন্টারফেসটি লেখেন তখন ডেটা মনে হয় কিনা এমনটি আপনি সরাসরি দেখতে পাবেন।
• সংরক্ষণাগারযোগ্যতা: যদি আপনার বিশুদ্ধ বাইনারি গুড়ের গাদা হিসাবে আপনার ডেটা থাকে এবং আপনি যে প্রোগ্রামটি ব্যাখ্যা করতে চান তা আলগা করে, আপনি ডেটা আলগা করেন (বা সেখানে কিছু খুঁজে পাওয়ার জন্য আপনাকে বেশ কিছুটা সময় ব্যয় করতে হবে); যদি আপনার সিরিয়ালযুক্ত ডেটা মানুষের পাঠযোগ্য হয় তবে আপনি সহজেই এটি সংরক্ষণাগার হিসাবে ব্যবহার করতে পারেন বা নতুন প্রোগ্রামের জন্য আপনার নিজস্ব আমদানিকারক প্রোগ্রাম করতে পারেন
• এইভাবে সিরিয়ালযুক্ত ডেটাটির ঘোষণামূলক প্রকৃতি এর অর্থ এটিও কম্পিউটার সিস্টেম এবং এর হার্ডওয়্যার থেকে সম্পূর্ণ স্বতন্ত্র; আপনি একে একে সম্পূর্ণ ভিন্ন নির্মিত কোয়ান্টাম কম্পিউটারে লোড করতে পারেন বা বিকল্প তথ্য সহ একটি এলিয়েন এআই সংক্রামিত করতে পারেন যাতে এটি ঘটনাক্রমে পরবর্তী সূর্যের দিকে উড়ে যায় (এমেরিচ আপনি যদি এটি পড়েন তবে একটি রেফারেন্সটি চমৎকার হবে, আপনি যদি আগামী 4 জুলাই এই ধারণাটি ব্যবহার করেন তবে সিনেমা)

Comments

আমার ডেটা সম্ভবত বেশিরভাগ মূল স্মৃতিতে রয়েছে, নিবন্ধগুলিতে নয়। যদি আমার ডেটা নিবন্ধগুলিতে ফিট করে তবে সিরিয়ালাইজেশন সবেমাত্র একটি সমস্যা। আমি মনে করি আপনি একটি রেজিস্টার কী তা ভুল বুঝেছেন।

— ডেভিড রিচার্বি

প্রকৃতপক্ষে, আমি এখানে শব্দটি খুব lyিলে .ালাভাবে ব্যবহার করেছি। তবে মূল কথাটি হ'ল আপনার ডেটাতে নিজের উপাদানগুলি সনাক্ত করতে বা অন্যান্য ডেটা উল্লেখ করার জন্য ঠিকানা জায়গার পয়েন্টার থাকতে পারে। এটি কোনও শারীরিক নিবন্ধক বা মূল স্মৃতিতে ভার্চুয়াল ঠিকানা কিনা তা বিবেচ্য নয়।

— ফ্রাঙ্ক হপকিন্স

না, আপনি "নিবন্ধক" শব্দটি পুরোপুরি ভুলভাবে ব্যবহার করেছেন। আপনি যে বিষয়গুলিতে নিবন্ধগুলি কল করছেন সেগুলি প্রকৃত রেজিস্টরের মেমরি শ্রেণিবিন্যাসের সম্পূর্ণ আলাদা অংশে রয়েছে।

— ডেভিড রিচার্বি

Answer 6

অন্যান্য উত্তরগুলি যা বলেছে তা ছাড়াও:

কখনও কখনও আপনি এমন জিনিসগুলিকে সিরিয়াল করতে চান যা বিশুদ্ধ ডেটা নয়।

উদাহরণস্বরূপ, কোনও ফাইল হ্যান্ডেল বা কোনও সার্ভারের সংযোগের কথা চিন্তা করুন। ফাইল হ্যান্ডেল বা সকেট একটি intহলেও, পরের বার প্রোগ্রামটি চালানোর সময় এই সংখ্যাটি অর্থহীন। এই জাতীয় জিনিসগুলিতে হ্যান্ডলগুলি ধারণ করে এমন অবজেক্টগুলিকে সঠিকভাবে পুনরায় তৈরি করতে আপনার ফাইলগুলি আবার খুলতে হবে এবং সংযোগগুলি পুনরায় তৈরি করতে হবে এবং এটি ব্যর্থ হলে কী করতে হবে তা সিদ্ধান্ত নিতে হবে।

আজকাল অনেকগুলি ভাষা অবজেক্টগুলির মধ্যে বেনাম ফাংশনগুলি সংরক্ষণ করে, উদাহরণস্বরূপ onBlah()জাভাস্ক্রিপ্টে একটি হ্যান্ডলার সমর্থন করে। এটি চ্যালেঞ্জিং কারণ এই জাতীয় কোডটিতে অতিরিক্ত টুকরো ডেটার উল্লেখ থাকতে পারে যা ঘুরেফিরে সিরিয়ালাইজড করা দরকার। (এবং তারপরে ক্রস-প্ল্যাটফর্ম পদ্ধতিতে সিরিয়াল কোড দেওয়ার বিষয়টি রয়েছে, যা ব্যাখ্যা করা ভাষাগুলির পক্ষে স্পষ্টতই সহজ) অনেক সিরিয়ালাইজেশন ব্যবস্থা কোড সিরিয়াল করার চেষ্টা করে না, তবে সিরিয়ালাইজ-জাভাস্ক্রিপ্ট দেখুন ।

আপনি যখন কোনও অবজেক্টকে সিরিয়ালাইজ করতে চান তবে এটিতে এমন কিছু রয়েছে যা আপনার সিরিয়ালাইজেশন প্রক্রিয়া দ্বারা সমর্থিত নয়, আপনাকে কোডটি এমনভাবে লিখতে হবে যাতে এটি কাজ করে। উদাহরণস্বরূপ, সম্ভাব্য ফাংশনগুলির একটি সীমাবদ্ধ সংখ্যা থাকা অবস্থায় আপনি বেনামে ফাংশনের জায়গায় এনামগুলি ব্যবহার করতে পারেন।

প্রায়শই আপনি সিরিয়ালযুক্ত ডেটা সংশ্লেষিত হতে চান।

আপনি যদি নেটওয়ার্কের মাধ্যমে ডেটা প্রেরণ করছেন বা এটি ডিস্কেও সঞ্চয় করছেন তবে আকার ছোট রাখাই গুরুত্বপূর্ণ। এটি অর্জনের অন্যতম সহজ উপায় হ'ল পুনর্নির্মাণ করা তথ্যগুলি ফেলে দেওয়া (উদাহরণস্বরূপ, ক্যাশে, হ্যাশ টেবিলগুলি এবং একই ডেটার বিকল্প উপস্থাপনা উপেক্ষা)।

অবশ্যই, প্রোগ্রামারটিকে ম্যানুয়ালি নির্বাচন করতে হবে কোনটি সংরক্ষণ করতে হবে এবং কোনটি বাতিল করতে হবে, এবং নিশ্চিত করুন যে জিনিসটি পুনরায় তৈরি করার সময় জিনিসগুলি পুনরায় তৈরি করা হবে।

একটি খেলা সংরক্ষণের কাজ সম্পর্কে চিন্তা করুন। বস্তুগুলিতে গ্রাফিক্স ডেটা, শব্দ ডেটা এবং অন্যান্য অবজেক্টগুলিতে প্রচুর পয়েন্টার থাকতে পারে। তবে এই জিনিসগুলির বেশিরভাগটি গেমের ডেটা ফাইলগুলি থেকে লোড করা যায় এবং সেভ ফাইলে সংরক্ষণ করার দরকার নেই। এটি ছেড়ে দেওয়া শ্রমসাধ্য হতে পারে তাই ছোট ছোট জিনিসগুলি প্রায়শই রেখে দেওয়া হয় I've

কখনও কখনও স্থান গুরুত্বপূর্ণ নয় তবে পঠনযোগ্যতা হ'ল সেই ক্ষেত্রে আপনি পরিবর্তে একটি ASCII ফর্ম্যাট (সম্ভবত JSON বা XML) ব্যবহার করতে পারেন।

Answer 7

বাইটের ক্রম আসলে কী তা নির্ধারণ করি। বাইট একটা ক্রম একটি অ নেতিবাচক পূর্ণসংখ্যা নামক নিয়ে গঠিত দৈর্ঘ্য এবং কিছু নির্বিচারে ফাংশন / চিঠিপত্রের যে কোনো পূর্ণসংখ্যা মানচিত্র আমি যে অন্তত শূন্য এবং কম দৈর্ঘ্য একটি বাইট মান (255 0 থেকে একটি পূর্ণসংখ্যা) এর।

আপনি একটি সাধারণ প্রোগ্রামে যে জিনিসগুলি ব্যবহার করেন সেগুলির মধ্যে অনেকগুলি সেই ফর্মটিতে নেই, কারণ বস্তুগুলি আসলে বিভিন্ন বিভিন্ন মেমরির বরাদ্দ যা র‍্যামের বিভিন্ন স্থানে থাকে এবং মিলিয়ন মিলিয়ন বাইট স্টাফের মাধ্যমে আপনি পৃথক পৃথক হতে পারে each যত্ন নেই। কেবলমাত্র একটি প্রাথমিক লিঙ্কযুক্ত তালিকার কথা চিন্তা করুন: তালিকার প্রতিটি নোড বাইটের ক্রম, হ্যাঁ, তবে নোডগুলি আপনার কম্পিউটারের স্মৃতিতে বিভিন্ন স্থানে রয়েছে এবং সেগুলি পয়েন্টারের সাথে সংযুক্ত থাকে। অথবা কেবল একটি সাধারণ কাঠামোর কথা চিন্তা করুন যা ভেরিয়েবল-দৈর্ঘ্যের স্ট্রিংয়ের পয়েন্টার রয়েছে।

বাইটের ক্রমে আমরা ডাটা স্ট্রাকচারকে সিরিয়ালাইজ করতে চাইার কারণটি হ'ল সাধারণত আমরা সেগুলি ডিস্কে সঞ্চয় করতে বা কোনও অন্য সিস্টেমে (যেমন নেটওয়ার্কের মাধ্যমে) প্রেরণ করতে চাই। আপনি যদি ডিস্কে কোনও পয়েন্টার সঞ্চয় করার চেষ্টা করেন বা এটি অন্য কোনও সিস্টেমে প্রেরণ করেন তবে এটি বেশ বেহুদা হবে কারণ যে পয়েন্টারটি পড়ার প্রোগ্রামটিতে মেমরির ক্ষেত্রগুলির একটি আলাদা সেট উপলব্ধ থাকবে।

Comments

আমি নিশ্চিত নই যে এটি একটি অনুক্রমের দুর্দান্ত সংজ্ঞা a বেশিরভাগ মানুষ একটি সিক্যুয়েন্সকে ভাল, একটি সিকোয়েন্স হিসাবে সংজ্ঞা দেয়: একের পর এক জিনিসগুলির একটি লাইন line আপনার সংজ্ঞা অনুসারে, int seq(int i) { if (0 <= i < length) return i+1; else return -1;}এটি একটি ক্রম। সুতরাং আমি কীভাবে এটি ডিস্কে সঞ্চয় করতে যাচ্ছি?

— ডেভিড রিচার্বি

দৈর্ঘ্য যদি 4 হয় তবে আমি চার বাইট ফাইল সামগ্রী সহ সংরক্ষণ করব: 1, 2, 3, 4।

— ডেভিড গ্রেসন

@ ডেভিডরিচার্বি তাঁর সংজ্ঞাটি "একের পর এক জিনিসগুলির একটি লাইন" এর সমতুল্য, এটি আপনার স্বজ্ঞাত সংজ্ঞার চেয়ে আরও একটি গাণিতিক এবং সুনির্দিষ্ট সংজ্ঞা। নোট করুন যে আপনার ফাংশনটি কোনও ক্রম নয় কারণ আপনার ক্রমটি থাকতে হলে সেই ফাংশন এবং অন্য একটি পূর্ণসংখ্যা প্রয়োজন যা দৈর্ঘ্য বলে।

— ব্যবহারকারী 253751

@ ফ্রেশএয়ার আমার বক্তব্যটি ক্রমটি 1, 2, 3, 4, 5 হয় 5. আমি যে জিনিসটি লিখেছি তা একটি ফাংশন । একটি ফাংশন একটি ক্রম নয়।

— ডেভিড রিচার্বি

ডিস্কে ফাংশন লেখার একটি সহজ উপায় হ'ল আমি ইতিমধ্যে প্রস্তাব করেছি: প্রতিটি সম্ভাব্য ইনপুট জন্য, আউটপুট সংরক্ষণ করুন। আমি মনে করি সম্ভবত আপনি এখনও এটি পাবেন না তবে আমি কী বলব তা নিশ্চিত নই। আপনি কি জানেন যে এম্বেড থাকা সিস্টেমে ব্যয়বহুল ফাংশনগুলি যেমন লকউইচ sinটেবিলের মধ্যে রূপান্তর করা সাধারণ , যা সংখ্যার ক্রম? আপনি কী জানতেন যে আমাদের ফাংশনটি আমাদের যত্ন নেওয়া ইনপুটগুলির জন্য এটি একইরকম? int seq(n) { int a[] = [1, 2, 3, 4]; return a[n]; } আপনি কেন ঠিক বলেছেন যে আমার ফোর-বাইট ফাইলটি অপর্যাপ্ত উপস্থাপনা?

— ডেভিড গ্রেসন

Answer 8

জটিলতা ডেটা এবং বস্তুগুলির নিজস্ব জটিলতা প্রতিফলিত করে। এই বিষয়গুলি বাস্তব বিশ্বের বস্তু বা কম্পিউটার কেবলমাত্র বস্তু হতে পারে। উত্তরটি নামেই রয়েছে। সিরিয়ালাইজেশন হ'ল বহুমাত্রিক বস্তুর লিনিয়ার উপস্থাপনা। খণ্ডিত র‌্যাম ছাড়াও আরও অনেক ইস্যু রয়েছে।

আপনি যদি 12 টি মাত্রিক অ্যারে এবং কিছু প্রোগ্রাম কোড সমতল করতে পারেন তবে সিরিয়ালাইজেশন আপনাকে মেশিনগুলির মধ্যে একটি সম্পূর্ণ কম্পিউটার প্রোগ্রাম (এবং ডেটা) স্থানান্তর করতে দেয়। আরএমআই / সিওআরবিএর মতো বিতরণকারী কম্পিউটিং প্রোটোকলগুলি ডেটা এবং প্রোগ্রামগুলি স্থানান্তর করতে সিরিয়ালাইজেশনটি ব্যাপকভাবে ব্যবহার করে।

আপনার ফোনের বিলটি বিবেচনা করুন। এটি আপনার একক কল (স্ট্রিংগুলির তালিকা), প্রদানের পরিমাণ (পূর্ণসংখ্যার) এবং দেশকে সমন্বিত একক বস্তু হতে পারে। অথবা আপনার ফোনের বিলটি উপরের থেকে বাইরে থাকতে পারে এবং এতে আপনার নামের সাথে যুক্ত আলাদা আইটেমযুক্ত ফোন কল থাকতে পারে। প্রতিটি সমতলভাবে আলাদা দেখাবে, আপনার সফ্টওয়্যারটির সংস্করণটি কীভাবে আপনার ফোন সংস্থা লিখেছিল তা প্রতিফলিত করে এবং যে কারণে বস্তু ভিত্তিক ডাটাবেসগুলি কখনই বন্ধ করেনি reflect

কাঠামোর কিছু অংশ এমনকি স্মৃতিতে নাও থাকতে পারে। আপনার যদি অলস ক্যাচিং থাকে তবে কোনও অবজেক্টের কিছু অংশ কেবলমাত্র একটি ডিস্ক ফাইলে উল্লেখ করা যেতে পারে এবং কেবলমাত্র সেই নির্দিষ্ট বস্তুর অংশটি অ্যাক্সেস করার পরে লোড করা হয়। গুরুতর জেদী ফ্রেমওয়ার্কে এটি সাধারণ। BLOB একটি ভাল উদাহরণ। গেট্টি ইমেজগুলি ফিদেল কাস্ত্রোর একটি বিশাল মাল্টি মেগাবাইট ছবি এবং চিত্রটির নাম, ভাড়া ব্যয় এবং চিত্রটি নিজেই যেমন কিছু মেটা ডেটা সঞ্চয় করতে পারে। আপনি সম্ভবত 200 এমবি চিত্র মেমরির মধ্যে প্রতিবার লোড করতে চাইবেন না, যদি না আপনি আসলে তার দিকে না তাকান। সিরিয়ালযুক্ত, পুরো ফাইলটির 200MB এরও বেশি স্টোরেজ প্রয়োজন।

কিছু বস্তু এমনকি মোটেও সিরিয়ালাইজ করা যায় না। জাভা প্রোগ্রামিংয়ের দেশে আপনার গ্রাফিক্স স্ক্রিন বা একটি শারীরিক সিরিয়াল পোর্ট উপস্থাপন করে এমন একটি প্রোগ্রামিং অবজেক্ট থাকতে পারে। এগুলির দুটিই সিরিয়াল করার কোনও বাস্তব ধারণা নেই। আপনি কীভাবে আপনার পোর্টটিকে অন্য কোনও নেটওয়ার্কে প্রেরণ করবেন?

পাসওয়ার্ড / এনক্রিপশন কীগুলির মতো কিছু জিনিস সংরক্ষণ বা প্রেরণ করা উচিত নয়। এগুলি (উদ্বায়ী / ক্ষণস্থায়ী ইত্যাদি) হিসাবে ট্যাগ করা যায় এবং সিরিয়ালাইজেশন প্রক্রিয়া এগুলি এড়িয়ে যায় তবে তারা র‌্যামে থাকতে পারে। এই ট্যাগগুলি ছাড়াই হ'ল এনক্রিপশন কী কীভাবে অজান্তেই প্লেইন ASCII এ পাঠানো / সংরক্ষণ করা হয়।

এটি এবং অন্যান্য উত্তরগুলি কেন এটি জটিল।

Answer 9

আমার যে সমস্যাটি হচ্ছে তা হ'ল: কি সমস্ত ভেরিয়েবল (ইন্ট বা কমপোজেট অবজেক্টের মতো আদিম) ইতিমধ্যে বাইটের ক্রম দ্বারা উপস্থাপিত হয় না?

হ্যা তারা. এখানে সমস্যাটি সেই বাইটগুলির বিন্যাস the একটি সরল int2, 4 বা 8 বিট দীর্ঘ হতে পারে। এটি বড় বা ছোট এন্ডিয়ান হতে পারে। এটি স্বাক্ষরযুক্ত, 1 এর পরিপূরক বা এমনকি কিছু সুপার এক্সটিক বিট কোডিংয়ে নেগাবাইনারি এর মতো স্বাক্ষরিত হতে পারে।

যদি আপনি কেবল intমেমোরি থেকে বাইনারি ফেলে দেন এবং এটিকে "সিরিয়ালাইজড" বলে থাকেন, আপনাকে এটি ডিসরিয়ালাইজ করার জন্য বেশ কয়েকটি পুরো কম্পিউটার, অপারেটিং সিস্টেম এবং আপনার প্রোগ্রাম সংযুক্ত করতে হবে। বা কমপক্ষে, তাদের একটি সুনির্দিষ্ট বিবরণ।

সুতরাং সিরিয়ালাইজেশন এত গভীর বিষয় কি করে? একটি ভেরিয়েবল সিরিয়ালাইজ করতে, আমরা কি কেবল এই বাইটগুলি মেমরির মধ্যে নিতে পারি না এবং সেগুলি একটি ফাইলে লিখতে পারি না? আমি কোন জটিলতা মিস করেছি?

একটি সাধারণ অবজেক্টের সিরিয়ালাইজেশন কিছু নিয়ম অনুসারে এটিকে অনেক বেশি লিখে দেওয়া হয়। এই বিধিগুলি প্রচুর এবং সর্বদা সুস্পষ্ট নয়। উদাহরণস্বরূপ xs:integer, এক্সএমএল-এ বেস -10-এ লেখা হয়। বেস -16 নয়, বেস -9 নয়, তবে 10 নয় It's এটি কোনও গোপন অনুমান নয়, এটি একটি আসল নিয়ম। এবং এই জাতীয় নিয়ম সিরিয়ালকরণকে সিরিয়ালকরণ করে তোলে। কারণ, বেশ কিছু, মেমোরিতে আপনার প্রোগ্রামের বিট লেআউট সম্পর্কে কোনও নিয়ম নেই ।

এটি একটি আইসবার্গের কেবল একটি টিপ ছিল। আসুন সেই সহজতম আদিমগুলির একটি ক্রমের উদাহরণ নিই: একটি সি struct। আপনি এটা ভাবতে পারেন

struct {
short width;
short height;
long count;
}

প্রদত্ত কম্পিউটার + ওএস এ একটি সংজ্ঞায়িত মেমরি লেআউট আছে? ভাল, এটা না। বর্তমান #pragma packসেটিংয়ের উপর নির্ভর করে সংকলক ক্ষেত্রগুলিকে প্যাড করবে। 32-বিট সংকলনের ডিফল্ট সেটিংসে উভয়কে shorts4 বাইটে প্যাড করা structহবে যাতে মেমরিতে 4 বাইটের 3 টি ক্ষেত্র থাকবে actually সুতরাং এখন, আপনাকে কেবল এটি নির্দিষ্ট করতে হবে না যে shortএটি 16 বিট দীর্ঘ, এটি একটি পূর্ণসংখ্যা, 1 এর পরিপূরক নেগেটিভ, বড় বা সামান্য এন্ডিয়ানতে লেখা। আপনার প্রোগ্রামটি সংকলিত কাঠামোগত প্যাকিং সেটিংটিও লিখতে হবে।

সিরিয়ালাইজেশন যা হ'ল এটি অনেকটা: নিয়মের একটি সেট তৈরি করা এবং তাদের সাথে লেগে থাকা।

এরপরে এই বিধিগুলি আরও পরিশীলিত কাঠামো (যেমন পরিবর্তনশীল দৈর্ঘ্যের তালিকাগুলি বা ননলাইনার ডেটা) গ্রহণ করার জন্য বাড়ানো যেতে পারে, মানব পাঠযোগ্যতা, সংস্করণ, পশ্চাদপটে সামঞ্জস্যতা এবং ত্রুটি সংশোধন ইত্যাদির মতো বৈশিষ্ট্যগুলি যুক্ত করা হয়েছে intতবে আপনি যদি একটি মাত্র লিখতে চান তবে ইতিমধ্যে যথেষ্ট জটিল আপনি কেবল এটি নির্ভরযোগ্যতার সাথে পড়তে সক্ষম হবেন তা নিশ্চিত করতে চান।