文 / 观察者说
“不做安安饿殍，犹效奋臂螳螂。” —— 明末 黄宗羲

【引言】

最近几年，一种声音甚嚣尘上：

“数学学那么深干嘛？买菜又不用解方程！”
“英语有翻译软件，何必逼孩子背单词？”
“孩子开心最重要，学习太苦会压抑天性……”

乍听之下，似乎充满人文关怀。
但若细究其后果，却令人不寒而栗——这些话，正在悄悄焊死普通家庭孩子的上升通道。

更有人批评：这是“英语碰瓷数学”，制造学科对立。
其实不然。本文想说的是：数学与英语，从来不是敌人，而是现代基础教育中缺一不可的双翼。弱化任何一方，都是对底层百姓未来的不负责任。

一、教育的根本目的：防骗、赋能、破垄断

教育的意义，远不止于“找工作”或“考大学”。它至少承担三大社会功能：

1. 防骗：知识是抵御愚昧的盾牌

一个理解基本化学的人，不会相信“假鸡蛋能以假乱真”；
一个掌握概率思维的人，不会沉迷“稳赚不赔”的理财骗局；
一个能读英文说明书的人，不会被“量子波动速读”“空气造水机”收割智商税。

正如《汉书·艺文志》所言：“民可使由之，不可使知之”——这句话常被误读为“愚民”，实则警示：若百姓无知，便易被操控。

2. 赋能：让普通人快速适应技术变革

同样是用智能手机：

• 文盲可能只会接打电话；
• 初中毕业生能学会扫码支付、视频通话、预约挂号。

这种差距，在AI与自动化时代将被急剧放大。
没有基础数学与语言能力，连“人机协作”的门槛都迈不过去。

3. 破垄断：防止知识成为少数人的特权

历史上，知识垄断必然导致阶层固化。

• 中国魏晋南北朝时期，“上品无寒门，下品无势族”（《晋书·刘毅传》），士族门阀垄断官场数百年；
• 印度种姓制度将人分为婆罗门、刹帝利、吠舍、首陀罗，甚至“不可接触者”，职业、婚姻、教育皆按血统世袭（《摩奴法典》，公元前2世纪）。

而打破这一切的，正是科举制度——它让寒门子弟凭一张考卷，也能走进庙堂。

今天，高考就是新时代的“科举”。
数学、语文、英语、科学，就是那张决定命运的试卷。

二、数学与英语，为何必须保留高要求？

有人问：日常生活中用不到微积分、用不到莎士比亚，为何要学？

这混淆了“工具性使用”与“素养性训练”。

▶ 数学：训练逻辑与抽象思维

• 解方程 ≠ 为了买菜，而是为了理解“变量”“因果”“优化”；
• 几何证明 ≠ 为了画图，而是为了建立“前提—推理—结论”的严谨链条。

正如数学家华罗庚所说：

“宇宙之大，粒子之微，火箭之速，化工之巧，地球之变，生物之谜，日用之繁，无处不用数学。”

▶ 英语：打开全球知识的大门

• 翻译软件能译句子，但译不出科学论文的逻辑脉络；
• AI 可以对话，但无法替代你直接阅读一手资料、参与国际协作。

中国工程院院士潘建伟曾坦言：

“如果没有扎实的英语能力，我们根本无法第一时间跟进量子通信的国际进展。”

数学培养“思考力”，英语拓展“信息源”——二者互补，而非互斥。

三、历史教训：放弃基础教育，等于重回种姓社会

▶ 中国：五姓七望的警示

唐代“五姓七望”（崔、卢、李、郑、王等士族），靠血统垄断政治资源近三百年。
《新唐书·柳冲传》载：“山东人士，耻与诸姓为婚，唯重旧门。”
直到科举普及、印刷术推广，知识才逐渐“去贵族化”。

▶ 印度：种姓制度的现代遗毒

尽管1947年印度宪法废除种姓制度，但教育机会仍高度不平等。
世界银行2022年报告指出：

Server Configuration Management System

The server_config.rs module provides a robust configuration management system for DICOM servers, supporting complex multi-environment deployments with flexible configuration sources.

Configuration Architecture

Multi-Source Configuration Loading

The system supports configuration loading from multiple sources:

• JSON configuration files (application.dev.json, application.test.json)
• Environment variables with prefix support
• Secure credential management

Environment-Specific Settings

Different environments (development, testing, production) can have distinct configurations while maintaining consistency through shared structures.

Core Configuration Components

Database Configuration

Supports multiple database backends including MySQL, PostgreSQL, and Doris with secure password handling and connection string generation.

Kafka Message Processing System for Medical Imaging

The [message_sender_kafka.rs] module provides robust Kafka integration for medical imaging systems, enabling scalable, reliable message processing for DICOM metadata and imaging workflows.

Message Processing Architecture

High-Throughput Design

Implements batch processing and compression to handle large volumes of medical imaging metadata with minimal resource consumption.

Reliable Delivery

Features built-in retry mechanisms and error handling to ensure message delivery even in challenging network conditions.

Topic Segregation

Uses separate Kafka topics for different message types:

Redis Key Management in DICOM Server

