JSON בDelphi: פרסר זרם מהיר עם System.JSON + מכשולים ב־UTF-8 עבור תווים מיוחדים

„JSON in Delphi“ נשמע כמו בעיה פתורה: System.JSON כבר מובנה, REST-Calls מחזירים טקסט — סיימנו. בפועל, השגיאות האמיתיות נוצרות דווקא כאשר JSON אינו זמין כמחרוזת נוחה אלא כזרם: HTTP-Response-Stream, זרם קבצים (Datei-Stream), Named Pipe, Message-Queue או BLOB גדול מתוך מסד הנתונים. אז מתמזגים שלושה היבטים שלרוב מוערכים פחות בשגרה: התנהגות בזיכרון, קידוד תווים (במיוחד UTF-8) ומקרי קצה סביב תווים מיוחדים.

המאמר הזה מציג גישה נקייה ומהירה לניתוח JSON מתוך TStream בלי יצירת העתקות מיותרות — ובמיוחד בלי מלכודות ה-UTF-8 הטיפוסיות שבהן תווים מיוחדים (לדוגמה Umlaute) „נשברים“ או שבהן הפרסר נופל לסירוגין עם הודעות מסתוריות. המוקד הוא ההשפעה על תפעול ויציבות ממשקים: יכולת דיבוג שחוזרת על עצמה, גבולות ברורים של השיטה וקריטריונים מתי ההשקעה באמת מצדיקת את עצמה.

Warum Streams beim JSON-Parsing in Delphi anders ticken

כל עוד מסמך JSON קטן, הדרך „לקרוא את ה-Stream למחרוזת, ואז לפרסר“ נוחה. מעבר לגודל payload מסוים (טיפית: רשימות גדולות, דוחות, נתוני סנכרון, ייצוא לוגים) זה כבר נהיה יקר מבחינת משאבים:

• Speicher-Duplikate: אתה קורא בייטים לבופר, ממיר למחרוזת Unicode (Delphi-String = UTF-16), והפרסר מייצר מבנים פנימיים נוספים. זה יכול להוביל לכמה העתקות חד־פעמיות בזיכרון.
• GC/Heap-Druck: מחרוזות זמניות רבות וערכי JSON זמניים מגדילים שפיצוח וזמני הקצאה, במיוחד בתהליכים ארוכי־ריצה (Services, Worker, Import-Jobs).
• Fehlerbild wird unklar: אם כבר בעת הקריאה ננקטות הנחות שגויות לגבי הקידוד, הפרסר של JSON יראה רק „תווים מוזרים“ או בתים שליטה בלתי צפויים.

חשוב להפריד בצורה ברורה: JSON הוא פורמלית Unicode, על הקו הוא כמעט תמיד UTF-8. Delphi עובד פנימית עם UTF-16. המעבר מבייטים (Stream) לתווים (String) הוא הנקודה שבה מתעוררות בעיות בתווים מיוחדים — לא בתוך ה-JSON עצמו.

System.JSON: Was es gut kann – und wo du aufpassen musst

System.JSON הוא ב-Delphi הסטנדרט ל-JSON מבוסס DOM: אתה מקבל מודל עצמים (TJSONObject, TJSONArray), יכול לשאול ערכים, לאיטרציה, לסדר סיריאליזציה. זה יציב לאינטגרציות עסקיות טיפוסיות, אך יש לכך שתי התוצאות:

• Es ist kein echter Streaming-Parser: מודל העצמים נבנה במלואו. ייתכן שתחסוך את קריאת המידע למחרוזת נפרדת, אבל ה-DOM נשאר תובעני לזיכרון.
• Die Parser-Eingabe ist in der Regel Text: בהתאם לגרסת Delphi וה-API הנבחר, מהר מאוד מוצאים את עצמך שוב בעבודה עם String, כולל המרת קידוד.

אם המטרה שלך היא „פרסר זרם מהיר“, בפועל בדרך כלל כוונתך לאחד משני דברים: (1) הימנעות מהעתקות מיותרות ו-(2) כישלון מוקדם ככל האפשר כאשר המטען פגום (fail-fast). את שניהם ניתן להשיג עם System.JSON — בתנאי שתשלט בשלב ההמרה מבייט לטקסט.

UTF-8-Fallstricke bei Sonderzeichen: die typischen Ursachen

