Nous avons des fichiers à charger où les valeurs de champ sont séparées par le "séparateur d'unité", 0x1f
Conformément à la doc , si non imprimable, il doit être encodé en UTF-8.
À l'aide de la CLI bq , j'ai essayé de transmettre l'argument -F avec U + 001F en vain: Erreur BigQuery lors de l'opération de chargement: le délimiteur de champ doit être un caractère unique, trouvé: "U + 001F" .
Pas de chance non plus avec 0x1F ou `\ x1f, avec ou sans guillemets.
Le codage est-il erroné ou s'agit-il d'un bogue dans bq ou dans l'API?
MODIFIER :
Il s'avère qu'après avoir joué avec l'explorateur, c'est l'API qui n'aime pas le délimiteur.
Outre les délimiteurs imprimables, vous pouvez utiliser \ t mais aussi les \ b non documentés (retour arrière) et \ f (champ de formulaire) apparemment. < br>
tab peut être un caractère valide saisi par l'utilisateur dans un champ de texte de forme libre, nous devons donc utiliser un caractère de contrôle (après la conversion de 'unit sep')
EDIT2: :
Notez que \ f comme délimiteur fonctionne correctement via l'API directement mais pas via l'interface de ligne de commande bq ( Le délimiteur de champ doit être un seul caractère, trouvé: "\ f" ).
3 Réponses :
Vous avez trouvé une limitation de la CLI: elle n'acceptera pas tous les caractères que l'API accepterait.
Comme indiqué dans edit2, la solution est d'aller directement à l'API via des méthodes alternatives.
En fait, grâce au support GCP, cela fonctionne sous Linux:
--field_delimiter=\x1f
Sous Windows, ce n'est pas si simple de renvoyer / générer un caractère de contrôle sur la ligne de commande. Plus facile si vous utilisez PowerShell.
Je suis d'accord avec @Felipe , il s'agit actuellement d'une limitation dans l'outil bq CLI , mais qui peut facilement être corrigé dans le code source dans mon esprit avec un .decode ('utf-8') sur l'argument en octets, de sorte que
bq load --autodetect --field_delimiter=$(printf '\x1f') [DATASET].[TABLE] gs://[BUCKET]/simple.csv
puisse fonctionne tel quel sur n'importe quelle plateforme.
Clôture avec l'espoir que l ' équipe CLI de bq considérera l'amélioration.
+1. Cela m'a vraiment fait gagner des heures et des heures d'analyse. Nous utilisons un délimiteur supérieur à 127 dans le code ascii, nous avons donc dû comprendre comment l'encoder dans la commande bq load. Lorsque nous avons utilisé du code octal comme ('\ 0001'), nous avons reçu des erreurs se plaignant que bq ne traitera que le premier caractère comme délimiteur, mais votre message nous a aidé à charger correctement les données.
Salut, j'essaye de charger le fichier CSV qui contient / u0001, j'utilise ci-dessous la commande bq load --autodetect --field_delimiter = '/ u0001' dataset_name.table_name /home/directory/event_file.csv. Mais je reçois une erreur BigQuery lors de l'opération de chargement: le délimiteur de champ doit être un seul caractère, trouvé: "/ u0001".
Vous pouvez spécifier bq load --field_delimiter = $ '\ x01'