عیب‌یابی · تا تاریخ 2026-10-13

Claude Code از ویرایش فایل‌های GBK خودداری می‌کند

تا تاریخ 2026-10-13، Edit و NotebookEdit در Claude Code کل فایل را دوباره به‌صورت UTF-8 ذخیره می‌کنند، و پیش از 2.1.296 هر بایتی که نمی‌توانستند رمزگشایی کنند با نویسه U+FFFD جایگزین می‌شد — همین بود که متن چینی و ژاپنی را در فایل‌های GBK، Shift-JIS یا Windows-1252 به داده‌های خراب تبدیل می‌کرد. از 2.1.296 به بعد (با تاریخ 9 اکتبر 2026 در تغییرات رسمی) چنین ویرایش‌هایی با پیام «File is not valid UTF-8» رد می‌شوند و هیچ چیز نوشته نمی‌شود. ترتیب امن: رمزگذاری را با فرمان عمومی file تأیید کنید، از فایل نسخه پشتیبان بگیرید و آن را با iconv تبدیل کنید، سپس بگذارید Claude Code دوباره ویرایش کند. شش صفحه مستندات Claude Code که این مقاله در 2026-10-13 به آن‌ها مراجعه کرده است — settings، troubleshooting، common-workflows، checkpointing، terminal-config و overview — هیچ تنظیمی را که رمزگذاری فایل را انتخاب کند فهرست نمی‌کنند.

به‌روزرسانی شده 2026-11-14

یک کلید برای Claude، GPT و مدل‌های پیشروی چینی، با صورت‌حساب به‌ازای توکن، آماده به کار در چند دقیقه.

#فایل در قالب UTF-8 معتبر نیست#2.1.296#دستور file -i#دستور iconv -f -t

چهار نکته که نخست باید روشن شود

2.1.296

نسخه‌ای که رد کردن از آن شروع می‌شود

این جمله در تغییرات رسمی زیر 2.1.296 آمده است، که تاریخ نسخه‌اش 9 اکتبر 2026 را نشان می‌دهد؛ همان جمله واژه‌به‌واژه در CHANGELOG.md در GitHub آمده است، جایی که سرفصل‌های نسخه هیچ تاریخی ندارند.

U+FFFD

نسخه‌های قدیمی‌تر چه می‌نوشتند

مرجع رسمی خطاها می‌گوید: پیش از v2.1.296، Edit و NotebookEdit چنین ویرایشی را اعمال می‌کردند و هر بایتی را که نمی‌توانستند رمزگشایی کنند به‌صورت U+FFFD ذخیره می‌کردند. این مرجع به هر کسی که هنوز روی نسخه قدیمی‌تر است می‌گوید Claude Code را به‌روزرسانی کند.

0 بایت

هزینه رد شدن یک ویرایش برای شما

به عبارت رسمی: Claude Code تغییر را رد کرد. چیزی نوشته نشد، بنابراین فایل همان‌گونه که بود باقی ماند. ویرایشی که رد شود، هر بایت فایل را دست‌نخورده باقی می‌گذارد.

دستور file -i

روش عمومی بررسی

صفحه راهنمای file(1) می‌گوید -i باعث می‌شود file رشته‌های نوع MIME را خروجی دهد (مثال آن text/plain; charset=us-ascii است) و --mime-encoding فقط همان بخش را چاپ می‌کند. این‌ها ابزارهای Unix هستند، نه گزینه‌های Claude Code.

چرا فایل‌ها خراب می‌شدند و چرا اکنون ویرایش‌ها رد می‌شوند

تا تاریخ 2026-10-13، مستندات رسمی به هر دو بخش پاسخ می‌دهند. مرجع ابزارها دلیل رد شدن را بیان می‌کند: ابزارها رد می‌کنند چون کل فایل را دوباره به‌صورت UTF-8 ذخیره می‌کنند، که هر بایتی را که نمی‌توانند رمزگشایی کنند با نویسه جایگزین U+FFFD عوض می‌کند. تغییرات می‌گوید پیش از 2.1.296، Edit و NotebookEdit هر نویسه non-ASCII را در فایل‌هایی که UTF-8 معتبر نیستند جایگزین می‌کردند، و مرجع خطاها می‌افزاید که آن‌ها هر بایتی را که نمی‌توانستند رمزگشایی کنند به‌صورت U+FFFD ذخیره می‌کردند، بنابراین یک ویرایش کافی بود تا فایلی GBK پر از نویسه‌های جایگزین شود. اکنون Edit و NotebookEdit رد می‌کنند و فایل را دست‌نخورده باقی می‌گذارند، و پیام سه رمزگذاری قدیمی را نام می‌برد: Windows-1252، Shift-JIS و GBK. به دامنه توجه کنید: مرجع خطاها می‌گوید بررسی، بایت‌های فایل را به‌طور کلی در بر می‌گیرد، بنابراین حتی فایلی که قرار است UTF-8 باشد نیز وقتی یک توالی بایت نامعتبر داشته باشد همان پیام را دریافت می‌کند.

