# ShowJCR puts journal impact factors and Chinese partition tables on the desktop

> ShowJCR is a C++ and Qt desktop application that searches a bundled SQLite database for a journal name and shows its impact factor, quartile, Chinese Academy of Sciences partitions, CCF ranking and warning list status side by side. It suits Chinese researchers and students who need those specific tables offline.

**hitfyd/ShowJCR** — 期刊分区查询小工具，包括新锐期刊分区表（2026）、中科院分区表升级版（2025）及国际期刊预警名单（2025、2024、2023、2021、2020）、JCR（2025、2024）、CCF推荐国际会议和期刊目录（2026）、计算领域高质量科技期刊分级目录（2025）。

- Repository: https://github.com/hitfyd/ShowJCR
- Stars: 546 · Forks: 61
- Language: C++
- License: GPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/hitfyd-showjcr

## The lookup problem this solves for Chinese researchers

ShowJCR is a desktop tool for looking up journal partition information, and the specific reason it exists is the fragmentation of the sources. The impact factor and quartile come from JCR, published by Clarivate. The partition tables come from the Chinese Academy of Sciences, and there is an upgraded version of that table which adds fields the original does not have: whether a journal is a Review, whether it is open access, the Web of Science indexing type such as SCI, SCIE, SSCI or ESCI, whether it is a Top journal, the large category partition, and one or more small category partitions. On top of that sit the CCF recommended conference and journal directory, the CCF tiered list of high quality computing journals, and the international journal warning list.

Anybody doing this by hand visits several websites, matches a journal name that may be spelled differently in each source, and reconciles rows that describe the same publication under different names. That is why the tool is not a general purpose citation database. It is a local index across these specific tables, and its value is that the answer arrives in one window.

The data itself is not small. The 2026 edition of the emerging journal partition table covers 22299 journals and 15 important conference proceedings in the computing field, drawn from sources including SCIE, SSCI and ESCI. The warning list is the opposite shape: the documentation is explicit that those tables contain only the journals on the warning list, a few dozen entries a year, and are not a complete partition table. Confusing the two would be a mistake the interface partly prevents, since the interface names them differently, showing the international warning tables under their own year labels.

The audience is narrow but large: Chinese graduate students deciding where to submit, their supervisors checking whether a journal counts, and anyone ranking journals for evaluation purposes. The application is written in C++ with a Qt interface, GPL-3.0 licensed, and it ships as a macOS app bundle and as Windows executables.

## How the lookup and the search fields work

The mechanism is a SQLite database and a set of views. The database file is called jcr.db, it sits in the resources directory of the application bundle, and the program reads the journal name you type, matches it against the tables, and shows the matching rows.

The design decision that makes this extensible is that the program has no compiled-in list of journals. Any new partition data is added as an additional table in jcr.db, with no change to the source code. The field naming rule is the part you have to get right, and it is stated clearly. The table must contain a field called Journal, which is the default search field. If Journal is not the first field, then the fields before it are also added as search fields, and their data can be queried in the program as well. The documentation gives two accepted layouts. Either the first data field is Journal, followed by columns such as an impact factor for a given year, or the first field is some other lookup key such as an abbreviated journal name or a Chinese title, with Journal as the second field, followed by a field for the field of study and a field for the CCF recommendation category.

So the search is fuzzy in practice rather than exact. Typing a journal name gets you suggestions as you type, the matching is case insensitive, and pressing Enter or clicking the query button returns the details. The visual design carries meaning: the year field is rendered in light grey so that different years of the CAS upgraded table are easy to separate from the JCR data, and fields such as the impact factor, the warning information, the large category partition and the Top marker are shown in red so the important answers stand out.

## The database is assembled by hand, and that is the maintenance cost

The jcr.db file is built from CSV files that ship with the repository, and the project is careful to say where each piece comes from. The raw files live in a directory whose name is in Chinese and translates to the original CAS partition table and JCR data files, and both the raw CSVs and the compiled jcr.db are in it. The recommended import order lists fifteen table names, and each has a matching CSV: the CAS tables FQBJCR2025, FQBJCR2023, FQBJCR2022 and FQBJCR2021, the JCR tables JCR2025 and JCR2024, the five international warning tables GJQKYJMD2025 back to GJQKYJMD2020, the CCF tables CCF2026 and CCFT2025, and the emerging table XR2026 with a companion XR2026Conferences.

