深度实战：Rust交叉编译适配OpenHarmony PC——ansi_term完整适配案例

Ne0inhk

— 22 min read
深度实战：Rust交叉编译适配OpenHarmony PC——ansi_term完整适配案例


🎨 深度实战：Rust交叉编译适配OpenHarmony PC——ansi_term完整适配案例

引言：

嘿，亲爱的技术爱好者们，大家好！我是ZEEKLOG（全区域）四榜榜首青云交！本文将围绕 Rust 交叉编译适配 OpenHarmony PC 的ansi_term完整适配案例展开详细介绍，从背景信息、环境准备，到项目分析、问题解决等方面，为大家呈现完整的适配案例，助力大家掌握相关技术要点。

在这里插入图片描述

正文：

接下来将详细阐述ansi_term在 OpenHarmony PC 平台的适配过程，包括背景介绍、环境准备、项目结构分析等多个方面，帮助大家全面了解这一技术实践。

一、背景介绍

1.1 ansi_term 工具简介

ansi_term 是一个用 Rust 编写的 ANSI 终端颜色和样式控制库，提供了丰富的终端文本格式化功能。本项目基于 ansi_term 库创建了一个命令行工具，用于演示和测试 ANSI 终端颜色功能。

1.1.1 核心功能
  • 16 种基本颜色：支持标准 ANSI 16 色（8 种标准色 + 8 种粗体色）
  • 256 色扩展：支持 256 色扩展调色板
  • RGB 真彩色：支持 24 位 RGB 真彩色显示
  • 文本样式：支持粗体、下划线、斜体、模糊、闪烁、反转、隐藏等样式
  • 组合样式：支持多种样式组合使用
  • 性能优化：使用 ANSIStrings 优化 ANSI 转义序列输出
1.1.2 应用场景
  • 终端美化工具开发
  • 命令行工具输出格式化
  • 终端 UI 开发
  • 日志输出美化
  • 开发调试工具

1.2 适配目标

将 ansi_term 命令行工具适配到鸿蒙 PC（OpenHarmony PC）平台，实现：

  • Rust 项目交叉编译支持
  • 支持 aarch64-linux-ohos 架构
  • 使用 OHOS SDK 工具链进行编译
  • 生成 HNP 格式的安装包
  • 生成 tar.gz 格式的发布包
  • 提供可执行的ansi_term命令

1.3 技术栈

  • 语言: Rust 2015 Edition
  • 构建系统: Cargo
  • 目标平台: aarch64-linux-ohos
  • 打包格式: HNP (HarmonyOS Native Package)
  • 编译工具链: OHOS SDK Native LLVM (clang/ld.lld)

1.4 工具优势

相比直接使用 ANSI 转义序列，ansi_term 提供了：

  • 类型安全: Rust 类型系统保证颜色和样式的正确使用
  • 零成本抽象：编译时优化，运行时性能优异
  • 易于使用：简洁的 API，链式调用风格
  • 跨平台：支持 Unix 和 Windows 平台
  • 功能丰富：支持多种颜色模式和文本样式
在这里插入图片描述

二、环境准备

2.1 系统要求

  • 开发环境: macOS / Linux / Windows (WSL)
  • Python: Python 3.x
  • Rust: Rust 1.66.1+（项目通过rust-toolchain.toml自动管理）
  • Cargo: Rust 包管理器（随 Rust 安装）
  • 鸿蒙 SDK: OHOS SDK (包含 native 工具链和 hnpcli 打包工具)

2.2 SDK 安装

2.2.1 下载 SDK
# 下载鸿蒙SDKcd ~ wget https://cidownload.openharmony.cn/version/Master_Version/ohos-sdk-full_ohos/20250819_020817/version-Master_Version-ohos-sdk-full_ohos-20250819_020817-ohos-sdk-full_ohos.tar.gz # 解压SDKtar -zvxf version-Master_Version-ohos-sdk-full_ohos-20250819_020817-ohos-sdk-full_ohos.tar.gz
2.2.2 SDK 目录结构
ohos-sdk/ ├── native/ │ ├── llvm/bin/ # 编译器工具链 │ ├── sysroot/ # 系统根目录（头文件和库） │ └── build-tools/ # 构建工具 └── toolchains/ └── hnpcli # HNP打包工具

2.3 Rust 环境配置

2.3.1 自动安装