جمله تغییرات به‌صورت واژه‌به‌واژه

مدخل تغییرات Claude Code برای 2.1.296 می‌گوید: رفع شد: Edit و NotebookEdit در فایل‌هایی که UTF-8 معتبر نیستند (Windows-1252، Shift-JIS، GBK) هر نویسه non-ASCII را جایگزین می‌کردند؛ چنین ویرایش‌هایی اکنون رد می‌شوند. این جمله در صفحه تغییرات code.claude.com و در CHANGELOG.md در GitHub یکسان است، و صفحه می‌گوید از همان فایل تولید می‌شود؛ فقط صفحه مستندات تاریخ نسخه 9 اکتبر 2026 را دارد. دو مدخل پیشین نیز اصلاح رمزگذاری هستند: 2.1.214 (18 ژوئیه 2026) مانع شد که > و >> در PowerShell 5.1 فایل‌های UTF-16LE بنویسند که ابزارهای دیگر نمی‌توانستند آن‌ها را به‌صورت UTF-8 بخوانند، و 2.1.267 (9 سپتامبر 2026) باعث شد انتشار artifact وقتی فایل UTF-8 معتبر نیست یا U+FFFD دارد، خط و ستون را نام ببرد.

سه مدخل تاریخ‌دار از صفحات رسمی

2026-07-18

Claude Code 2.1.214: مشکل نوشتن فایل‌های UTF-16LE توسط > و >> در Windows PowerShell 5.1 را که ابزارهای دیگر نمی‌توانستند آن‌ها را به‌صورت UTF-8 بخوانند، و مشکل از کار افتادن اسکریپت‌های Python با UnicodeDecodeError هنگام خواندن ورودی استاندارد non-UTF-8 را رفع می‌کند. مرجع ابزارها می‌گوید این رفتارهای رمزگذاری Windows به v2.1.214 یا بالاتر نیاز دارند.

2026-09-09

Claude Code 2.1.267: انتشار artifact از فایلی که UTF-8 معتبر نیست یا نویسه جایگزین U+FFFD را دارد، اکنون خط و ستون برای اصلاح را گزارش می‌کند. مرجع خطاها می‌افزاید که پیش از v2.1.267، Claude Code چنین فایلی را بدون بررسی بارگذاری می‌کرد و سرور انتشار را رد می‌کرد.

2026-10-09

Claude Code 2.1.296: Edit و NotebookEdit دیگر نویسه‌های non-ASCII را در فایل‌هایی که UTF-8 معتبر نیستند (Windows-1252، Shift-JIS، GBK) جایگزین نمی‌کنند و در عوض آن ویرایش‌ها را رد می‌کنند.

تأییدشده در برابر مستندنشده

تأییدشده (واژه‌به‌واژه در صفحات رسمی)

همه این موارد دقیقاً با همین عبارات در صفحه‌های رسمی‌ای آمده است که این مقاله در 2026-10-13 به آن‌ها مراجعه کرده است: جمله تغییرات نسخه 2.1.296 و تاریخ آن 9 اکتبر 2026؛ مرجع ابزارها که می‌گوید Claude نمی‌تواند از NotebookEdit روی فایلی که UTF-8 معتبر نیست استفاده کند. همین برای Edit هم صادق است، مگر اینکه فایل با byte-order mark از نوع UTF-16 little-endian آغاز شود. — استثنای byte-order mark فقط برای Edit نوشته شده است؛ اینکه امتناع، فایل را دست‌نخورده باقی می‌گذارد، و اینکه دلیل آن ذخیره دوباره کل فایل به‌صورت UTF-8 است؛ متن پیام مرجع خطاها و دو گزینه آن (اجازه دادن به Claude برای تغییر فایل با یک دستور shell که آن را با کدگذاری خودش می‌خواند و می‌نویسد، یا تبدیل به UTF-8 و ویرایش دوباره)؛ اینکه پیش از v2.1.296 بایت‌های غیرقابل‌رمزگشایی به‌صورت U+FFFD ذخیره می‌شدند؛ و اینکه Write هنوز می‌تواند چنین فایلی را جایگزین کند اما سپس آن را به‌صورت UTF-8 ذخیره می‌کند، بنابراین کدگذاری اصلی از دست می‌رود. در سمت ابزارهای عمومی: file(1) برای -i و --mime-encoding، iconv(1) برای -f و --from-code، -t و --to-code، -l، -c، //TRANSLIT و //IGNORE، و فهرست کدگذاری‌های GNU libiconv که شامل SHIFT_JIS، GBK و خانواده CP1252 است.