The redis_key.rs module is a critical component of the DICOM server infrastructure, providing high-performance caching capabilities for medical imaging metadata and authentication data. This module implements intelligent key generation and caching strategies to significantly reduce database load and improve response times.

Core Features

Authentication Caching

The module efficiently caches JWKS (JSON Web Key Set) URLs, which are essential for OAuth2/OpenID Connect authentication in medical imaging systems. This reduces authentication overhead and improves security token validation performance.

Certificate Management System for Medical Imaging

The cert_helper.rs module provides comprehensive certificate management capabilities for securing medical imaging systems, implementing Public Key Infrastructure (PKI) with X.509 certificates and OpenSSL integration.

Security Architecture

Certificate Authority (CA) Management

Implements a complete CA system for issuing and managing certificates within medical imaging environments.

Client Certificate Generation

Generates client certificates with machine-specific bindings for enhanced security.

Server Certificate Management

Creates server certificates for HTTPS and DICOM TLS connections.

Storage Configuration and Management System

The storage_config.rs module provides intelligent storage management for medical imaging systems, optimizing file organization and path management for large-scale DICOM archives.

Storage Architecture

Hierarchical Directory Structure

Implements a logical directory hierarchy based on medical imaging metadata:

• Tenant-based organization for multi-tenant deployments
• Date-based grouping for efficient retrieval
• UID-based separation for unique identification

Path Management

Generates consistent, predictable paths for all DICOM files and associated metadata.

Key Features

UID Hashing

Uses SeaHash algorithm to create fixed-length hashed identifiers for secure, predictable path generation while maintaining patient privacy.

DICOM Server Common Library

这是一个用于 DICOM 医疗影像系统的通用库，提供了各种核心功能模块。

功能模块

• DICOM-Cloud Part Tow 4.1 Common Module Introduce
• DICOM-Cloud Part Tow 4.2 storage configuration
• DICOM-Cloud Part Tow 4.3 database factory
• DICOM-Cloud Part Tow 4.4 Redis
• DICOM-Cloud Part Tow 4.4 Kafka Message Publish
• DICOM-Cloud Part Tow 4.6 Extract Dicom Information
• DICOM-Cloud Part Tow 4.7 Security
• DICOM-Cloud Part Tow 4.8 Write File To Storage

项目概述

该库旨在为 DICOM 服务器提供可重用的组件，包括配置加载、数据库访问、缓存管理、消息传递等功能。

GoTo Summary : how-to-build-cloud-dicom

title: “DICOM File Transfer and Conversion - Medical Imaging Format Transformation” description: “Learn how DICOM file transfer and conversion capabilities handle various medical imaging transfer syntaxes with GDCM integration for seamless format transformation.” keywords: [“DICOM conversion”, “medical imaging”, “file transfer”, “transfer syntax”, “GDCM integration”, “image processing”, “format transformation”] date: 2024-01-01T00:00:00+08:00 draft: false

DICOM File Transfer and Conversion System

The [change_file_transfer.rs] module provides comprehensive DICOM file transfer syntax conversion capabilities, enabling seamless format transformation for medical imaging systems using GDCM integration.

DICOM Object Metadata Extraction System

The [dicom_object_meta.rs] module provides comprehensive extraction capabilities for DICOM medical imaging metadata, processing hundreds of standardized DICOM tags to create structured data representations.

Metadata Categories

Patient Information

Extracts critical patient identifiers and demographics:

• Patient name, ID, and demographics
• Birth date and sex
• Medical record numbers
• Accession numbers

Study Metadata

Processes study-level information:

• Study instance UID and description
• Study date and time
• Referring physician information
• Study ID and accession numbers

Series Information

Handles series-specific data:

1. 概述

   在这个篇文章中，我们将介绍如何使用Rust实现一个可扩展的云DICOM-WEB服务，该服务支持多种数据库模式，如MySQL、PostgreSQL和MongoDB。

2. 准备工作 接口定义,或是说是 trait 定义

dicom_dbprovider.rs

use crate::dicom_meta::{DicomJsonMeta, DicomStateMeta};
use async_trait::async_trait;
use thiserror::Error;

#[derive(Error, Debug)]
pub enum DbError {
    #[error("Database operation failed: {0}")]
    DatabaseError(String),

    #[error("DataRow not exists: {0}")]
    RecordNotExists(String),


    #[error("Record already exists")]
    AlreadyExists,

    #[error("Entity extraction failed: {0}")]
    ExtractionFailed(String),

    #[error("Transaction failed: {0}")]
    TransactionFailed(String),
}
pub fn current_time() -> chrono::NaiveDateTime {
    chrono::Local::now().naive_local()
}
#[async_trait]
pub trait DbProvider: Send + Sync {
    async fn save_state_info(&self, state_meta: &DicomStateMeta) -> Result<(), DbError>;

    async fn save_state_list(&self, state_meta: &[DicomStateMeta]) -> Result<(), DbError>;

    async fn save_json_list(&self, state_meta: &[DicomJsonMeta]) -> Result<(), DbError>;

    async fn get_state_metaes(
        &self,
        tenant_id: &str,
        study_uid: &str,
    ) -> Result<Vec<DicomStateMeta>, DbError>;


