“나중에 읽을게요”: 오프라인 인터넷 페이지 모음의 어려운 운명

어떤 사람들은 없이는 살 수 없는 유형의 소프트웨어가 있는 반면, 다른 사람들은 그러한 것이 존재하거나 누군가에게 전혀 필요하지 않다는 것을 상상조차 할 수 없습니다. 나에게 있어 수년 동안 이 프로그램은 매크로풀 웹리서치, 인터넷 페이지를 일종의 오프라인 라이브러리에 저장하고 읽고 구성할 수 있는 기능입니다. 나는 많은 독자들이 링크 모음이나 브라우저와 저장된 문서 세트가 있는 폴더의 조합을 사용하여 잘 지내고 있다고 확신합니다. 나는 최소한 문서를 "읽음" 또는 "즐겨찾기"로 표시하고, 한 텍스트에서 다른 텍스트로 빠르게 이동하고, 인터넷이나 특정 사이트의 가용성에 의존하지 않고 싶습니다. 인터넷이 없을 때(예를 들어 이동 중) 정확히 읽을 시간이 있으며, 불행히도 링크는 종종 수명이 짧은 것으로 판명됩니다.

분명히 WebResearch의 저자는 대략 이러한 사람들을 믿고 있었습니다. 이 프로그램에는 섹션 및 태그별 목록 작성, 메모 편집, 모든 종류의 내보내기/가져오기 등 다양한 기능이 포함되어 있습니다. 그러나 2013년쯤에 프로젝트 업데이트가 중단되면서 개발자의 웹사이트도 사라졌습니다. 몇 년 동안 나는 이 말을 탔지만 먼저 브라우저 플러그인이 떨어져서(당시 버전의 IE 및 FireFox에서만 사용 가능) 최신 사이트가 이전 IE 엔진 기반 뷰어에서 정상적으로 표시되지 않았습니다.

WebResearch 메인 창, PC Week/RE 17호(575)

실망의 길

교체를 피할 수 없다는 것이 분명해지자 백그라운드에서 괜찮은 아날로그를 찾기 시작했습니다. 내 욕망이 극도로 겸손하기 때문에 여기에는 특별한 어려움이 없을 것 같았습니다. 저는 다음을 포함하는 WebResearch 도구의 일부만 사용하여 작업할 준비가 되었습니다.

• 확장 기능을 사용하여 브라우저에서 HTML 페이지 저장
• 최소한의 카탈로그 도구(이름 변경, 카탈로그 구성, 라벨)
• (바람직하게는) PDF 문서 지원;
• 컬렉션을 다른 장치와 동기화하는 적절한 방법.

놀랍게도 나는 인터넷을 광범위하게 샅샅이 뒤지고 주석과 일치하는 12개의 프로그램을 주의 깊게 연구했지만 유사한 것을 찾을 수 없었습니다(설명과 유사한 기능은 구독을 통해서만 사용할 수 있는 Evernote 제외). 오늘날 내 소망을 적어도 어느 정도 만족시켜 주는 유일한 것은 프로젝트뿐이다 태그스페이스 и 마이베이스. 일반적으로 그들의 연구는 특정한 문화적 관심을 가지고 있습니다.

TagSpaces는 아름다운 웹사이트, 적응형 레이아웃, 물론 어두운 테마를 갖춘 Electron의 "세련되고 패셔너블한 청소년" 구성 도구입니다. 이것이 없었다면 우리는 어디에 있었을까요? 동시에 패셔너블한 둥근 아이콘이 있는 컬렉션의 불운한 목차는 화면의 절반을 차지하고 최대 20개 정도의 요소를 수용하며 단축키 지원이나 보고 있는 문서의 렌더링과 같은 기본적인 사항이 기록됩니다. 잔여 원리에 따라. 결과적으로 문서가 비뚤어지게 표시되고 컬렉션 작업은 지루하고 시간이 많이 걸리는 마우스 연습 세트로 변합니다.

그 대척점인 myBase는 90년대 후반에 나왔습니다. 순전히 기능적인 인터페이스 우리는 매우 풍부한 설정과 기능 세트를 가지고 있습니다. 그러나 여기의 보기 창은 이전 IE 기반의 브라우저와 동일하며(이미 읽기가 어렵습니다) 모든 문서는 단일 데이터베이스에 저장됩니다. 예를 들어 Dropbox 폴더에 넣으면(아직 다른 장치와 동기화할 수 있는 다른 방법이 없음) 컬렉션이 조금만 변경되어도 수백 메가바이트의 정보가 서버에 업로드될 때까지 기다려야 합니다.

전환점