تأییدنشده و مستندنشده

سه چیز در هشت صفحه مستندات Claude Code که این مقاله در 2026-10-13 به آن‌ها مراجعه کرده است توصیف نشده — settings، troubleshooting، common-workflows، checkpointing، terminal-config، overview، errors و tools reference — پس برنامه‌ریزی خود را بر پایه آن‌ها قرار ندهید. نخست، هیچ‌یک از آن‌ها به شما اجازه انتخاب کدگذاری فایل را نمی‌دهد: فقط صفحه‌های مرجع خطاها و ابزارها به نحوه رمزگشایی فایل‌ها می‌پردازند و شش صفحه دیگر هیچ تنظیم کدگذاری‌ای فهرست نمی‌کنند. دوم، هیچ تنظیم یا گزینه‌ای در آن صفحه‌ها باعث نمی‌شود Edit فایل را به‌صورت GBK دوباره بنویسد. سوم، هیچ ابزاری ارائه نمی‌دهند که متنی را که پیش‌تر به U+FFFD تبدیل شده بازگرداند: در بخش artifact-publish، مرجع خطاها فقط می‌گوید فایل را دوباره به‌صورت UTF-8 ذخیره کنید و هر U+FFFD را با نویسه‌ای جایگزین کنید که ویرایش، چسباندن یا تبدیل قبلی از دست داده است. file(1) همچنین می‌گوید بخشی از منطق کدگذاری‌اش در encoding.c هاردکد شده است، پس حدس مجموعه‌نویسه آن یک نشانه است نه مدرک.

دو مسیر رسمی، دو نوع به‌هم‌ریختگی

حفظ کدگذاری در برابر تبدیل به UTF-8

مرجع خطاها دو مسیر می‌دهد: برای حفظ فایل در کدگذاری فعلی، اجازه دهید Claude تغییر را با یک دستور shell انجام دهد که فایل را با همان کدگذاری می‌خواند و می‌نویسد؛ برای ادامه ویرایش با ابزار Edit، آن را به UTF-8 تبدیل کنید، یا بایت‌های نامعتبر را در فایلی که قرار است UTF-8 باشد اصلاح کنید، سپس از Claude بخواهید ویرایش را دوباره انجام دهد. تنها مسیر دوم Edit و NotebookEdit را بازمی‌گرداند. برای مسیر اول، مرجع خطاها روش را نام می‌برد اما دستوری نمی‌دهد، و راه عمومی چیزی مانند iconv -f GBK -t UTF-8 است.

فایل خراب در برابر نمایش خراب

صفحه troubleshooting، مربع‌ها، لکه‌ها و نویسه‌های نادرست در ترمینال یکپارچه VS Code، Cursor یا Devin Desktop را به رندر GPU ترمینال نسبت می‌دهد و به شما می‌گوید /terminal-setup را اجرا کنید تا terminal.integrated.gpuAcceleration را روی off بگذارید، یا آن را در تنظیمات ویرایشگر تغییر دهید و پنجره را دوباره بارگذاری کنید؛ آنجا بایت‌ها دست‌نخورده‌اند. یک مشکل واقعی کدگذاری با پیام File is not valid UTF-8 نشان داده می‌شود و از 2.1.296 به بعد چیزی نوشته نمی‌شود. اگر متن از قبل نویسه‌های U+FFFD را داشته باشد، آن همان نویسه‌ای است که نسخه‌های پیش از 2.1.296 می‌نوشتند.

به این ترتیب پیش بروید