    /*
     * 获取需要生成JSON格式的Metadata的序列信息.
     * end_time: 截止时间.
     */
    async fn get_json_metaes(&self, end_time: chrono::NaiveDateTime) -> Result<Vec<DicomStateMeta>, DbError>;

    async fn get_json_meta(&self, tenant_id:&str, study_uid: &str, series_uid: &str)->Result<DicomJsonMeta, DbError>;
}

3. 实现

3.1 MySQL数据库实现

DICOM 网关（DICOM Gateway）是一种专门用于在不同医疗信息系统之间转换、路由、适配或处理 DICOM数据流的中间件系统。

它通常部署在网络边界或系统集成点，起到“协议转换器”、“数据路由器”和“数据预处理器”的作用。

一、DICOM 网关是什么？

从概念上讲，DICOM 网关是传统网络“网关”在医学影像领域的具体应用：

连接不同协议/格式系统：例如将传统的 DICOM C-STORE（基于 TCP 的 DIMSE 协议）转换为现代的 DICOMweb（基于 HTTP/REST 的 WADO/QIDO/STOW）。

实现跨系统互操作性：如连接老旧 PACS 与云原生影像平台（如 Azure Health Data Services、Google Healthcare API）。

执行数据预处理：如去标识化（de-identification）、元数据标准化、图像压缩、格式转换等。

二、DICOM 网关需要实现哪些核心功能？

一个完整的 DICOM 网关通常需支持以下功能模块：

1. DICOM DIMSE 支持（传统协议）

• 接收/发送 C-ECHO、C-STORE、C-FIND、C-MOVE 等服务类用户（SCU/SCP）请求。
• 支持 AETitle（应用实体标题）认证与过滤。
• 处理 DICOM 关联（Association）建立与释放。

2. DICOMweb 支持（现代 Web API）

• 实现 STOW-RS（上传）、WADO-RS（下载）、QIDO-RS（查询）。
• 支持 multipart/related 或 single-part 上传。
• 兼容 FHIR ImagingStudy 等扩展标准（可选）。

3. 数据路由与转发

• 根据规则（如 Modality、StudyInstanceUID、AETitle）将 DICOM 实例转发到一个或多个目标（PACS、云服务、AI引擎等）。
• 支持失败重试、队列管理、流量控制。

4. 数据处理与转换

• 去标识化（De-identification）：移除或替换患者隐私信息（如 PatientName, PatientID），符合 HIPAA 或 GDPR。
• 元数据标准化：统一不同设备厂商的标签写法（如将 Siemens 的私有标签映射为标准标签）。
• 图像格式转换：如将 JPEG2000 转为 JPEG-LS，或将多帧转为单帧序列。

5. 日志、监控与审计

• 记录所有接收/转发事件。
• 提供健康检查接口（如 /healthz）。
• 支持 Prometheus/Grafana 监控（现代网关常见）。

6. 安全机制

• TLS 加密（DICOM over TLS、HTTPS）。
• 身份认证（API Key、OAuth2、JWT）。
• IP 白名单/AETitle 白名单。

三、有哪些开源的 DICOM 网关项目可供参考？

引言

在 DICOM 医疗影像系统中，数据的准确性和一致性至关重要。本文将深入探讨如何使用 Rust 的类型系统来创建自定义的安全类型封装，以防止运行时错误并提高代码的可维护性。

BoundedString：长度限制字符串

BoundedString<N> 是一个泛型结构体，用于确保字符串长度不超过指定的 N 个字符。

FixedLengthString：固定长度字符串

FixedLengthString<N> 确保字符串长度恰好为 N 个字符，这在处理某些 DICOM 字段时非常有用。

DicomDateString：DICOM 日期格式

DICOM 标准要求日期字段使用 YYYYMMDD 格式，DicomDateString 类型专门用于处理这种格式。

类型系统的优势

1. 编译时保证

通过这些自定义类型，许多数据验证错误可以在编译时就被发现，而不是在运行时才暴露。

2. 明确的意图表达

类型名称本身就表达了数据的约束条件，使代码更具可读性和自文档化。

3. 防止错误传递

一旦数据通过类型验证，后续代码可以假设数据格式是正确的，无需重复验证。

具体实现:

1.dicom_dbtype.rs

use serde::{Deserialize, Serialize};
use snafu::Snafu;
use std::fmt;
use std::hash::Hash;

#[derive(Debug, Snafu)]
#[non_exhaustive]
pub enum BoundedStringError {
    #[snafu(display("String too long: {} > {}", len, max))]
    TooLong { max: usize, len: usize },
    #[snafu(display("String length is: {}  and  expected: {}", len, fixlen))]
    LengthError { fixlen: usize, len: usize },
}

type BoundedResult<T, E = BoundedStringError> = Result<T, E>;

#[derive(Debug, Clone, Serialize, Deserialize)]
#[serde(transparent)]
#[derive(Default)]
pub struct BoundedString<const N: usize> {
    value: String,
}

impl<const N: usize> fmt::Display for BoundedString<N> {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        write!(f, "{}", self.value)
    }
}