אם Umlaute (ä/ö/ü/ß) או תווים מיוחדים אחרים בתוצאה נראים שגויים (ä, – וכו׳), זה כמעט תמיד חוסר התאמת קידוד (Encoding-Mismatch). בתחום Delphi הסיבות האלה נפוצות במיוחד:

1) ANSI-Fallback durch „bequeme“ Helper

כמה נתיבי קריאה מניחים בשתיקה את קידוד ה‑System‑ANSI (Codepage של Windows-המערכת) אם לא נמסרת הקצבה מפורשת. זה בולט רק כאשר ה‑Payload אינו מכיל רק ASCII. בנתוני בדיקה זה לעיתים קרובות „בסדר“ במקרה, אבל בפרודקשן זה מתנקם כשמדובר בשמות אמיתיים, מקומות או טקסט חופשי.

2) BOM-Verwirrung (Byte Order Mark)

UTF-8 יכול להתחיל עם BOM (בתים EF BB BF). בהקשר Web ה‑BOM יחסית לא שגרתי, אבל בקבצים זה קורה. חלק מה‑Reader מזהים BOM ומתאימים את הקידוד, אחרים לא או רק במצבים מסוימים. אם BOM נכנס למחרוזת כתו רגיל, לעתים תראה תו בלתי נראה מסוג „Zero Width No-Break Space“ בהתחלה או שה־JSON‑Parser ייכשל מיד על הטוקן הראשון.

3) Doppel-Konvertierung (UTF-8 wird „nochmal“ interpretiert)

התופעה הקלאסית — הופעת תו שגוי כמו „ä“ במקום „ä“ — מתרחשת כאשר בתים של UTF-8 מפוענחים תחילה כהלכה ל‑Unicode, אך בהמשך מפוענחים שוב בטעות כבתים ANSI/UTF-8 (או ההיפך). ב־Delphi זה קורה לעתים קרובות כשיש חוסר בהירות במעברים בין TBytes, RawByteString ו־string.

4) Trunkierung mitten in einem Multibyte-Zeichen

UTF-8 מקודד תווים מיוחדים ב‑2–4 בתים. אם אתה קורא ב‑Chunks (למשל 8 KB) והגבול בין החתיכות נופל באמצע תו, הדקודר חייב לבצע אחסון ביניים נקי. גישה נאיבית שמשנה כל Chunk למחרוזת בנפרד ואז מדביקה אותן יוצרת רצפים לא תקניים. זה יכול להיראות כשגיאה ספוראדית, תלוי בגבולות חבילות, בהתנהגות פרוקסי או ב‑HTTP‑Chunking.

5) Falsche Annahmen aus HTTP-Headern

ב־REST המקור לעיתים קרובות מוצג כ־Content-Type: application/json; charset=utf-8. עם זאת, חלק מהשרתים אינם שולחים charset וחלק שולחים ערכים שגויים. אם אתה סומך בעיוורון על ההדר, זה עשוי להשתנות לפי גרסת ה‑Backend. עבור תפעול ותמיכה זה מועיל לבדוק את זרם הבתים בפועל ולרשום לוג במקרי שגיאה.

Ein sauberer Ansatz: Stream → UTF-8-Decoder → JSON-Parser

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

1. Bytes aus dem Stream lesen (בשליטה, במידת הצורך עם Limit/Timeout ב־HTTP‑Client).
2. Decoding nach Unicode עם UTF-8 מפורש (קבלת BOM כאפשרות).
3. Parsing עם System.JSON לתוך מודל אובייקטים או להוצאת נתונים ממוקדת.

המנוף החשוב ביותר הוא שלב 2: אינך רוצה שמערכת ה“Default Encoding“ תחליט במקום. ב‑Delphi המשמעות היא: TEncoding.UTF8 explizit setzen ולא להסתמך על המרות מרומזות.

Was „schnell“ hier konkret bedeutet

עם System.JSON לא תבצע אופטימיזציה שמסירה את DOM. אבל תוכל להימנע מ־:

• עותק נוסף של כל ה‑Payload כמחרוזת ביניים, אם פנימית אתה בכל מקרה צריך רק כמה ערכים (אז עדיף פרסר אחר; על כך מאוחר יותר),
• קידוד חוזר מרובה,
• וגם תוכל לקרוא Payloads גדולים מאוד בבקרה (עם גבול גודל והודעת שגיאה נקייה), במקום להסתיים ב‑Out-of-Memory או ב‑Access Violations.

מקרה קצה קונקרטי: תווים מיוחדים שבורים, אך רק לפעמים

