این مقاله/پست درباره string خیلی جاله،‌ من قبلا درباره فرق unicode با utf-8 خونده بودم، اما اینجا بیشتر درباره تاریخشون فهمیدم،

زمانی که ascii معرفی شد کلا برای حروف انگلیسی ساخته شده بود، و البته یکسری از کاراکتر‌ها و دستورات دیگه.
مثلا برای اسپیس کد 32 و مثلا برای حرف A از کد 65 داخلش استفاده میشد.
ولی کد‌های قبل 32 چی؟ اون‌ها برای دستورات استفاده میشه مثلا کد 7 برای صدای beep هست!

حالا تمامی این کاراکتر‌ها کلا توی 7 بیت قرار می‌گیرن و بیشتر نیاز ندارن.
مثلا اگه حرف z رو درنظر بگیریم، کد اسکیش میشه 122
و باینری 122 میشه 1111010 و همینطور که می‌بینید، با فقط هفت بیت حروف انگلیسی، اعداد، سیمبل‌ها و دستورات رو می‌تونم داشته باشیم،
اما کامپیوتر ها با هشت بیت کار می‌کنند، پس پیاده سازی ascii که داخل کامپیوتر یک بیت اضافه‌ای به ما میده!(آخرین بیت سمت چپ) پس از کد 128 تا 255 برای هیچکاری استفاده نمیشه داخل تیبل ascii

اینجاست که شرکت‌ها و برنامه نویس ها تصمیم می‌گیرن اون بیت آخر رو برای کار های خودشون استفاده کنند.
همچنین هر زبانی مثلا یونانی از برای خودش یه کد پیج داشته
مثلا توی بعضی از سیستم عامل ها از کد 130 برای کاراکتر é استفاده میشده، و یه ورژن دیگه‌ای از همون سیستم عامل(DOS) از این کد برای کاراکتر ג استفاده میشده.
اینم باید بگم که همه قبول کردن که تمامی کد های زیر 128 دست نخورده بمونه خوشبختانه.
اینکه کدهای بالای 128 نماینده چه کاراکتری باشه بستگی داره به اینکه از چه code page استفاده می‌کردن. مثلا code page 862 در اسرائیل استفاده میشده و 737 در یونان.
حالا سیستم عامل DOS از کلی کد پیج ساپورت می‌کرده، ولی همزمان نمیشده توی یک فایل تکست از دو زبان استفاده کنی.


حالا عجیب‌تر اینکه این سسیتم توی زبان هایی مثل چینی بدرد نمی‌خوره، چون خب از 'حرف' استفاده نمی‌کنند و کاراکترهاشون نماده و هزاران کاراکتر دارند،
پس توی 8 بیت جا نمی‌شن. خب اینا چیکار کردن؟ از چیزی به اسم DBCS استفاده کردن این یعنی double bytes character set
درواقع برای پیاده‌سازی زبان چینی باید تعداد بایت ها رو دو برابر می‌کردن،
این خودش یه مشکلی داره، اینکه تایپ یک کاراکتر ساده‌ست(حرکت رو به جلو) اما اگه بخای به عقب برگردی، این یه چالشه، چون نمی‌دونی کاراکتری که تایپ کردی یک بایتی بوده یا دو بایتی.
تا اینجا انچنان مشکلی نداشتیم، اما وقتی پای اینترنت به کامپیوتر‌ها باز شد، دیگه اینجا بود متن‌ها توی سیستم‌های مختلف به خوبی کار نمی‌کردند. و unicode اختراع شد.

به صورت خلاصه unicode به ازای هر کاراکتری یک کد داره، که بهش میگن code point، یونیکد طوری ساخته شده که حتی اگه در آینده‌هم کاراکتری و یا زبانی اختراع بشه، با unicode میشه یک کد منحصر بفرد بهش داد.
مثلا برای کاراکتر A از کد U0041 استفاده میشه،
و یا برای مثال U+0048 U+0065 U+006C U+006C U+006F. میشه Hello.
این کد‌ها هگزا دسیمال هستند.


اوکی حالا سوال اینجاست که ما برای هرکاراکتری یک کد در نظر گرفتیم، اوکی خب چطوری روی هارد قراره ذخیره‌ش کنیم؟
در حالت اول و خب خیلی ساده میشه اکثر کد ها رو داخل 16 بیت دخیره کرد، اما دو مشکل وجود داره:
اول اینکه فضای بیشتری برای ذخیره می‌گیره،
دوم اینکه خب اینهمه تکست که از قبل نوشته شده، یکی باید همه اونها رو تبدیل کنه.
یا شاید یه بتونیم الگوریتم backward comaptible ایجاد کنیم.