impl<const N: usize> BoundedString<N> {
    pub fn new(s: String) -> BoundedResult<BoundedString<N>> {
        if s.len() > N {
            Err(BoundedStringError::TooLong {
                max: N,
                len: s.len(),
            })
        } else {
            Ok(Self { value: s })
        }
    }
    pub fn from_str(s: &str) -> BoundedResult<BoundedString<N>> {
        if s.len() > N {
            Err(BoundedStringError::TooLong {
                max: N,
                len: s.len(),
            })
        } else {
            Ok(Self {
                value: s.to_string(),
            })
        }
    }
    pub fn from_string(s: &String) -> BoundedResult<BoundedString<N>> {
        if s.len() > N {
            Err(BoundedStringError::TooLong {
                max: N,
                len: s.len(),
            })
        } else {
            Ok(Self { value: s.clone() })
        }
    }
    pub fn as_str(&self) -> &str {
        &self.value
    }

    // 使用 deref 方式访问
    pub fn as_ref(&self) -> &String {
        &self.value
    }
}
impl<const N: usize> Hash for BoundedString<N> {
    fn hash<H: std::hash::Hasher>(&self, state: &mut H) {
        self.value.hash(state);
    }
}

impl<const N: usize> PartialEq for BoundedString<N> {
    fn eq(&self, other: &Self) -> bool {
        self.value == other.value
    }
}

impl<const N: usize> Eq for BoundedString<N> {}

impl<const N: usize> TryFrom<&str> for BoundedString<N> {
    type Error = BoundedStringError;
    fn try_from(s: &str) -> BoundedResult<Self> {
        BoundedString::from_str(s)
    }
}

#[derive(Debug, Clone, Serialize, Deserialize)]
#[serde(transparent)]
pub struct FixedLengthString<const N: usize> {
    pub(crate) value: String,
}

impl<const N: usize> Hash for FixedLengthString<N> {
    fn hash<H: std::hash::Hasher>(&self, state: &mut H) {
        self.value.hash(state);
    }
}

impl<const N: usize> PartialEq for FixedLengthString<N> {
    fn eq(&self, other: &Self) -> bool {
        self.value == other.value
    }
}

impl<const N: usize> Eq for FixedLengthString<N> {}

/// DICOM文件中的表示日期的字符串，格式为 YYYYMMDD, 长度为 8, 例如 "20231005"
#[derive(Debug, Clone, Serialize, Deserialize, PartialEq, Eq, Hash)]
#[serde(transparent)]
pub struct DicomDateString {
    pub(crate) value: String,
}

// 为 DicomDateString 实现 Display trait
impl fmt::Display for DicomDateString {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        write!(f, "{}", self.value)
    }
}

impl TryFrom<&str> for DicomDateString {
    type Error = BoundedStringError;
    fn try_from(s: &str) -> BoundedResult<Self> {
        // 使用 NaiveDate 验证日期格式和有效性
        chrono::NaiveDate::parse_from_str(&s, "%Y%m%d").map_err(|_| {
            BoundedStringError::LengthError {
                fixlen: 8,
                len: s.len(),
            }
        })?;
        Ok(Self {
            value: s.to_string(),
        })
    }
}

impl TryFrom<&String> for DicomDateString {
    type Error = BoundedStringError;
    fn try_from(s: &String) -> BoundedResult<Self> {
        // 使用 NaiveDate 验证日期格式和有效性
        chrono::NaiveDate::parse_from_str(&s, "%Y%m%d").map_err(|_| {
            BoundedStringError::LengthError {
                fixlen: 8,
                len: s.len(),
            }
        })?;
        Ok(Self { value: s.clone() })
    }
}

impl<const N: usize> FixedLengthString<N> {
    pub fn new(s: String) -> BoundedResult<FixedLengthString<N>> {
        if s.len() != N {
            Err(BoundedStringError::LengthError {
                fixlen: N,
                len: s.len(),
            })
        } else {
            Ok(Self { value: s })
        }
    }

    pub fn from_str(s: &str) -> BoundedResult<FixedLengthString<N>> {
        if s.len() != N {
            Err(BoundedStringError::LengthError {
                fixlen: N,
                len: s.len(),
            })
        } else {
            Ok(Self {
                value: s.to_string(),
            })
        }
    }

    pub fn from_string(s: &String) -> BoundedResult<FixedLengthString<N>> {
        if s.len() != N {
            Err(BoundedStringError::LengthError {
                fixlen: N,
                len: s.len(),
            })
        } else {
            Ok(Self { value: s.clone() })
        }
    }

    pub fn as_str(&self) -> &str {
        &self.value
    }
}

impl DicomDateString {
    pub fn as_str(&self) -> &str {
        self.value.as_str()
    }

    pub(crate) fn from_db(s: &str) -> Self {
        // 使用 NaiveDate 验证日期格式和有效性
        chrono::NaiveDate::parse_from_str(&s, "%Y%m%d")
            .map_err(|_| BoundedStringError::LengthError {
                fixlen: 8,
                len: s.len(),
            })
            .expect(
                format!(
                    "DicomDateString::make_from_db  only support YYYYMMDD format, but got {}",
                    s
                )
                .as_str(),
            );

        Self {
            value: s.to_string(),
        }
    }
}