项目包含rust-toolchain.toml文件，Cargo 会自动安装指定版本的 Rust：

[toolchain] channel = "1.66.1"
2.3.2 手动验证
rustc --version # 应显示 rustc 1.66.1 或更高版本 cargo --version # 应显示 cargo 1.66.1 或更高版本

三、项目结构分析

3.1 目录结构

ansi_term4oh/ ├── Cargo.toml # Rust项目配置 ├── Cargo.lock # 依赖版本锁定文件 ├── build_ohos.sh # OpenHarmony构建脚本 ├── hnp.json # HNP包配置 ├── README.md # 项目说明 ├── LICENCE # 许可证文件 ├── src/ # 源代码目录 │ ├── lib.rs # 库代码（ansi_term库） │ ├── main.rs # 命令行工具主程序 │ ├── ansi.rs # ANSI转义序列处理 │ ├── style.rs # 样式定义 │ ├── display.rs # 显示格式化 │ ├── write.rs # 写入操作 │ ├── util.rs # 工具函数 │ ├── debug.rs # 调试功能 │ ├── difference.rs # 差异比较 │ └── windows.rs # Windows平台支持 └── examples/ # 示例代码 ├── basic_colours.rs # 基本颜色示例 ├── 256_colours.rs # 256色示例 └── rgb_colours.rs # RGB颜色示例

3.2 Cargo.toml 关键配置

[package] name = "ansi_term" description = "Library for ANSI terminal colours and styles (bold, underline)" version = "0.12.1" edition = "2015" # 使用2015版本以兼容旧代码 [lib] name = "ansi_term" [[bin]] name = "ansi_term" path = "src/main.rs" # 命令行工具入口 [dependencies.serde] version = "1.0.90" features = ["derive"] optional = true [target.'cfg(target_os="windows")'.dependencies.winapi] version = "0.3.4" features = ["consoleapi", "errhandlingapi", "fileapi", "handleapi", "processenv"] [features] derive_serde_style = ["serde"]
3.2.1 关键配置说明
  • Edition 2015: 使用 Rust 2015 版本以兼容 ansi_term 库的旧代码风格
  • Binary 配置：添加了[[bin]]配置，定义命令行工具入口
  • 可选依赖: serde 用于序列化支持（可选）
  • Windows 支持: winapi 仅在 Windows 平台编译

3.3 命令行工具设计

3.3.1 main.rs 核心功能
// 支持的命令- basic /16- 显示16种基本颜色 -256- 显示256色扩展 - rgb - 显示RGB真彩色渐变 - styles - 显示各种文本样式 - demo - 显示所有演示 - help - 显示帮助信息
3.3.2 设计特点
  • 模块化设计，每个功能独立函数
  • 友好的命令行界面
  • 丰富的演示功能
  • 彩色输出展示

四、问题诊断与解决

4.1 问题 1: 缺少命令行工具入口

4.1.1 问题描述

ansi_term 原本是一个库（library），没有命令行工具入口。需要创建一个main.rs文件来实现命令行功能。

4.1.2 错误示例
error: could not find `main` function
4.1.3 解决方案
  • 创建src/main.rs文件，实现命令行工具逻辑
  • 在Cargo.toml中添加[[bin]]配置：
[[bin]] name = "ansi_term" path = "src/main.rs"

4.2 问题 2: Rust Edition 兼容性

4.2.1 问题描述

ansi_term 库使用 Rust 2015 edition 的代码风格，在较新的 Rust 版本中会产生警告。

4.2.2 警告示例
warning: trait objects without an explicit `dyn` are deprecated warning: no edition set: defaulting to the 2015 edition
4.2.3 解决方案

在Cargo.toml中明确指定 edition：

[package] edition = "2015" # 明确指定版本
4.2.4 影响
  • 警告不影响编译和运行
  • 保持与原始库的兼容性
  • 功能完全正常

4.3 问题 3: extern crate 声明

4.3.1 问题描述

在 Rust 2015 edition 中，需要在代码中显式声明extern crate。

4.3.2 错误示例
error[E0432]: unresolved import `ansi_term`
4.3.3 解决方案

在main.rs开头添加extern crate声明：

externcrateansi_term;useansi_term::{Style,Colour,ANSIString,ANSIStrings};

4.4 问题 4: 交叉编译架构不匹配（Exec format error）

