simdutf 8.0.0-ok1 source package in openKylin

Changelog

simdutf (8.0.0-ok1) huanghe; urgency=medium

  * Build for openKylin.

 -- openKylinBot <email address hidden>  Wed, 06 May 2026 16:54:24 +0800

Upload details

Uploaded by:
openKylinBot
Sponsored by:
luoyaoming
Uploaded to:
Huanghe V3.0
Original maintainer:
Openkylin Developers
Architectures:
any
Section:
libs
Urgency:
Medium Urgency

Publishing See full publishing history

Series Pocket Published Component Section
Huanghe V3.0 proposed main libs

Downloads

File Size SHA-256 Checksum
simdutf_8.0.0.orig.tar.xz 1.5 MiB 7057f02198434b809b0aec7207871907831e1b31d95fd5129fa73029fa060c00
simdutf_8.0.0-ok1.debian.tar.xz 4.8 KiB 9470c34e6a2c2e77b3473eda5ba6ffe355db756ea036a258349e67774838dd63
simdutf_8.0.0-ok1.dsc 1.9 KiB 8c5bc038b7d38995333fbdd5972e4e10c1be3564d8697c227005a917cf2b0ce6

View changes file

Binary packages built by this source

libsimdutf-dev: Fast Unicode validation and transcoding - development files

 Most modern software relies on the Unicode standard. In memory, Unicode
 strings are represented using either UTF-8 or UTF-16. The UTF-8 format is the
 de facto standard on the web (JSON, HTML, etc.) and it has been adopted as the
 default in many popular programming languages (Go, Zig, Rust, Swift, etc.).
 The UTF-16 format is standard in Java, C# and in many Windows technologies.
 .
 Not all sequences of bytes are valid Unicode strings. It is unsafe to use
 Unicode strings in UTF-8 and UTF-16LE without first validating them.
 Furthermore, we often need to convert strings from one encoding to another, by
 a process called transcoding. For security purposes, such transcoding should
 be validating: it should refuse to transcode incorrect strings.
 .
 This library provide fast Unicode functions such as
 .
  * ASCII, UTF-8, UTF-16LE/BE and UTF-32 validation, with and without error
    identification,
  * Latin1 to UTF-8 transcoding,
  * Latin1 to UTF-16LE/BE transcoding
  * Latin1 to UTF-32 transcoding
  * UTF-8 to Latin1 transcoding, with or without validation, with and without
    error identification,
  * UTF-8 to UTF-16LE/BE transcoding, with or without validation, with and
    without error identification,
  * UTF-8 to UTF-32 transcoding, with or without validation, with and without
    error identification,
  * UTF-16LE/BE to Latin1 transcoding, with or without validation, with and
    without error identification,
  * UTF-16LE/BE to UTF-8 transcoding, with or without validation, with and
    without error identification,
  * UTF-32 to Latin1 transcoding, with or without validation, with and without
    error identification,
  * UTF-32 to UTF-8 transcoding, with or without validation, with and without
    error identification,
  * UTF-32 to UTF-16LE/BE transcoding, with or without validation, with and
    without error identification,
  * UTF-16LE/BE to UTF-32 transcoding, with or without validation, with and
    without error identification,
  * From an UTF-8 string, compute the size of the Latin1 equivalent string,
  * From an UTF-8 string, compute the size of the UTF-16 equivalent string,
  * From an UTF-8 string, compute the size of the UTF-32 equivalent string
    (equivalent to UTF-8 character counting),
  * From an UTF-16LE/BE string, compute the size of the Latin1 equivalent
    string,
  * From an UTF-16LE/BE string, compute the size of the UTF-8 equivalent
    string,
  * From an UTF-32 string, compute the size of the UTF-8 or UTF-16LE equivalent
    string,
  * From an UTF-16LE/BE string, compute the size of the UTF-32 equivalent
    string (equivalent to UTF-16 character counting),
  * UTF-8 and UTF-16LE/BE character counting,
  * UTF-16 endianness change (UTF16-LE/BE to UTF-16-BE/LE),
  * WHATWG forgiving-base64 (with or without URL encoding) to binary,
  * Binary to base64 (with or without URL encoding).
 .
 The functions are accelerated using SIMD instructions (e.g., ARM NEON, SSE,
 AVX, AVX-512, RISC-V Vector Extension, LoongSon, POWER, etc.). When your
 strings contain hundreds of characters, we can often transcode them at speeds
 exceeding a billion characters per second. You should expect high speeds not
 only with English strings (ASCII) but also Chinese, Japanese, Arabic, and so
 forth. We handle the full character range (including, for example, emojis).
 .
 The library compiles down to a small library of a few hundred kilobytes. Our
 functions are exception-free and non allocating. We have extensive tests and
 extensive benchmarks.
 .
 This package ships the development files.