2. dicom_meta.rs

   Read more →

本项目展示了如何在 Rust 中构建一个健壮、类型安全的数据库访问层，特别适用于需要严格数据验证的医疗领域应用。通过抽象接口和具体实现分离的设计，系统可以轻松扩展支持更多类型的数据库，同时保证了代码的可维护性和可测试性。

核心设计概念

1. 类型安全的数据结构

项目中定义了几个关键的类型安全封装：

• BoundedString: 限制长度的字符串类型
• FixedLengthString: 固定长度的字符串类型
• DicomDateString: 专门用于 DICOM 日期格式的字符串类型

// 示例：BoundedString 的定义
#[derive(Debug, Clone, Serialize, Deserialize)]
#[serde(transparent)]
pub struct BoundedString<const N: usize> {
    value: String,
}

2. 统一的数据库访问接口

通过 DbProvider trait 抽象了数据库操作接口：

#[async_trait]
pub trait DbProvider: Send + Sync {
    async fn save_state_info(&self, state_meta: &DicomStateMeta) -> Result<(), DbError>;
    async fn save_state_list(&self, state_meta: &[DicomStateMeta]) -> Result<(), DbError>;
    async fn save_json_list(&self, state_meta: &[DicomJsonMeta]) -> Result<(), DbError>;
    // ... 其他方法
}

3. 数据库类型适配

MySQL MySqlDbProvider 结构体实现了针对 MySQL 数据库的操作：

本文介绍了一个基于 Rust 语言开发的 DICOM 医疗影像系统架构设计，该系统采用现代化的技术栈，包括 PostgreSQL 作为主索引数据库、Apache Doris 用于日志存储、RedPanda 作为消息队列以及 Redis 作为缓存。系统设计支持单机运行和分布式扩展，充分利用了 Rust 语言的安全性和性能优势。

DICOM 医疗影像系统架构概览及运行环境介绍

核心组件

• PostgreSQL: 主索引数据库，存储患者、检查、序列等核心元数据
• Apache Doris: 日志存储，记录 DICOM CStoreSCP 服务和 WADO-RS 服务访问日志
• RedPanda: 消息队列，处理系统间异步通信
• Redis: 缓存层，提升系统响应速度
• Rust: 开发语言，利用 dicom-rs 库处理 DICOM 数据

服务模块

• wado-storescp: DICOM CStoreSCP 服务，接收 DICOM 文件并写入磁盘
• wado-consumer: 消费消息队列中的存储事件，提取元数据并写入数据库
• wado-server: DICOM WEB WADO-RS API 接口实现
• wado-webworker: 定期生成 JSON 格式的元数据用于加速访问

数据库设计

• PostgreSQL 主索引数据库
• PostgreSQL 作为主索引数据库存储核心元数据，包括:
• dicom_state_meta: 存储患者、检查、序列级别的元数据
• dicom_json_meta: 记录需要生成 JSON 格式元数据的序列信息

Apache Doris 日志存储

文 / 观察者说
首发于 | 深度观察·教育公平专栏

【导语】

“孩子开心最重要，学那么多干嘛？”
“数学买菜用不上，英语有翻译软件就够了。”

这些话听起来温柔体贴，实则暗藏杀机。
它们正在悄悄剥夺普通家庭孩子唯一能靠自己改变命运的机会——
系统性基础教育。

今天，我们必须戳破这个“善意谎言”：
弱化数学、取消英语、鼓吹快乐，不是减负，是断路。

一、你以为的“无用”，其实是底层的“护甲”

很多人说：“我工作十几年，一次都没用过二次函数。”
但教育的目的，从来不是为了“日常使用”，而是为了打开可能性、建立免疫力。

• 一个理解概率的人，不会轻信“稳赚不赔”的理财骗局；
• 一个会查英文资料的学生，能直接接触全球前沿技术；
• 一个逻辑清晰的青年，不容易被煽动、操控、收割。

知识不是工具，而是盾牌。
一旦我们以“生活中用不到”为由砍掉基础学科，义务教育就退化成“识字班”——只教认字算账，不教思考判断。

结果？
底层永远停留在执行层，而真正的技术、资本与话语权，继续牢牢掌握在少数人手中。

二、历史早已警告：知识垄断 = 社会死亡

中国唐代“五姓七望”靠门第垄断官场数百年；
印度种姓制度将人分为“天生高贵”与“生来卑贱”。

《晋书》那句“上品无寒门，下品无势族”，至今读来仍令人脊背发凉。

而打破这一切的，正是科举制度——它让寒门子弟凭一张考卷，也能走进庙堂。

今天，高考就是新时代的“科举”。
数学、语文、英语、理综，就是那张决定命运的试卷。

如果你现在说“这些科目太难，孩子快乐更重要”，
等于主动放弃入场券，把孩子推回“世袭阶层”的牢笼。

三、现实更残酷：全球都在上演“知识门阀化”

▶ 印度：种姓阴影从未散去

尽管宪法废除种姓制度，但教育机会仍高度不平等。
世界银行2022年报告指出：

高种姓群体进入高等教育的比例是低种姓的3倍以上；
顶尖理工学院（IITs）中，农村和低种姓学生占比长期低于15%。

