דילוג לתוכן
  • חוקי הפורום
  • פופולרי
  • לא נפתר
  • משתמשים
  • חיפוש גוגל בפורום
  • צור קשר
עיצובים
  • בהיר
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • כהה
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • ברירת מחדל (ללא עיצוב (ברירת מחדל))
  • ללא עיצוב (ברירת מחדל)
כיווץ
מתמחים טופ
  1. דף הבית
  2. סלולרי
  3. שונות וטיפים - סלולרי
  4. בירור | ייבוא אנשי קשר לנוקיה 225 (תומך כשר) - פתרון של קלוד

בירור | ייבוא אנשי קשר לנוקיה 225 (תומך כשר) - פתרון של קלוד

מתוזמן נעוץ נעול הועבר שונות וטיפים - סלולרי
5 פוסטים 2 כותבים 44 צפיות 3 עוקבים
  • מהישן לחדש
  • מהחדש לישן
  • הכי הרבה הצבעות
תגובה
  • תגובה כנושא
התחברו כדי לפרסם תגובה
נושא זה נמחק. רק משתמשים עם הרשאות מתאימות יוכלו לצפות בו.
  • א מנותק
    א מנותק
    אפרון
    כתב נערך לאחרונה על ידי
    #1

    רקע:
    לפני כשנה הלך לי מכשיר הטלפון, הצלחתי לחלץ ממנו את אנשי הקשר והם קיימים אצלי בקובץ vcf וגם בcsv.

    כיום יש לי מכשיר נוקיה 225 תומך כשר, ובכל הדרכים שניסיתי לייבא אליו את אנשי הקשר לא הצלחתי (תוכנות ייעודיות לא מזהות את המכשיר. אין לחצן "ייבוא אנשי קשר", וכשאני רוצה לפתוח את הקובץ דרך המכשיר הוא כותב לי "סוג קובץ אינו נתמך")

    ביקשתי מקלוד להציע לי פתרון, והוא הציע לי להשתמש ב"יצירת גיבוי" ו"שחזור גיבוי". לדבריו אם אני אייצא לו את קובץ הגיבוי הוא יוכל ליצור קובץ זהה (כדי שהמכשיר יזהה אותו) ולהוסיף בתוכו את כל אנשי הקשר הישנים שלי, אני אחליף את הקובץ האמיתי של המכשיר בקובץ שהוא ייצור לי, וכך כשהמכשיר "ישחזר גיבוי" הוא יכניס את כל אנשי הקשר שלי.

    אשמח לשמוע את חוות דעתכם, האם זה בסיכון גבוה/לא מומלץ/מומלץ, והאם ומה אני מפספס

    כמובן שאשמור לעצמי עותק של הגיבוי האמיתי כדי שלא אאבד את המידע במקרה שהוא ידפוק את העסק

    תודה רבה

    א תגובה 1 תגובה אחרונה
    1
    • א אפרון העביר נושא זה מ-סלולרי
    • א אפרון

      רקע:
      לפני כשנה הלך לי מכשיר הטלפון, הצלחתי לחלץ ממנו את אנשי הקשר והם קיימים אצלי בקובץ vcf וגם בcsv.

      כיום יש לי מכשיר נוקיה 225 תומך כשר, ובכל הדרכים שניסיתי לייבא אליו את אנשי הקשר לא הצלחתי (תוכנות ייעודיות לא מזהות את המכשיר. אין לחצן "ייבוא אנשי קשר", וכשאני רוצה לפתוח את הקובץ דרך המכשיר הוא כותב לי "סוג קובץ אינו נתמך")

      ביקשתי מקלוד להציע לי פתרון, והוא הציע לי להשתמש ב"יצירת גיבוי" ו"שחזור גיבוי". לדבריו אם אני אייצא לו את קובץ הגיבוי הוא יוכל ליצור קובץ זהה (כדי שהמכשיר יזהה אותו) ולהוסיף בתוכו את כל אנשי הקשר הישנים שלי, אני אחליף את הקובץ האמיתי של המכשיר בקובץ שהוא ייצור לי, וכך כשהמכשיר "ישחזר גיבוי" הוא יכניס את כל אנשי הקשר שלי.

      אשמח לשמוע את חוות דעתכם, האם זה בסיכון גבוה/לא מומלץ/מומלץ, והאם ומה אני מפספס

      כמובן שאשמור לעצמי עותק של הגיבוי האמיתי כדי שלא אאבד את המידע במקרה שהוא ידפוק את העסק

      תודה רבה

      א מנותק
      א מנותק
      אפרון
      כתב נערך לאחרונה על ידי אפרון
      #2

      לאחר שלא קיבלתי תגובה כאן פניתי לג'מיני

      הוא ממש מתנגד: (האם ייתכן שיש ביניהם סכסוכי עבר אז הוא "מלכלך עליו"? 😉 )

      "התשובה הקצרה היא שמדובר בפתרון בסיכון גבוה מאוד, וברוב המוחלט של המקרים הוא פשוט לא יעבוד.

      להלן פירוט של הדברים שפספסת, ההסבר הטכני מדוע זה מסוכן או צפוי להיכשל, וחלופות בטוחות יותר.

      מה פספסת ולמה השיטה של עריכת קובץ גיבוי בעייתית?
      מבנה קבצים סגור ומוצפן/חתום: מכשירים כדוגמת הנוקיה 225 (המבוססים לרוב על מערכות הפעלה קנייניות כמו Mocor או ThreadX) מייצרים קבצי גיבוי מוצפנים, מקודדים, או כאלו שעוברים בדיקת שלמות (Checksum / Digital Signature). אם משנים אפילו בת אחת בתוך קובץ כזה דרך כלי חיצוני, המכשיר יזהה שהקובץ פגום או שאינו אותנטי ויסרב לשחזר אותו לחלוטין.

      מורכבות מבנה הנתונים: קובצי גיבוי של מכשירים פשוטים אינם טקסט פשוט כמו CSV או VCF, אלא בסיסי נתונים בינאריים סגורים. בינה מלאכותית עלולה לנחש מבנה או לייצר קובץ שנראה דומה חיצונית, אך בפועל יגרום לקריסת יישום אנשי הקשר במכשיר.

      סיכון ל"בריק" (Brick) או איפוס: במקרה הגרוע, טעינת קובץ גיבוי פגום או שונה עלולה לשבש את מערכת ההפעלה של המכשיר ולדרוש איפוס קשיח (Factory Reset), מה שיגרום לאובדן כל מה שקיים במכשיר כיום."

      מכיוון שאני לחלוטין לא מהתחום אין לי שמץ של מושג האם הוא קישקש לי בשכל, או מעלה טענות הגיוניות, אשמח אם מישהו שמבין בזה יוכל לתת לי חוות דעת... (ג'מיני ממש בטוח בעצמו...)

      א תגובה 1 תגובה אחרונה
      1
      • א אפרון

        לאחר שלא קיבלתי תגובה כאן פניתי לג'מיני

        הוא ממש מתנגד: (האם ייתכן שיש ביניהם סכסוכי עבר אז הוא "מלכלך עליו"? 😉 )

        "התשובה הקצרה היא שמדובר בפתרון בסיכון גבוה מאוד, וברוב המוחלט של המקרים הוא פשוט לא יעבוד.

        להלן פירוט של הדברים שפספסת, ההסבר הטכני מדוע זה מסוכן או צפוי להיכשל, וחלופות בטוחות יותר.

        מה פספסת ולמה השיטה של עריכת קובץ גיבוי בעייתית?
        מבנה קבצים סגור ומוצפן/חתום: מכשירים כדוגמת הנוקיה 225 (המבוססים לרוב על מערכות הפעלה קנייניות כמו Mocor או ThreadX) מייצרים קבצי גיבוי מוצפנים, מקודדים, או כאלו שעוברים בדיקת שלמות (Checksum / Digital Signature). אם משנים אפילו בת אחת בתוך קובץ כזה דרך כלי חיצוני, המכשיר יזהה שהקובץ פגום או שאינו אותנטי ויסרב לשחזר אותו לחלוטין.

        מורכבות מבנה הנתונים: קובצי גיבוי של מכשירים פשוטים אינם טקסט פשוט כמו CSV או VCF, אלא בסיסי נתונים בינאריים סגורים. בינה מלאכותית עלולה לנחש מבנה או לייצר קובץ שנראה דומה חיצונית, אך בפועל יגרום לקריסת יישום אנשי הקשר במכשיר.

        סיכון ל"בריק" (Brick) או איפוס: במקרה הגרוע, טעינת קובץ גיבוי פגום או שונה עלולה לשבש את מערכת ההפעלה של המכשיר ולדרוש איפוס קשיח (Factory Reset), מה שיגרום לאובדן כל מה שקיים במכשיר כיום."

        מכיוון שאני לחלוטין לא מהתחום אין לי שמץ של מושג האם הוא קישקש לי בשכל, או מעלה טענות הגיוניות, אשמח אם מישהו שמבין בזה יוכל לתת לי חוות דעת... (ג'מיני ממש בטוח בעצמו...)

        א מנותק
        א מנותק
        אפרון
        כתב נערך לאחרונה על ידי
        #3

        תשובתו של קלוד:
        תשובה כנה: ג'מיני צודק בעיקרון הכללי (זה קוד לא רשמי, יש סיכון), אבל חלק מהטענות הספציפיות שלו לא מתאימות למה שראיתי בפועל בקובץ שלך. בואו נפרק את זה:

        "קובץ מוצפן/חתום עם checksum" — זה לא תואם את מה שמצאתי. פיצחתי את כל 201 הרשומות בקובץ האמיתי שלך וקראתי מהן שמות בעברית תקינים ומספרי טלפון נכונים. אם הקובץ היה מוצפן, זה פשוט לא היה אפשרי — הייתי מקבל רעש אקראי, לא טקסט קריא. מיפיתי כל בית לא-אפס בכמה רשומות שונות, ולא מצאתי שום שדה נוסף שמשתנה בהתאם לתוכן (כלומר checksum) — כל בית מוסבר: שדות קבועים, ID, אורך+טלפון בקידוד BCD, אורך+שם ב-UTF-16. זו לא ניחוש — זו פענוח אמפירי מול הקובץ האמיתי שלך, עם אימות round-trip אוטומטי.

        "בינה מלאכותית עלולה לנחש מבנה" — בדיוק בגלל זה לא ניחשתי. לא בניתי את זה מול "פורמט Nokia כללי" מהאינטרנט — בניתי את זה מול הבייטים בפועל בקובץ ששלחת, ואימתתי שהפענוח־קידוד־פענוח חוזר בדיוק לאותם ערכים, כולל מקרי קצה (שמות ארוכים, אימוג'י, מספרים קצרים).

        מה שנכון וחשוב בטענה שלו — הסיכון האמיתי:
        אין לי גישה למכשיר פיזי, אז אין לי דרך לבדוק בפועל מה קורה כשלוחצים "Restore". זה החלק שבאמת לא יכול להבטיח. שתי אפשרויות שלא שללתי לגמרי:

        יכול להיות אימות נוסף שאני לא רואה בקובץ עצמו (למשל התאמה מול ibphone_head.in, שלא נגעתי בו).
        אם קוד הפענוח במכשיר לא עושה בדיקות גבולות (bounds checking) על שדות כמו אורך השם, זה תיאורטית יכול לגרום להתנהגות לא צפויה — לא סביר שזה "יקריס את מערכת ההפעלה" (זו טבלת רשומות שטוחה בגודל קבוע, בלי מצביעים לקוד או לזיכרון אחר), אבל אי אפשר להבטיח 0%.

        ההמלצה המעשית שלי, שמכבדת את שני הצדדים של הסיכון:

        This is general information, not medical advice. If your symptoms are severe, sudden, or don’t improve, talk to a healthcare professional.
        בדיקה זהירה — קודם רשומה אחת
        מוסיפים רק 1-2 אנשי קשר חדשים (לא אמיתיים) ומשחזרים. אם זה עובד והמכשיר עובד רגיל, יודעים שההנדסה נכונה לפני שמוסיפים את כל הרשימה.
        מוסיפים 1-2 שורות בדויות עם שם מזוהה (למשל: TEST1)
        משחזרים ובודקים שהמכשיר עובד ושאנשי הקשר הישנים עדיין שם
        רק אחרי הצלחה מאומתת מוסיפים את כל הרשימה המלאה
        חזרה לדרך הידנית
        מוותרים על השיטה האוטומטית ומקלידים איש איש דרך התפריט הרגיל של המכשיר (או בדיקה נוספת שם עצמם הפעם), אם הסיכון של שיטה לא-רשמית מרגיש לכם יותר מדי.
        מזינים 5-10 אנשי קשר בעת
        מעבירים דרך SIM או קורא כרטיסים במחשב
        אין סיכון לבאגים בקובץ הגיבוי, רק איטי ואיטי

        שני הדברים חשובים לזכור בכל מקרה:

        *יש לכם כבר עותק של ה-phonebook.ib וה-ibphone_head.in המקוריים (העלית אותם אליי) — אז אם שחזור לא עובד, הדרך חזרה היא פשוט להחזיר את הקבצים המקוריים לתיקייה ולשחזר אותם שוב. זה לא מצב שבו "המידע הקיים אבד" — רק שהחדש לא נכנס.

        ולגבי "בריק"/איפוס יצרן: התרחיש הזה קורה בדרך כלל כשמשבשים קובץ קושחה או מערכת (bootloader, partition table וכו') — לא קובץ אנשי קשר של אפליקציה בודדת. הסיכוי שקובץ אנשי קשר לא תקין יפיל את כל מערכת ההפעלה הוא נמוך, אבל בלי בדיקה בפועל על המכשיר אני לא יכול להבטיח 0%. הבדיקה עם רשומה בודדת (אופציה 1 למעלה) היא בדיוק הדרך לצמצם את זה לסיכון כמעט אפסי.*

        א תגובה 1 תגובה אחרונה
        1
        • א אפרון

          תשובתו של קלוד:
          תשובה כנה: ג'מיני צודק בעיקרון הכללי (זה קוד לא רשמי, יש סיכון), אבל חלק מהטענות הספציפיות שלו לא מתאימות למה שראיתי בפועל בקובץ שלך. בואו נפרק את זה:

          "קובץ מוצפן/חתום עם checksum" — זה לא תואם את מה שמצאתי. פיצחתי את כל 201 הרשומות בקובץ האמיתי שלך וקראתי מהן שמות בעברית תקינים ומספרי טלפון נכונים. אם הקובץ היה מוצפן, זה פשוט לא היה אפשרי — הייתי מקבל רעש אקראי, לא טקסט קריא. מיפיתי כל בית לא-אפס בכמה רשומות שונות, ולא מצאתי שום שדה נוסף שמשתנה בהתאם לתוכן (כלומר checksum) — כל בית מוסבר: שדות קבועים, ID, אורך+טלפון בקידוד BCD, אורך+שם ב-UTF-16. זו לא ניחוש — זו פענוח אמפירי מול הקובץ האמיתי שלך, עם אימות round-trip אוטומטי.

          "בינה מלאכותית עלולה לנחש מבנה" — בדיוק בגלל זה לא ניחשתי. לא בניתי את זה מול "פורמט Nokia כללי" מהאינטרנט — בניתי את זה מול הבייטים בפועל בקובץ ששלחת, ואימתתי שהפענוח־קידוד־פענוח חוזר בדיוק לאותם ערכים, כולל מקרי קצה (שמות ארוכים, אימוג'י, מספרים קצרים).

          מה שנכון וחשוב בטענה שלו — הסיכון האמיתי:
          אין לי גישה למכשיר פיזי, אז אין לי דרך לבדוק בפועל מה קורה כשלוחצים "Restore". זה החלק שבאמת לא יכול להבטיח. שתי אפשרויות שלא שללתי לגמרי:

          יכול להיות אימות נוסף שאני לא רואה בקובץ עצמו (למשל התאמה מול ibphone_head.in, שלא נגעתי בו).
          אם קוד הפענוח במכשיר לא עושה בדיקות גבולות (bounds checking) על שדות כמו אורך השם, זה תיאורטית יכול לגרום להתנהגות לא צפויה — לא סביר שזה "יקריס את מערכת ההפעלה" (זו טבלת רשומות שטוחה בגודל קבוע, בלי מצביעים לקוד או לזיכרון אחר), אבל אי אפשר להבטיח 0%.

          ההמלצה המעשית שלי, שמכבדת את שני הצדדים של הסיכון:

          This is general information, not medical advice. If your symptoms are severe, sudden, or don’t improve, talk to a healthcare professional.
          בדיקה זהירה — קודם רשומה אחת
          מוסיפים רק 1-2 אנשי קשר חדשים (לא אמיתיים) ומשחזרים. אם זה עובד והמכשיר עובד רגיל, יודעים שההנדסה נכונה לפני שמוסיפים את כל הרשימה.
          מוסיפים 1-2 שורות בדויות עם שם מזוהה (למשל: TEST1)
          משחזרים ובודקים שהמכשיר עובד ושאנשי הקשר הישנים עדיין שם
          רק אחרי הצלחה מאומתת מוסיפים את כל הרשימה המלאה
          חזרה לדרך הידנית
          מוותרים על השיטה האוטומטית ומקלידים איש איש דרך התפריט הרגיל של המכשיר (או בדיקה נוספת שם עצמם הפעם), אם הסיכון של שיטה לא-רשמית מרגיש לכם יותר מדי.
          מזינים 5-10 אנשי קשר בעת
          מעבירים דרך SIM או קורא כרטיסים במחשב
          אין סיכון לבאגים בקובץ הגיבוי, רק איטי ואיטי

          שני הדברים חשובים לזכור בכל מקרה:

          *יש לכם כבר עותק של ה-phonebook.ib וה-ibphone_head.in המקוריים (העלית אותם אליי) — אז אם שחזור לא עובד, הדרך חזרה היא פשוט להחזיר את הקבצים המקוריים לתיקייה ולשחזר אותם שוב. זה לא מצב שבו "המידע הקיים אבד" — רק שהחדש לא נכנס.

          ולגבי "בריק"/איפוס יצרן: התרחיש הזה קורה בדרך כלל כשמשבשים קובץ קושחה או מערכת (bootloader, partition table וכו') — לא קובץ אנשי קשר של אפליקציה בודדת. הסיכוי שקובץ אנשי קשר לא תקין יפיל את כל מערכת ההפעלה הוא נמוך, אבל בלי בדיקה בפועל על המכשיר אני לא יכול להבטיח 0%. הבדיקה עם רשומה בודדת (אופציה 1 למעלה) היא בדיוק הדרך לצמצם את זה לסיכון כמעט אפסי.*

          א מנותק
          א מנותק
          אפרון
          כתב נערך לאחרונה על ידי
          #4

          ועכשיו לשורה התחתונה:
          לאחר ניסויים רבים בהם קלוד נכשל שוב ושוב הוא הרים ידיים:
          "בדקתי את הקובץ הזה לעומק — הוא תקין ב-100% מכל בדיקה שיש לי: שדה גודל התוכן נכון (117008=568×206 בדיוק), הרשומות החדשות זהות במבנה שלהן לרשומות אמיתיות שהמכשיר יצר בעצמו (השוויתי בית-אחר-בית), כל ה-ID-ים ייחודיים, כל השמות והטלפונים מפוענחים נכון, שום פגם.

          זה אומר משהו חשוב: הגעתי לגבול של מה שאפשר לגלות מבחינה חיצונית. אם קובץ שתואם באופן מושלם לכל דפוס שראיתי בקבצים אמיתיים עדיין נדחה — הסיכוי הגובר הוא שהמכשיר לא בודק רק את תוכן הקובץ עצמו, אלא משווה אותו למשהו שהוא שומר בזיכרון הפנימי שלו (למשל hash של הקובץ בזמן שהוא יצר את הגיבוי המקורי) — משהו שאין לי דרך לראות או לשחזר מבחוץ, כי הוא לא נמצא באף אחד משני הקבצים שיש לי גישה אליהם.

          בכנות: המשך ניחוש עיוור על הפורמט הבינארי כנראה לא יוביל לפריצת דרך נוספת מכאן. זה הזמן לשקול ברצינות לזנוח את השיטה הזו."

          למרות שאשמח לקבל פתרונות חלופיים, אני מניח שכיוון שאין זה תואם לכותרת האשכול אשמח אם מי שיש לו פתרון יוכל לפנות אלי באישי או לפתוח אשכול חדש בנושא
          תודה על הדיון הפורה
          גמח"ט

          נ תגובה 1 תגובה אחרונה
          😥
          1
          • א אפרון

            ועכשיו לשורה התחתונה:
            לאחר ניסויים רבים בהם קלוד נכשל שוב ושוב הוא הרים ידיים:
            "בדקתי את הקובץ הזה לעומק — הוא תקין ב-100% מכל בדיקה שיש לי: שדה גודל התוכן נכון (117008=568×206 בדיוק), הרשומות החדשות זהות במבנה שלהן לרשומות אמיתיות שהמכשיר יצר בעצמו (השוויתי בית-אחר-בית), כל ה-ID-ים ייחודיים, כל השמות והטלפונים מפוענחים נכון, שום פגם.

            זה אומר משהו חשוב: הגעתי לגבול של מה שאפשר לגלות מבחינה חיצונית. אם קובץ שתואם באופן מושלם לכל דפוס שראיתי בקבצים אמיתיים עדיין נדחה — הסיכוי הגובר הוא שהמכשיר לא בודק רק את תוכן הקובץ עצמו, אלא משווה אותו למשהו שהוא שומר בזיכרון הפנימי שלו (למשל hash של הקובץ בזמן שהוא יצר את הגיבוי המקורי) — משהו שאין לי דרך לראות או לשחזר מבחוץ, כי הוא לא נמצא באף אחד משני הקבצים שיש לי גישה אליהם.

            בכנות: המשך ניחוש עיוור על הפורמט הבינארי כנראה לא יוביל לפריצת דרך נוספת מכאן. זה הזמן לשקול ברצינות לזנוח את השיטה הזו."

            למרות שאשמח לקבל פתרונות חלופיים, אני מניח שכיוון שאין זה תואם לכותרת האשכול אשמח אם מי שיש לו פתרון יוכל לפנות אלי באישי או לפתוח אשכול חדש בנושא
            תודה על הדיון הפורה
            גמח"ט

            נ מנותק
            נ מנותק
            נתן מרדכי שלום
            כתב נערך לאחרונה על ידי
            #5

            @אפרון פעם אחרת עדיף שתתיעץ עם המומחים כאן, הם עשו את זה אלפי פעמים...
            בגדול הפתרון הוא לייבא את הקובץ לאנשי קשר של גוגל, ולאחמ"כ לייצא לקובץ VCF, שנתמך בנוקיה 225

            תגובה 1 תגובה אחרונה
            0

            שלום! נראה שהשיחה הזו מעניינת אותך, אבל עדיין אין לך חשבון.

            נמאס לכם לגלול בין אותם הפוסטים בכל ביקור? כשנרשמים לחשבון, תמיד תחזרו בדיוק למקום שבו הייתם קודם, ותוכלו לבחור לקבל התראות על תגובות חדשות (בין אם במייל, ובין אם בהתראת פוש). תוכלו גם לשמור סימניות ולפרגן ב-upvote לפוסטים כדי להביע הערכה לחברי קהילה אחרים.

            בעזרת התרומה שלך, הפוסט הזה יכול להיות אפילו טוב יותר 💗

            הרשמה התחברות

            • התחברות

            • אין לך חשבון עדיין? הרשמה

            • התחברו או הירשמו כדי לחפש.
            • פוסט ראשון
              פוסט אחרון
            0
            • חוקי הפורום
            • פופולרי
            • לא נפתר
            • משתמשים
            • חיפוש גוגל בפורום
            • צור קשר