מקרה מגבול מהניסיון שיכול להיות ערמומי במיוחד: ה‑Payload הוא ביסודו JSON תקין ב־UTF-8, אבל אתה קורא אותו בChunks וממירה כל Chunk למחרוזת. כל עוד מופיע רק ASCII, אינך מבחין בשום בעיה. ברגע שאות מסוג Umlaut נמצא בדיוק על גבול ה‑Chunk, נוצרים רצפים לא תקינים של UTF-8. התוצאה: או תווים משובשים או שגיאת פרסינג במקום שונה מהתוכן האמיתי.

כיצד תזהה זאת:

• שגיאות פרסינג מופיעות „באופן אקראי“ בתשובות גדולות, לא בקטנות.
• אותו Request מצליח לפעמים ונכשל לפעמים (תלוי ב‑Chunking/Transport).
• דמפ־הקס של הבייטים מראה UTF-8 תקין, אך המחרוזת שנרשמה בלוג מכילה Replacement Characters (�) או Mojibake קלאסי.

הפתרון אינו להשתמש ב“יותר readln“ או „גדולים יותר Buffer“, אלא בדקודר שמטפל כראוי ברצפי מולטיבייט ומאחסן אותם בזכרון חוצץ מעבר לגבולות ה‑Chunk. זו בדיוק הנקודה שבה TStreamReader בשילוב עם קידוד UTF-8 יכול להיות מועיל — בתנאי שתאתחל אותו נכון.

מדריך מעשי: כיצד לבדוק באופן לשחזור את UTF-8 ב־Delphi

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

1) Die ersten Bytes prüfen (BOM, JSON-Start)

אם ה‑JSON מגיע עם BOM, תראה בתחילת הזרם EF BB BF. מיד לאחר מכן אמור בדרך כלל להופיע „{“ או „[„. אם כבר מופיע „“ במחרוזת, ה‑BOM טופל לא כ‑BOM אלא כטקסט מפוענח.

2) Rohbytes in Hex loggen – aber begrenzt

אל תרשום Payloads שלמות בפרודקשן (פרטיות, עלויות, נפח לוג). הוכח כמועיל:

• Prefix (למשל, 256 או 1024 הבתים הראשונים),
• Suffix (256 הבתים האחרונים),
• ו‑Hash (SHA-256) לקורלציה, אם אתה צריך להשוות Payloads.

כך תוכל לרוב לאבחן בעיות בתווים מיוחדים בתוך דקות: האם רצף הבייטים עבור „ä“ נכון (C3 A4)? האם יש חיתוך? האם מופיע 0x00 בלתי צפוי (Nullbyte), למשל עקב הנחה שגויה של UTF-16?

3) Content-Type und Charset mitloggen

ב‑HTTP/REST: תעד את Content-Type ואת ה‑charset המוצהר. אם הבתים ברורים כ‑UTF-8, אבל ה‑charset מצהיר משהו אחר, אל תיענה בעיוורון ל‑charset בצד הלקוח. עבור JSON, UTF-8 הוא הסטנדרט דה‑פקטו. במקרה של ספק: ניתוח הבתים גובר על ההדר.

מנתח זרם מהיר עם System.JSON: תכנון ללא העתקות מיותרות

דפוס מעשי הוא: אתה קורא מה‑Stream לתא‑בייטים, בונה ממנו מחרוזת פעם אחת בלבד ב‑UTF-8, ומעביר את המחרוזת ל‑JSON‑Parser. זה לא „Streaming“ במובן של SAX, אבל זו צינור מבוקר וביצועי ללא שינויים מפתיעים של קידוד.

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

• אילו כללי קידוד חלים (בדרך כלל UTF-8, BOM אופציונלי)?
• מה הגודל המרבי המותר ל‑Payload (הגנה מפני DoS, גבולות תפעוליים)?
• איך נראות הודעות השגיאה (עם הקשר, אבל ללא דליפת נתונים)?

אסטרטגיית קריאה: אחסון ביניים מוגבל במקום „StreamToString“ ללא גבול

אם אתה מקבל JSON ממקורות חיצוניים (שותפים, mobile Clients, צד שלישי), גבול גודל הוא חובה. בלי גבול מספיק בקשה יחידה לא מוצלחת תוכל לגרום ל‑service להיות תחת Memory Pressure. מעשית זה אומר: בעת הקריאה ספור את סכום הבתים ועצור כאשר מגיעים לגבול – עם Exception ברורה שמובנת במערכות המוניטורינג.