4.4.1 问题描述

在 OpenHarmony PC 上执行ansi_term --help时出现错误：

ansi_term: cannot execute binary file: Exec format error
4.4.2 原因分析
  1. 架构不匹配：二进制文件是在 macOS 上编译的（Mach-O 格式），而不是 Linux 格式
  2. 缺少交叉编译：默认cargo build会编译 host 平台的二进制文件
  3. 目标平台: OpenHarmony PC 需要 Linux ARM64（ELF 格式）的二进制文件
4.4.3 错误示例
# 在OpenHarmony PC上执行 $ ansi_term --help ansi_term: cannot execute binary file: Exec format error # 检查二进制文件格式（在macOS上） $ file ansi_term ansi_term: Mach-O 64-bit executable arm64 # macOS格式
4.4.4 解决方案
4.4.4.1 方案 1: 使用 musl target 交叉编译（推荐）

OpenHarmony 使用 musl libc，可以使用aarch64-unknown-linux-musl target 进行交叉编译：

# 1. 安装musl target rustup target add aarch64-unknown-linux-musl # 2. 配置Cargo交叉编译# 创建 .cargo/config.toml[target.aarch64-unknown-linux-musl] linker ="clang" ar ="llvm-ar" rustflags =["-C", "link-arg=--target=aarch64-linux-ohos", "-C", "link-arg=--sysroot=${SYSROOT}", "-C", "link-arg=-fuse-ld=lld", ]# 3. 修改build_ohos.shexportCARGO_TARGET_AARCH64_UNKNOWN_LINUX_MUSL_LINKER="${CC}"exportRUSTFLAGS="-Clink-arg=--target=${TARGET_PLATFORM} -Clink-arg=--sysroot=${SYSROOT} -Clink-arg=-fuse-ld=lld" cargo build --release --target aarch64-unknown-linux-musl BIN=target/aarch64-unknown-linux-musl/release/ansi_term
4.4.4.2 验证
# 检查二进制文件格式 $ file ansi_term ansi_term: ELF 64-bit LSB executable, ARM aarch64, version 1(SYSV), statically linked # Linux格式# 在OpenHarmony PC上执行 $ ansi_term --help ansi_term 命令行工具 用法: ansi_term <命令>...
4.4.4.3 关键修改点
  • 使用--target aarch64-unknown-linux-musl指定目标平台
  • 配置链接器为 OHOS SDK 的 clang
  • 设置 sysroot 和链接参数
  • 二进制文件路径改为target/aarch64-unknown-linux-musl/release/
4.4.4.4 注意事项
  • 在 macOS 上无法直接执行 Linux 二进制文件，这是正常的
  • 构建脚本中的验证步骤会显示 “cannot execute binary file”，可以忽略
  • 二进制文件在 OpenHarmony PC 上可以正常运行

五、详细修改步骤

5.1 步骤 1: 创建命令行工具入口

5.1.1 文件
src/main.rs

创建命令行工具主程序，实现以下功能：

  • 命令解析
  • 16 色基本颜色演示
  • 256 色扩展演示
  • RGB 真彩色演示
  • 文本样式演示
  • 帮助信息
5.1.2 关键代码片段
externcrateansi_term;useansi_term::{Style,Colour,ANSIString,ANSIStrings};fnmain(){let args:Vec<String>=std::env::args().collect();if args.len()<2{print_usage();return;}match args[1].as_str(){"basic"|"16"=>demo_basic_colours(),"256"=>demo_256_colours(),"rgb"=>demo_rgb_colours(),"styles"=>demo_styles(),"demo"=>demo_all(),"help"|"-h"|"--help"=>print_usage(), _ =>{println!("{}",Colour::Red.paint("未知命令"));print_usage();}}}

5.2 步骤 2: 更新 Cargo.toml 配置

5.2.1 文件
Cargo.toml

添加以下配置：

[package] edition = "2015" # 明确指定Rust版本 [[bin]] name = "ansi_term" path = "src/main.rs"

5.3 步骤 3: 配置交叉编译

5.3.1 文件
.cargo/config.toml

创建 Cargo 配置文件，设置交叉编译参数：

[target.aarch64-unknown-linux-musl] linker = "clang" ar = "llvm-ar" rustflags = [ "-C", "link-arg=--target=aarch64-linux-ohos", "-C", "link-arg=--sysroot=${SYSROOT}", "-C", "link-arg=-fuse-ld=lld", ]
5.3.2 文件
build_ohos.sh