اینجاست که جادوی utf-8 که یک encondig هست میاد وسط،
توی utf-8 از 0 تا 127 توی همون 8 بیت ذخیره می‌شه
و چیزی که به فضای بیشتری نیاز داره چی؟
وقتی کاراکتری بیشتر از 127 (یعنی نیاز به بیش از 7 بیت) نیاز داشته باشه، UTF-8 از چند بایت استفاده می‌کنه:
بایت اول یه "الگو" داره که نشون می‌ده این کاراکتر چند بایتیه، و بایت‌های بعدی با 10xxxxxx شروع می‌شن.
اینطوری کامپیوتر می‌فهمه این یه کاراکتر چندبایتیه و چطوری باید رمزگشایی‌ش کنه.


> این متن رو از اینجا هم می‌تونید بخونید.

رادیو رو اپدیت کردم،‌ تنها یه فیچر بدرد بخور بهش اضافه کردم که بشه آهنگی که داره پلی میشه رو دانلود کرد.
و خب چون هدفم از این سایت این بود که خیلی ساده باشه، دکمه دانلود رو توی منو کناریش گذاشتم که صفحه‌ش شلوغ نشه.

یه چیزی داریم به اسم zip bomb مثلا فایل zip.42 که کلا 42 کیلوبایت هست اما وقتی اکسترکت بشه حجمش به 4.5 پتابایت می‌رسه. ولی چطوری؟
باید بدونیم الگوریتم های زیپ مثل DEFLATE چطوری کار می‌کنند.

الگوریتم های زیب وقتی میخان یه چیزی رو زیپ کنند، داده های تکراری رو حذف می‌کنند،
حالا فرض کنید که این داده‌های تکراری دقیقا کل فایل باشه،
مثلا فایلی با سایز 4.5 پتابایت فقط پر شده از 0
حالا اگه این فایل زیپ بشه چقدر میشه حجمش؟

یه جدولی داخل فایل های زیپ هست به اسم dictionary
این جدول به یک داده‌ی تکراری پوینت می‌کنه
مثلا بجای اینکه چهار ترابایت 0 رو نگه‌داره
به هر جایی که قراره 0 باشه اشاره می‌کنه،

اما به این سادگی نیست، چرا؟ چون اصلا منطقی نیست داخل جدول یه کاراکتر بذاری و بعد داخل دیتا به این کاراکتر اشاره کنی، اینطوری حجم خود فایل بیشتر هم میشه.
پس این الگوریتم چطوری کار می‌کنه؟

میاد و با مجموعه‌ای/توالی از داده‌های تکراری کار می‌کنه.
مثلا وقتی یک توالی داده مثل 00001111 داشته باشیم، الگوریتم همه این رو یکجایی ذخیره می‌کنه و هرجایی که دقیقا همین دیتا تکرار شده باشه،‌ یه پوینتر می‌ذاره.

حالا ما یه محدودیتی داریم، اینکه ما داریم می‌گیم 4.5 پتابایت داده‌های تکراری 0 قراره کنار هم باشن
خب این بازم منطقی نیست که بیای و توی دیکشنری همه این 0 ها رو بذاری و بگی اینا یکجا تکرار شده
و یا اینکه بگی ما یه 0 داریم و بقیه فایل همش از این 0 ساخته شده!

الگوریتم میاد و هر 258 بایت که متوالی تکرار شدن رو داخل جدول می‌ذاره
بعد می‌بینه که خب 258 بایت بعدی هم که همونه! پس یه اشاره‌گر(پوینتر) می‌ذاره کنار اشاره‌گر قبلی، و بعد دوباره همین روند رو باید برای 4.5 پتابایت دیتا انجام بده!
اینطوری به اندازه چند ترابایت ما پوینتر درست کردیم :))

پس zip bomb چطوری درست شد؟
خیلی ساده یکبار یک فایل زیپ مثلا 1 گیگ ساخته شد، بعد این فایل چند بار دیگه کپی شد و اون کپی ها زیپ شدن
این روند اینقدر ادامه پیدا می‌کنه تا یه فایل زیپ داشته باشیم که کلی فایل زیپ دیگه داخلش باشه(recursive)
وقتی برنامه‌ای بخاد فایل رو اکسترکت کنه،‌ هر فایل زیپ دیگه‌ای هم داخل باشه اکسترکت می‌کنه.



من یه امتحانی کردم، با dd یک فایل 10 گیگ ساختم که همه از 0 پر شده بود.
بعد با الگوریتم lzma زیپ کردم، فایل نهایی شد 100 مگابایت.

dd if=/dev/zero of=./data bs=100M count=100
tar --lzma -cvf data.lzma.tar ./data