许多私立精英学校甚至拒收“无英语基础”的学生——而英语能力，恰恰与家庭阶层绑定。

▶ 美国：精英教育的“隐形高墙”

哈佛大学2023年新生中：

近70%来自全美收入前20%的家庭，
而底层20%家庭的孩子仅占约4%（Harvard Gazette, 2023）。

通往藤校的跳板——如菲利普斯安多弗高中，录取率仅11%，年学费超47万人民币，入学需SSAT成绩碾压90%同龄人。

所谓“快乐教育”，只属于公立学校；真正的精英，从小就在高强度学术训练中厮杀。

▶ 中国：清北农村学子比例持续走低

北京大学2020年新生中，农村户籍学生仅占14.8%；
清华大学同期约为17%（国家统计局数据显示，农村人口占比约36%）。

若无“国家专项计划”强制干预，顶尖高校正自然滑向“城市中产俱乐部”。

一旦基础教育降低标准，农村孩子连参与竞争的资格都将丧失。

四、中国的奇迹，正源于全民基础教育

为什么中国能成为“世界工厂”并迈向智造强国？
不是因为有几个天才，而是因为数亿劳动者具备基础科学素养。

• 数控机床操作员要懂坐标系；
• 无人机飞手要知道100KG、12A, 220V,10KM的意思；
• 外卖员要会用导航;

这些能力，都源于义务教育阶段打下的底子。

如果我们现在听信“无用论”，取消难度、弱化课程，
未来的高精尖产业，谁来支撑？

【结语】教育不是消费，而是权利

“不做安安饿殍，犹效奋臂螳螂。”
——明末思想家黄宗羲

Read more →

1-Step How To Use FoDICOM To Construct DICOM CStoreSCU Tool, Batch Send DICOM Files For Testing And Verification

FoDICOM is a powerful open-source DICOM library written in C#. It provides a wide range of features for working with DICOM data, including support for reading, writing, and manipulating DICOM files. In this tutorial, we will use FoDICOM to construct a DICOM CStoreSCU tool, which can be used to batch send DICOM files for testing and verification purposes.

如何利用开源项目,构建分布式DICOM-WEB服务.

总体架构

1. Apache-kafka 作为消息队列.开发阶段可用RedPanda 替代.
2. Apache-Doris 作为数据仓库.提供DicomStateMeta,DicomImageMeta 及WadoAccessLog 存储,提供查询及统计分析.
3. PostgreSQL 作为数据库.提供数据存储功能.及检查索引功能.只存储PatientInformation,StudyInformation,SeriesInformation 这一级别的元数据.充分利用关系数据库的ACID特性.后续可用Citus进行扩容.
4. Redis 作为缓存.提供数据缓存功能.
5. Nginx 作为反向代理服务器.提供负载均衡,静态文件,TLS透传等

收图文件服务接收的文件,先存储到本地,再通过 kafka 发送到消息队列.

MessageBody = { TransferSyntax, SopInstancheUID, StudyInstanceUID,SeriesInstanceUID, PatientID, FileName, FileSize, FilePath }

消息分发到多个队列:

1. 存储队列: 存储文件信息,文件存储路径,文件大小.
2. 索引队列: 提取文件TAG信息, 包括PatientInfomation, StudyInformation, SeriesInformation, ImageInformation.并写入Doris库
3. 转换队列: 对于部分传输语法,因为Cornerstone3D无法解析,需要转换成CornerstoneJS能够解析的格式.转换失败的写入Doris转换记录表.

服务用途及说明

wado-server

DICOM Web WADO-RS API 接口实现 ,根据配置选项决定是否开启 OAuth2 认证.

wado-storescp

DICOM CStoreSCP 服务,接收DICOM文件并写入磁盘,同是分发消息到Kafka:  storage_queue,log_queue      
- 1.存储文件路径: ${ROOT}/<TenantID>/<StudyInstanceUID>/<SeriesInstanceUID>/<SopInstanceUID>.dcm
- 2.往消息队列: storage_queue ,log_queue 发送消息

wado-consumer

消费Kafka消息队列storage_queue ,提取DicomStateMeta 到主数据库,并通过消息队列:dicom_state_queue,dicom_image_queue发布DicomStateMeta,DicomImageMeta 到Doris数据库
- 1.从storage-queue读,往dicom_state_queue,dicom_image_queue写
- 2.提取DicomStateMeta 到主数据库,
- 3.通过消息队列:dicom_state_queue,dicom_image_queue发布DicomStateMeta,DicomImageMeta 到Doris数据库 Stream_Load 模式

wado-webworker

定期扫描数据库,根据最后更新时间生成JSON格式的metadata用于加速WADO-Server的访问

总结

后续的相关子系统的介绍均围绕这里的进行展开.

在 .NET 项目中使用 NLog 记录日志的好处

NLog 是一个功能强大、灵活且高性能的日志记录框架，广泛应用于 .NET（包括 .NET Framework、.NET Core 和 .NET 5/6/7/8+）应用程序中。在 .NET 项目中集成 NLog 可显著提升系统的可观测性、可维护性和调试效率。以下是使用 NLog 的主要优势说明。

