semvec/pypi-packages huggingface dataset:
cnki-html2json 0.1.10
A package for converting cnki journal papers' html to json
License: MIT
Requires Python: >=3.8
Keywords: cnki,text structure,crawler

# 从知网HTML格式的文献中提取结构化文本

本仓库是一个从知网HTML格式的期刊论文中提取结构化文本，然后导出JSON文件的工具，方便对中文期刊论文进行全文分析。

最近更新：  
- `v0.1.8` 优化爬虫策略，适当提高了爬取速度；
- `v0.1.5` 对解析论文HTML字符串的方法进行重构，提高了解析的准确率；

核心功能：
- 从期刊论文的HTML字符串中解析出包含两级子章节的结构化文本；
- 实现一个Selenium爬虫，可以批量获取所需文献的结构化文本；
- 提供三种模式，既可以导出结构化文本，也可以导出非结构化的纯文本；
  - `structure` 导出结构化文本，包含两级子章节对应的正文和参考文献索引；
  - `raw` 与 `structure` 模式相似，但是会在正文中保留参考文献标签，如[1,2]，以及换行符等；
  - `plain` 导出纯文本，不含章节结构；
  - 以上三种模式都包含参考文献，可以参考 [examples](examples) 文件夹中给出的样例；

使用限制：
- 确保所在的网络环境能正常使用知网；
- 仅能提取期刊论文，其他文献类型未做测试；
- 无法提取文献中的图片、表格等，因此提取的内容可能不完整；
- 本工具已经尽力覆盖大多数情况，但不能保证每一篇文献都能正常提取；

## 快速开始
本工具使用 Python 开发，请确保电脑上安装了 Python3.8 或以上版本。如果使用爬虫，需要提前配置好对应浏览器的驱动，例如Chrome的驱动为 [ChromeDriver](https://chromedriver.chromium.org/downloads)

```console
$ pip install cnki_html2json
```

## 使用方法
1、函数调用，解析单篇文献的HTML字符串

```python
from cnki_html2json.html2json import ExtractContent
with open('paper.html', 'r', encoding='utf-8') as f:
    raw_html = f.read()
print(ExtractContent(raw_html).extract(mode='raw',export_path=None))
```
`extract` 函数参数说明：

| 参数 | 说明 |
| --- | --- |
| `mode` | 可选值为 `structure`, `plain`, `raw`，默认为 `raw` |
| `export_path` | 保存结果的路径，默认为 `None` ，则不保存文件 |

> 函数返回值说明：参考 [examples](examples) 文件夹中给出的样例，调用该函数得到的结果仅包含正文内容和参考文献，不包括文献元数据。

2、使用命令行工具，启动Selenium爬虫，在弹出的浏览器窗口(默认为Chrome)中完成检索，默认120秒后开始爬取

```console
$ 无需设置任何参数，在终端中输入以下指令即可启动爬虫
$ cnki-crawler
```
```console
$ 设置论文提取的起始索引和终止索引，模式设置为structure，记录日志
$ cnki-crawler -s 1 -e 100 -m structure -l
$ 或者是
$ cnki-crawler --start_paper_index 1 --end_paper_index 100 -mode structure --log
```

命令行工具参数说明：
|  | 参数 | 说明 |
| --- | --- | --- |
| -s | --start_paper_index | 论文提取的起始索引，默认为 `1`，从第一篇开始下载 |
| -e | --end_paper_index | 论文提取的终止索引，默认为 `None`，爬取到最后 |
| -m | --mode | 模式，可选值为 `raw(default)`、`structure`、`plain`|
| -b | --browser | 浏览器类型，可选值为 `Chrome(default)`、`Edge`、`Firefox`|
| -save | --save_path | 下载文件的保存路径，默认为当前目录的 `dataset` 文件夹 |
| -wait | --wait_time | 为检索预留的等待时间，默认 `120` 秒 |
| -l | --log | 是否记录日志，指定该参数则保存日志，无需传值，</br>日志将保存在 `save_path` 下的 `log` 文件夹中 |

> 如果未指定保存路径，将下载结果默认保存在当前目录的 `dataset` 文件夹中；  
由于提取的是文献全文，1分钟大概能下载4篇文献，可以放到夜间运行 (自动过滑块验证)；

## JSON文件字段说明
| 一级字段 | 二级字段 | 三级字段 | 说明 |
| --- | --- | --- | --- |
| metadata | title |  | 论文标题 |
|  | authors |  | 论文作者 |
|  | orgs |  | 作者所属机构 |
|  | abstract |  | 论文摘要 |
|  | keywords |  | 论文关键词 |
|  | funds |  | 基金资助 |
|  | class_num |  | 分类号 |
|  | source |  | 来源期刊 |
|  | issue |  | 期 |
| body_text | 1.xxx(一级章节标题) | 1.1xxx(二级章节标题) | reference_index对应本章节的参考文献索引；text对应本章节的文本 |
|  | 2.xxx | 2.1xxx |  |
|  | ...| ... |  |
| other | 作者贡献声明 |  |  |
|  | 利益冲突声明 |  |  |
|  | 参考文献 |  |  |

## 开源协议
本项目使用 [MIT](LICENSE) 协议，具体可查看 [LICENSE](LICENSE) 文件。
systemPY 0.0.16
Python application component initialization system
License: MIT
Keywords: asyncio,graceful,init,initialization,shutdown,manager

# systemPY

![Logo](https://raw.githubusercontent.com/kai3341/systemPY/main/docs/images/systempy-logo.png)

Python application component initialization system

![python](https://img.shields.io/pypi/pyversions/systemPY)
![version](https://img.shields.io/pypi/v/systemPY)
![downloads](https://img.shields.io/pypi/dm/systemPY)
![format](https://img.shields.io/pypi/format/systemPY)
[![Documentation Status](https://readthedocs.org/projects/systempy/badge/?version=latest)](https://systempy.readthedocs.io/en/latest/?badge=latest)
![GitHub issues](https://img.shields.io/github/issues/kai3341/systemPY)

Full documantation is available at
[Read the Docs](https://systempy.readthedocs.io/en/latest/)

## The problem

The regular application contain many atomic components. Asyncio makes theirs
initializing a little bit complicated. It's OK, when you have single entrypoint
and initialize your application components via your framework. While you add
new components to your application iteratively, you don't see any problem

When you create any new entrypoint, you have to think a lot, how to initialize
application components again, which callbacks should be called and in which
order. But it's a half of the problem! You have to implement also graceful
shutdown

The most painful part is one-time scripts. It's kind of The Banana Gorilla
Problem: you wanted a banana but you have to initialize a gorilla holding the
banana and the entire jungle, and then graceful shutdown it

## Solution

This library allows you to implement application startup and shutdown in
declarative way. You have to implement a class for each your component,
write the startup and shutdown code. Then combine required components as
mixins into the current application `Unit` class. Then create an instance
and pass dependencies as keyword arguments. In case it's daemon run
`instance.run_sync()` methed

## Basic principles

There are 6 most significant stages of the application lifecycle:

* `on_init` executes exactly once on application startup

* `pre_startup` is called before event loop startup

* `on_startup` is called exactly when event loop started

* `on_shutdown` is called when application is going shutdown or reload but
event loop still working

* `post_shutdown` is called after event loop stopped or drained. When
application is going to reload, then it should be called `pre_startup`

* `on_exit` executes exactly once when application is stopping

You may to create `Unit` classes for each your application component where you
may put your code. Then you may combine these `Unit` class mixins into the
current worker class, which aggregate your defined callbacks and run in the
right order. Depending on application type, these callbacks may be called by
primary application or by you are