① کدگذاری را با دستورهای عمومی تأیید کنید. file(1) گزینه -i را مستند می‌کند (رشته‌های نوع MIME؛ نمونه‌اش text/plain; charset=us-ascii است) و --mime-encoding را فقط برای همان عنصر، و iconv -l نام کدگذاری‌هایی را که سیستم شما می‌شناسد فهرست می‌کند؛ این‌ها ابزارهای Unix هستند، نه گزینه‌های Claude Code. ② نسخه پشتیبان بگیرید، سپس تبدیل کنید. ابتدا از فایل اصلی کپی بگیرید، سپس iconv را با ذکر هر دو طرف اجرا کنید: خلاصه راهنما iconv [ options ] [ -f from-encoding ] [ -t to-encoding ] است و نمونه‌اش iconv -f ISO-8859-15 -t UTF-8 < input.txt > output.txt. راهنما همچنین می‌گوید نویسه‌های غیرقابل‌تبدیل باعث توقف iconv می‌شوند مگر اینکه -c را بدهید؛ //TRANSLIT آن‌ها را تقریب می‌زند و وقتی نتواند علامت سؤال چاپ می‌کند؛ و //IGNORE آن‌ها را دور می‌ریزد و پس از تبدیل خطا گزارش می‌کند؛ هر یک از این‌ها نویسه‌ها را از دست می‌دهد، پس نتیجه را بررسی کنید و اصل را نگه دارید. ③ سپس بگذارید Claude Code ویرایش کند. Claude Code را به 2.1.296 یا بالاتر به‌روزرسانی کنید (برای نسخه‌های قدیمی‌تر، مستندات فقط می‌گوید: Claude Code را به‌روزرسانی کنید). اگر فایل باید در کدگذاری خودش بماند، از پیام رسمی پیروی کنید و از Claude بخواهید از دستور shell استفاده کند که آن کدگذاری را می‌خواند و می‌نویسد؛ وقتی فایل UTF-8 شد، Edit دوباره کار می‌کند، در حالی که جایگزینی کامل با Write آن را به‌صورت UTF-8 ذخیره می‌کند و کدگذاری اصلی از دست می‌رود.

درباره QCode

بررسی کدگذاری داخل Claude Code روی دستگاه شما انجام می‌شود، بنابراین به این بستگی ندارد که از کدام نقطه پایانی استفاده می‌کنید. دو متغیر Claude Code را به QCode متصل می‌کنند: ANTHROPIC_BASE_URL که روی https://api.qcode.cc/api تنظیم می‌شود و ANTHROPIC_AUTH_TOKEN که روی کلید cr_ از داشبورد تنظیم می‌شود؛ راهنمای تنظیم ANTHROPIC_BASE_URL در qcode.cc اضافه می‌کند که مقدار اسلش انتهایی ندارد و مدل‌های Claude فقط از طریق نقطه پایانی Anthropic ارائه می‌شوند. از 2026-10-13، claude-sonnet-5-5، claude-haiku-4-5-20251001 و claude-opus-5-5 در QCode در دسترس هستند. صورت‌حساب به‌ازای هر توکن است؛ نرخ هر مدل در /models فهرست شده است.

پرسش‌های متداول

چرا Claude Code فایل GBK من را به داده‌های خراب تبدیل کرد و چرا اکنون ویرایش را رد می‌کند؟

زیرا Edit و NotebookEdit کل فایل را دوباره به‌صورت UTF-8 ذخیره می‌کنند. مرجع ابزارها دلیل رد شدن را بیان می‌کند: این ابزارها ویرایش را رد می‌کنند زیرا کل فایل را دوباره به‌صورت UTF-8 ذخیره می‌کنند، کاری که هر بایتی را که نتوانند کدگشایی کنند با نویسه جایگزین U+FFFD عوض می‌کند. پیش از 2.1.296 دقیقاً همین جایگزینی رخ می‌داد، بنابراین یک ویرایش فایل GBK یا Shift-JIS را از نویسه‌های جایگزین پر می‌کرد. از 2.1.296 به بعد آن ویرایش‌ها رد می‌شوند: تغییرات می‌گوید Edit و NotebookEdit اصلاح شدند تا دیگر هر نویسه غیر ASCII را در فایل‌هایی که UTF-8 معتبر نیستند (Windows-1252، Shift-JIS، GBK) جایگزین نکنند؛ چنین ویرایش‌هایی اکنون رد می‌شوند، و مرجع خطا می‌افزاید که چیزی نوشته نشد، بنابراین فایل همان‌طور که بود باقی می‌ماند. نحوه نمایش نویسه‌ها روی صفحه به ویرایشگر شما بستگی دارد؛ نویسه‌ای که مستندات نام می‌برد U+FFFD است.

