Legacy-PDF-Name-Tokens

THPDFNameObject.Value und Legacy-Dictionary-Keys behalten PDF-Name-Tokens ohne führenden Slash; geladene Parser-Tokens können bereits #HH-Escapes enthalten

Der Legacy-Writer dekodiert ein bestehendes Token und enkodiert dann alle reservierten Bytes, Whitespace-, Control- und Nicht-ASCII-UTF-8-Bytes; bestehende Escapes werden kanonisiert, ohne doppelt zu escapen

Das Token #41 bezeichnet beispielsweise A, während #2341 den literalen Text #41 bezeichnet; neu authored rohe Bytes mit _PDFNameEncode enkodieren, bevor ein literales Hash gefolgt von zwei Hex-Ziffern gespeichert wird

Ungültige Hex-Sequenzen wie #GZ und ein abschließendes Hash bleiben literale Daten und werden bei der Serialisierung als #23GZ und #23 escapet

Führende und nachfolgende Leerzeichen werden als #20 erhalten, und der leere Name bleibt ein leerer PDF-Name; Werte in Arrays, verschachtelten Dictionaries und Dictionary-Keys nutzen dieselben Serialisierungsregeln

Namen sind keine PDF-Textstrings: Der Writer bewahrt Bytes und transkodiert die Quell-Encodierung des Aufrufers nicht; UTF8Encode verwenden, wenn neu authored Unicode-Namen geliefert werden

Frische native XFA-Builder-Dictionaries nutzen dekodierte Keys, während Name-Werte token-basiert bleiben; Adapter müssen diese dekodierten Keys einmal enkodieren, wenn sie sie in das Legacy-Objektmodell überführen