libsimdutf-tools: Fast Unicode validation and transcoding - utilities

 Most modern software relies on the Unicode standard. In memory, Unicode
 strings are represented using either UTF-8 or UTF-16. The UTF-8 format is the
 de facto standard on the web (JSON, HTML, etc.) and it has been adopted as the
 default in many popular programming languages (Go, Zig, Rust, Swift, etc.).
 The UTF-16 format is standard in Java, C# and in many Windows technologies.
 .
 Not all sequences of bytes are valid Unicode strings. It is unsafe to use
 Unicode strings in UTF-8 and UTF-16LE without first validating them.
 Furthermore, we often need to convert strings from one encoding to another, by
 a process called transcoding. For security purposes, such transcoding should
 be validating: it should refuse to transcode incorrect strings.
 .
 This library provide fast Unicode functions such as
 .
  * ASCII, UTF-8, UTF-16LE/BE and UTF-32 validation, with and without error
    identification,
  * Latin1 to UTF-8 transcoding,
  * Latin1 to UTF-16LE/BE transcoding
  * Latin1 to UTF-32 transcoding
  * UTF-8 to Latin1 transcoding, with or without validation, with and without
    error identification,
  * UTF-8 to UTF-16LE/BE transcoding, with or without validation, with and
    without error identification,
  * UTF-8 to UTF-32 transcoding, with or without validation, with and without
    error identification,
  * UTF-16LE/BE to Latin1 transcoding, with or without validation, with and
    without error identification,
  * UTF-16LE/BE to UTF-8 transcoding, with or without validation, with and
    without error identification,
  * UTF-32 to Latin1 transcoding, with or without validation, with and without
    error identification,
  * UTF-32 to UTF-8 transcoding, with or without validation, with and without
    error identification,
  * UTF-32 to UTF-16LE/BE transcoding, with or without validation, with and
    without error identification,
  * UTF-16LE/BE to UTF-32 transcoding, with or without validation, with and
    without error identification,
  * From an UTF-8 string, compute the size of the Latin1 equivalent string,
  * From an UTF-8 string, compute the size of the UTF-16 equivalent string,
  * From an UTF-8 string, compute the size of the UTF-32 equivalent string
    (equivalent to UTF-8 character counting),
  * From an UTF-16LE/BE string, compute the size of the Latin1 equivalent
    string,
  * From an UTF-16LE/BE string, compute the size of the UTF-8 equivalent
    string,
  * From an UTF-32 string, compute the size of the UTF-8 or UTF-16LE equivalent
    string,
  * From an UTF-16LE/BE string, compute the size of the UTF-32 equivalent
    string (equivalent to UTF-16 character counting),
  * UTF-8 and UTF-16LE/BE character counting,
  * UTF-16 endianness change (UTF16-LE/BE to UTF-16-BE/LE),
  * WHATWG forgiving-base64 (with or without URL encoding) to binary,
  * Binary to base64 (with or without URL encoding).
 .
 The functions are accelerated using SIMD instructions (e.g., ARM NEON, SSE,
 AVX, AVX-512, RISC-V Vector Extension, LoongSon, POWER, etc.). When your
 strings contain hundreds of characters, we can often transcode them at speeds
 exceeding a billion characters per second. You should expect high speeds not
 only with English strings (ASCII) but also Chinese, Japanese, Arabic, and so
 forth. We handle the full character range (including, for example, emojis).
 .
 The library compiles down to a small library of a few hundred kilobytes. Our
 functions are exception-free and non allocating. We have extensive tests and
 extensive benchmarks.
 .
 This package ships several command line tools.