همینکار رو مجدد تکرار کردم اما بجای استفاده از 0 از دیتای رندوم استفاده کردم،‌ فایل زیپ هیچ تغییری نکرد.

dd if=/dev/random of=./data bs=100M count=100
tar --lzma -cvf data.lzma.tar ./data

موج تغییرات مسکن از ۲۳ خرداد (تحلیل پلتفرم دیوار):

https://divarrealstatesinthesedays.netlify.app

از 23 خرداد تا الان اتفاقات زیادی افتاده، تو چند روز اخیر تعداد آگهی‌های منتشر شده و فروش مسکن به شدت زیاد شده، اینجا می‌تونید یه کم روی نمودار این تحلیل ها رو بررسی کنید، هنوز جای کار داره خیلی ولی خب برای فعلا...

یکی از جذاب‌ترین کارهایی بود که امتحانش کرده بودم، اگه نظری دارین خوشحال میشم بگین.
حقیقتا فهمیدن آمار و اعداد و نمایش اون ها به شیوه درست کار بسی سخت ولی سودمندی هست.

(فعلا حالت سمپل دیتا که بیش از ۴۰۰۰ تا آگهی هستن رو Scrape می‌کنه و تحلیلش رو نشون میده روی Sample data کلیک کنید و بعد آنالیز، بعدا حالت آپلود فایل هم قرار می‌دم که اتومات و بروز تر بشه)

18 npm Packages Compromised in Major Supply-Chain Attack!

read at my blog: https://neox1de.com/blog/18-npm-packages-hacked/

یه سرویس برای systemd درست کرده بودم که سه کار رو باید همزمان انجام می‌داد.
برای مثال

while true; do
sleep 3 &
sleep 5 &
sleep 9 &
done

اتفاقی که افتاد این بود که وقتی این کد ران می‌شد، همون تایم systemd می‌گفت برنامه کارش تموم شد و سرویس exit می‌شد.
بعد از چند روز فهمیدم که مشکل دقیقا همون & آخر هر دستور هست، اینکه برنامه بره توی بکگراند رو نیاز داشتم،
سه دستور هر کدومشون یه loop بینهایت بودن ولی systemd فکر می‌کرد کارشون تموم شده.
متوجه شدم که یک دستوری داریم به اسم wait
باعث میشه که هیچی exit نشه تا آخرین پروسه‌های تو بکگراند کارشون تموم بشه. توی مورد من هیچوقت تموم نمی‌شد.

این TUIOS خیلی جالب بود،
توی ترمینال می‌تونی یکسری window هایی درست کنی و روی هر کدوم یکسری کامند خاص ران کنی،
شبیه i3 هست ولی کلا توی ترمیناله.

https://github.com/Gaurav-Gosain/tuios

یکی از اقداماتی که برای سرویس‌های پروداکشن لازمه ‌Replication هست.
اگر فرض کنیم شما یک API نوشتین که از دیتابیس استفاده می‌کنه، برای اینکه سرویس API سریع تر بشه و خب bottleneck(گلوگاه) رو حذف کنیم،
ما سرویس‌ api رو روی چند سرور اجرا می‌کنیم، اینطوری با یک load balancer جلوی api، می‌تونیم ترافیک رو تقسیم کنیم بین سرویس‌ها.
اما خب خود دیتابیس می‌تونه bottleneck باشه. راهکار چیه؟ اینکه بتونیم بر اساس نیازمندی پروژه یکی از انواع HA کردن‌ها رو برای دیتابیس انتخاب کنیم.
توی این پست دیتابیس Postgresql رو باهم HA می‌کنیم.

من ابزار‌های ترمینالی رو ترجیح می‌دم به کار کردن با GUI. توی این پست چند ابزار برای مدیریت کردن سرور‌های ssh رو معرفی کردم ولی در آخر sshs که از همه برام جذاب‌تر هست رو معرفی کردم و یکم توضیح دادم که چطور من ازش استفاده می‌کنم.


https://wiregeek.ir/p/%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%DA%A9%D8%A7%D9%86%DA%A9%D8%B4%D9%86-ssh/

https://github.com/besoeasy/file-drop


این یه ابزار خیلی جالبه که امروز بهش برخوردم.
با این ابزار شما فایل‌هاتون رو با IPFS از طریق سیستم خودتون شیر می‌کنید،
پشت NAT که باشین بازم کار می‌کنه،
فقط باید حتما انلاین بمونید و یا یک نود دیگه‌ای دیتا رو کامل دانلود کرده باشه و seed بشه.
به هرحال ابزار‌‌های p2p خیلی جذابن.