一、核心优势

1. 高性能与低开销

• NLog 经过高度优化，采用异步写入、缓冲和批处理机制，对应用程序性能影响极小。
• 支持异步日志（async="true"），避免 I/O 阻塞主线程。

2. 灵活的配置方式

• 支持通过 XML 配置文件（如 nlog.config）进行外部化配置，无需重新编译代码即可调整日志行为。
• 也支持 代码方式配置，适用于动态场景或云原生环境。

3. 丰富的输出目标（Targets）

NLog 支持将日志同时写入多种目标，包括：

• 文件（按日期/大小自动滚动）
• 控制台
• 数据库（SQL Server、PostgreSQL 等）
• Windows 事件日志
• Elasticsearch、Graylog、Seq 等日志聚合平台
• 电子邮件、HTTP 端点、消息队列等

4. 强大的日志过滤与路由

• 可基于日志级别（Trace、Debug、Info、Warn、Error、Fatal）、日志来源（Logger 名称）、自定义条件进行精细路由。
• 支持“规则链”（Rules），实现复杂的日志分发逻辑。

5. 结构化日志支持

• 原生支持结构化日志（Structured Logging），便于与现代日志分析工具（如 Serilog + Seq、ELK）集成。
• 使用 ${message}、${event-properties:item=...} 等布局渲染器提取结构化字段。

6. 自动日志文件管理

• 内置日志文件归档策略：按时间（每日/每小时）、按大小（如 10MB）自动分割。
• 可配置最大保留文件数或总大小，防止磁盘爆满。

7. 跨平台兼容性

• 完全支持 .NET Standard，可在 Windows、Linux、macOS 上运行。
• 适用于 ASP.NET Core、WPF、WinForms、控制台应用、Azure Functions、MAUI 等各类 .NET 项目。

8. 活跃的社区与持续维护

• 开源（MIT 许可）、文档完善、更新频繁，拥有庞大的用户社区和丰富的插件生态。

二、典型应用场景

三、简单示例

1. 安装 NuGet 包

dotnet add package NLog
dotnet add package NLog.Web.AspNetCore  # ASP.NET Core 项目推荐

2. 创建配置文件 nlog.config

<?xml version="1.0" encoding="utf-8"?>

<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      autoReload="true"
      internalLogLevel="Info"
      internalLogFile=".\internal-nlog.txt">

    <!-- 定义日志输出的 target -->
    <targets>
        <!-- 输出到文件，按大小滚动 -->
        <target name="logfile"
                xsi:type="File"
                fileName="logs/logfile.log"
                layout="${longdate}|${level:uppercase=true}|${logger}|${message} ${exception:format=tostring}"
                maxArchiveFiles="10"
                archiveAboveSize="5242880"
                archiveFileName="logs/archived/logfile.{#}.log"
                archiveNumbering="Sequence"
                keepFileOpen="false"
                concurrentWrites="true"
                enableFileDelete="true" />
        <!-- 输出到文件，按大小滚动 -->
        <target name="errorFile"
                xsi:type="File"
                fileName="logs/error.log"
                layout="${longdate}|${level:uppercase=true}|${logger}|${message} ${exception:format=tostring}"
                maxArchiveFiles="10"
                archiveAboveSize="5242880"
                archiveFileName="logs/archived/logfile.{#}.log"
                archiveNumbering="Sequence"
                keepFileOpen="false"
                concurrentWrites="true"
                enableFileDelete="true" />

        <target name="console"
                xsi:type="ColoredConsole"
                layout="${longdate}|${level:uppercase=true}|${logger}|${message} ${exception:format=tostring}">
            <!-- 为不同日志级别配置不同颜色 -->
            <highlight-row condition="level == LogLevel.Debug" foregroundColor="DarkGray" />
            <highlight-row condition="level == LogLevel.Info" foregroundColor="Gray" />
            <highlight-row condition="level == LogLevel.Warn" foregroundColor="Yellow" />
            <highlight-row condition="level == LogLevel.Error" foregroundColor="Red" />
            <highlight-row condition="level == LogLevel.Fatal" foregroundColor="Red" backgroundColor="White" />

        </target>
    </targets>

    <rules>
        <!-- 规则：所有日志都输出到 logfile -->
        <logger name="*" minlevel="Info" writeTo="logfile" />
        <logger name="*" minlevel="Debug" writeTo="console" />
        <logger name="*" minlevel="Error" writeTo="errorFile" />
    </rules>
</nlog>

3. 使用NLog

using FellowOakDicom;
using Microsoft.Extensions.Configuration;
using NLog;

namespace change_ts;

internal class Program
{
    // 获取当前类日志记录器
    private static readonly Logger Logger = LogManager.GetCurrentClassLogger();