修改构建脚本，使用交叉编译：

# 使用musl target进行交叉编译（OpenHarmony使用musl libc）if! rustup target list --installed |grep -q "aarch64-unknown-linux-musl";thenecho"Installing aarch64-unknown-linux-musl target..." rustup target add aarch64-unknown-linux-musl fiexportCARGO_TARGET_AARCH64_UNKNOWN_LINUX_MUSL_LINKER="${CC}"exportRUSTFLAGS="-Clink-arg=--target=${TARGET_PLATFORM} -Clink-arg=--sysroot=${SYSROOT} -Clink-arg=-fuse-ld=lld" cargo build --release --target aarch64-unknown-linux-musl BIN=target/aarch64-unknown-linux-musl/release/ansi_term

5.4 步骤 4: 验证 HNP 配置

5.4.1 文件
hnp.json 
{"type":"hnp-config","name":"ansi_term","version":"0.12.2","install":{}}

六、构建验证

6.1 执行构建

cd /Users/baixm/HarmonyOSPC/build ./build.sh --sdk /Users/baixm/ohos-sdk --module ansi_term4oh

6.2 构建输出

6.2.1 成功输出示例
Build in: <Darwin Mac 24.6.0 ...> by cross tool chains. python : Python 3.9.13 CC : /Users/baixm/ohos-sdk/native/llvm/bin/clang ... Installation prefix: /Users/baixm/HarmonyOSPC/data/service/hnp/ansi_term.org/ansi_term_0.12.2 Building ansi_term command-line tool... Compiling ansi_term v0.12.1 Finished `release` profile [optimized] target(s) in 0.48s ansi_term installed successfully ansi_term 命令行工具 用法: ansi_term <命令> ... [INFO][HNP][hnp_pack.c:116]PackHnp end. ... ret=0 Creating tar.gz archive... a ansi_term_0.12.2 a ansi_term_0.12.2/bin a ansi_term_0.12.2/bin/ansi_term ... ✅ Build completed successfully!
6.2.2 构建警告说明
  • Rust 2015 edition 的警告是正常的，不影响功能
  • 在 macOS 上无法执行 Linux 二进制文件是正常的（会显示 “cannot execute binary file”）
  • 编译成功，二进制文件生成正常

6.3 验证二进制文件格式

6.3.1 在 macOS 上验证
file${ANSI_TERM_INSTALL_HNP_PATH}/bin/ansi_term
6.3.2 预期输出
ansi_term: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, not stripped
6.3.3 关键信息
  • ELF - Linux 可执行文件格式
  • ARM aarch64 - ARM64 架构
  • statically linked - 静态链接，无外部依赖
6.3.4 错误格式示例（如果未交叉编译）
ansi_term: Mach-O 64-bit executable arm64 # macOS格式，无法在Linux上运行

6.4 验证输出文件

ls -lh output/ |grep ansi_term
6.4.1 预期输出
-rw-r--r-- 1 user staff XXXK Nov 24 12:00 ansi_term.hnp -rw-r--r-- 1 user staff XXXK Nov 24 12:00 ohos_ansi_term_0.12.2.tar.gz

6.5 验证安装目录结构

tree ${HNP_PUBLIC_PATH}/ansi_term.org/ansi_term_0.12.2/
6.5.1 预期结构
ansi_term_0.12.2/ ├── bin/ │ └── ansi_term # 可执行文件 ├── share/ │ └── man/ │ └── man1/ # 手册页目录（空） └── hnp.json # HNP包配置

七、使用示例

7.1 基本使用

