Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Variant field names not being ordered correctly via UTF-8 byte order

Fermée
  • Quelque chose ne va pas ?
#3,735 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 2 jours

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
68/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
java
Domaine
data-engineering

Piste de recherche

Commencez par VariantBuilder et Variant.getFieldByKey, puis reproduisez le problème à l’aide d’un objet comportant un nom de champ du plan supplémentaire et suffisamment de champs pour déclencher une recherche binaire. Vérifiez que les identifiants de champ suivent l’ordre des octets UTF-8 et que la recherche aboutit pour les objets produits à la fois par parquet-java et par des writers conformes à la spécification.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Type: bug
Describe the bug, including details regarding any error messages, version, and platform.

The Variant spec requires the field ids in an object's header to be sorted by the
UTF-8 byte order of the field names, so a reader can binary-search them.
VariantBuilder sorted the fields — and Variant.getFieldByKey binary-searched them —
using String.compareTo, which orders by UTF-16 code units, not UTF-8 bytes.

The two orderings are identical for all field names in the Basic Multilingual Plane, but
they diverge for names containing supplementary-plane characters (U+10000 and above):
String.compareTo orders a leading high surrogate (0xD800–0xDBFF) before code points in
U+E000..U+FFFF, whereas UTF-8 byte order (and the spec) orders them after. Consequences:

  • An object parquet-java builds with such keys has field ids sorted in an order that
    violates the spec.
  • A spec-compliant reader (e.g. the Apache Arrow C++/Rust/Go Variant readers) binary-searching
    that object can fail to find fields.
  • Conversely, parquet-java's own binary search fails to find a supplementary-plane key in an
    object produced by a spec-compliant writer.

The bug only surfaces when an object both contains a supplementary-plane key and is large
enough to take the binary-search path, so it has gone unnoticed.

Component(s)

Core

Langage dominant
Java
Étoiles
3.1k
Forks
1.6k
Merge moyen
4 j 9 h
PR mergées (30 j)
32

Préparer son environnement

Nous n'avons pas encore vérifié les fichiers d'installation de ce projet. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de apache/parquet-java

Toutes les issues de apache/parquet-java

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.