# \[X\] leere Felder im Export nicht leer

**URL:** https://community.mp3tag.de/t/x-leere-felder-im-export-nicht-leer/1271
**Category:** Fehlermeldungen
**Created:** [September 4, 2004, 9:25am UTC](https://community.mp3tag.de/t/x-leere-felder-im-export-nicht-leer/1271 "2004-09-04T09:25:27Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![BobbyGee](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/b/c89c15/32.png) [@BobbyGee](https://community.mp3tag.de/u/BobbyGee)
#### Post date: [September 4, 2004, 9:25am UTC](https://community.mp3tag.de/t/x-leere-felder-im-export-nicht-leer/1271/1 "2004-09-04T09:25:27Z")

</div>

leere benutzerdef. Spalten werden im Export-File als %Feld% gespeichert

V 2.24b

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [September 4, 2004, 11:24am UTC](https://community.mp3tag.de/t/x-leere-felder-im-export-nicht-leer/1271/2 "2004-09-04T11:24:53Z")

</div>

Das ist kein Bug und lässt sich leider nicht ändern.

Der Hintergrund: In der Exportkonfiguration können ja bereits Zeichenketten in der Form "%......%" auftreten, die dann mit ersetzt würden (also als Platzhalter mit nicht vorhandenem Inhalt gewertet würden).

Viele Grüße,  
~ Florian

---

<div class="post-metadata">

### Author: ![BobbyGee](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/b/c89c15/32.png) [@BobbyGee](https://community.mp3tag.de/u/BobbyGee)
#### Post date: [September 4, 2004, 12:23pm UTC](https://community.mp3tag.de/t/x-leere-felder-im-export-nicht-leer/1271/3 "2004-09-04T12:23:47Z")

</div>

Hallo Florian,

ich weiß nicht ob wir uns hier richtig verstanden haben - oder ich nur Deine Reply nicht richtig verstehe.  
Bei meinem Bug Report geht es NICHT darum, dass es so einen Feldnamen nicht gibt, den ich in meiner Export-Konfiguration stehen habe.  
Wenn mein benutzerdef. Feld im mp3 einen Wert hat, kommt dieser auch korrekt in der Export-Datei, wenn ein mp3 aber dieses Feld nicht hat, steht im Exportfile "%meinFeldname%".

Was ich halt "erwarte" (ich weiß, Mp3Tag ist Freeware/Donationware) ist, dass es beim Exportfile (wie auch möglichst an anderen Stellen des Programms) keine Unterschied macht, ob es ein Standardfeld ist oder ein benutzerdefiniertes.

Ciao, Robert

PS: Als ich damals in Deinen Newsletter von den benutzerdef. Feldern las, war mein erster Gedanke: "oh, da hat er sich aber einen großen Brocken Arbeit aufgehalst - und ob das wohl auf Anhieb funktioniert?"

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [September 4, 2004, 3:39pm UTC](https://community.mp3tag.de/t/x-leere-felder-im-export-nicht-leer/1271/4 "2004-09-04T15:39:16Z")

</div>

Hallo Robert,

das Deine Standard-Felder in der Exportkonfiguration ersetzt werden liegt einfach daran, dass sie wahrscheinlich ausgefüllt sind.

Ich mache eigentlich nur noch beim Auslesen des ID3v1-Tags und bei den Eingabefeldern für die Standard-Felder eine Unterscheidung zwischen Standard-Feldern und benutzerdefinierten bzw. erweiterten Tag-Feldern.

Ich möchte Dir das Problem kurz an Hand einer kleinen Beispielkonfiguration schildern:

> [@](#):
>
> [EXPORTRECORD]  
> RECORDLINE01=%\_filename\_ext%

Würden jetzt nach und nach alle "%...%"-Paare ausgewertet, würde als zweites der fett markierte **%20")'\>%** als Platzhalter hergenommen - leider ist dieses Tag-Feld nicht im Tag vorhanden und so wird daraus:

> [@](#):
>
> [EXPORTRECORD]  
> RECORDLINE01=\<a href='$replace("%\_filename\_ext%", " ", "\_filename\_ext%

Ich hoffe Du verstehst nun was ich meine.

Viele Grüße,  
~ Florian

---

<div class="post-metadata">

### Author: ![BobbyGee](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/b/c89c15/32.png) [@BobbyGee](https://community.mp3tag.de/u/BobbyGee)
#### Post date: [September 6, 2004, 10:22pm UTC](https://community.mp3tag.de/t/x-leere-felder-im-export-nicht-leer/1271/5 "2004-09-06T22:22:18Z")

</div>

> [@](#):
>
> das Deine Standard-Felder in der Exportkonfiguration ersetzt werden liegt einfach daran, dass sie wahrscheinlich ausgefüllt sind.

Hi Florian,

ok, wohl daran, dass es sie in jedem mp3-File gibt? ID3V1-Tags hab ich immer. Ein leerer Comment wird auch als Leerstring exportiert.

Mein Vorschlag zum Ersetzen der Platzhalter: nicht nur auf Vorhandensein des Felds im mp3-File checken (das wird man bei einem benutzer-/Mp3Tag-spezifischem Feld nicht durchgängig in allen MP3s vorfinden), sondern auch auf Vorhandensein in der Spaltenkonfiguration checken.  
Und wenn Letzteres, aber Feld nicht im File, dann Leerstring ausgeben.

Mfg Robert

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [September 7, 2004, 6:59am UTC](https://community.mp3tag.de/t/x-leere-felder-im-export-nicht-leer/1271/6 "2004-09-07T06:59:58Z")

</div>

Die Spalten haben ja so absolut nichts mit dem Export zu tun und ich werde mich hüten noch weitere solche "Hacks" einzubauen.

Im Moment werden "bekannte" Tag-Felder im Export ersetzt, wenn diese leer sein sollten. Diese bekannten Tag-Felder sind die, die in der Liste beim Anlegen eines neuen Tag-Felds im erweiterten Tag-Dialog angeboten werden. Um dort ein Feld einzutragen, musst Du einfach einmal ein solches Tag-Feld anlegen - es wird dann dieser Liste hinzugefügt.

Für alle anderen Felder könnte ich mir eine Funktion - z.B. _$meta(string)_ - vorstellen, die einen leeren String liefert, wenn das Argument immer noch ein Platzhalter ist (also nicht ausgewertet werden konnte).

Viele Grüße,  
~ Florian