7.1.1 显示帮助信息
# 在OpenHarmony PC终端执行 ansi_term help# 或 ansi_term -h # 或 ansi_term --help
7.1.1.1 输出示例
ansi_term 命令行工具 用法: ansi_term <命令> 可用命令: basic, 16 - 显示16种基本颜色 256 - 显示256色扩展 rgb - 显示RGB真彩色渐变 styles - 显示各种文本样式 demo - 显示所有演示 help - 显示帮助信息
image-20251202095448651
7.1.2 显示 16 种基本颜色
# 在OpenHarmony PC终端执行 ansi_term basic # 或 ansi_term 16
7.1.2.1 输出示例
=== 16种基本颜色演示 === Normal Bold Black Black Bold Red Red Bold Green Green Bold Yellow Yellow Bold Blue Blue Bold Purple Purple Bold Cyan Cyan Bold White White Bold 背景色示例: 红色文字，白色背景 绿色文字，黑色背景 蓝色文字，黄色背景
image-20251202095529755
7.1.3 显示 256 色扩展
# 在OpenHarmony PC终端执行 ansi_term 256
7.1.3.1 输出示例
=== 256色扩展演示 === 标准颜色 (0-15): 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 颜色方块 (16-231): [显示6x6x6的颜色方块网格] 灰度色阶 (232-255): [显示灰度渐变条]
image-20251202095608019
7.1.4 显示 RGB 真彩色渐变
# 在OpenHarmony PC终端执行 ansi_term rgb
7.1.4.1 输出示例
=== RGB 24位真彩色演示 === RGB渐变示例: [显示40x8的RGB渐变网格] 常用颜色示例: Steel Blue Coral Lime Green Gold Violet
image-20251202095634660
7.1.5 显示文本样式
# 在OpenHarmony PC终端执行 ansi_term styles
7.1.5.1 输出示例
=== 文本样式演示 === 粗体: Bold Text 下划线: Underlined Text 斜体: Italic Text 模糊: Dimmed Text 闪烁: Blinking Text 反转: Reversed Text 隐藏: Hidden Text 组合样式: 粗体 + 下划线 绿色粗体，黑色背景 蓝色下划线，黄色背景 ANSIStrings 优化示例: 值: [重要信息]
image-20251202095734049
7.1.6 显示所有演示
# 在OpenHarmony PC终端执行 ansi_term demo
7.1.6.1 输出示例
[依次显示所有演示内容]
image-20251202095808356

7.2 常见问题排查

7.2.1 问题 1: Exec format error
7.2.1.1 症状
$ ansi_term --help ansi_term: cannot execute binary file: Exec format error
7.2.1.2 原因
  • 二进制文件格式不正确（可能是 macOS 格式而非 Linux 格式）
  • 未使用交叉编译，编译了 host 平台的二进制文件
7.2.1.3 解决方案
  • 验证构建脚本中的 target 配置

重新交叉编译：

cargo build --release --target aarch64-unknown-linux-musl

检查二进制文件格式：

file ansi_term # 应该是: ELF 64-bit LSB executable, ARM aarch64
7.2.2 问题 2: 动态链接库缺失
7.2.2.1 症状
$ ansi_term --help ansi_term: error while loading shared libraries: libc.so: cannot open shared object file
7.2.2.2 原因
  • 使用了动态链接，但目标系统缺少库文件
7.2.2.3 解决方案
  • 使用静态链接（musl target 默认静态链接）
  • 确保使用--target aarch64-unknown-linux-musl

7.3 实际应用场景

7.3.1 在脚本中使用
#!/bin/bash# 使用ansi_term美化脚本输出echo"$(ansi_term basic |grep -A 1"Green")"echo"$(ansi_term styles |grep"粗体")"
7.3.2 终端美化
# 创建彩色提示符exportPS1="$(ansi_term rgb |head -1)"
7.3.3 日志输出美化
# 在应用程序中使用ansi_term库# 输出彩色日志信息

7.4 高级用法

7.4.1 组合使用
# 连续执行多个命令 ansi_term basic && ansi_term styles
7.4.2 输出重定向
# 保存输出到文件 ansi_term demo > ansi_demo.txt # 管道处理 ansi_term 256|grep"颜色"

八、总结与最佳实践

8.1 适配要点总结

8.1.1 命令行工具创建
  • 从库项目转换为可执行工具
  • 创建main.rs实现命令行逻辑
  • 在Cargo.toml中添加[[bin]]配置
8.1.2 构建脚本适配
  • 修正安装路径变量名
  • 修正二进制文件名
  • 移除不必要的文件复制
  • 添加安装验证步骤
8.1.3 Rust 版本兼容
  • 明确指定 Rust 2015 edition
  • 使用extern crate声明
  • 处理编译警告
8.1.4 打包配置
  • 配置 HNP 包信息
  • 生成 HNP 和 tar.gz 包
  • 验证安装目录结构

8.2 最佳实践