מדוע אני לעתים מצפה ל‑UTF-8 „ללא BOM“, אבל אבחן BOM

ב‑REST‑Payloads ה‑BOM נדיר. בקבצים (Exports, עריכה ידנית) הוא נפוץ יותר. למסלולי ייבוא עמידים עדיף להתיר BOM אך לעשות אותו גלוי בלוג, כי זה יכול להעיד על „עולם הקבצים“ במקום „עולם ה‑API“.

הרוצחים השקטים: ברירות המחדל של TStreamReader וקוראי טקסט במצב משולב

TStreamReader נוח, אבל עליך לשלוט בשתי נקודות באופן ברור:

• להגדיר במפורש את הקידוד: אל תסמוך על כך שיזהה אותו באופן אוטומטי.
• להבין את ה‑buffering: ה‑Reader מבצע buffering פנימי. אם תקרא את אותו Stream שוב במקום אחר מאוחר יותר, המיקום בסטרים רלוונטי. זה נשמע טריוויאלי, אבל בצינורות ייבוא גדולים זה הופך במהירות למקור שגיאות.

בעייתי במיוחד הוא מצב משולב: תחילה קוראים חלק בתור bytes (למשל לצורך logging או Magic‑Bytes), ואז ממשיכים עם TStreamReader. אם לא תוסיפו גלילה חזרה נקייה או לא תאתחלו את ה‑Reader במיקום הנכון, תקראו מה‑byte 257 במקום מ‑0. ה‑JSON‑Parser ידווח אז „Invalid character at position …“, למרות שה‑Payload עצמה תקינה.

כשתויות מיוחדות עדיין „שבורות“ למרות UTF-8: Escaping vs. יוניקוד אמיתי

JSON יכול להכיל תווים מיוחדים בשתי דרכים:

• כתווים אמיתיים בקידוד UTF-8 (למשל „München“ כבייטים C3 BC …).
• רצף בריחה (למשל „Mu00fcnchen“).

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

System.JSON מספקת לך בשני המקרים בסופו של דבר מחרוזות Delphi נורמליות (UTF-16), אם הדרך עד אז הייתה תקינה.

להעריך ביצועים בצורה ריאליסטית: עלויות DOM, מערכים גדולים וסלקטיביות

המרכיב המשפיע ביותר על ביצועים לעיתים רחוקות הוא „להאיץ את ה-parser“ — אלא לנתח פחות. עם System.JSON זה קשה, כי אתה מקבל את ה-DOM. שלוש סיטואציות טיפוסיות:

• מערכים גדולים (10.000+ אלמנטים): יצירת ה-DOM גוזלת זמן וזיכרון RAM. אם אתה צריך רק 2 שדות לכל אלמנט, parser התומך ב-streaming (SAX/Tokenizer) לעיתים הגיוני יותר. System.JSON לא נבנתה לזה.
• אובייקטים בודדים עם שדות רבים: אם אתה צריך רק כמה שדות, עדיין אפשר להשתמש ב-DOM, אבל הימנע ממעברים חוזרים. שלוף ערכים פעם אחת ומפה אותם למבני הנתונים שלך.
• כמה payloads גדולים ברצף: ב-Import-Jobs או ב-Sync-Worker משתלם לקפסל את פעולת הפרסינג בשלבים ברורים ולשחרר אחרי כל מסמך את כל ההפניות, כדי שמנהל הזיכרון יוכל לפנות. זה טריוויאלי, אבל בשירותים זה נעשה לעיתים קרובות „בצד“.

„Parser זרם מהיר“ עם System.JSON הוא לכן לעיתים פשרה טובה: קריאה יעילה ונכונה, שימוש מודע ב-DOM, והגדרת גבולות. אם אתה צריך סמנטיקת סטרימינג אמיתית (למשל לעבד אלמנטים של מערך אחד-אחרי-השני בלי להחזיק הכל בזיכרון), System.JSON אינה הבסיס המתאים.

חוסן בתפעול: דפוסי שגיאה וכיצד להפוך אותם לנגישים מיידית

שגיאות פרסינג של JSON בלוגים לעיתים קרובות לא מספקות מידע שימושי, כי הן מציינות רק מיקום. לתפעול ותמיכה אתה צריך הקשר:

