Kijk niet alleen naar de lettergrootte voor Word-titels: stijl is een betere structurele aanwijzing

Als u een script gebruikt om de inhoudsopgave of hoofdstukken van Word-documenten batchgewijs te extraheren, kan het voorkomen dat een kop van het eerste niveau wordt gemist, of dat vetgedrukte tekst verkeerd wordt beoordeeld als hoofdstuk. Dit komt meestal niet omdat de reguliere expressies niet goed genoeg zijn geschreven, maar omdat er op de alinea geen titelstijl zoals Heading 1 is toegepast, maar omdat de lettergrootte handmatig is vergroot en de tekst vet is weergegeven. Bij de verwerking van de structuur van Word-documenten is visuele representatie niet gelijk aan structuur, en paragraph.style is een betrouwbaardere semantische aanwijzing.

De onderstaande inhoud is geschikt voor ontwikkelaars en documentingenieurs die verantwoordelijk zijn voor documentautomatisering, batchparsering of controles voorafgaand aan de vertaling. De voorbeelden in dit artikel maken gebruik van synthetische monsters en worden in het geheugen gegenereerd voor gemakkelijke reproductie en begrip. De code is gecontroleerd met voorbeelden in een geïsoleerde omgeving, maar dit is geen garantie voor alle echte bestanden of productprestaties. Voordat u belangrijke documenten verwerkt, dient u de originelen te bewaren en deze te controleren op basis van de grenzen en acceptatie-items in de tekst.

Hoe Word-titels identificeren? Conclusie in één zin

Conclusie in één zin: gebruik paragraph.style als de belangrijkste basis voor het beoordelen van titels, en gebruik Engelse interne namen of toewijzingstabellen om stijlen te vinden. Kijk niet alleen naar de lettergrootte en vetgedrukte tekst.

Waarom moeten we Engelse interne namen gebruiken om stijlen te vinden?

python-docx werkt op de onderliggende WordprocessingML-bestanden, niet op de Word-toepassingsinterface. Ongeacht of het Word van de gebruiker Chinees, Japans of Duits is, de opgeslagen namen van ingebouwde stijlen zijn in het Engels. 'Titel 1', weergegeven in de Chinese versie van de Word-interface, wordt bijvoorbeeld vastgelegd als Heading 1 in XML. Voor stijlopslagmethoden en naamgevingsregels raadpleegt u Stijlen begrijpen - python-docx Conceptbeschrijving.

Als styles['标题 1'] wordt gebruikt voor het zoeken in de code, zal het programma direct KeyError genereren. Dit is een van de meest voorkomende valkuilen bij het werken met meertalige documenten.

Aangepaste stijlen vallen niet onder deze beperking en hun namen in de XML zijn precies zoals de gebruiker ze op de interface ziet. Daarom kunt u bij het schrijven van robuuste parseerlogica een toewijzingstabel samenstellen van gelokaliseerde weergavenamen naar Engelse interne namen, of u kunt van indieners van documenten eisen dat ze een standaardsjabloon gebruiken.

Synthesevoorbeeld: correcte uitvoer en randgevallen

Om de logica van stijlherkenning aan te tonen, construeren we een synthetisch voorbeeld met drie typische alinea's:

1. Paragraaf A: De Heading 1-stijl wordt toegepast en de tekst is "Hoofdstuk 1 Inleiding".
2. Paragraaf B: De stijl is Normal, maar de lettergrootte en vetgedrukte tekst zijn handmatig ingesteld op 16pt, en de tekst is 'Belangrijk'.
3. Paragraaf C: De aangepaste stijl MyCustomTitle wordt toegepast en de tekst is "Bijlagebeschrijving".

Verwachte uitvoer: De parser zou een gestructureerde lijst moeten retourneren met alleen alinea A en alinea C gemarkeerd als titelknooppunten. Hoewel Paragraaf B visueel prominent aanwezig is, moet deze vanwege het gebrek aan semantische stijl worden geclassificeerd als gewone tekst, of worden gemarkeerd als "vermoedelijke titel die handmatig moet worden bevestigd", en kan deze niet automatisch worden gepromoveerd tot een structureel knooppunt.

Fouten en grensinvoer: Als een referentiestijl in een bepaalde alinea in het document is verwijderd, d.w.z. w:pStyle w:val="DeletedStyle" bestaat in XML maar de stijldefinitie ontbreekt, kan python-docx None teruggeven of een uitzondering gooien bij het openen van paragraph.style.name. Een veiligere aanpak is om vóór toegang te controleren of er stijlobjecten bestaan, of dergelijke paragrafen te downgraden naar platte tekstverwerking om te voorkomen dat het hele parsingproces wordt onderbroken.

Geheugenconstructievoorbeelden en stijlassertiecode

De volgende code laat zien hoe stijlherkenningslogica te verifiëren in een gecontroleerde omgeving. Het wordt gebruikt om API-gebruik en assertiebenaderingen te demonstreren, niet om een parser van productiekwaliteit te zijn. Als je het daadwerkelijk gebruikt, gebruik het dan in een omgeving waar je afhankelijke versies hebt vergrendeld. python-docx>=0.8.11 wordt aanbevolen. Voor specifiek gebruik van stijlen, zie Werken met stijlen - officiële documentatie van Python-docx.

from docx import Document
from docx.enum.style import WD_STYLE_TYPE
from docx.shared import Pt