8.2.1 项目结构
  • 保持库和命令行工具分离
  • 使用模块化设计
  • 提供清晰的命令行接口
8.2.2 构建流程
  • 使用set -e确保错误时退出
  • 验证关键文件存在
  • 提供清晰的构建日志
8.2.3 代码质量
  • 处理所有错误情况
  • 提供友好的错误消息
  • 使用彩色输出提升用户体验
8.2.4 文档完善
  • 提供使用示例
  • 说明命令参数
  • 记录已知问题

九、附录

9.1 完整文件清单

9.1.1 创建的文件
  • src/main.rs - 命令行工具主程序
  • build_ohos.sh - OpenHarmony 构建脚本（重写）
  • .cargo/config.toml - Cargo 交叉编译配置
  • aarch64-linux-ohos.json - Rust target spec 文件（备用）
9.1.2 修改的文件
  • Cargo.toml - 添加 binary 配置和 edition 设置
9.1.3 生成的文件
  • output/ansi_term.hnp - HNP 格式安装包
  • output/ohos_ansi_term_0.12.2.tar.gz - tar.gz 格式发布包

9.2 参考命令

# 构建命令 ./build.sh --sdk /path/to/ohos-sdk --module ansi_term4oh # 查看构建输出ls -lh output/ |grep ansi_term # 验证安装目录 tree ${HNP_PUBLIC_PATH}/ansi_term.org/ansi_term_0.12.2/ # 验证二进制文件格式（在macOS上）file${HNP_PUBLIC_PATH}/ansi_term.org/ansi_term_0.12.2/bin/ansi_term # 应该显示: ELF 64-bit LSB executable, ARM aarch64# 验证二进制文件格式（在macOS上）file${HNP_PUBLIC_PATH}/ansi_term.org/ansi_term_0.12.2/bin/ansi_term # 应该显示: ELF 64-bit LSB executable, ARM aarch64# 测试命令（在OpenHarmony PC上）exportPATH=${HNP_PUBLIC_PATH}/ansi_term.org/ansi_term_0.12.2/bin:$PATH ansi_term help ansi_term demo # 如果出现"cannot execute binary file"错误，检查：# 1. 二进制文件格式是否正确（应为ELF格式）# 2. 是否使用了交叉编译（--target aarch64-unknown-linux-musl）# 3. 链接方式是否为静态链接# 如果出现"cannot execute binary file"错误，检查：# 1. 二进制文件格式是否正确（应为ELF格式）# 2. 是否使用了交叉编译（--target aarch64-unknown-linux-musl）# 3. 链接方式是否为静态链接

9.3 版本信息

  • ansi_term 版本: 0.12.1
  • 适配日期: 2025-12-2
  • 目标平台: aarch64-linux-ohos
  • Rust 版本: 1.66.1 (Edition 2015)
  • 依赖数量: 0 个直接依赖（纯库项目）
  • 源仓库地址: https://github.com/ogham/rust-ansi-term
  • 适配完成仓库地址：https://gitcode.com/szkygc/ansi_term4oh

9.4 相关资源

  • ansi_term 文档: https://docs.rs/ansi_term/
  • GitHub 仓库: https://github.com/ogham/rust-ansi-term
  • Crates.io: https://crates.io/crates/ansi_term
  • ANSI 转义序列: https://en.wikipedia.org/wiki/ANSI_escape_code

9.5 技术说明

9.5.1 ANSI 转义序列简介

ANSI 转义序列是用于控制终端文本颜色、样式和光标位置的标准化代码。ansi_term 库提供了类型安全的 API 来生成这些序列。