아마도 메모의 추가 내용은 독자에게 분명해 보일 것입니다. 이제 우리는 기존 아날로그보다 머리와 어깨가 뛰어난 우리 자신의 자전거를 제공받을 것입니다. 일종의 그렇습니다. 그러나 정답은 아닙니다. 나는 정말로 myBase와 TagSpaces의 시련을 참을 수 없었고, 마지막 부분에 제공할 링크인 나만의 문서 관리자를 스케치했습니다. 그러나 이 작은 개인 프로젝트는 그 자체로는 기사의 가치가 없습니다. 제가 글을 쓰는 이유는 제가 일하면서 얻은 경험과 전혀 예상하지 못했던 여러 불쾌한 놀라움을 공유하는 것이 흥미로울 것이라고 생각했기 때문입니다.

목표와 목적

지금은 꽤 바쁜 생활을 하고 있어 본격적인 취미 프로젝트를 할 시간이 없다는 사실부터 시작하겠습니다. 따라서 처음부터 작업 속도를 높일 수 있다면 손에 들어오는 모든 구성 요소를 사용하여 악기를 조각할 준비가 되었다고 결정했습니다. 또한 지금은 최소한의 기능만 구현하기로 약속했는데, 이는 없이는 절대 불가능합니다.

데이터 형식 및 페이지 저장

웹 페이지는 어떤 형식으로 디스크에 저장되어야 합니까? 이전에 공식화된 요구 사항을 고려할 때 "전체 웹 페이지" 저장 형식, 즉 기본 HTML 파일과 관련 리소스가 있는 폴더 또는 MHTML 형식 중 하나를 선택하는 것이 작은 것 같았습니다. 첫 번째 옵션은 나에게 즉시 덜 선호되는 것처럼 보였습니다. 디스크에 파일의 쓰레기 더미가 있으면 기쁨이 거의 없습니다. 여기서 중요한 문서를 추출하고, 검색할 때 불필요한 문서를 필터링하고, 복사할 때 무결성을 모니터링해야 합니다. TagSpaces로 작업하려고 할 때 리소스 폴더 이름이 점으로 시작되도록 모든 문서를 다시 저장해야 했습니다. 그러면 시스템이 해당 문서를 "숨김"으로 인식하고 표시하지 않았습니다.

이 문제는 모든 것이 데이터베이스에 저장되어 있기 때문에 myBase에서는 보이지 않지만 제 경우에는 단순성의 원칙이 우세했습니다. 저는 모든 것을 디스크에 일반 파일로 저장하여 구현을 처리할 필요가 없도록 하고 싶었습니다. 복사, 이름 바꾸기, 삭제 및 동기화와 같은 일상적인 작업.

MHTML 형식은 어려운 시기를 겪고 있습니다. MHTML을 저장하는 쉬운 방법 이번 여름에 Chrome에서 쫓겨났습니다, 그리고 지금은 페이지가 어디에 저장되어야 하는지조차 모르겠습니다. 아직 기회가 사라지지 않았고 타사 확장 기능도 있지만 일반적으로 이는 일종의 나쁜 징조입니다. 또한 MHTML 형식으로 저장 Chromium Embedded Framework에서는 지원되지 않습니다., 또한 낙관주의를 추가하지 않습니다.

동시에 나는 브라우저의 페이지를 지정된 폴더에 저장하는 간단한 방법을 찾기 시작했습니다. 그 결과, 두 문제 모두 손실 없이 해결되었습니다. 저는 멋진 프로젝트를 발견했습니다. 단일 파일, 웹페이지의 내용을 별도의 독립적인 HTML 파일로 저장할 수 있습니다. 이는 모든 관련 리소스를 base64 형식으로 변환하고 이를 HTML에 직접 포함함으로써 수행됩니다. 물론 파일 크기도 커지고 내용도 좀 어수선해 보이지만 전체적으로 접근 방식이 안정적이고 단순해 보여서 결정했습니다.

SingleFile은 브라우저 확장 기능과 명령줄 응용 프로그램으로 모두 제공됩니다. 이제 확장 프로그램을 사용합니다. 저장할 대상 폴더를 수동으로 선택해야 한다는 점을 제외하면 매우 편리합니다. 앞으로는 이 프로세스를 단순화하기 위해 애플리케이션을 개선하려고 노력할 것입니다. Chrome에서 타사 애플리케이션을 호출하려면 확장 프로그램을 사용할 수 있습니다. 외부 애플리케이션 버튼 - 이것은 나의 또 다른 유용한 발견입니다. 그건 그렇고, 응용 프로그램은 이미 유용했습니다. 이 응용 프로그램의 도움으로 TagSpaces의 폴더 및 파일 모음을 독립적인 HTML 문서 세트로 변환했습니다.