def build_sample_doc():
    """构建含混合样式的合成文档，无需外部文件"""
    doc = Document()
    # 标准内置标题
    doc.add_heading('Chapter One', level=1)
    # 视觉像标题但无样式
    p_visual = doc.add_paragraph('Visual Fake Title')
    run = p_visual.runs[0]
    run.bold = True
    run.font.size = Pt(15)  # 使用Pt单位确保API规范
    # 自定义样式
    if 'MyCustomTitle' not in [s.name for s in doc.styles]:
        doc.styles.add_style('MyCustomTitle', WD_STYLE_TYPE.PARAGRAPH)
    doc.add_paragraph('Appendix Note', style='MyCustomTitle')
    return doc

def extract_semantic_headings(doc):
    """仅提取具有明确样式的标题，忽略直接格式化"""
    headings = []
    for para in doc.paragraphs:
        style_name = para.style.name if para.style else None
        # 严格匹配：内置Heading或已知自定义标题样式
        if style_name and (style_name.startswith('Heading ') or style_name == 'MyCustomTitle'):
            headings.append({'text': para.text, 'style': style_name})
    return headings

# 验证逻辑
sample = build_sample_doc()
result = extract_semantic_headings(sample)

assert len(result) == 2, f"期望2个语义标题，实际得到{len(result)}个"
assert result[0]['style'] == 'Heading 1'
assert result[1]['style'] == 'MyCustomTitle'
assert all('Visual Fake' not in item['text'] for item in result)

Deze code sluit expliciet het beoordelen van titels uitsluitend uit op lettertypeattributen. assert wordt gebruikt om te bevestigen dat logica aan de verwachtingen voldoet, maar in echte documenten kunnen asserties worden vervangen door logging of uitzonderingsverzamelingsmechanismen, waardoor het eenvoudiger wordt om problemen uniform te bekijken tijdens batchverwerking.

Acceptatiechecklist en Grenzen voor handmatige beoordeling

Geautomatiseerde parsing kan niet alle typografische gewoonten dekken. De onderstaande tabel vat veelvoorkomende scenario-afhandelingsbeslissingen samen en helpt teams de grenzen tussen samenwerking tussen machine en mens duidelijk te definiëren.

Let op: deze tabel is bedoeld voor logische validatie op het niveau van de codedemonstratie, en het end-to-end effect moet worden geëvalueerd op basis van specifieke documenttypes. Zo kunnen "definitieklausules" in juridische contracten een speciale stijl gebruiken en moeten ze niet als hoofdstukkoppen worden behandeld; De "Notities" in de technische handleiding kunnen speciale behandeling vereisen tijdens de vertaling, zelfs bij gebruik van Heading 3. Bij het tegenkomen van specifieke regels in dergelijke vakgebieden moet handmatige controle worden toegevoegd.

📊 Kernvergelijking

🎯 Welke methode past bij jou?

Als je de inhoudsopgave of hoofdstukstructuur uit Word moet extraheren

Geef prioriteit aan het gebruik van paragraph.style voor beoordeling; vertrouw niet op lettergrootte of vetgedrukthed.

Als je werkt met gelokaliseerde versies van Word-documenten in het Chinees, Japans of andere talen

Gebruik de Engelse interne naam om ingebouwde stijlen te vinden, of maak een mappingtabel van de gelokaliseerde naam naar de interne naam.

Als je document door meerdere mensen is geschreven en inconsistente formaten heeft

Voor paragrafen die zijn gestyled als Normal maar visueel prominent zijn, wordt handmatige controle behouden en locatie-informatie geregistreerd.

Als je juridische contracten of technische handleidingen behandelt

Bepaal eerst specifieke stijlregels binnen het vakgebied, en bepaal vervolgens welke alinea's automatisch herkenbaar zijn en welke handmatig oordeel vereisen.

❓ Veelgestelde Vragen (FAQ)

1. Waarom kun je niet gewoon styles['标题 1'] gebruiken om titels te vinden?

Omdat python-docx de onderliggende XML leest, worden de ingebouwde stijlen opgeslagen als Engelse namen in XML, zoals Heading 1. De Chinese versie van de interface van Word toont "Titel 1" in code die KeyError veroorzaakt.

2. Paragrafen hebben alleen een groot lettertype en zijn vetgedrukt; kunnen ze als titels worden gebruikt?

Het wordt niet aanbevolen om het automatisch als titel te gebruiken. Dergelijke paragrafen missen semantische stijl en moeten worden gemarkeerd als "verdachte titels," en pas na handmatige bevestiging mogen ze in de structuur worden opgenomen.

3. Hoe ga je om met alineastijlen zoals None?

Het wordt aanbevolen om waarschuwingen op te nemen en als platte tekst te verwerken. Als dergelijke situaties vaak voorkomen in bulkdocumenten, moet handmatige controle worden geregeld.

4. Kunnen aangepaste stijlen als titels worden gebruikt?

Als de aangepaste stijl van Heading 1 erft en de base_style-overervingsketen compleet is, kan het als een geldige titel worden beschouwd.

📝 Samenvatting

Bij het beoordelen van Word-titels moet stijl het belangrijkste criterium zijn, niet alleen het visuele effect. Nadat de codeverificatie is afgerond, is het nog steeds noodzakelijk om de betrouwbaarheid van de resultaten te verifiëren door het specifieke documenttype te overwegen en handmatig te controleren.

Ervaar nu: upload je document om te beginnen met vertalen, waarbij je de originele opmaak behoudt