libsimdutf31: Fast Unicode validation and transcoding

 Most modern software relies on the Unicode standard. In memory, Unicode
 strings are represented using either UTF-8 or UTF-16. The UTF-8 format is the
 de facto standard on the web (JSON, HTML, etc.) and it has been adopted as the
 default in many popular programming languages (Go, Zig, Rust, Swift, etc.).
 The UTF-16 format is standard in Java, C# and in many Windows technologies.
 .
 Not all sequences of bytes are valid Unicode strings. It is unsafe to use
 Unicode strings in UTF-8 and UTF-16LE without first validating them.
 Furthermore, we often need to convert strings from one encoding to another, by
 a process called transcoding. For security purposes, such transcoding should
 be validating: it should refuse to transcode incorrect strings.
 .
 This library provide fast Unicode functions such as
 .
  * ASCII, UTF-8, UTF-16LE/BE and UTF-32 validation, with and without error
    identification,
  * Latin1 to UTF-8 transcoding,
  * Latin1 to UTF-16LE/BE transcoding
  * Latin1 to UTF-32 transcoding
  * UTF-8 to Latin1 transcoding, with or without validation, with and without
    error identification,
  * UTF-8 to UTF-16LE/BE transcoding, with or without validation, with and
    without error identification,
  * UTF-8 to UTF-32 transcoding, with or without validation, with and without
    error identification,
  * UTF-16LE/BE to Latin1 transcoding, with or without validation, with and
    without error identification,
  * UTF-16LE/BE to UTF-8 transcoding, with or without validation, with and
    without error identification,
  * UTF-32 to Latin1 transcoding, with or without validation, with and without
    error identification,
  * UTF-32 to UTF-8 transcoding, with or without validation, with and without
    error identification,
  * UTF-32 to UTF-16LE/BE transcoding, with or without validation, with and
    without error identification,
  * UTF-16LE/BE to UTF-32 transcoding, with or without validation, with and
    without error identification,
  * From an UTF-8 string, compute the size of the Latin1 equivalent string,
  * From an UTF-8 string, compute the size of the UTF-16 equivalent string,
  * From an UTF-8 string, compute the size of the UTF-32 equivalent string
    (equivalent to UTF-8 character counting),
  * From an UTF-16LE/BE string, compute the size of the Latin1 equivalent
    string,
  * From an UTF-16LE/BE string, compute the size of the UTF-8 equivalent
    string,
  * From an UTF-32 string, compute the size of the UTF-8 or UTF-16LE equivalent
    string,
  * From an UTF-16LE/BE string, compute the size of the UTF-32 equivalent
    string (equivalent to UTF-16 character counting),
  * UTF-8 and UTF-16LE/BE character counting,
  * UTF-16 endianness change (UTF16-LE/BE to UTF-16-BE/LE),
  * WHATWG forgiving-base64 (with or without URL encoding) to binary,
  * Binary to base64 (with or without URL encoding).
 .
 The functions are accelerated using SIMD instructions (e.g., ARM NEON, SSE,
 AVX, AVX-512, RISC-V Vector Extension, LoongSon, POWER, etc.). When your
 strings contain hundreds of characters, we can often transcode them at speeds
 exceeding a billion characters per second. You should expect high speeds not
 only with English strings (ASCII) but also Chinese, Japanese, Arabic, and so
 forth. We handle the full character range (including, for example, emojis).
 .
 The library compiles down to a small library of a few hundred kilobytes. Our
 functions are exception-free and non allocating. We have extensive tests and
 extensive benchmarks.
 .
 This package ships the shared object.