چگونه تأیید کنم که یک فایل واقعاً از چه کدگذاری‌ای استفاده می‌کند؟

از فرمان عمومی file استفاده کنید. دفترچه راهنمای file(1) می‌گوید -i باعث می‌شود فرمان file به‌جای رشته‌های سنتی‌ترِ قابل خواندن برای انسان، رشته‌های نوع MIME را خروجی دهد؛ مثال آن text/plain; charset=us-ascii است، و این‌که --mime-type و --mime-encoding فقط عنصر مشخص‌شده را چاپ می‌کنند. پاسخ را نشانه‌ای تلقی کنید: file متن را بر اساس بازه‌ها و توالی‌های بایت طبقه‌بندی می‌کند، و دفترچه راهنما اشاره می‌کند که بخشی از منطق کدگذاری در encoding.c سخت‌کد شده است، بنابراین با تبدیل به‌وسیله iconv و خواندن دوباره متن تأیید کنید. شش صفحه مستندات Claude Code که این مقاله در 2026-10-13 به آن‌ها مراجعه کرد (settings، troubleshooting، common-workflows، checkpointing، terminal-config و overview) هیچ فرمانی را که کدگذاری یک فایل را چاپ یا تنظیم کند ذکر نمی‌کنند.

چگونه به UTF-8 تبدیل کنم و آیا ابتدا باید پشتیبان تهیه کنم؟

اول پشتیبان تهیه کنید، دوم تبدیل کنید، سوم مقایسه کنید. خلاصه دستور iconv(1) به این صورت است: iconv [ options ] [ -f from-encoding ] [ -t to-encoding ]؛ -f کدگذاری نویسه‌های ورودی و -t کدگذاری خروجی را نام می‌برد، و مثال خود دفترچه راهنما iconv -f ISO-8859-15 -t UTF-8 < input.txt > output.txt است، بنابراین برای یک فایل GBK از -f GBK استفاده می‌شود. آنچه دفترچه راهنما درباره خطاها می‌گوید را به یاد داشته باشید: نویسه‌های غیرقابل تبدیل اجرا را متوقف می‌کنند مگر این‌که -c را بدهید؛ //TRANSLIT آن‌ها را تقریب می‌زند و وقتی نتواند، علامت سؤال چاپ می‌کند؛ و //IGNORE آن‌ها را پس از تبدیل با یک خطا دور می‌ریزد. همه این‌ها نویسه‌ها را از دست می‌دهند، بنابراین نسخه کپی را نگه دارید و بخش‌های چینی یا ژاپنی را بررسی کنید. این‌ها کاربردهای استاندارد ابزارهای Unix هستند، نه پارامترهای Claude Code.

آیا برای Shift-JIS ژاپنی و Windows-1252 غربی هم همین‌طور است؟

همان قاعده، همان مجموعه. جمله مربوط به 2.1.296، Windows-1252 و Shift-JIS و GBK را با هم نام می‌برد؛ مرجع خطا همان سه مورد را نام می‌برد، و مرجع ابزارها Windows-1252 و Shift-JIS را مثال می‌آورد. معیار بررسی این است که آیا بایت‌های فایل به‌طور کامل به‌صورت UTF-8 کدگشایی می‌شوند یا نه؛ بنابراین فایلی که باید UTF-8 باشد، وقتی حتی یک توالی بایت نامعتبر داشته باشد، همان پیام را فعال می‌کند. برای تبدیل، از نام‌های فهرست کدگذاری GNU libiconv استفاده کنید که شامل SHIFT_JIS، CP932، GBK، CP936، GB18030، BIG5 و خانواده CP1250 تا CP1257 است، و UTF-8 را به‌عنوان مقصد قرار دهید.

چگونه Claude Code را از طریق QCode متصل کنم، و نرخ‌ها کجا هستند؟

