mirror of
https://github.com/ArchiveBox/ArchiveBox.git
synced 2026-04-25 09:06:02 +03:00
[GH-ISSUE #235] Parsing: Sources that aren't URL-encoded can contain URLs with brackets, parens, and other separator symbols #162
Labels
No labels
expected: maybe someday
expected: next release
expected: release after next
expected: unlikely unless contributed
good first ticket
help wanted
pull-request
scope: all users
scope: windows users
size: easy
size: hard
size: medium
size: medium
status: backlog
status: blocked
status: done
status: idea-phase
status: needs followup
status: wip
status: wontfix
touches: API/CLI/Spec
touches: configuration
touches: data/schema/architecture
touches: dependencies/packaging
touches: docs
touches: js
touches: views/replayers/html/css
why: correctness
why: functionality
why: performance
why: security
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ArchiveBox#162
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @anarcat on GitHub (May 6, 2019).
Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/235
Describe the bug
I was trying to archive this Wikipedia page:
https://en.wikipedia.org/wiki/Insert_(effects_processing)
Archivebox sees it as:
https://en.wikipedia.org/wiki/Insert_
Bad box! No cookie! :)
Steps to reproduce
echo 'https://en.wikipedia.org/wiki/Insert_(effects_processing)' | archivebox add
Screenshots or log output
Software versions
Workaround
Run
sed 's/(/%28/;s/)/%29/'over the list of URLs, although I suspect more special characters might be affected.@pirate commented on GitHub (May 6, 2019):
Ah damn, I explicitly stop parsing at those characters because of cases like this:
The current regex looks like this:
I don't see any easy solutions, but there are a few crappy options:
()and[]in URLsI don't think the problem is limited to markdown files unfortunately, so I'm hesitant to add a separate parser just for markdown to paper over the issue. there are lots of formats that have meaningful symbols to break up URLs that are also valid URL characters.
@anarcat commented on GitHub (May 6, 2019):
i think it might be worth making it possible for
archivebox addto be told what kind of input to expect.if it's a "one URL per line" file, it shouldn't do any parsing except for splitting on newlines. same with known JSON or bookmarks formats...
@pirate commented on GitHub (Oct 18, 2019):
I think this is reasonable, if the first line starts with
http...and ends with\nwe can probably consider the whole import to be raw URLs separated by newlines.It gets harder when parsing other types of sources though (e.g. txt, markdown, arbitrary html, etc):
RFC7089-compliant headers during replay / viewing of Snapshot content #1622RFC7089-compliant headers during replay / viewing of Snapshot content #3133