    static async Task Main()
    {
        // 在 DicomSetupBuilder 之前添加
        System.Text.Encoding.RegisterProvider(System.Text.CodePagesEncodingProvider.Instance); 
        // 创建 CancellationTokenSource 来处理 Ctrl+C 信号
        var cancellationTokenSource = new CancellationTokenSource();
        Console.CancelKeyPress += (_, e) =>
        {
            e.Cancel = true; // 阻止程序立即退出
            Logger.Info("收到 Ctrl+C 信号，正在优雅关闭...");
            cancellationTokenSource.Cancel();
        };
        try
        {
            new DicomSetupBuilder()
                .RegisterServices(s =>
                    s.AddFellowOakDicom()
                        .AddTranscoderManager<FellowOakDicom.Imaging.NativeCodec.NativeTranscoderManager>())
                .SkipValidation()
                .Build();

            // 确保日志目录存在
            var logDir = Path.Combine(AppContext.BaseDirectory, "logs");
            var archivedDir = Path.Combine(logDir, "archived");

            if (!Directory.Exists(logDir))
                Directory.CreateDirectory(logDir);

            if (!Directory.Exists(archivedDir))
                Directory.CreateDirectory(archivedDir);

            Logger.Info("🚀 应用程序启动，NLog 日志配置成功！");

            // 创建配置构建器来读取 appsettings.json
            var configuration = new ConfigurationBuilder()
                .SetBasePath(AppContext.BaseDirectory)
                .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
                .Build(); 

            Console.WriteLine("XXXX启动中...");
 
            Logger.Info("XXXX已启动，服务正在运行中... 按 Ctrl+C 退出");

            // 等待取消信号
            await Task.Delay(Timeout.Infinite, cancellationTokenSource.Token);
        }
        catch (OperationCanceledException)
        {
            // 正常的取消操作，不需要记录错误
            Logger.Info("应用程序正在关闭...");
        }
        catch (Exception ex)
        {
            // 记录内部异常到 NLog（如果配置了 internalLogFile 也会记录 NLog 自己的错误）
            Logger.Error(ex, "程序因异常停止");
            throw;
        }
        finally
        { 
            // 确保所有日志都写入磁盘并关闭资源
            LogManager.Shutdown();
        }
    }
}

运行程序时，NLog 会自动创建日志目录和文件，并记录应用程序的启动和运行信息。当程序接收到 Ctrl+C 信号时，NLog 会记录应用程序正在关闭的信息。如果程序因为异常而停止，NLog 会记录异常信息。

修改 DICOM 文件传输语法的目的及好处

在医学影像处理与交换过程中，传输语法（Transfer Syntax） 是 DICOM 标准中用于定义数据编码方式的关键组成部分。它决定了 DICOM 文件中数据元素的字节序、值表示（VR）是否显式声明，以及像素数据是否经过压缩。因此，修改 DICOM 文件的传输语法是一种常见且重要的操作，具有明确的目的和显著的好处。

一、目的

1. 兼容性适配

不同厂商的 PACS（Picture Archiving and Communication System）、工作站或 DICOM 查看器可能仅支持特定的传输语法。将文件转换为接收方支持的语法，可确保顺利导入与显示。

2. 存储优化

通过将图像从无压缩格式（如 Implicit VR Little Endian）转换为压缩格式（如 JPEG Lossless 或 JPEG-LS），可大幅减小文件体积，节省存储空间与网络带宽。

3. 性能提升

某些系统对显式 VR（Explicit VR）格式解析更快；而另一些系统则偏好隐式 VR（Implicit VR）。调整传输语法可优化读取/写入性能。

4. 满足归档或传输标准

医院或区域医疗信息平台常规定统一的传输语法（如强制使用 Explicit VR Little Endian），以确保数据一致性与长期可读性。

二、好处

三、常见传输语法转换示例

⚠️ 注意：有损压缩（如 JPEG Baseline）会丢失原始像素信息，不适用于诊断用途；无损压缩（如 JPEG-LS、JPEG 2000 Lossless）则可在压缩的同时保留全部诊断信息。

Read more →

DICOM基础概念

DICOM（Digital Imaging and Communications in Medicine）是医学影像及其相关信息的国际标准（ISO 12052），用于存储、交换和传输医学图像及相关数据。DICOM 文件不仅包含像素数据（即图像本身），还包含大量描述该图像的元数据，这些元数据以“数据元素”（Data Elements）的形式组织在“信息对象定义”（Information Object Definition, IOD）中。

• ✅ 一、DICOM 文件的核心结构

  • 文件头（File Meta Information）

    • 固定长度为 128 字节的前导（通常全为 0x00，可选）
    • 4 字节的 DICOM 前缀 “DICM”
    • 文件元信息组（Group 0002），包含：
      • (0002,0000) File Meta Information Group Length
      • (0002,0001) File Meta Information Version
      • (0002,0002) Media Storage SOP Class UID
      • (0002,0003) Media Storage SOP Instance UID
      • (0002,0010) Transfer Syntax UID
      • (0002,0012) Implementation Class UID
      • (0002,0013) Implementation Version Name

  • 数据集（Dataset）

    • 包含实际的图像信息和元数据，遵循特定的 IOD（如 CT Image IOD、MR Image IOD 等）
    • 数据元素按标签（Tag）组织，格式为 (gggg,eeee)，其中 gggg 是组号，eeee 是元素号
    • 每个数据元素包括：Tag、VR（Value Representation）、Value Length、Value

• ✅ 二、核心信息对象（IOD）结构说明

  Read more →