دو متغیر. آموزش Claude Code در QCode این‌ها را می‌دهد: export ANTHROPIC_BASE_URL = https://api.qcode.cc/api و export ANTHROPIC_AUTH_TOKEN = cr_ و سپس کلید شما، و جدول نقاط پایانی در مستندات QCode همان مقدار https://api.qcode.cc/api را به Claude Code می‌دهد؛ راهنمای تنظیم ANTHROPIC_BASE_URL در qcode.cc اضافه می‌کند که Base URL اسلش انتهایی ندارد و مدل‌های Claude فقط به نقطه پایانی Anthropic می‌روند. از 2026-10-13، claude-sonnet-5-5، claude-haiku-4-5-20251001 و claude-opus-5-5 در QCode در دسترس هستند. صورت‌حساب به‌ازای هر توکن است؛ نرخ هر مدل در /models فهرست شده است.

چگونه از چین پرداخت کنم و شروع به کار کنم؟

Alipay و WeChat Pay هر دو کار می‌کنند. صفحه روش‌های پرداخت QCode در صفحه شارژ حساب، این موارد را فهرست می‌کند: Alipay، WeChat Pay، کارت اعتباری / نقدی (Visa / Mastercard)، Apple Pay / Google Pay و ارز دیجیتال (بسیاری از ارزها و شبکه‌ها، با تطبیق دستی انتقال درون‌زنجیره‌ای)؛ صورت‌حساب پیش‌پرداخت است — ابتدا حساب را شارژ می‌کنید، سپس پلنی می‌خرید که از موجودی کم می‌کند. همان صفحه محدودیت‌هایی را که نمایش می‌دهد ذکر می‌کند: شارژ حساب با CNY از ¥30 شروع می‌شود و شارژ حساب با USD از $5 تا $2,000 است. پس از ثبت‌نام، یک کلید cr_ در داشبورد ایجاد کنید و Claude Code را به آن متصل کنید.

منابع

تغییرات Claude Code (صفحه تغییرات code.claude.com و CHANGELOG.md در GitHub) و صفحات مستندات رسمی Error reference، Tools reference، Troubleshooting، Settings، Terminal configuration، Overview، Common workflows و Checkpointing، همگی در تاریخ 2026-10-13 بررسی شده‌اند؛ برای ابزارهای عمومی، صفحات راهنمای file(1) و iconv(1) در man7.org و مستندات GNU libiconv نیز در تاریخ 2026-10-13؛ برای QCode، صفحات docs.qcode.cc درباره نقاط پایانی و مسیرهای API، آموزش Claude Code و روش‌های پرداخت، به‌علاوه راهنماهای داخل سایت درباره استفاده از Claude Code در چین، نصب یک‌کلیکی و راه‌اندازی ANTHROPIC_BASE_URL، همگی در تاریخ 2026-10-13 بررسی شده‌اند.

یک کلید cr_، Claude Code متصل

ANTHROPIC_BASE_URL را روی https://api.qcode.cc/api و ANTHROPIC_AUTH_TOKEN را همان‌طور که مستندات QCode توضیح می‌دهد تنظیم کنید، claude-sonnet-5-5 و سایر مدل‌های Claude را اجرا کنید؛ صورت‌حساب به‌ازای هر توکن است و نرخ‌های هر مدل در /models فهرست شده‌اند.

مطالب مرتبط

راهنمای پرداخت با رمزارز

نه رمزارز، 56 شبکه، کارمزد پلتفرم صفر برای اعتبار API کدنویسی با هوش مصنوعی.

نقل‌قول‌ها و مراحل این صفحه در تاریخ 2026-10-13 با تغییرات و مستندات Claude Code، صفحات راهنمای file(1) و iconv(1)، مستندات GNU libiconv و مستندات QCode بررسی شده‌اند؛ صفحات رسمی بدون اطلاع قبلی تغییر می‌کنند، بنابراین ملاک، صفحات رسمی است. file و iconv ابزارهای عمومی Unix هستند: این صفحه استفاده مستندشده آن‌ها را نشان می‌دهد، نه گزینه‌های Claude Code. دسترس‌پذیری مدل‌ها همان چیزی است که /models نشان می‌دهد.

مطمئن نیستید از کجا شروع کنید؟

یک هفته امتحان کنید

بسته کوچک: $4 برای $30 سهمیه، به مدت 7 روز معتبر

هر روز از آن استفاده کنید

Starter: $9.00/ماه با $5 سهمیه در هر روز — فقط $0.060 به‌ازای هر $1 سهمیه، در برابر حدود $0.113 برای بسته متوسط