• מיקום בייט לעומת מיקום תו: ב-UTF-8 זה לא זהה. אם הפרסר מדווח על מיקום תו, מיקום הבייט יכול לסטות. ל-Byte-dumps מיקום הבייט הוא הקריטי.
• קטע סביב מקום השגיאה: ברישום במקרה של שגיאה רושם חלון קטן סביב המיקום (למשל 40 תווים לפני/אחרי), אבל רק אם אין נתונים רגישים כלולים. חלופה: רושם רק בפורמט הקסדצימלי.
• קורלציה: Request-ID, Endpoint, Partner-ID, Payload-Hash. אחרת לעולם לא תמצא את „אותה שגיאה“ שוב.

המטרה היא שבמהלך דקות לאחר תקרית בייצור תוכל לענות: „פירוש שגוי של קידוד“, „Payload נחתך“, „השרת מחזיר JSON לא חוקי“ או „יש לנו בעיית מיפוי“.

להימנע ממלכודות UTF-8 בצורה ממוקדת: רשימת בדיקה

• הגדרת קידוד תמיד במפורש: בעת קריאה מזרם ובכתיבה ללוגים/קבצים אל תסמוך על ברירות מחדל.
• אין המרה של chunk ל-string ישירה: אם אתה קורא ב-chunks, אסוף את הבייטים או השתמש בדקודר שמאחד/מאגר רצפי מולטיבייט.
• סובלנות ל-BOM, אבל גלוי: קבל אותו, אך אפשר לזהות אותו בזמן דיבאג.
• הגבל גבולות: גודל payload מקסימלי, עומק מקסימלי של אובייקט/מערך (אם ניתן לשלוט בכך), זמני timeout ב-HTTP-Client.

מתי באמת כדאי להשקיע במנתח סטרימינג?

אין צורך לאופטימיזציה של כל מקום שבו מופיע JSON. הגישה בדרך‑כלל משתלמת אם מתקיים לפחות אחד מהדברים הבאים:

• Payloads גדולים (מספר MB) מתרחשים באופן קבוע או עלולים להתרחש.
• תהליכים ארוכי‑ריצה (Service, Worker) מעבדים הרבה Payloads ואתה מבחין בשיאי זיכרון או בפירגמנטציה.
• אינטראופרביליות עם מערכות הטרוגניות: מספר שותפים, פלטפורמות שונות, קידודים שגויים מדי פעם.
• היסטוריית תקלות: כבר היו „אומלאוטים שבורים“, שגיאות ניתוח נקודתיות, או הפסקות ייבוא שקשה לשכפל.

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

הבחנה: מתי נדרש סטרימינג אמיתי

System.JSON הוא מבוסס DOM. אם ברצונך לעבד נתונים באמת „במהלך העברה“, לדוגמה מערך גדול איבר‑אחר‑איבר בלי להחזיקו בשלמותו בזיכרון, תצטרך גישת מנתח שונה (Tokenizer/SAX). זו לא הערכת ערך, אלא החלטת ארכיטקטורה:

• DOM (System.JSON): נוח, מתאים לאובייקטי עסק טיפוסיים, אבל צורך זיכרון רב.
• Streaming/SAX: צריכת זיכרון נמוכה, מתאים לנתונים גדולים מאוד, אך דורש מאמץ מימוש גדול יותר וטיפול שגיאות קפדני יותר.

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

מסקנה: JSON בDelphi יהיה אמין אם תטפל בקידוד ובזרמים כשכבה נפרדת

רוב הבעיות סביב „JSON בDelphi“ אינן נובעות מהמנתח ה‑JSON עצמו, אלא מהשלב הבלתי בולט שלפניו: בתים מתוך זרם מומרנים לטקסט. אם תטפל שם ב‑UTF‑8 במפורש, תזהה מקרים של BOM, לא תתעלם מגבולות ה‑Chunk ותגדיר גבולות גודל ברורים, השגיאות האופייניות של תווים ייעלמו — ושגיאות ניתוח ספורדיות יהפכו לשכפלות.

System.JSON נשאר סטנדרט פרגמטי: לא המנתח הסטרימינג המהיר ביותר, אבל יציב אם אתה שולט בקלט ומקבל במודע את עלויות ה‑DOM. אם תרצה, נוכל לעבור יחד על מסלול הייבוא/REST הספציפי שלך ולזהות את הנקודה שבה הקידוד או ה‑Chunking מתמוטטים: צור קשר.

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

לדון בפרויקט או ביוזמת מודרניזציה עם Net-Base.