Three of those can be imported with a script the project ships, and it rebuilds the FQBJCR2021, FQBJCR2022 and FQBJCR2023 tables from the CSVs when those files exist:

```bash
python3 scripts/import-fqbjcr.py
```

The 2025 CAS table is not handled by that script and has to be imported with DB Browser for SQLite, or the script has to be extended. That is the single most useful thing to know about maintaining this project, because it is the point where a fresh database and an updated one diverge.

The same applies to the build. The documentation is emphatic that make install does not run the import script, and that the macOS build only copies the existing jcr.db into the application bundle. The database content is whatever that file holds, and it is never regenerated from the CSVs during a build. So the sequence for keeping up with a new year of data is: run the import script, then build. The Makefile exposes exactly that split, with a build target and a separate import-db target that calls the script:

```bash
import-db:
	@python3 ./scripts/import-fqbjcr.py
```

The Makefile also carries build, install, rebuild, open, package and release targets, each delegating to a shell script under scripts/, so the macOS workflow is scripted end to end rather than left as manual steps.

## Building on macOS and the Windows executable options

The macOS build depends on Qt 6 installed through Homebrew, CMake, and Python 3, which is needed only for the import script. The make targets are documented with their intent: make install configures, compiles, packages with macdeployqt, signs and installs into the Applications folder, make build only produces the application bundle in the build directory, make package produces a zip archive in the dist directory named for the version, make release packages and publishes a GitHub release on a fork remote and needs the gh tool authenticated, and make open launches the installed application.

One detail in the build matters for correctness rather than convenience. During the build the jcr.db file is copied into the application bundle under Contents/Resources, and the documentation states plainly that the database content is determined by that file and is not regenerated from the CSVs at build time. That is why the import step is separate and why the build order matters.

On Windows the project offers two executable forms. The first is a ShowJCR.7z archive which you extract to any directory and run, and it needs the jcr.db file plus the Qt dependencies, with windeployqt used to collect the dependencies and the internationalisation translations folder deleted. The second is a single ShowJCR.exe that uses Enigma Virtual Box to pack all the dependencies into one executable so it can run standalone. For a researcher on a lab machine where installing a runtime is annoying, the single file form is the reason the project takes the trouble.

The application also has tray behaviour and a clipboard watcher, which are listed as four property options. It can start on login to the system tray, exit to the tray instead of quitting, watch the clipboard in the background and query automatically when the copied text is a journal name, and bring the window to the front after such an automatic query completes. That last pair is a small workflow decision with a real effect: if you copy a journal name from a PDF and switch to the app, the answer is already there.

## The data will go stale, and the interface is honest about it

The main limitation is not the software, it is the subject matter. Everything the program shows is a dated copy. The emerging partition table is the 2026 edition released on 2026-03-24. The JCR impact factors and quartiles are updated to the 2025 edition, published on 2026-06-17, with the 2024 figures kept alongside for comparison. The warning list editions span 2020, 2021, 2023, 2024 and 2025, and the 2024 edition no longer distinguishes warning levels but gives warning reasons instead. The new emerging table also no longer publishes a separate warning list, marking journals as Under Review instead. Each of those changes is a place where two readers looking at different editions can disagree.

The tool's behaviour around the data is sensible but needs one piece of user knowledge. If JCR 2025 or the CAS partition information does not appear by default, the fix given is to open the menu in the lower right corner, choose the data table selection and tick the relevant tables. In other words, the application ships every table but shows a subset by default, which is a reasonable choice for a fast start and an easy trap for a first-time user who concludes the data is missing.

There are also quirks in the underlying data that the project documents, because they will confuse anyone comparing against another database. The 2026 edition also has entries where a single journal carries two large category partitions, and where two distinct journals share a name with different ISSN numbers, such as Australasian Plant Pathology and Heart Rhythm. Australasian Plant Pathology and Heart Rhythm are two distinct journals that share a name, with different ISSN numbers. A tool that quietly returned one of them would be wrong in a way you could not detect, so the data carries the disambiguation.