GUI 및 브라우저 문제

나는 Python이 모든 종류의 간단한 파일 및 문자열 작업에 적합하다는 것을 알았고, 내 작업 프로젝트 중 하나가 다음을 사용하기 때문에 wx위젯, 선택 wx파이썬 주요 프레임워크로서 논리적으로 보였습니다.

또한 다른 프로그램에서 페이지를 표시할 때 발생하는 문제를 충분히 확인한 후 이를 처리하는 신뢰할 수 있는 유일한 방법은 최신 브라우저, 즉 Chrome 또는 Firefox를 기반으로 하는 프로그램에 시각화 도우미를 도입하는 것이라는 결론에 도달했습니다.

이런 일을 마지막으로 해야 했던 것은 약 15년 ​​전이었고 어떤 함정도 예상하지 못했다는 점을 인정해야 합니다. "그냥 브라우저를 양식에 두드리는 것"은 불가능하다는 것이 밝혀졌습니다. 어쨌든 인류는 이 작업에 안정적이고 보편적으로 대처할 수 없었습니다. 양식의 목록 상자나 버튼은 모든 GUI 프레임워크에 배치할 수 있으며 심지어 크로스 플랫폼 코드를 생성할 수도 있습니다. 2019년에는 HTML 표시도 보편적으로 해결된 문제여야 했던 것 같습니다.

예를 들어 wxWidgets에서 표준 "브라우저" 구성 요소는 시스템 종속 "브라우저"에 대한 크로스 플랫폼 래퍼로 밝혀졌습니다. 예를 들어 Windows의 경우 다음을 의미합니다. 인터넷 익스플로러 7, Windows Forms의 상황은 그다지 좋지 않으며 IE9보다 최신 버전은 중요하지 않은 방법으로만 사용할 수 있습니다. 레지스트리 조작. 보시다시피 지난 15년 동안 다른 일을 해온 사람은 나뿐만이 아닙니다. 여기서도 아무것도 싹 트지 않았습니다.

그런 다음 프레임워크를 변경하거나 브라우저의 대체 구성 요소를 찾는 선택에 직면했습니다. 망설이다가 두 번째 길을 먼저 시도해보기로 결정하고 빠르게 프로젝트를 접하게 되었습니다. CEF Python: Chromium Embedded Framework용 Python 바인딩, Chromium을 Python 애플리케이션에 내장하는 작업을 위해 특별히 설계되었습니다.

상황을 평가하십시오. Python은 세계에서 가장 인기 있는 프로그래밍 언어 중 하나이며 Chrome은 본질적으로 브라우저 시장의 독점자입니다. 동시에 CEF Python은 실제로 에너지의 지원을 받습니다. 한 남자, 그에게 힘과 건강. 이제 이거 필요한 사람 없나요?..

그러나 CEF Python은 결국 나에게 도움이 되지 않았습니다. 프로젝트 저장소의 wxWidgets와의 통합에 대한 기본 예조차도 솔직히 버그가 있었지만 더 많은 문제를 해결하려고 시도했지만 발생한 모든 문제를 해결할 수 없었습니다. 나는 그 주제에 대해 더 깊이 다루지도 않을 것입니다.

Chromium Embedded Framework 기반의 구성요소를 좀 더 자세히 살펴보고 최종적으로 사용해 보기로 결정했습니다. C#용 버전. 나는 거의 항상 Windows로 작업하기 때문에 일반적으로 크로스 플랫폼 기능을 포기할 것이라는 전망은 나를 특별히 괴롭히지 않았습니다.

처음에는 피할 수 없는 소란이 있었지만 상황은 훨씬 더 빠르게 진행되었습니다. CefSharp와 Windows Forms의 조합이 승리한 것으로 판명되었고 대부분의 기술 문제를 아무런 문제 없이 해결할 수 있었습니다.

시도되지 않은 것에 대해

구성 요소를 사용하여 FireFox를 C# 애플리케이션에 구현해 볼 수도 있습니다. Geckofx, 하지만 그에 대해 아무 말도 할 수 없습니다. Qt 프레임워크의 표준 브라우저 구성 요소는 다음과 같습니다. QWebEngineView 설립 크롬에이므로 아마도 CefSharp와 마찬가지로 작동할 것입니다.

Qt의 팬들은 다음과 같이 논평하고 싶을 수도 있습니다. Qt를 사용했다면 아무런 문제도 없었을 것입니다. 이것이 사실일 수도 있지만, Python 또는 C++에서 애플리케이션을 위한 GUI 프레임워크를 선택할 때 wxWidgets를 첫 번째 옵션은 아니지만 두 번째 옵션으로 고려할 수 있습니다. 그리고 내 생각으로는 브라우저와 같은 것은 탬버린과 함께 춤을 추지 않고도 어느 정도 개발된 GUI 프레임워크에 내장되어야 합니다.

