Tokeny nazw legacy PDF

THPDFNameObject.Value i legacy klucze słowników zachowują tokeny nazw PDF bez wiodącego ukośnika; tokeny parsera wczytanego mogą już zawierać eskapy #HH

Legacy writer dekoduje istniejący token, a potem koduje wszystkie zarezerwowane bajty, białe znaki, bajty sterujące i bajty UTF-8 spoza ASCII; istniejące eskapy są kanonizowane bez podwójnego eskapowania

Na przykład token #41 oznacza A, podczas gdy #2341 oznacza literałowy tekst #41; koduj nowo autorskie surowe bajty przez _PDFNameEncode przed zapisaniem literałowego hasza, po którym następują dwie cyfry szesnastkowe

Niepoprawne sekwencje hex takie jak #GZ i końcowy hash pozostają danymi literałowymi i są eskapowane jako #23GZ i #23 podczas serializacji

Wiodące i końcowe spacje są zachowywane jako #20, a pusta nazwa pozostaje pustą nazwą PDF; wartości w tablicach, zagnieżdżonych słownikach i kluczach słowników używają tych samych reguł serializacji

Nazwy nie są łańcuchami tekstu PDF: writer zachowuje bajty i nie transkoduje kodowania źródła wywołującego; użyj UTF8Encode przy dostarczaniu nowo autorskich nazw Unicode

Świeże słowniki natywnego budowniczego XFA używają zdekodowanych kluczy, podczas gdy wartości nazw pozostają oparte na tokenach; adaptery muszą kodować te zdekodowane klucze raz przy przenoszeniu ich do legacy modelu obiektów