A final limitation is that the licence is GPL-3.0. Using the application is unproblematic, and modifying it or distributing a build carries the copyleft obligations of that licence, which is worth checking against your organisation's rules before you fork it. For reference, the newer release notes mention that the Qt dependencies were slimmed down because of compatibility issues, with feedback welcome, which tells you the build has been fought over on macOS.

## Where a desktop lookup table is the wrong tool

If you need current data, a local copy is the wrong instrument. The JCR impact factor for a given year is published once and then changes only when the publisher reissues it, but partition tables and warning lists are revised on their own schedule by their own bodies, and a database you updated in June is wrong the moment the next edition lands. The project's own release notes show the rhythm: a new emerging partition table edition in March, a JCR update in June, and separate smaller releases for each. If your evaluation depends on the very latest edition, you need to check upstream and re-import, and the application cannot do that for you.

The second case is scale and automation. This is a window where you type a name and read an answer. It has no command line interface, no API, no bulk lookup and no export. If you are analysing thousands of journals for a paper or building a submission pipeline, you want the CSV files the project ships, loaded into a database or a script, and you would be using the raw source data rather than the application. The project is genuinely helpful here, because the CSVs and the json-schema are both in the repository, but the application is not the tool for that job.

The third case is the opposite of the second. If you do not need the Chinese specific tables at all and you just want an impact factor, a general citation database or the publisher's own page will be faster, and they will not require you to keep a local SQLite file current. ShowJCR earns its place by combining several tables that are otherwise scattered, in one offline window, with Chinese name matching and a clipboard workflow. If none of those specific tables matter to you, the combination has no value and the individual sources are simpler.

## Conclusion

Adopt ShowJCR if you regularly need to check a journal's impact factor, quartile, Chinese Academy of Sciences partition or CCF ranking and you want to do it offline against a known version. Do not adopt it as an authoritative source, since every table it carries is a dated copy that the upstream publishers update independently, and do not rely on the packaged Windows build without checking the Enigma Virtual Box variant you downloaded. Before you use a table, open the menu in the lower right and select the data tables you need, since the default view does not show every year, and note that the 2025 CAS table still has to be imported by hand into jcr.db.

## FAQ

### What is ShowJCR and which journal data does it show?

It is a C++ and Qt desktop application that looks up a journal in a bundled SQLite database and shows its JCR impact factor and quartile, the Chinese Academy of Sciences upgraded partition data, the CCF recommended directory, the CCF tiered computing journal list and the international journal warning list entries.

### How do I build ShowJCR on macOS?

You need Qt 6 from Homebrew, CMake and Python 3 for the import script. Run `make install` to configure, compile, package with macdeployqt, sign and install into the Applications folder, `make build` to only produce the bundle in build/, `make package` to create a versioned zip in dist/, and `make open` to launch the installed application.

### Why does ShowJCR not show all the year tables by default?

The default view shows only a subset. To see JCR 2025 or the Chinese Academy of Sciences partition information, open the menu in the lower right corner, choose the data table selection and tick the corresponding tables.

### How do I add new partition data to the ShowJCR database?

Add a table to jcr.db with no change to the source code, using DB Browser for SQLite to import a CSV. The table must contain a Journal field, which is the default search field, and any fields before Journal are added as search fields as well.

### Does the ShowJCR build regenerate jcr.db from the CSV files?

No. The build copies the existing jcr.db into the application bundle under Contents/Resources, and the database content is determined by that file. The import script for the 2021 to 2023 Chinese Academy of Sciences tables must be run separately before building, and the 2025 table has to be imported by hand.

### How current is ShowJCR and what licence is it under?

The repository is not archived and the last push was on 2026-09-24. The releases include v2026-1.2 on 2026-06-17 with the JCR 2025 update and slimmer Qt dependencies, and v2026-1.1 on 2026-03-27 with the 2026 emerging partition table and the 2026 CCF directory. The project is GPL-3.0 licensed.

## Sources

- [hitfyd/ShowJCR on GitHub](https://github.com/hitfyd/ShowJCR)
- [Issues](https://github.com/hitfyd/ShowJCR/issues)
- [License: GPL-3.0](https://github.com/hitfyd/ShowJCR/blob/master/LICENSE)
- [README](https://github.com/hitfyd/ShowJCR/blob/master/README.md)
- [Releases](https://github.com/hitfyd/ShowJCR/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hitfyd-showjcr