웹라이브러리

그러나 작업 제목이 있는 내 지원서로 돌아가겠습니다. 웹라이브러리. 오늘은 (드럼 롤) 다음과 같습니다:

게다가 깨끗하고 간결한 인터페이스 여기서는 가장 기본적인 기능만 구현됩니다.

• 시스템의 지정된 디렉터리를 문서 라이브러리로 표시합니다.
• 브라우저 창에서 문서를 봅니다. 일반적인 방법(커서 키, PgUp, PgDn, Home, End)으로 목록을 탐색하고 Space 및 Shift+Space 키를 사용하여 브라우저를 스크롤합니다.
• 문서 이름 바꾸기.
• 단축키를 사용하여 문서를 읽음 또는 즐겨찾기로 표시하세요.
• 모든 분야별로 문서를 정렬합니다.
• 라이브러리 폴더에 변경 사항이 있으면 응용 프로그램 창을 새로 고칩니다.
• 종료 시 창 설정을 저장합니다.

이 모든 것이 사소한 기능처럼 보일 수 있지만 TagSpaces에 열 크기를 저장하는 기능은 아직 지원되지 않습니다. 분명히 작성자에게는 다른 우선 순위가 있습니다.

상태(읽기/즐겨찾기)는 단순히 파일 이름(파일 읽기)에 저장됩니다. doc.html 로 개명 doc{R,S}.html). 그런 동기화는 없지만 단순히 Dropbox에 라이브러리를 보관합니다. 결국 그것은 파일이 있는 폴더일 뿐입니다.

파일 이동 및 삭제와 같은 간단한 기능을 개선하고 임의의 태그를 사용하여 태그를 구현할 계획은 여전히 ​​남아 있습니다. 누구든지 돕고 싶다면 기뻐할 것입니다.

조사 결과

다양성. 처음부터 말했듯이, 한 사람의 툴킷이 다른 사람과 얼마나 다를 수 있는지는 놀랍습니다. WebResearch와 같은 도구를 사용하는 것은 나에게 자연스러운 일이었고, 그 도구가 없기 때문에 거의 육체적인 불편함을 느꼈습니다. 동시에, 분명히 같은 생각을 가진 사람이 거의 없습니다. 그렇지 않으면 유사점을 찾는 데 문제가 없을 것입니다. 반면에 훨씬 더 주류 소프트웨어에서도 유사한 사례가 발생합니다. 예를 들어 Microsoft는 OneNote의 데스크톱 버전을 업데이트하지 않을 예정이므로 어쩔 수 없이 2016 버전을 사용해야 하며 조만간 다른 버전에서도 전환해야 합니다. 어딘가요.

또한 놀라운 점은 라이브러리와 프레임워크의 현재 환경을 탐색하는 것이 얼마나 어려운지입니다. 내 업무에서는 데스크톱 응용 프로그램을 처음부터 끝까지 작성해야 하는 경우가 거의 없으며 문자 그대로 모든 프로그래밍 언어에 대한 모든 도구가 내 작업에 적합할 것이라고 가정했습니다(창 1개, 구성 요소 3개, 사소한 상호 작용). 그래서 우리는 무엇이든 받아들이고 며칠 안에 그것을 합니다.

현실은 훨씬 덜 호의적이며 갑자기 문제에 직면할 수 있다는 것이 밝혀졌습니다. 브라우저 창을 늘리는 데 사용할 수 있는 두 개의 분할기가 있다고 가정해 보겠습니다. 따라서 wxWidgets에 로드한 후 해당 위치를 복원하는 것은 매우 어렵습니다. 시스템이 나에게 사용 가능한 거의 모든 이벤트 후에 이를 기본 위치에 배치하고 필요한 것을 달성하기 위해 모든 종류의 해킹을 수행해야 하기 때문입니다. 누가 추측했을까요?

반면에 Windows Forms에서는 모든 것이 "비즈니스 인터페이스"를 위해 설계되었다는 것이 분명합니다. 응용 프로그램 설정 저장/복원, 구성 요소의 편리한 인터페이스(예: TreeView 구성 요소에 루트에서 하위 요소까지의 전체 경로를 요청할 수 있다고는 예상하지 못했습니다) 문자열 형식) 및 폴더 콘텐츠 변경 추적기와 같은 중요하지 않은 도구입니다.

어쨌든 시간이 낭비되지 않았고 결과도 만족스럽다고 할 수 있는데 인생에서 무엇을 더 바랄 수 있겠습니까?

출처 : habr.com