9.5.2 常见 ANSI 转义序列
  • \x1b[31m - 红色前景
  • \x1b[1m - 粗体
  • \x1b[4m - 下划线
  • \x1b[0m - 重置所有样式
9.5.3 ansi_term 的优势
  • 类型安全：编译时检查颜色和样式
  • 零成本抽象：编译时优化
  • 易于使用：简洁的 API
  • 跨平台：自动处理平台差异
在这里插入图片描述

结束语：

通过本文的详细介绍，我们全面了解了ansi_term命令行工具在 OpenHarmony PC 平台的适配过程，从背景、环境到具体操作步骤和问题解决，为开发者提供了清晰的指引。希望大家能借此掌握相关技术，更好地进行终端应用开发。

诚邀各位参与投票，关于 Rust 交叉编译适配 OpenHarmony，你最关注哪个方面？快来投票。

🗳️参与投票和联系我：

返回文章

Read more

【AIGC实战】蓝耘元生代部署通义万相2.1文生视频，up主亲测好用~

【AIGC实战】蓝耘元生代部署通义万相2.1文生视频，up主亲测好用~

文章目录 * 👏什么是文生视频？ * 👏通义万相2.1文生视频 * 👏开源仓库代码 * 👏蓝耘元生代部署通义万相2.1文生视频 * 👏平台注册 * 👏部署通义万相2.1文生视频 * 👏使用通义万相2.1文生视频 * 👏总结 👏什么是文生视频？ 文生视频（Text-to-Video）是利用人工智能技术，通过文本描述生成视频内容的一种创新技术。类似于图像生成技术，文生视频允许用户通过输入简单的文本描述，AI模型会自动将其转化为动态视频。这种技术广泛应用于创作、广告、教育等领域，为内容创作者提供了新的创作方式和灵感。 👏通义万相2.1文生视频 IT之家 1 月 10 日消息，阿里旗下通义万相宣布推出 2.1 版本模型升级，视频生成、图像生成两大能力均有显著提升。 在视频生成方面，通义万相 2.1 通过自研的高效 VAE 和 DiT 架构增强了时空上下文建模能力，支持无限长 1080P 视频的高效编解码，

By Ne0inhk

VsCode远程Copilot无法使用Claude Agent问题

最近我突然发现vscode Copilot中Claude模型突然没了，我刚充的钱啊！没有Claude我还用啥Copilot 很多小伙伴知道要开代理，开完代理后确实Claude会出来，本地使用是没有任何问题的，但是如果使用远程ssh的话，会出现访问异常，连接不上的情况。这时候很多小伙伴就在网上寻找方法，在vscode setting中添加这么一段代码。可以看看这篇博客 "http.proxy": "http://127.0.0.1:1082", "remote.extensionKind": { "GitHub.copilot": [ "ui" ], "GitHub.copilot-chat": [ "ui" ], "pub.name": [ "ui&

By Ne0inhk
LLaMA Factory 核心原理讲解

LLaMA Factory 核心原理讲解

大家好，我是herosunly。985院校硕士毕业，现担任算法研究员一职，热衷于大模型算法的研究与应用。曾担任百度千帆大模型比赛、BPAA算法大赛评委，编写微软OpenAI考试认证指导手册。曾获得阿里云天池比赛第一名，CCF比赛第二名，科大讯飞比赛第三名。授权多项发明专利。对机器学习和深度学习拥有自己独到的见解。曾经辅导过若干个非计算机专业的学生进入到算法行业就业。希望和大家一起成长进步。 本文主要介绍了LLaMA Factory 核心原理讲解，希望能对学习大模型的同学们有所帮助。 文章目录 * 1. 前言 * 2. 核心模块讲解 * 3. SFT流程讲解 1. 前言 在之前的文章主要介绍了LLaMA Factory的操作方法，其中包括： * LLaMA Factory多卡微调的实战教程 * 基于华为昇腾910B和LLaMA Factory多卡微调的实战教程 * LLaMA Factory添加新模型template的实战解析 * LLaMA Factory在预测阶段时添加原有问题的实战代码 * 详解大模型多轮对话的数据组织形式 但也有同学提出疑问

By Ne0inhk

告别复杂操作：灵感画廊极简AI绘画体验

告别复杂操作：灵感画廊极简AI绘画体验 "见微知著，凝光成影。将梦境的碎片，凝结为永恒的视觉诗篇。" 你是否曾经被复杂的AI绘画工具劝退？参数太多、界面太乱、学习成本太高...现在，这一切都将成为过去。灵感画廊（Atelier of Light and Shadow）基于Stable Diffusion XL 1.0打造，却彻底摒弃了工业化的复杂界面，为你提供一个如艺术沙龙般恬静的创作空间。 1. 为什么选择灵感画廊？ 传统的AI绘画工具往往让人望而生畏。密密麻麻的参数滑块、晦涩难懂的技术术语、需要反复调试的复杂设置...这些都不是创作者想要的。 灵感画廊完全不同。它相信：真正的创作应该专注于灵感本身，而不是技术细节。 这里没有"提示词"，只有"梦境描述"；没有"反向词"

By Ne0inhk